AgileAndSecure.com Featured on TheServerSide.net

AgileAndSecure.com was featured on TheServerSide.net based on my presentation at last week's OWASP AppSec 2006 conference.  The actual article is on SearchAppSecurity.com.

Agility and Security Like Open Source Software and Profits

I saw a great quote from MySQL CEO Marten Mickos in a Slashdot interview:

"But we also need to know that it is very difficult to walk the fine line between freedom of software and freedom to pursue profits. The two are not at odds with each other, but there are overlapping areas where you need to have all details right."

I see this as being very similar to Agility and Security - the goals are not necessarily in opposition to one another but in the areas where there are competing concerns you have to work to get the details right.  How much documentation is "too much" for an Agile process?  How little central control is "too little" for a secure development process.  These can be tricky issues and the right answers are likely to be different from organization to organization and from project to project within an organization.

OWASP AppSec 2006 Slide Deck Online

The slide deck from yesterday's presentation to the OWASP AppSec 2006 conference is online here.  Thanks to all the folks who attended and asked great questions.

Thoughts on "The New Methodololgy" - Part 1

I have been re-reading Martin Fowler's seminal essay The New Methodology where he outlines the reasoning for Agile methodologies.  The focus of the article is on the adaptive nature of Agile methodologies and their people-first orientation.  The article is fantastic but it is telling that a search for the words "security" and "secure" turns up no matches.  As with the principles of the Agile Manifesto I wanted to step through this document section by section and see where security needs to get involved.

First up is the section "From Nothing, to Monumental, to Agile"

One of the legacy practices that is maligned in the article is the tendency for traditional development methodologies to have a long testing phase at the end of a development cycle.  In a lot of organizations, this is where "security" gets implemented by either talking to the infrastructure team about firewall rules or if an organization is really trying hard they'll run a scanning tool or hire a firm to do an application pen test.  The problem with this is that finding security bugs at this point blows up the project - either the release is delayed while the security flaws are patched or the application goes live with known security issues. The Agile folks want to roll a lot of the quality testing into the process on a day to day basis rather than bunch it all up at the end and from a security standpoint this is a fantastic idea.  Paying attention to security every day of the development cycle is going to produce better results than tacking security on at the end.

Another issue the article raises is the weight that documentation requirements and other tasks add to traditional methodologies.  Agile methodologies seek to strip out all tasks that are unnecessary to the point that the documentation is the actual software source code.  I think everyone would agree that most traditional waterfall methodologies are too document-centric and this hinders team productivity and responsiveness.  However, design level documentation can be very important for security in that it helps to capture not just what decisions are made (the source code does this the best) but also why decisions were made.  Understanding this context is often key because misunderstanding it leads to poor decision making and logical application flaws.  The ability to adapt and change is great, but doing this without a solid understanding of the security context in which you are operating is a recipe for disaster.

Finally, the article makes the point that no process will ever make up for the quality of the development team.  Process and structure help to enforce consistent results, but they will not substitute for talented and well trained developers.  I've heard it said before: "You can't patch stupid"  This is becomes even more true in Agile development environments where you take away a lot of the process safety net.  You can't have a review team inserting themselves every step of the way to make sure you followed the process to the letter if you ever expect to ship useful, working software.  Agile teams raise the bar on the skill level and "engagedness" required of the team members.  If you want your Agile team to build secure software then every person on the team needs to understand secure coding and risk assessment because the responsibility will fall on them to make good decisions, day in and day out.

Presentation at OWASP AppSec 2006

I will be giving a presentation titled "Agile and Secure: Can We Be Both" at the OWASP AppSec 2006 conference.  The presentation will be on Tuesday October 17th from 3:20pm until 4:30pm in the Bay Auditorium.  Check out the full conference agenda.

The talk will cover some of the basics of what we will be exploring on this blog.  We will talk about Agile methodologies in general as well as offering some specific guidelines about Agile methodologies such as eXtreme Programming and Scrum.

Come on by the conference if you can and watch this space for more resources like links to the slide deck and video of the presentation.

Agile Manifesto Analysis - Part 4

This is the last day talking about the security implications of the principles of the Agile Manifesto.  The principles are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Finally:
Responding to change over following a plan

This works fine for Agile methodologies as long as security parameters have been addressed up front: what data is considered sensitive?  what are the availability goals?  who are the malicious users you are most afraid of?  If this framework has been established at the inception of the project and it is used as a point of reference when changes have to be made then security need not suffer.

However, if these security requirements change over time then the team may be forced to reconsider how any number of user stories must change in the face of the updated security context. Automated testing helps to protect the functionality of code in the face of constant refactoring.  Agile teams need to understand that changes in the security goals of a project will require more manual "security refactoring" where previous decisions have to be reviewed in light of updated goals.  Maintaing risk models along with use cases and user stories can help because they can be reviewed to be sure they are still valid in face of new developments.

The Agile Manifesto has captured the fundamentals of a tremendous shift in the practice of software development, but it fails to directly address security.  In my experience, if security isn't being directly addressed it isn't being addressed at all.  Organizations using Agile methodologies need to instrument their processes to ensure that security a key topic of discussion.

Agile Manifesto Analysis - Part 3

We've been talking about the principles of the Agile Manifesto and how security needs to be addressed as well.  The principles are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In this post:
Customer collaboration over contract negotiation

