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

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 | » ]

Steve Freeman

Posts: 3
Nickname: smgfreeman
Registered: May, 2006

Re: Security and Agility: Never the Twain Shall Meet?

Posted: May 17, 2006 1:38 PM

(Hi Johann, I think we met at SPA)

I don't think the real issue is whether we write documents or not.

I suspect the difficulty for the IT Security community is that they're used to doing audits and writing policies, rather than being involved throughout the lifetime of the development. The tests usually describe what you want the system to do, whereas security is about what the system should not do. So the security specialist has to find a way to describe all the loopholes in some excutable way -- on a system that's changing beneath them.

I'm sure it can be done, since we managed to convert the testers, and the result is likely to be better than a hit-and-run audit. After all, real security is about constant monitoring and adjusting, which is what we do best. It's a shift for the security community, they're used to doing full system threat analysis. So we'll have to find some sympathetic (or desperate :-) experts and work things through with them. Anyone know of a good pilot project?

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Lakoff's Political Analysis Applies

Posted: May 17, 2006 1:54 PM

> > I also think it's important to stop believing in the
> > perfectly secure system, and the provably correct
> system,
> > etc. Reality is thorny. It leaps out of every box you
> > attempt to put it in.
>
> That, to me, hit's the nail on the head.

Some systems properties are perfectly proofable and every reasonable type system does already proof the absense of certain classes of bugs. If the primary goal is to minimize bugs it should be clear that certain techniques and formal modeling are superiour just like using Python/Ruby etc. support most flexibility and enable the quickest resonses to volatile user requirements.

A good showcase of a company that is engaged in producing secure software is presented in the following IEEE Spectrum article:

http://www.ecf.toronto.edu/~tsavor/IEEE_Spectrum_The_Exterminators.PDF

Without some reasonable examples the dicussion tends to decline to ideological statements, subjectivistic definitions and shallow reflections about liberal vs conservative attitudes.

Regards,
Kay

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Lakoff's Political Analysis Applies

Posted: May 17, 2006 1:55 PM

> > This is the main
> > problem with the waterfall model. It assumes
> everything
> > goes as planned.
>
> That view of the waterfall model is the one held only by
> people wishing to criticize it. In practice, the
> waterfall model is a series of 'waterfalls' where you
> don't pass from one stage to the next until you pass the
> exit tests for that stage, otherwise you loop back and
> repeat the process. Now there are very many problems with
> the waterfall model but nevertheless it's wrong t portray
> it as a one-way ticket.

Well, where I work, the schedule prescribes deployment immediately after the partner testing. This would be the only full system test. There is nothing in the schedule for dealing with the inevitable issues and the schedule is set in stone.

Carl Manaster

Posts: 24
Nickname: cmanaster
Registered: Jun, 2003

Re: Lakoff's Political Analysis Applies

Posted: May 17, 2006 1:57 PM

Hi, Michael,

Thanks for the reply.

> I've read a lot of Lakoff, including his non-political
> stuff. His metaphor has its uses, but like all
> generalizations, it's both true and not true depending on
> the particular case. That's what makes it so hard to talk
> about any of these things. The people who agree see more
> cases that match and the people who disagree see more
> cases that don't.

Well, that's true of some generalizations... ;-)

> I have another theory, though. I think that the
> distinction you're drawing is really orthogonal to
> politics. It's related to the degree to which people
> place their faith in logic. Hilbert's program collapsed
> nearly a century ago, but there are still people who feel
> that you can prove everything.. that the world should
> be/is an orderly place where all the rules apply.. and
> damn, it looked so good in the plan.. the plan was so good
> that it had to work.

I agree that non-Agile practices reflect a conviction that everything can be known (up front), leading to attempts to control outcomes through rigorous formal practice. And that Agile practices recognize the absurdity of trying to know everything, leading to attempts to create an environment - malleable code, safety nets, skills and attitudes - that prepare us for tomorrow's situation without dictating that situation. I agree that this is fundamental to the methodological split.

But I also think that this split maps quite well to the Strict Father / Nurturant Parent divide, and in trying to understand either side and the nature of the differences between them, there is a lot to be gained from the metaphor.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Lakoff's Political Analysis Applies

Posted: May 17, 2006 2:22 PM

> A good showcase of a company that is engaged in producing
> secure software is presented in the following IEEE
> Spectrum article:
>
> http://www.ecf.toronto.edu/~tsavor/IEEE_Spectrum_The_Exterm
> inators.PDF

