I know it might sound sort of corny but whenever I think of the Department of Homeland Security (DHS) “SWAMP” program (the Software Assurance Marketplace) my mind immediately goes to The Empire Strikes Back.
You probably know the part I mean. When Luke lands on the swamp planet of Dagobah to receive his training from Yoda. What can I say? My mind goes in some fairly random directions sometimes. But while it was the acronym — the mere fact that it’s called “SWAMP” — that initially led me to make that connection, the more I think about it, the less it seems like a freely-associated non sequitur and the more it strikes me as a fairly apt metaphor.
If that sounds strange to you, think about what happened to Luke when he went to Dagobah. For him, the physical swamp where he trained with Yoda was a source of wisdom and guidance. He went in looking for answers, direction, training, information, and found it there.
This guidance/wisdom is much in the vein of what AppSec practitioners can expect when they use the DHS SWAMP. It is (or can be for those that use it), a valuable source of guidance and information. The trick is in knowing that it’s there, knowing how they can make the best use of it, and having an open mind in using it for their enterprises.
So, for those that may not be familiar with DHS’ SWAMP program, but have responsibility for application security in their enterprises, let’s delve into it. What the program is, why it should matter to you, and what you can do to leverage it.
First off, what is the SWAMP?
The Software Assurance Marketplace is a program sponsored by the DHS, and hosted at the Morgridge Institute for Research (located at the University of Wisconsin Madison campus). The purpose of the SWAMP is to provide a collaborative, open environment that allows no-cost access to a body of software testing tools, code samples, test-beds, and other resources designed to enable robust application security testing.
Why do this? A few reasons: to increase the software security posture of the industry as a whole, to hone and refine the testing tools that provide data about the state of software security, to share data among likeminded folks, to collect metrics about tool performance, to learn about how these tools operate and perform, etc.
Anyone can register for access and use it to test any applications they choose. The only limitations are the languages supported (per the FAQ, currently that includes /C++, Java source, Java bytecode, Python, and Android Mobile Code) and the platforms supported. Once in the SWAMP, end users can make use of the tools collected there to analyze applications, employ their own tools in that environment, while tool developers can benchmark their tools against known-vulnerable software and test suites to evaluate their tool’s performance, accuracy, operation, etc.
For those that are concerned about sharing their application code with others (or the DHS for that matter), the SWAMP makes it clear that applications that are submitted are considered private and not shared with others unless explicitly shared.
How can I make use of it?
Now, obviously if you’re a developer of a software security analysis tool, the benefits of this should be obvious: here’s a free service that you can use as a test-bed to help refine and develop your tool or service offering.
Likewise, if you’re a generalized application developer, the benefits to you are probably similarly obvious: a free service that allows you to perform testing that would otherwise come at significant cost (sometimes prohibitive cost) and/or require specialized expertise.
But even for security practitioners outside these two groups, there is a role to play and a benefit that the SWAMP can have. Specifically, by leveraging the SWAMP as part of your application security program, you may be able to expand the reach of the technical testing controls that you employ when it comes to fielded software.
What I mean by that is that very often, application security can take a back-seat to other types of security countermeasures. For example, consider what you would think if you heard of an enterprise that had made a significant investment in application security controls (things like software security testing tools) but a fairly minimal level of investment in infrastructure and network controls (things like firewalls and IDS systems)?
Would that surprise you? What about the reverse case? You’d probably be less surprised by the latter than the former, right?
The truth of it is that, when there’s a choice to make between whether to allocate dollars to infrastructure-level security controls or whether to allocate those same dollars to application-level tools, infrastructure tends to win. There are often solid reasons for this, but the “too long; didn’t read” version is that many application security efforts find themselves with fewer dollars to spend on tools than they would like.
But what if those same folks – the ones who find their application testing efforts limited by budget dollars – could test some percentage of those apps for free? For example, what if there was a population of in-house developed applications that they could test without having to invest in a commercial tool to do it?
What if they had a community of folks to collaborate with to make sure that they’re using the tools properly and getting good data from them? What if the custodians of that environment kept all of those tools maintained so that the practitioners could focus less on the busywork of maintaining the tools and more on what they actually need to get accomplished (i.e. testing the software)? Sounds appealing, right?
Now, granted it’s the case that not every application will fit the bill as a candidate for testing via the SWAMP – for example, they don’t support every programming language out there, every tool in the world, or every platform that exists. That said, if the number of applications you could test in the SWAMP is greater than zero, it just might let you get more done with the dollars you have.
Meaning, having the SWAMP on your radar can add value to your AppSec program – in fact, even for those not completely focused on AppSec, it can still add quite a bit of value to your overall security program.
Ed Moyle is Director of Emerging Business and Technology for ISACA. Prior to joining ISACA, Ed was a founding partner of the analyst firm Security Curve. In his more than 15 years in information security, Ed has held numerous practitioner and analyst positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers, and senior security analyst with Trintech. Ed is co-author of Cryptographic Libraries for Developers and a frequent contributor to the Information Security industry as author, public speaker, and analyst.