Tag Archives: SWAMP

What about libraries?

In response to an interesting article on Contrast Security on libraries and application security, SWAMP Chief Scientist, Dr. Barton Miller elucidates on how the SWAMP will augment appsec:

“Thank you Dave for stressing the importance of libraries when thinking about software assurance.  This is certainly an issue that has motivated our approach to building the code assessment capabilities of the SWAMP.

We fully share your view that the issue of vulnerabilities in libraries is a serious and challenging problem. This has been well noted by the security research community and is seen in CWE and CVE reports associated with popular libraries.  And run-time (dynamic) tools are an important element of the solution to this problem.

In the SWAMP, we are taking a security-in-depth approach that enables software developers to combine both static and dynamic techniques when continuously assess their code.  In the static domain, this means the detection of libraries dependences at build time (a technology that the SWAMP supports) and then assuring that all components are assessed.  This approach can be made quite tractable by recording with library versions have already been assessed and reusing those results. In the dynamic domain, this means running tools that will follow execution into these dependence libraries and assess them.

As we move to include dynamic tools in the SWAMP, we would be happy to see a tool like Contrast include in the selection of tools that are part of our evolving marketplace.”

Signal Online Covers Software Assurance Marketplace!

Homeland Security Department Seeks Software Assurance Marketplace Participants

By George I. Seffers

About the Author

Cybersecurity collaborative environment goes live in January

The U.S. Department of Homeland Security is seeking participants for the Software Assurance Marketplace (SWAMP), which is expected to open to beta users in January. The ultimate goal for the marketplace is to help protect the nation’s critical infrastructure by improving software used for essential functions, such as electrical power, gas and oil, and banking and finance. Potential participants are invited to register at the continuous assurance website.

The SWAMP offers a collection of software quality assurance tools to help developers test and evaluate their code for weaknesses and vulnerabilities. It also provides tool developers with an environment where they can test, calibrate and improve the ability of their tools to scan a range of languages such as JAVA, C++ and .NET, as well as being able to look at a wide range of weaknesses. Additionally, it is meant to assist software researchers in discovering new techniques and methods to help create better performing assessment tools, and it provides a learning environment for educators and students to better understand how to develop software code.

“The need for SWAMP stems from the fact that software is everywhere. Software powers our critical infrastructure. We’re talking oil and gas, finance, transportation, so there are a lot of key components that are very important. We realize that in order to protect that from our adversaries, we need to have a resilient infrastructure in place, and software is the underlying entry point and attack vector that a lot of our adversaries use to try to compromise our systems,” says Kevin Greene, software assurance program manager, Cybersecurity Division, Science and Technology Directorate, Department of Homeland Security.

Greene says he hopes that up to 500 users will sign up by next year. “In January 2014, we will have our initial operating capability, where we will make the SWAMP available for the public to start using. So, we want to have software available for a limited subset of users to start doing testing, cranking out different things, coming up with some ways we can improve the environment before we fully open it up to the public,” he explains. The SWAMP is a five-year effort, which should become fully operational around the end of the third year, he adds.

Beta users will have access to five software assurance tools, including PMD, FindBugs, CppCheck, Oink and Clang, and more than 100 software packages and test cases for analysis runs, such as Jenkins, K-9, Hadoop and Scribe. “The good thing about those tools is that they are currently being used in the open source community as well as in a lot of operational environments. In terms of the packages, if we can help identify weaknesses in those widely used packages, we’re doing our job in helping the community identify weaknesses and provide them in a way that they can, through a crowdsourcing approach, make changes and fixes so they can funnel those changes back to the software assurance marketplace,” Greene says.

The SWAMP will add major functionality about every six months. In mid-2014, for example, the marketplace will include tools for assessing code used for mobile devices, and six months after that, users will be able to assess binary code. “A lot of times we don’t get the source code. We get the actual binary, so if we get the binary, we need to be able to still provide a mechanism by which users can vet software. We realize the combination of source analysis as well as binary analysis is very important,” Greene explains.

Greene expresses hope that the SWAMP will help address the growing size and complexity of software. “Typically, tools have not been designed to scale, to provide that type of robustness. One of the things I’m trying to figure out through my software assurance program is how we can continue to develop techniques that will keep pace with the changes in software, the complexity, the size. How we can constantly develop techniques that are advancements but that also keep pace with the rapid changes in software,” he says.

Additionally, he foresees the marketplace helping to improve education and awareness. “We want to partner with academia and offer educational opportunities through the SWAMP that provide the awareness and education to develop better software,” he says. “We need community input and involvement so that we can share tools, techniques, resources and experience. Because the SWAMP is a collaborative resource environment, we treat it like a laboratory. This is where people come and collaborate and find new breakthroughs.”

That collaboration also could lead to better assessment tools. “Once we create better performing tools, there is a better chance of software developers adopting the tools earlier in the development process. That will go a long way in reducing the cost of software failures. Typically, they don’t use the tools because the tools don’t perform that well,” he reports. “We want folks who are passionate about software assurance, who are passionate about improving software. But also, we want the small tool developers to be a part of the SWAMP as well, because typically they don’t have the resources to improve their tools.”