Coincidentally, there is an article about langauges like Z in this month's Scientific American. I was planning on learning at least one of these in the near future.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Lakoff's Political Analysis Applies

Posted: May 17, 2006 6:10 PM

> Have you read any of Lakoff's work?

No, Women, Fire, and Dangerous things is on my pile of stuff to read. But it never gets closer to the top. Priorities.

> In the Strict Father family, the source of knowledge and
> power is vested in the Father. The nature of people is to
> be lazy and evil, so for their own good it is his duty to
> punish them and keep them on the straight and narrow, so
> that they will come, in time, to overcome their own
> laziness that they may one day break away and (in the case
> of sons) be Strict Fathers of their own family. Society
> is held together by such disciplined people.

Ah, I see, like FDR.

> In the Nurturant Parent family, knowledge is distributed.
> The Parent's role is to protect the children, share
> e his/her knowledge, give the children the opportunity to
> explore the world in safety and with encouragement. It is
> understood that children who grow up in safety and (within
> limits) freedom will themselves come to be nurturant, to
> care for everyone around them.

Ah, I see, like Reagan.

>
> Now, then - which of these best maps to Agile, and which
> to waterfall?

Neither. While Agile encourages shared knowledge and some freedom of exploration, it also demands strict discipline. I see both roles firmly ensconsed. By the same token waterfall encourages shared knowledge through disciplined documentation. Again. both roles.

> I seem to have pushed one of your buttons, Uncle Bob, and
> I'm not sorry - I think it's good to explore the issues
> that most provoke us. But I am fascinated. Thanks for
> the reply.

Oh, yes, this is one of my hot buttons. You may, or may not know of my history of debates on comp.lang.c++ and comp.object. Those debates were often against someone who continuously suggested that my views about C++ were right wing regressive reactionary dead-hand-of-the-past cowboy hacker stuff, whereas his ideas were progressive, enlivening, powerful, beautiful, welcoming, encouraging, etc. He was for waterfall.

Carl Manaster

Posts: 24
Nickname: cmanaster
Registered: Jun, 2003

Re: Lakoff's Political Analysis Applies

Posted: May 17, 2006 6:42 PM

Hi, Uncle Bob,

> Ah, I see, like FDR.
> Ah, I see, like Reagan.

Ummmm, no. :-)

> Oh, yes, this is one of my hot buttons. You may, or may
> not know of my history of debates on comp.lang.c++ and
> comp.object. Those debates were often against someone who
> continuously suggested that my views about C++ were right
> wing regressive reactionary dead-hand-of-the-past cowboy
> hacker stuff, whereas his ideas were progressive,
> enlivening, powerful, beautiful, welcoming, encouraging,
> etc. He was for waterfall.

Nope; never saw them.

OK, then. Quoting an obscure document I found somewhere on the internets:

> Individuals and interactions over process and tools.
Nurturant Parent, or Strict Father?

>Working software over comprehensive documentation
Nurturant Parent, or Strict Father?

> Customer collaboration over contract negotiation
Nurturant Parent, or Strict Father?

> Responding to change over following a plan
Nurturant Parent, or Strict Father?

Notice I'm not asking, "conservative or liberal?" I think the conservative/liberal metaphor might have some merit, but it's not the one I'm exploring, and Lakoff's metaphor is effective (for politics) probably in part because the family model is more fundamental.

Certainly discipline is a part of Agile; certainly, too, there are aspects of nurturing. Which are prevalent, when looked at in comparison to "waterfall" as we are here using the term? For me, it's a very easy answer, and I think - though I have been careful not to state it thus far in this conversation - that you know what my answer is. That is evidence, to me, that the metaphor is effective and may have some explanatory value.

Thanks for a stimulating discussion.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Lakoff's Political Analysis Applies

Posted: May 18, 2006 6:53 AM

> OK, then. Quoting an obscure document I found somewhere on
> the internets:
>
> > Individuals and interactions over process and tools.
> Nurturant Parent, or Strict Father?

Neither. The "nurturant parent" might easily advise the "nurtured child" to "look both ways before crossing the street" rather than to interact with the individual driving the car. By the same token the Strict Father might very well advise a young man to talk to his teachers about homework and extra-credit rather than simply copying down the assignments from the board and reading the book.

I'm not going to reply point by point to the other manifesto items. The same points can be made.

