OK, you're skeptical. I was too. We've all heard this sort of thing before. Who needs another secure-software development life cycle that, in the end, isn't heeded enough to make a bit of difference? When I was invited to participate in the Rugged Software effort, I was reluctant. I'm far more impressed by actions than titles, certifications or checklists that are all too easy to ignore.
But despite my initial reluctance, I'm on board. For starters, Rugged Software isn't another S-SDLC. Founded by Joshua Corman, the director of security intelligence for Akamai Technologies; David Rice, executive director of Monterey Group; and Jeff Williams, CEO of Aspect Security, the Rugged Software initiative was born from frustration with the status quo. We've all spent years chasing patches and vulnerabilities, but we don't seem to be making positive progress on that front. As , "Software is currently in a state of vulnerability management. That's a negative approach, and it hasn't made frequent breaches go away. Rugged is a more positive approach, where you're not supposed to find a bunch of vulnerabilities in pentesting."
Look, the mere fact that SQL injection remains the No. 1 vulnerability on the tells you all you need to know about how well the status quo is serving us. Because when you get right down to it, .
At this point, what the Rugged Software initiative aims to do is still summed up pretty well in the Rugged Software Manifesto that the movement's founders drafted two years ago:
* I am rugged and, more importantly, my code is rugged.
* I recognize that software has become a foundation of our modern world.
* I recognize the awesome responsibility that comes with this foundational role.
* I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
* I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic, and national security.
* I recognize these things -- and I choose to be rugged.
* I am rugged because I refuse to be a source of vulnerability or weakness.
* I am rugged because I assure my code will support its mission.
* I am rugged because my code can face these challenges and persist in spite of them.
* I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.
The Rugged folks believe software (as well as operations and other aspects of our information systems) must be resilient and built to withstand persistent attacks by determined adversaries. And in the face of failure, we should be able to quickly and gracefully respond to the failure in a businesslike manner.
But I am very much encouraged that the Rugged movement isn't just about developing software. It is envisioned to encompass the entire life of software, from design through operations and maintenance. Again, these are words we've heard before, but perhaps our collective frustrations with the status quo are sufficiently high that we can now actually put those words into action. Here's hoping.
More than has been true of S-SDLC, the Rugged movement aims to provide guidance to software developers, who would start by publicly stating what they do to make their software rugged. We see similar things in other realms, such as consumer product quality labels. Can it help make software more secure and rugged? The jury is out, but perhaps by publicly claiming certain aspects of an application's security, developers will take things more seriously. Again, here's hoping.
And some of the guidance would be actionable. Rugged envisions providing assistance to software developers on things like criteria for selecting a programming language for a project, advice on using that programming language securely and so on. Rugged also intends to help support development of new programming language technologies that are free of today's common defects. (Imagine a middleware language in which dynamic SQL queries are not even possible. Instead, all SQL queries would be parameterized, as with Java's PreparedStatement API.)
Still feeling some trepidation about the Rugged Software effort as I headed for this month's sessions, I was reassured by the attitude I noticed among the initial team gathered in Washington. I told them that I feel that software should be more "self-aware," so that it knows when it is under attack, can provide business contextual alerting to the security team, take active steps to evade the attack and thus protect the business data and processes it handles. This notion was consistently met with agreement and support.
In the end, the Rugged Software movement will be judged by the users and developers of software, of course. Whether it succeeds or fails will depend on whether CIOs and other business executives buy into it and start demanding more of their software -- whether that software is built in-house, is outsourced or sits in someone's . And it will need to break through to the developer community, which is justifiably leery of a group of self-appointed security experts trying to tell them what to do. Hopefully, the inclusion of people like Wilander will help there.
We all need to demand more -- the status quo cannot stand. SQL injection is something we cannot tolerate in our systems. Our current attempts to rid our systems of it and other security weaknesses are proving inadequate. We cannot give up either. Rugged Software just may be a reasonable starting point for us all to think differently about things.
With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.
in Computerworld's Security Topic Center.