Greene predicts that the SWAMP will foster major software assurance advances. “We’re trying to do our job in protecting our nation’s critical infrastructure and providing capabilities to be more proactive instead of reactive to cyberthreats. Along with the technologies I’m developing, I think the SWAMP will definitely be a revolutionary force in the software assurance community. We anticipate advancing some breakthroughs in the SWAMP,” he declares.

What are executives doing about vulnerabilities?

Our friends at Sonatype published a very interesting blog by Mark Troester illustrating the apparent disconnect between executive desire for secure applications and the actual effort spent making them secure. I encourage you to read Mark’s piece, which highlights some interesting data from the (ISC)2 Global Workforce Study CXO Report. He points out that even though application vulnerabilities account for 72% of the top security threats, the effort spent on application security during development is dismal. The reason for this state of affairs is a complex topic. No one argues that we want/need more secure software. The question many are faced with, however, is what’s the easiest and least expensive option? Build security in OR fix vulnerabilities as they pop up and cause issues?

I’m not going to opine on the technical merits of one over the other, but rather speak to the marketing and brand equity costs associated with tabling security efforts until they’ve reared their proverbial ugly head. The line between marketing and IT has not just thinned over the past few years, but been altogether blurred. Marketers are now walking into an IT director’s office demanding the latest and greatest open course CRM or CMS. They want to integrate social media applications and location based services. Marketing, in the business world, is often driving the software implementation and development path, which puts pressure on the technical staff to evaluate a lot of new software applications. This creates some inevitable friction, as noted in a blog on Harvard Business Review this week.

Since I am a marketer, you’d think I’d be be firmly on the side of Team Marketing in this debate, but the truth is that the more I learn from developers and assurance testers, the more I want to encourage my business colleagues to slow down and give IT a little time to vet the software we marketers are clamoring to have. There is no real excuse to skip security and assurance testing before software is either 1) deployed to the customer (if you’re an application developer)  or 2) deployed within your environment.  Yes, it’s going to take a little time, which will make you nervous as you add up your developer billing rates. But the tradeoff may well be worth it.

Here’s an example from a past life:

As a director of marketing, I spend an average of $150 to acquire a new customer. This number is an aggregate of various efforts, like online, print and direct mail marketing.  (It doesn’t even include the man hours needed to create an engaging campaign or train the sales staff, etc.) As a result of my efforts, I gain 10,000 new customers in a year. This is good news because once I have a new customer, my costs to retain him go down each year, sometimes as low as $30/per year. As long as I provide good products and services, I’m good. I can see a return on my investment.

Now let’s pretend that my team and I decide to install and implement a new application on our website or on our server. We’ve given IT a short amount of time to vet, install and support this new software. It’s all about beating our competitors, right? Now imagine that this software has a critical vulnerability that creates a window of opportunity for a hacker to access confidential customer or vendor data. This could be names and addresses. It could be credit card information or passwords or all of the above (how timely to have Adobe as the poster child for this situation).

Begrudgingly, we need to let customers know that we’ve been hacked. Depending on how we approach our customers with the problem, they may give us another chance to earn their trust. But what if they don’t? What if I have to go find another 10,000 or more customers at $150 each just to replace the ones I already gained? What if I have to engage a PR firm at $250/hour to manage the branding issues that will inevitably pop up? I’m looking at thousands of dollars…hundreds of thousands of dollars to find business and regain trust. That’s a lot more than the initial investment I could have made in assurance and vulnerability detection efforts.

Of course, even security experts will tell you that there are no guarantees and determined hackers sometimes prevail. But, if you have an opportunity to reduce your risk, why not take it. To all my marketing friends, here’s my call to action…work with IT and listen to their concerns about security. I think you’ll be glad you did.

–Karen Hitchcock

Miron Livny Speaks at WIN

Miron spoke at the Wisconsin Innovation Network Luncheon on cybersecurity Tuesday, Feb. 26, 2013, along with Josh Bressers of Red Hat.

There were roughly 40 attendees who offered many questions on the general topic of cybersecurity and how the SWAMP will play a role in improving software security.

Josh is the front-end security lead for Red Hat. By front-end he means all the things that make Red Hat software more secure BEFORE it leaves the door. That includes developer education related to secure coding practices (really just getting started here), as well as manual and automated analysis.

After the lunch, Josh spent a bit of time with the MIR SWAMP team and the UW’s Jim Kupsch, discussing broad ways in which Red Hat and SWAMP could potentially collaborate including:

  1. Development, sharing and dissemination of secure coding practice educational materials
  2. Sponsoring or contributing to open source SWA tool development
  3. Using SWAMP for some of their ‘front end’ security operations

Josh also mentioned a Fedora project called Firehose – An Interchange Format for Static Code Analysis Results – a capability we are interested in supporting in SWAMP.