> Notice I'm not asking, "conservative or liberal?" I think
> the conservative/liberal metaphor might have some merit,
> but it's not the one I'm exploring, and Lakoff's metaphor
> is effective (for politics) probably in part because the
> family model is more fundamental.

I don't agree that the difference between conservativism and liberalism are somehow aligned to some kind of parenting model.

> Certainly discipline is a part of Agile; certainly, too,
> there are aspects of nurturing. Which are prevalent, when
> looked at in comparison to "waterfall" as we are here
> using the term? For me, it's a very easy answer, and I
> think - though I have been careful not to state it thus
> far in this conversation - that you know what my answer
> is. That is evidence, to me, that the metaphor is
> effective and may have some explanatory value.

I don't think it is an easy answer. Indeed, I don't think the question has a meaninful answer at all. Oh, I think some of the literature has a nurturing bias. Some of it is downrignt bleedin-heart. "Don't worry little programmers, MUM will protect you from the big bad managers." However, the reality is that Agile Methods are methods to get software done for profit, and have nothing to do with warm fuzzy mom's and strict dads. They have to do with making money.

Johan Peeters

Posts: 30
Nickname: yo
Registered: Nov, 2003

Re: Lakoff's Political Analysis Applies

Posted: May 18, 2006 8:06 AM

The jealous versus loving and trusting spouse seem to me more apt than the parent analogy.

Johan Peeters

Posts: 30
Nickname: yo
Registered: Nov, 2003

Re: Security and Agility: Never the Twain Shall Meet?

Posted: May 18, 2006 8:15 AM

> (Hi Johann, I think we met at SPA)

yes we did

> I don't think the real issue is whether we write documents
> or not.

I agree, but at the moment documents monopolize the bandwidth. So they are a real problem.

> I suspect the difficulty for the IT Security community is
> that they're used to doing audits and writing policies,
> rather than being involved throughout the lifetime of the
> development. The tests usually describe what you want the
> system to do, whereas security is about what the system
> should not do. So the security specialist has to
> find a way to describe all the loopholes in some excutable
> way -- on a system that's changing beneath them.

Yes. I have been wondering whether static checkers checking invariants could do for security what xUnit has done for functional testing. Just a thought.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Automated Tests

Posted: May 18, 2006 7:30 PM

> It is important to remember that requirements in Agile
> Methods are intensely formal. Every feature is documented
> as a suit of automated acceptance tests. The design of
> every module is specified as a suite of unit tests. These
> tests are written before the code that makes them pass.
> It is difficult to be more formal than that.

Requirements are supposed to be in the language of the customer. So unless your customer is a programmer, automated tests are not requirements.

Likewise, acceptance tests are ideally written by the customer, and at the very least should be well understood by the customer. So unless your customer is a programmer, acceptance tests cannot be automated.

Please note that I'm not bashing automated testing. I fully believe in it. However, of think redefining standard industry terms in ways contrary to their core meaning is extremely counter productive, and even dishonest.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Automated Tests

Posted: May 18, 2006 9:31 PM

> > It is important to remember that requirements in Agile
> > Methods are intensely formal. Every feature is
> documented
> > as a suit of automated acceptance tests. The design of
> > every module is specified as a suite of unit tests.
> These
> > tests are written before the code that makes them pass.
> > It is difficult to be more formal than that.
>
> Requirements are supposed to be in the language of the
> customer. So unless your customer is a programmer,
> automated tests are not requirements.
>
> Likewise, acceptance tests are ideally written by the
> customer, and at the very least should be well understood
> by the customer. So unless your customer is a programmer,
> acceptance tests cannot be automated.
>
> Please note that I'm not bashing automated testing. I
> fully believe in it. However, of think redefining
> standard industry terms in ways contrary to their core
> meaning is extremely counter productive, and even
> dishonest.

It sounds like you haven't seen FIT or Fitnesse yet. Automated acceptance tests can be written by customers. They can write them in their own language, with their own terminology in Word, Excel.. anything that can be saved as HTML.

These tests are written by customers in the language of the customer and enabled by some bridging code written by the programmers. When you use these tools, there is no difference between requirements and tests.

The industry terms are being redefined because we have better tools now, and practice is advancing.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Security and Agility: Never the Twain Shall Meet?

Posted: May 19, 2006 3:52 AM

