Agile is nothing new, it is just a new word for an age old way to do things. And what it has to do with security - security is much, much more than just some word, technology, method, whatever. And if the "security specialist" means just IT - a lost case already. Of course application and system security are important but saying that a (computer) development method solves security problems is, in my mind, a little (or more than a little) dangerous, someone might even believe that?

Don't get me wrong, I love agile, it brings the old teamwork back which was lost to (wrongly understood) waterfall (another story) , but saying it replaces education, thinking, planning, designing, checking, testing, etc is just a little too much marketing to my taste.

"Is it possible to build something secure without the traditional traceability the security folks like?"

Seems like PGP2 to build something secure enough, not to be traditionally traceable. Of course, what is not liked about it, is that then the traditional head role chiefs are no longer in head chief roles..... but that is their problem/busted ego trip to deal with.

... which development framework you use. If you want a secure product then you need:

a) security requirements included in the specification;

b) security awareness in developers; and

c) security assessment tools for the QA function.

Without these three fundamentals, you will be (at best) reduced to finding and fixing security flaws in the delivered product, which is both very expensive and not very effective.

The problem that agile, or iterative, development solves is validation of design quality. Planning big is known for notoriously missing small details, and this is exactly where security vulnerabilities are. What iterative development does well is to validate design, stage by stage (or feature by feature), by the quality of the code implementing it. It is a rule that I learned that poor design always yields poor code, yet no one can prepare perfect design upfront. In iterative development there is a feedback loop from code to design (which is not possible in traditional waterfall model) which allows for design to mature before product is completed, as well as to avoid writing unsecure code by refining design. Two kinds of people (both difficult to come by) are required : coders good enough to recognize and oppose bad code as well as designers humble enough to take and act on input received from coders. In agile these two roles are often combined (coders are also designers), and it works rather well, but is not required.

I almost entirely agree*, Bronek Kozicki. Very Clearly and Succinctly Put.

* In Real Virtual Agility would both roles necessarily/ideally be combined to Speed XXXXPress Delivery ...... although with Time not a Factor, neither would be Speed.

I Imagine that those able to wear more than One Hat at the Same Time and to combine both Roles Excellently in Excellence in A.N.Other Role would be difficult enough to come by, but they may be more than enabled to reveal themselves.

Agile is inherently more secure for two reasons.

Firstly the paired coding/code review mind set meansd that poor coding is caught in hte bud. I consider myself a good and concientious coder but I always code better when I know someone is looking, and it sometimes takes two to spot a potential buffer overflow ro SQL injection ulnerability.

Secondly, Agile, is built around feedback. Anyone in hte project can bring up an issue and the iterative cycle is geared up to deal with this. This means anyone can bring up a "what if the guy goes home without logging off?" type issues, and they get fed back into the design process with a minimum fuss.

In more formal methodologies (e.g. the methodology formerly known as Prince) its a pain in the arse to bring up design issues once a phase has been signed off; so people just sit in the corner and bight their tongues when thye see an obvious security hole.

I'm sorry, but I don't believe that statement to be even close to being accurate.

Having more people to check a piece of code makes sense; and the more people working on it, the greater chance of finding mistakes; but only if all of the people working on it understand the actual issues. If they don't, then it doesn't matter in the slightest how many people work on a particular piece of code.

Agile and waterfall have strengths and weaknesses as highlighted by previous comments.

With either method more emphasis has to be placed on reuse of known good coding patterns, and architectures (with my personal bias preferably Open Source).

Reuse improves quality through iteration, many eyes, and much testing. Given the time available it allows the coder to concentrate more on the overall design, and new code they are writing, reduces the chances of introducing new errors.

Focusing on Security Architecture patterns and controls can also help, www.opensecurity.architecture.org is a good place to start for this topic.

"I'm sorry, but I don't believe that statement to be even close to being accurate." .... By Tony Posted Wednesday 28th May 2008 11:52 GMT

How very bizarre whenever you are so agile into the debating fray, Tony, even should you not fully understand James Anderson and the methodology formerly known as Prince. IT can easily be XXXXPlaned to you at Virtual TelePortation Levels of Artificial Intelligence.

Hmmmm - that's easy for you to say.

Oh my god I think I am communicating with a Martian.

Somebody pass the dried frog pills.

@Tony.

I totally agree that having two morons reveiw code is no better than one moron revewing code. And the need for a "security" culture in a team.

However traditional development environments tend to have a "security by decree" culture which does not work. An intellegent programer looking at an application and thinking "how would I break this" is the single most useful security tool available.

"I'm sorry, but I don't believe that statement to be even close to being accurate."

I'm sorry, but I think you missed the point. It is not how many people see the code, as 2 is often good enough (original author + reviewer), and you need to have at least 2 people in your team who understand the code for other reasons (think business continuity etc.).

The added value that agile provides is feedback. Without feedback there is no way to refine the design, which means that original flaws will cripple the system if they go undetected early. Agile removes this constraint - design flaws can be fixed as they reported, and (as code quality follows design quality) they are often diagnosed by code smells, during review phase. Waterfall model is, on the other hand, based on unrealistic assumption that design can be perfected without feedback.

Which model can produce safer code in your opinion? The one based on unrealistic assumption, or then one based on quality control?

"Hmmmm - that's easy for you to say." .... By Tony Posted Wednesday 28th May 2008 17:48 GMT

Yes, but/and it is also easily written down for All to Follow in Plain Text at their Leisure/as Needs and/or Curiosity Leads.

What one discovers in Virtualisation is that Critical InfraStructure Systems are Default FailSafed against Intrusion and Proxy MalManagement by Virtue of the Simple Transparent Complexity of the Necessary CodeXXXXs which Drive the Artificially Created Environment...... which is the VREnvironment Creating Pukka Pure Code to Driver and Create New Codes Creating the Virtualised Environment ...... which is Quantum, being as IT is both a Working Parallel for the NeuReal World [for of course the Perception of Reality is bound to change whenever Systems are Virtualised into the Cloud Space/CyberSpaces] to be Mirrored and Managed from Dynamically Linked Resources plying/betatesting FutureWare for Systems Replacements/Patching/Overhaul.

Logically eventually will the myriad competing Systems Dynamically Link Resources to Provide Selfless Service and Increased Benefit rather than Selfish Competitive Advantage and Profit which is Stored/Banked for Third Party Private Play with First Party Public Assets.

That will require the Third Party Private Players to redefine their Role should Assets be moved into Selfless Provision of Service Accounts in AI Virtualised Space beyond their Jurisdiction and Earthly Jurisprudence...... which is a logical dDeeper Progression/Quantum Leap Evolution of the Off-Shore Tax-Free Safe Haven Gravy Train although most probably Beta described as AI Virtually Hedged Futures and Derivative Mutual Fund ur2die4 ....... for it is certainly Floated/Launched as nothing less than that, and it is of course, so much more than that.

... is just a straw man. I think even NASA prototypes its stuff iteratively to check it's fit for purpose.

As is the corresponding image of the Agile process as being of a couple of guys at a screen saying, "OK, what shall we code today ?".

Think, "small design, fitting into bigger design" - with increasing levels of abstraction !

I think that I'm setting myself up to be flamed....

I accept that having a method of control (when used properly) is better than not having one. However...

The point that I wanted to make is that as far as security goes, it is not appropriate to say that one system or method is better than another without a full definition of the specifics.

To use an analogy - years ago, the law changed to enforce the fitting and wearing of seat belts in a car. At the beginning, people were regularly told by salesmen that a given car was more secure because it had the seat belts. In reality, that was only true for the people inside, if the seat belts were actually used. If not, they were of no value and the security of the car was no greater than any other. (it was not any more secure for rear seat passengers until the law changed again, and it was no safer for anyone outside of the car).

Equally, there are many urban legends (and a few factual stories) about people that suffered greater injury from the seat belt than would have been the case if they had not be using it. Presumably because the seatbelt was designed for an "average" person, and the person using it was outside of the sepcified range.

(And of course, we could add to that, the fitting of seatbelts does not prevent someone from breaking into a car so in fact it doesn't increase "security".)

When describing security, it is necessary to explain what is being secured, against what and how. The only truly inherently secure system is one that never actually gets built. (and I'm not even sure about that!)

"Using test-driven development is excellent for security. By defining a suite of security test cases before development starts, the team is much more likely to include the right controls and use them properly."

Great concept in theory, but really hard to implement in practice: how to develop "negative" tests needed in security? Can you really test that your code is not exploitable?

Of course, you can implement obvious tests, like "if you enter a wrong username/password the access is denied" or even some elementary tests against XSS and SQL Injection, but how to test crypto-strength, session management, denial of service, race conditions, just to name a few?