Agile development methodologies might be the new fad in software design, but how much emphasis is there on secure code? Australian .NET developer and consultant at Readify, Rocky Heckman, reveals some concerns of agile development methodologies.
Agile development methodologies might be the new fad in software design, but how much emphasis is there on secure code? Australian .NET developer and consultant at Readify, Rocky Heckman, reveals some concerns of agile development methodologies.
That post smells like FUD to me.
Speaking about Agile Development Methodologies (ADM), he says:
“Most ADMs don’t allow for security advisors reviewing designs and code.”
“ADMs don’t lend themselves well to ‘taking time’ for anything.”
“They also don’t allow for an independent security advisor to review the designs for logical security flaws or flaws in proposed protocols.”
“security takes time. It’s not hard, it just takes time, and that is time that ADMs don’t’ want to spend.”
I don’t see any kind of basis for any of those assertions.
I don’t see any kind of basis for any of those assertions.
His assertions seem to be based on the list of Agile Principles. Here it is, summarized:
1) Do as little work as possible.
2) Code in teams.
3) Deliver early and often.
It doesn’t say anything about security or code inspections.
Secure code development methodologies might be the new fad in software design, but how much emphasis is there on business agility?
Australian .NET developer and consultant at Agilify, Rockster Redvines, reveals some concerns of secure development methodologies.
Is anyone other than the agile coaches and book writers making any money with agile?
<ADM weenie>
most successful projects use ADMs whether they know it or not.
Is anyone other than the agile coaches and book writers making any money with agile?
Does it matter? It’s not like any “methodology” really works in software. There is no method to the madness, only madness in the methods.
No there are methodologies that work, they just don’t speed it up and they cost a lot. That’s the backlash against the CMM-SW; you’ll be right on time every time, they just won’t like how long that takes.
Bottom line, if you want really really good software that is complex and works really well, then it takes a long time to make it.
Did you forget about testing. Agile software puts major emphasis on unit testing code thoroughly. Unittests can be put to use creating secure code. Create security unittests!! In this respect agile can be more secure than standard, design by the Requirements Doc development.
Agile is great, maybe even critical for small to medium sized businesses with a small internal dev staff to develop apps for use in house. It probably has other uses too. In house app dev often is plauged by changing/unclear requirements and the resources aren’t there to spend big $$$ up front. Also these users usually need something up and going ASAP. Agile really fits the bill here.
Shouldn’t the aspects of developing secure applications be dealt with in the requirements and specifications? Shouldn’t agile development methods be merely the means of achieving the requirements and specifications?
Certainly security should be a larger concern in larger development projects, developers and managers should be better educated in these manners.
But how specifically should methodologies such as extreme programming ‘call out’ security issues?
I’m not an industry leader, a community contributor, or even somebody my neighbors know very well, but here’s my opinion.
The most beneficial thing brought about by the Agile methodoly is book sales.
Seriously, I think that some concepts (like pair programming) are a good idea, but other than that…
Every project I’ve been involved with that used the Agile methodologies ended up just like projects that didn’t use the Agile methodologies. They shipped, and in order to get them out the door we all had to stay overtime and pizza was brought in.
No difference in shipping schedules. No difference in quality. No difference in the time I had to spend staying late. No difference in the food that was brought in.
I’ve used “agile” techniques for a few years now, since a company I worked for began to adopt XP practices. Agile development has become a catch-all term for various techniques, some of which might not be an ideal choice for developing rock-solid security.
Having said that, the heavy use of testing and the “many eyes” from both shared code and XP’s adoption of paired programming certainly helps with developing solid code with fewer chances of exposing opportunities for exploits. If you need solid security, add in the required checks that you would on a traditional “waterfall” developed project.
There seems to be a lot of FUD floating around about agile development. Sure it has problems, no system is foolproof, sure there are areas where it isn’t ideal – but so-called traditional methods have their own set of problems too. Use the right tool/process for the job.
>His assertions seem to be based on the list of Agile
>Principles. Here it is, summarized:
>
>1) Do as little work as possible.
>2) Code in teams.
>3) Deliver early and often.
>It doesn’t say anything about security or code
>inspections.
First, true, it also doesn’t say in there that a customer has to be able to use the software or that the developer must show up wearing pants to work. My point is, there’s a lot in this grievously-condensed list of principles (and it is, at best, grievously-condensed). Security is a requirement that is easily expressed in business requirements, be they in the form of state diagrams, requirements documents or user stories.
Second, a statement to lump all agile methodologies together and pass down a ruling on their collective impact on security should go down in history as one of the great blanket statements of all times. Nothing could be more fundamentally flawed and lacking in understanding of the variety and nature of various agile methodologies.
Third, this list does not begin to sum up the principles and values of THE MOST agile methodology.
Fourth (and I think this is one of the most misunderstood concepts behind ANY methodology), no methodology should be taken out the box and applied wholesale without considerable consideration examining its principles and the methodological requirements of your product. Any and all methodologies should be tooled and tailored to fit a teams needs and if that includes a security review facet, so be it.
This article either expresses the authors ignorance or real development or is FUD.
In my experience, improved quality is the key thing to come out of it (other than the book sales, yes). Things like pair-programming and test-driven development have a fair amount of up-front cost, but they do result in better code – both objectively as measured by defects found, and subjectively by anyone making subsequent changes.
As to why security doesn’t appear in books on agile development, I’d not expect it to – it’s something developers have to be aware of, but has nothing to do with the methodology used to develop it.
Yes Agile methods do a lot of testing, and the quality is fairly high. Like the article says though it’s quality centered around functionality. Security does have to appear in books but it does have to appear in the process. The reason is, the developers aren’t equiped to handle it completely on their own.
Putting all the responsibility onto a developer (or pair of them) is a good way to get things overlooked. Developers are getting better but still aren’t as well trained in security as they should be. If you are writing the tests, the code and doing the review there’s an inbuilt conflict of interest there. You are too close to the source to be objective in your reviews. You can’t leave it all up to the developers.
We’ve used what appears to be an “agile development process” in the airline industry for years when doing internal aplications programming. The process concentrates on using a small number of expert programmers (folks who know a lot about both the business rules and the technical environment) to address issues and make code changes quickly but thoroughly, and a formal review process is in place (at least in our case), mainly upfront-design reviews by peers and also peer code sanity checks before any code is allowed even into the test environment as part of the monthly GEN (full environment recompile) cycle.
Security isn’t as much of an issue in the mainframe environment we’re coding in simply because most security concerns are handled by either the OS itself (Unisys OS2200) or the transaction environment in which the applications software operates (Unisys HVTIP) — such programs do not (and cannot) perform dynamic memory allocation or deallocation on their own (a program module is assigned a fixed amount of memory when it’s compiled/linked, and the OS dynamically swaps out memory pages as needed), and both code and data banks are isolated by the system and marked in such a way that data cannot be executed (and code cannot be referenced at all) without the machine generating a hardware page fault.
When one has a large number of programmers with extensive experience and a quickly changing application environment, I think “agile programming” is a far more intuitive approach to effective software development than many of the top-down methodogies I’ve seen espoused by industry experts — while such waterall methods tend to work well for software houses developing code for external customers, a business writing code for its own internal consumption doesn’t always have the same luxury of time…
A suggestion: never write about something you don’t know (and even more important you’ve never tried!). Agility is more attitude than process, more environment than
methodology.
The “core” practices not only aren’t written in the stone but *have* to be adapted to your own reality and need. We can say that if you apply ADM by the book you didn’t undertand the book.
Speaking about books: there are so many info on the net that you don’t really need to buy a book to learn and start improving so the FUD about books writers is a nonsense. I’m an agile developer and manager since 2001 and I have just one agile book.
It seems to me that since most “agile” methods utilize some form of “test first” or “code to the test” mentality, if you want a secure application have security tests first. Then the code will be written to meet those security needs. Viola, problem solved.
agile methods:
“measure once, cut many times”
top-heavy methods:
“measure many times, maybe never cut”
old school methods (long since forgetten):
“measure twice, cut once”