> > (Hi Johann, I think we met at SPA)
>
> yes we did
>
> > I don't think the real issue is whether we write
> documents
> > or not.
>
> I agree, but at the moment documents monopolize the
> bandwidth. So they are a real problem.
>
> > I suspect the difficulty for the IT Security community
> is
> > that they're used to doing audits and writing policies,
> > rather than being involved throughout the lifetime of
> the
> > development. The tests usually describe what you want
> the
> > system to do, whereas security is about what the system
> > should not do. So the security specialist has to
> > find a way to describe all the loopholes in some
> excutable
> > way -- on a system that's changing beneath them.
>
> Yes. I have been wondering whether static checkers
> checking invariants could do for security what xUnit has
> done for functional testing. Just a thought.

When I think about automatical proof-techniques systems like HOL come to my mind:

http://www.cl.cam.ac.uk/Research/HVG/HOL/

I'm not sure if such like were discussed on OWASP ( maybe but you can tell us a bit more )? I don't see a principle reason why those shall not be embraced by agile thinkers although they might not attract masses of programmers just like Java or scripting languages. But this is more an educational problem than one of the SW development process that is selected.

Regards,
Kay

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Automated Tests

Posted: May 19, 2006 6:52 AM

> It sounds like you haven't seen FIT or Fitnesse yet.
> Automated acceptance tests can be written by customers.
> . They can write them in their own language, with their
> own terminology in Word, Excel.. anything that can be
> saved as HTML.
>
> These tests are written by customers in the language of
> the customer and enabled by some bridging code written by
> the programmers. When you use these tools, there is no
> difference between requirements and tests.
>
> The industry terms are being redefined because we have
> better tools now, and practice is advancing.

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.

Steven Mak

Posts: 1
Nickname: tcmak
Registered: May, 2006

Re: Security and Agility: Never the Twain Shall Meet?

Posted: May 20, 2006 8:45 AM

A common and yet BIG misconception about Agile Software Development is that ASD were against the production of formal documentaion. And this is simply WRONG.

There is no such rule as to oppose the production of any document.

The important point for being agile is to produce what is needed, and produce what is just needed, no more and no less.

To explain further, if you were asking an Agile developer to produce more documentation than it's needed by the users, NO. But doing documentation that fits the need of users, YES.

Apart from generating documentations from codes or test suites, if the end users find the neccessity for producing any documents, these would be prioritised like other tasks, and work in iterations to be discussed among developers (e.g. how often they can update it) and users (e.g. how frequent it should be updated). This produces a more realistic estimation of the effort required by developers and what can be expected by the users.

It's also about communication and trust. Users do their best in voicing their needs and developers do their best to produce the deliverables (codes, diagrams, documents, ... ) and certainly this includes doing their best in not producing any security problems. This is the same no matter applying Agile principles or not.

If the users find the need of bringing a security expert to the scene, just do so. Agile principles are about how to deliver better and be realistic in delivering them. Tasks are prioritised as they were. There is no conflict at all.

It's not hindering any developers' job as tasks are arranged in each iteration. If such documentation takes a whole iteration to complete, and users and developers agreed that they would be delivering the documentation in the comming iteration, then developers would spend the iteration to produce the document then.

It's weird and inappropriate for saying certain development methodologies being lack of security concerns. Can anyone tell me if Waterfall addresses any of security concerns? or is there any specific requirements in CMMI addressing security issues?

> 
> I led a discussion at the Belgian <a
> href="http://owasp.org">OWASP</a> chapter meeting last
> week on whether agile processes are capable of producing
> secure software. Received wisdom in the security community
> has it that they cannot. Security professionals object to
> the lack of formal documentation. They argue that without
> formal specifications, there can be no credible assurance
> argument. The agile community, for their part, has
> blithely ignored security concerns.
> 
> 
> I do not believe formality is the issue. Formal
> specifications are not a virtue in themselves. They are
> only useful to the extent that they aid communication.
> Often the demands security officers put on developers get
> in the way of communication, rather than furthering it.
> Developers find them overly bureaucratic and a hindrance
> to getting their job done.
> 
> 
> To many present, agile development was new. Initially, the
> reaction was very cautious, especially from the security
> professionals present. The ice broke when one of them
> observed that while defending against attacks, the ICT
> security profession tends to work in a very agile way: do,
> observe, steer, do - iterate as quickly as possible.
> 
> 
> So there is an agile mindset on the development side, an
> agile mindset on the security side, but what passes in
> between is distinctly non-agile. It does not have to be
> like that. We have to get rid of the wall between the
> two.
>

Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic