I had a chance to talk with Dan Cornell from the Open Web Application Security Project (OWASP) and the Denim Group. Dan has over 13 years of experience in development and is one of the founders at the Denim Group, a company that does security consulting day in and day out for all types of clients. Dan wrote Sprajax, a security analyzer for AJAX applications, and is the chair of the OWASP Global Membership Committee.
While a lot of us work with security, it is usually in addition to other dev or ops responsibilities and isn’t our sole focus. However, Dan Cornell and his company are in the weeds of app security daily. It is a pleasure to have him on the agile admin blog and we are chatting with him on his thoughts on the Rugged Software Manifesto. We ran across this manifesto at the Lonestar Application Security Conference (LASCON) and heard it referred to by both OWASP board members and Department of Homeland Security types so we thought we should look it up, and it seemed interesting. So here’s Dan’s thoughts on the subject.
@wickett: Hi Dan, welcome to the agile admin blog. Our first question for you is, what do we mean by Rugged Software?
@danielcornell: I think of software that is going to run as intended, regardless of the conditions it encounters when it is deployed. A big part of this is security, but that isn’t the only thing. You also have to take into account reliability, survivability and a variety of other ‘-ity’ properties. The Internet, and networks in general, are dangerous places where you need to be conscious of both malicious actors as well as other, unintentional adverse conditions such as service outages, congestion, untrained users making mistakes and so on. Rugged Software is software that is designed and built to deal with these conditions – foreseen or not.
@wickett: When we have talked about Rugged Software with developers, we get a fair amount of pushback and hear statements like, “Rugged Software isn’t really real and that it is just a PR play.” Some developers and engineers we;ve talked to say that it lacks depth, clarity and process, but I wonder if these engineers have even seen the original Agile Manifesto. In my mind, I look back at the original Agile Manifesto and I am equally under-whelmed by it as I imagine they are by the Rugged Software Manifesto. Do you see any parallels between the original Agile Manifesto and the Rugged Software Manifesto?
@danielcornell: The two biggest challenges I see for the Rugged Software movement are to provide a business justification for being Rugged to management and to answer the “so what?” question for developers. Dealing with the first will go a long way toward solving the second.
If you ask most executives and managers if they’d like their software to be Rugged they’ll likely give an answer somewhat along the lines of: “Sure I’d love to be ‘Rugged.’ And ‘Agile’ and ‘Pragmatic’ and whatever other buzzwords the industry has come up with lately. All that stuff is great but what I really want is to be on time and on budget and I want more features than our competitors.” Thinking about security and quality and performance and anything else comes later.
So this is an area where the Rugged movement needs to do a better job of explaining why Rugged makes good business sense and you run into the same challenges that information security folks have had making a business justification for security for years. Allowing an organization to avoid pain when the auditors or compliance folks come around is of value – but it often isn’t enough. Reducing downtime and disruption in the future because you have avoided a breach or outage is of value – but it often isn’t enough. David Rice has done some great thinking in this area in his book Geekonomics but, as an industry, I think we are still looking for the universal truth to be revealed that will make everyone sit up and take notice and I think we’re going to be waiting for a long time.
That said, some organizations have made the decision that this is an area that merits focus and when executives and managers make Rugged (or security or whatever) a priority then it is much easier to get the troops to fall in line. I’m reminded of a secure coding training class I ran recently for an ISV where the VP in charge of engineering stood up at the beginning of the class and said “This is a priority for us and the material in this class represents the base level of knowledge everyone is expected to have.” Then he sat in the entire two day class and at the end told his people “I hope you paid attention because you are going to be held accountable for knowing and implementing this material.” Wow! This was one of the best classes I taught in a long time; everyone showed up on time, paid attention, asked questions and so on. I’d love to think it is because I’m such a funny and engaging guy but what really made the difference is that the leadership demonstrated with actions that security is a priority. A similar model is always going to be the most effective way to drive Rugged into an organization. Bottom-up, grass roots efforts are valuable because they raise awareness and help to identify like-minded potential champions, but to drive adoption at scale management needs to feel that this is a priority.
Speaking of priorities, I think this is an area where the Agile Manifesto style can provide some guidance. The Rugged Manifesto is a great call to arms, but it is very self-referential: “I am Rugged… and more importantly my code is Rugged” And so on. If you look at the Agile Manifesto it calls out trade offs: “Individuals and interactions over processes and tools,” for example. It accepts that processes and tools have merit, but chooses to value individuals and interactions more. Acknowledging that decisions must be made and providing guidance on why one is superior to another is a stronger basis for a conversation and this is going to be key. Right now those trade-offs are presented as “Prefer code without vulnerabilities over code with vulnerabilities” Duh! Who wouldn’t want that? But the real question is what are they going to have to give up to get it.
@wickett: Over the next five years, do you see the Rugged Software Manifesto becoming a standard? Will we have Rugged development practices and be operating on a new paradigm for development or will it get lumped under Agile?
@danielcornell: Well the Rugged Software Manifesto is just that – a Manifesto. It isn’t a standard. And I don’t think we are ever going to see a standard for software development because “development” is too big a thing to be done in a standard way. You can’t expect folks building banking applications for East Coast financials to follow the same process as a couple of folks in a garage trying to build the next Facebook. What I hope is developed and adopted, however, are so-called “best practices” such as threat modeling, static analysis for quality and security, security code review, penetration testing and so on.
Also, Agile and Rugged are two separate movements. Agile is about creating customer-centric software in a flexible and timely manner and Rugged is about making software that doesn’t break. Their goals are not exclusive, but they’re also different.
@wickett: When thinking about Rugged Software, what are practical steps that individual developers can adopt into their current practices whether they use Agile, Waterfall, or other development methodology?
@danielcornell: Well first I think it is important to note that individual developers can have a positive impact on their own code, but this is going to be largely ineffective if the rest of the development team doesn’t share the same goals. The “weakest link in the chain” analogy comes to mind. That said…
Threat Modeling is a practice that can be adopted into any development methodology. There are lots of resources out there that explain how to use it to improve the security of complicated systems and it can also be used for the greater purpose of Rugged software by asking questions such as “what if this data flow stop flowing” or “what if this data store becomes unavailable” This is best done by the team as a whole but it is also a practice that an individual developer can use on their own portions of a system.
Penetration testing and resiliency testing are other practices that teams can implement to help test the Ruggedness of their applications and systems.
@wickett: What open source tools do you think should fit into the tool chain for a rugged developer? What about for a rugged operations/sysadmin?
@danielcornell: Static analysis tools like FindBugs, PMD and FxCop can be really valuable. For dynamic testing a web proxy like WebScarab can be really useful to testing how software is going to respond to unexpected inputs.
On the operations/sysadmin thing a critical Rugged practice is to proactively monitor systems in order to anticipate problems. From the standpoint, you should be instrumenting systems and not just tracking failures. When an HTTP server goes down it is often too late to prevent an outage and that isn’t very Rugged. Instead you also need to be tracking disk and processor usage, traffic and response time trends and so on in order to be able to anticipate problems. Fortunately there are a lot of open source tools available for DIY folks as well as SaaS offerings that can make this sort of instrumentation less of a hill to climb that it was in the past.
@wickett: We appreciate having time with Dan and hearing from an industry leader on Rugged Software. To keep up Dan on the interweb, you can follow him on twitter or check out his blog.
the agile admin 