Traditional contracting processes haven't done a very good job of integrating security as a requirement.  Instead they tend to rely on general indemnifications and liabilities to be dredged up after something bad happens and used as clubs and shields to do organizational battle.  Obviously this isn't a terribly healthy or productive way to address the issue...

The real solution is to address security up front and then throughout the process.  In theory you could add security requirements to the contracting process.  OWASP had some folks doing work in this area a while back, in fact.  However real security has to be implemented during system development and working with the customer is the perfect way to do this - if you keep the customer focused on security.

Agile methodologies have made a point of aggressively incorporating customer input and customer feedback into the development process.  This leads to developing software that meets the customer's functional needs.  However, none of the Agile methodologies I have looked at specifically address customers' security requirements and that is an area of focus that needs to be proactively addressed in any secure methodology.

You could argue that security requirements should be naturally addressed when building user stories or use cases, but that isn't enough because teams haven't been doing this.  This has to be a specific TODO item to address because if it isn't then security will fall by the wayside as the customer focuses on all the cool new functionality they want to include in the next iteration.

Asking questions about security forces you to ask questions about risk and so "Planning Game" sessions need to include a risk budget as well as a level of effort budget.  Ask customers to make specific decisions about how much risk they are willing to take on and keep them informed about the consequences of the features being built.  Make sure that customers understand what they are asking for and what the security implications will be.  Force the customer to make rankings of what types of data are more valuable or sensitive than others.

The Agile folks are right - using contracts as weapons is a poor approach to getting useful business systems developed and put into production.  The increased focus on collaboration is great for addressing business concerns but Agile practicioners need to explicitly address security issues.  Customers are certainly capable of making decisions about risk and security, but it is the responsibility of the developers to force the issue.

Agile Manifesto Analysis - Part 2

As mentioned before I've been re-reading the main principles of the Agile Manifesto recently, and although they are very interesting they don't really address security issues.  Over the next couple of posts I wanted to take a look at these principles and see how they related to security concerns.  The principles are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Next up:
Working software over comprehensive documentation

"Working Software" is a great idea, of course.  And previous waterfall-style software development methodologies did focus too much on documentation.  But security issues have a nasty habit of cropping up when the thought processes of the past are forgotten when making the updates of the present.  Maintaining a record of the thought process that goes on during high and low level design is key to help prevent this sort of issue.   Agile gurus like to say "the code is the documentation" and that is certainly one way to approach things.  However, the code will only tell you what decision was finally made - not why that decision was made.

One technique we use that has been effective is integrating risk assessment and threat modeling into the documentation of individual use cases or user stories.  Hang on to those documents for later reference.  This doesn't provide the kind of full top-down view you could have had with more rigorous program of documentation, but at the very least it help to maintain some memory of the security concerns that shaped the past.  More on this later...

 

Agile Manifesto Analysis - Part 1

I've been re-reading the main principles of the Agile Manifesto recently, and although they are very interesting they don't really address security issues.  Over the next couple of posts I wanted to take a look at these principles and see how they related to security concerns.  The principles are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

 First up:

Individuals and interactions over processes and tools
On Agile teams looking to build secure software every individual has to have a base level of knowledge of secure coding.  Every developer has to be able to trust that the other developers are doing the right thing with regard to security.  Collective code ownership is a cornerstone of Agile development methodologies and it requires common coding standards.  Building secure software requires secure coding standards.  If Agile teams are going to create secure software, then all developers have to be trained in secure development to avoid injecting technical application vulnerabilities into code they write.  You have to be able to trust your team members.

That being said let's not rule out the use of tools.  From open source and freeware tools like FxCop to commercial tools like Fortify, there are a number of tools that can easily integrate into Agile processes that can help to enforce base-level security standards at the source code level.

Also processes can help to enforce consistency.  And when it comes to security, consistency is crucial  A chain is only as secure as its weakest link and an application is only as secure as its least secure point.  Integrating security into Agile methodologies requires selectively moving away from iron-clad processes and procedures.  This tension will be a theme discussed repeatedly on this blog.

To sum it up: individuals are important and at the end of the day it is individuals who write secure or insecure code.  But let's not throw tools out the window because they can be a force multiplier by helping to ensure consistency and provide a baseline from which individuals can improve.  And let's not throw process out the window because consistent execution is required for dependable security.

Introducing the Agile and Secure Blog

Welcome to the AgileAndSecure.com blog brought to you by Denim Group.  This blog exists to foster research and discussion about integrating security into Agile methodologies.  If things go well, the work done on this blog will be collated into a book and published.

Agile methodologies have developed to address a number of the shortcomings of traditional software development practices.  Extensive planning and documentation has given way to flexibility and frequent releases.  The customer has been elevated from someone consulted at the beginning of the process to being an integral part of the team throughout.  Automated testing applied from the beginning has replaced monstrous QA phases at the end of the development effort.  And for the most part software has improved.

Unfortunately many of the practices in Agile methodologies either ignore or blatantly go against traditional approaches to creating secure systems.  Documentation that would previously have defined design features to implement security functionality has given way to a mentality of "the code is the documentation" that lacks central command and control.  Frequent releases make it impractical to perform exhaustive system penetration testing before rollouts.  We have become better at creating software faster - but is it secure enough?

These issues will be the central topics of discussion on this blog with the intention of getting the software and security communities talking to one another and sharing ideas.  The business climate is not going to be satisfied with software that takes longer to create and in an increasingly online world security cannot be allowed to suffer.  These are difficult issues but ones that must be addressed.