commentary I was at the Ruxcon Security Conference in Sydney a while ago and some of the conversations were around Agile Development Methodologies (ADMs). At the conference I overheard a discussion where one of the delegates said, -We need to target -ReallyBig" Corp. for penetration testing and security consulting because they just adopted Extreme Programming as their development methodology so they'll be easy targets". It started me wondering on just what ADMs have sacrificed for rapid development and what impression this has left in people's minds.
The general consensus was that ADMs certainly don't do threat modelling, or security focused code reviews. Even with Test Driven Development (TDD) the focus is on creating tests that prove functionality and exercise the class. While this is a good technique and does well with code coverage, they don't mention testing for security. The tests focus on high quality code from the perspective of the features and reliable repeatability of operations. There is little or no mention of penetration style testing or threat modelling.
Even with Pair Programming the onus for ensuring that the application and code are secure lies entirely with the developers writing it. Most ADMs don't allow for security advisors reviewing designs and code. This is how we got into trouble in the first place. Quite simply developers still aren't as well versed in secure coding as they should be. It's critical to take the time to focus on the security of the applications. ADMs don't lend themselves well to 'taking time' for anything.
While there is time allocated to putting together a design for the product, these methodologies do not propose security reviews of those designs. There is no threat modelling or attack tree development. They also don't allow for an independent security advisor to review the designs for logical security flaws or flaws in proposed protocols.
Isn't it a little worrying that you can pick up almost any book on ADMs and not find one mention of security in it? Security has to start with the Software/System Development Life Cycle (SDLC), and the design. If you are designing on the fly with a focus to just getting the functionality out the door for this push or sprint you aren't thinking about securing your product. The design won't take into account the bigger picture and the security impacts of this piece of work. ADMs are great at getting the right product to the customer in a timely fashion. They produce systems that make happy customers within short timeframes.
Where the problem arises is that security takes time. It's not hard, it just takes time, and that is time that ADMs don't' want to spend. The focus is getting the product to the customer. The quality of the product is in the functionality and meeting the customer's needs. They are very good at that, but it is often at the expense of thorough security.
If security reviews, and attack/defence patterns can be applied easily, in more of a template style, they wouldn't be as much of a burden on the timeline of a project. A set of common attack patterns and the recommended defences would be easy to follow and therefore more palatable by the ADM developers because they don't have to spend a lot of time worrying about security. They can get back to what they do best, coding the features.
How do we secure ADMs without sacrificing what they do well and preventing the products from being labelled as soft targets? This post has been fairly pointed because I would like to generate some discussion on this and get a feel for people's positions around this topic. Please express your opinions but keep it civil!
Rocky is a .NET developer/consultant specialising in software design and secure software development. He is currently working for Readify. He can be contacted from his Blog at http://www.rockyh.net.
1
Andrew Hudson - 09/08/05
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?
» Report offensive content
2
Curt Hibbs - 09/08/05
The whole premise of this post is a non-sequiter. Security consciousness and agile development are orthogonal concepts. Security consciousness is complete a function of the development team regardless of whether or not they use agile development.
» Report offensive content
3
Tobias - 10/08/05
Take a look at the scrumdevelopment group responses to this article at
http://groups.yahoo.com/group/scrumdevelopment/message/8879
http://groups.yahoo.com/group/scrumdevelopment/message/8886
http://groups.yahoo.com/group/scrumdevelopment/message/8887
and possibly others by the time you read this...
» Report offensive content
4
Jeff - 10/08/05
One might ask the same question of RUP or any other process. Or one might ask why agile doesn't directly address usability, or supportability, or any other (non-functional) "URPS" requirements.
Or one might just figure that there's nothing in agile (or RUP) that says you *can't* emphasize security, if that is indeed important to your development efforts. It's just another requirement.
» Report offensive content
5
Jeff - 10/08/05
One might ask the same question of RUP or any other process. Or one might ask why agile doesn't directly address usability, or supportability, or any other (non-functional) "URPS" requirements.
Or one might just figure that there's nothing in agile (or RUP) that says you *can't* emphasize security, if that is indeed important to your development efforts. It's just another requirement.
» Report offensive content
6
Ken Boucher - 10/08/05
If security is a requirement, what part of ADM suggests not meeting the requirements. "One Room" (part of XP) clearly dictates that all the members of the team should be in the same room. Since security is a requirement, the person who needs to insure the code is secure should be in that room working with and educating the developers.
This is so basic that I can't see why it needed to be said, but apparently if it isn't explicitly stated, there are people who don't think how the processes should apply to them.
» Report offensive content
7
nev - 10/08/05
Interesting article that the agile community should take on board rather than just shoot it down.
Security isn't just another requirement, it should be the most important factor for your applications.
» Report offensive content
8
William Pietri - 10/08/05
Good Questions, But Too Much Supposition
In your article, you write, "Where the problem arises is that security takes time. It's not hard, it just takes time, and that is time that ADMs don’t' want to spend."
People make the same argument about, among other things, software architecture and user interface design. The theory seems to be that if there isn't a checklist item telling developers to do it, or some special phase for the work, developers will just leave it out.
In my experience with agile teams, this is bunk. Certainly, if neither the product manager nor any of the developers think about security (or architecture, or usability) then the product will reflect that. But that's true with any process. On an Extreme Programming team, all it takes is one person in the room to ask the important questions and employ the right techniques. As with design, security is too important to confine to a single phase: you should pay attention to it all the time.
"They are very good at that, but it is often at the expense of thorough security."
Do you have any evidence of this? I've never heard of that with an XP team, and I've talked to a lot of them.
Further, you completely ignore the role of bugs in security breaches. A large portion of security holes are, plain and simple, due to poor coding. Pair programming, unit testing, acceptance testing, frequent iterations, and small releases all mean more eyes, more testing, and more real-world use with the core code. Refactoring, by removing duplication and tightening architecture, removes places bugs can hide. Many XP teams have rates below one bug per developer month, radically better than industry norms.
"[These methodologies] also don’t allow for an independent security advisor to review the designs for logical security flaws or flaws in proposed protocols."
This is patently false. The whole point to agile development methods is agility. An advisor can certainly review protocols (or anything else) at any point, and any requests for changes should be cheerfully accommodated.
Agile methods have further advantages: By producing working software early in the project and regularly thereafter, security auditors can check not just documents, but actual implementations. By adding to the automated test suite, a security reviewer can prevent regressions. Given the highly collaborative environment of processes like Extreme Programming, knowledge from the external security resource will diffuse through the team quickly and reliably. Thanks to the emphasis on code and design quality, the system will be easier to review. And if a hole is discovered in shipping software, the team is already accustomed to doing high-quality work with a very quick turnaround.
» Report offensive content
9
Daniel Hernandez - 11/08/05
Security within ADM may be problematic for organizations that don't have a good awareness of security standards and practices or have it "baked into" their culture. Many companies are used to security requirements and security testing being called out in their SDLC or at a given point in time. Generally speaking, security is independent of a given metholodology, yet important design decisions need to be made earlier rather than later because one can't easily go back and fix it. ADMs often tackle the hard problems first, but security also needs to be defined early too.
With small, core teams under an ADM, the risk of neglecting security, or various quality/performance requirements, is naturally there; therefore, it's important to have good security practices and secure coding guidelines and ****urance that they'll be followed.
» Report offensive content
10
Daniel Hernandez - 11/08/05
Security within ADM may be problematic for organizations that don't have a good awareness of security standards and practices or have it "baked into" their culture. Many companies are used to security requirements and security testing being called out in their SDLC or at a given point in time. Generally speaking, security is independent of a given metholodology, yet important design decisions need to be made earlier rather than later because one can't easily go back and fix it. ADMs often tackle the hard problems first, but security also needs to be defined early too.
With small, core teams under an ADM, the risk of neglecting security, or various quality/performance requirements, is naturally there; therefore, it's important to have good security practices and secure coding guidelines and ****urance that they'll be followed.
» Report offensive content
11
Jim Hyslop - 14/08/05
From the article:
"Isn't it a little worrying that you can pick up almost any book on ADMs and not find one mention of security in it?"
Well, it's been many a year since I've opened any books on traditional (e.g. waterfall) DMs, but I don't recall seeing any mention of security in them. Do current books on non-agile development methodologies mention security at all? If not, then the quoted statement is a huge straw-man argument.
» Report offensive content
12
Scrum Master - 17/08/05
Does anyone review edit the articles because the author has absolutely no idea what he's talking about and he's as clueless as they come.
» Report offensive content
13
Farshad Khoshpasand - 25/08/05
Some times security is a part of system requirements and some times it is not when we talk about functional and non-functional requirements. I am pretty sure about one thing and when it comes to develop a system with high security functional requirements, there are a number of other methodologies to choose among and this is the case for most of the time, I would guess. As I understand this Agile methodology is suited for development of small or medium sized systems with a default security issues that most of the time fall into the default scenarios by nature. From my own experience I have to say, use much more restricted methodologies when it comes to developing a secure, dependable, scalable and reliable system. I am sure this Agile methodology is a very good methodology only and only if you have a project of a size for 4 or may be 5 developers, that have "time-to-market" as one of major focuses, if not the only one.
» Report offensive content