Denim Group, Ltd. Blog

After more than two years in development we’re finally publicly releasing our ThreadFix open source application vulnerability management system. It is still pre-production, but it represents an almost complete rewrite from the “Technology Preview” version we released when it was still called “Vulnerability Manager.”

A more complete description of the system and its capabilities is:

ThreadFix is a software vulnerability aggregation and management system that reduces the time it takes to fix software vulnerabilities. ThreadFix imports the results from dynamic, static and manual testing to provide a centralized view of software security defects across development teams and applications. The system allows companies to correlate testing results and streamline software remediation efforts by simplifying feeds to software issue trackers. By auto generating application firewall rules, this tool allows organizations to continue remediation work uninterrupted. ThreadFix empowers managers with vulnerability trending reports that show progress over time, giving them justification for their efforts.

So what’s next? You can download ThreadFix here. The current beta is available as a pre-built Tomcat install (the final release will likely be a pre-configured virtual machine). Just unzip and run. During the beta period we will be looking to push new versions on a weekly basis. Also we have a “Getting Started” guide that runs through the major functionality as well as other documentation on the wiki to describe the different parts of the system.

There is still work to do – we need to improve the stability of the scan importers, we need to tighten up the security of parts of the system, and we need to build out the REST API. If you run into any issues using ThreadFix or if you have feature requests please use the online bug tracking system here or email me at the address listed below.

Also you can follow ThreadFix on Twitter: @threadfix

We’re tremendously excited to get this software released to a wider audience. Contact us if you are interested in learning more about using ThreadFix for application vulnerability management.

--Dan

dan _at_ denimgroup.com

Technorati Tags: application security, application vulnerabilities, application vulnerability management, dan cornell, denim group, threadfix

February 01, 2012 in Application Security Remediation, ThreadFix Application Vulerability Management | Permalink | Comments (0) | TrackBack (0)

January 26, 2012

Pre-RSA Podcast: What Does Fixing Application Vulnerabilities Cost?

I sat down witih Jeanne Friedman last week and recorded a short podcast preview for my upcoming presentation at RSA 2012 “Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?” You can see her post online here and you can download the 8 minute podcast here. The actual session is ASEC-302 and will be Thursday, March 1^st, 2012 at 9:30am in Room 302. Hope to see folks there!

--Dan

dan _at_ denimgroup.com

Technorati Tags: application remediation, application security, daniel cornell, denim group, rsa security, rsa security conference 2012, vulnerabilities

January 26, 2012 in Application Security Remediation, Conferences, Remediation | Permalink | Comments (0) | TrackBack (0)

January 17, 2012

OWASP AppSecUS Video/Slides Online: Self Healing Cloud

The video from my “Self Healing Cloud” presentation from OWASP AppSec US in Minneapolis last year is now online:

The presentation discusses automatically generating “virtual patch” rules for IDS/IPS and WAF systems based on web application scanner results. We have been working on this technique for a while and have a lab set up to test and optimize our results. We have created a “hub-and-spoke” system for creating virtual patches for a variety of blocking technologies based on uploading results from most common commercial and open source web application vulnerabilitity scanning results.

The slides for the presentation are also online:

--Dan

dan _at_ denimgroup.com

January 17, 2012 | Permalink | Comments (0) | TrackBack (0)

November 22, 2011

Remediation On Rails: Executing Your Software Security Remediation Project

[See last Thursday’s post “’FIX IT!’ Ain’t Gonna Cut It” for more information on kicking off a software security remediation project and Friday’s post “Don’t Bring an HTML Encoder to a SQL Injection Fight” for more information on planning a remediation project.]

The good news is that if you got your stakeholders aligned in an Inception phase and if you know what you are going to do and how you are going to do it from a Planning phase, actually fixing the vulnerabilities is usually pretty easy: you just do what you said you were going to do. That said, there are some potential pittfalls.

For starters - you can’t always just start fixing vulnerabilities. You first have to have a working development environment where you can make changes and test them. For applications being actively developed with good configuration management this should be pretty easy. For the 10 year old end-of-lifed ASP Classic application that no one has touched in five years it can be more challenging. This can be a huge time waster and wading through a couple of messy projects has renewed my belief in the value of configuration management and environment documentation.

Also once you fix vulnerabilities you have to both make sure your fixes worked and make sure you didn’t break the application. The way of the world is that the last person to touch the code is assumed to be responsible for anything that goes wrong, so you want to be sure to be able to demonstrate that security fixes aren’t responsible for any downtime. If your application has a suite of automated unit and functional tests they will really be paying dividends at this point. If you agreed that a “fix” would be considered successful if it no longer turned up in a scan then you’ll need to re-run a scan. If your fix stanards were more involved then you will need to runt through and confirm that the vulnerabilities have been addressed. Again – automation can be a big help for certain types of vulnerabilities.

Finally you can’t declare victory until your updated – and tested – code is pushed into production. Using an existing update window is preferable or you may have to do an out-of-cycle release. The important thing is that the code goes live. If vulnerabilities are supposed to be fixed and the next round of testing from your external auditors indicates that they haven’t been you should expect to get a nasty phone call. So far every time I have seen this situation in a well-run remediation project it has been because code updates or mandated configuration changes had not actually been pushed into the production environment.

Here is a short video where we talk a bit about the Execution phase for software security remediation projects:

Here is a presentation outlining some of our research on the actual costs of remediating different classes of vulnerabilities as well as where time gets spent during the execution of remediation projects:

You can read the full HOWTO Guide for Software Security Vulnerability Remediation here:

--Dan

dan _at_ denimgroup.com

Technorati Tags: application security remediation, dan cornell, denim group, execution phase remediation, remediation, remediation project, software security remediation

November 22, 2011 in Application Security Remediation, Remediation | Permalink | Comments (0) | TrackBack (0)

November 18, 2011

Don't Bring an HTML Encoder to a SQL Injection Fight: Planning Your Remediation Project

[See yesterday’s post “’FIX IT!’ Ain’t Gonna Cut It” for more information on kicking off a software security remediation project.]

Normally information security creative writing is reserved for marketing brochures talking about Advanced Persistent Threats, but I thought I would share a little something I’ve been working on. This is an excerpt from an infosec romance novel I have in progress titled “The Remediation Diaries”

After we sent out our assessment report we hadn’t heard a peep from the application team until Alice the development manager came to me and complained one of her developers, Bob, was behind schedul and had been “screwing around” all week doing some sort of “security crap.” Wandering the halls until I found him, a premonition hit me that the conversation was going to take a frightening turn. I felt a hollowness in the pit of my stomach as I looked into the puppy dog eyes of a developer who wanted nothing more than to prove his competence and win the aproval of the security team.

“The report was pretty long and a little confusing, but in there it said the XSS vulns were because we weren’t escaping text before we sent it to the browser.” I breathed a small sigh of relief. At least Bob read the report and seemed to understand the important parts. Things were looking up. “So I wrote an ‘escape’ function that turns all the left and right brackets into the escape sequences.” My heart started racing – did Bob really think that was a sufficient answer? “Then I went around and pasted it in the code to fix a bunch of the pages – I think I got them all.” My throat closed up. This was not going well. “I didn’t want to bother you so I went and did that for all the injection vulnerabilities, too. Can we run another test?” My heart stopped beating and I was convinced I was in full-on cardiac arrest. I smelled toast burning – was I having a stroke?

I struggled to keep my cheerful poker face. What was the kindest way to handle this? How could I encourage Bob’s enthusiasm without crushing his soul? My brain was shouting: That’s a crappy way to make an HTML escape function! And it doesn’t work for HTML attributes! And why would anyone think that HTML escaping was the same as SQL escaping? And why wouldn’t you just use parameterized queries to fix SQL injection properly? Why didn’t they know how to fix this stuff right the first time? If only I had helped the developers plan a little bit before they ran off on their own…

[Side note: What do you think? Do I have a future as a novelist? Or should I stick with my day job?]

On a more serious note, this story typifies the types of unproductive efforts we see with poorly-planned remediation efforts. Just as the Inception phase is needed to make sure that the stakeholders are on the same page, efforts needs to be planned so that there is unambiguous agreement on issues such as:

Which specific vulnerabilities are going to be fixed and when?
Specifically how should the vulnerabilities be fixed?
What sort of follow-on testing is going to be performed and what is the standard by which vulnerabilities will be considered to be successfully addressed?

Developers are smart people. The vast majority of them also have the best of intentions – they want to write good code and they want to write secure code and, if given the choice and the time, they would prefer to do things the “right” way. But if you rile them up and don’t provide guidance – especially when it comes to unfamiliar territory like security fixes – you are likely to be disappointed with the results. And if you are disappointed then you can be sure that development managers and other stakeholders are going to be both disappointed and angry. In addition, they aren’t going to be interested in funding your next remediation effort. Up-front planning and explicit guidance means the difference between successful vulnerability remediation and ineffective time-wasting so spend the time with developers to get this right the first time.

Here is a short video where we talk a bit about the Planning phase for software security remediation projects:

You can read the full HOWTO Guide for Software Security Vulnerability Remediation here:

--Dan

dan _at_ denimgroup.com

Technorati Tags: application security remediation, dan cornell, denim group, developer, how to do remediation, inception phase, inception remediation, security team

November 18, 2011 in Application Security Remediation, Remediation | Permalink | Comments (0) | TrackBack (0)

November 17, 2011

"FIX IT!" Ain't Gonna Cut It: Kicking Off a Software Security Remediation Project

Imagine this scenario: Your development team builds an application and puts it into production. Down the road, a customer asks you to do a security assessment. You run a scanner against the application and perhaps even do some manual penetration testing. The result is you end up with a long list of vulnerabilities and the customer wants them fixed. So the security team meets with the development team and the exchange goes something like this:

Thanks, security team! Very helpful! Come back any time…

If you’re going to spend the time and resources diverting development teams from building new features to fix security vulnerabilities all parties involved owe it to themselves to make sure the effort is successful. Based on our experience doing software security remediation projects the ones that are approached in a thoughtful and structured manner tend to do far better than ones based on a mandate of “FIX IT!” We’ve developed a HOW-TO guide for software security remediation projects outlining just such a structure, and these projects start with an Inception phase.

The Inception phase is used to get all the stakeholders together and on the same page. Software security remediation projects are typically software development projects, not security testing projects and they need to be estimated and project managed as such. They also force people from different parts of an organization with different goals to work together. Before moving forward, teams need to agree on things like:

Approximate budget and where the budget is coming from
Desired (but realistic) timeline
Specific compliance or audit issues that must be addressed
Initial project success criteria (“fix all the CRITICAL and HIGH vulnerabilities” or “fix all public-facing cross-site scripting”)

Given this shared understanding the involved parties can start to work on planning the actual remediation effort, but in the absence of a consensus the remediation project likely does not have a clear mandate and this is a recipe for project failure.

Here is a short video talking a bit about the Inception phase for software security remediation projects. Hopefully you find it to be a bit more constructive than the previous one.

Also, you can read the full HOWTO Guide for Software Security Vulnerability Remediation here:

--Dan

dan _at_ denimgroup.com

Technorati Tags: application security remediation, dan cornell, denim group, developer, how to do remediation, inception phase, inception remediation, security team

November 17, 2011 in Application Security Remediation, Remediation | Permalink | Comments (1) | TrackBack (0)

November 16, 2011

Webinar: The Self-Healing Cloud

Tomorrow I'll be giving a free webinar called "The Self-Healing Cloud." I'll be discussing automated virtual patching and how it can be successfully employed.

You can sign up for the webinar below. If you're interested in the topic but can't attend the webinar, sign up to receive information after the webinar.

Thursday, November 17, 11am (CST)
The Self-Healing Cloud: Protecting Applications and Infrastructure with Automated Virtual Patching
Presented by Dan Cornell

Organizations sometimes deploy applications on their infrastructure without thorough security testing, putting the applications and the infrastructure they are deployed on at risk of exploitation. Application-level vulnerabilities often require coding changes to be fully addressed. Virtual patching is a technique where targeted rules are created for web application firewalls or other IDS/IPS technologies to help mitigate specific known application vulnerabilities. Attendees will learn how to create virtual patches and the nuances of using virtual patches.

--Dan

dan _at_ denimgroup.com

November 16, 2011 in Cloud | Permalink | Comments (0) | TrackBack (0)

Technorati Tags: automated virtual patching, cloud security, cloud webinar, dan cornell, denim group, free webinar, security webinar, self healing cloud

November 08, 2011

New Application Security Webinar Series

We've got some great webinars coming up, starting next week. John Dickson be explaining how to rank inherited applications according to the amount of risk they present to an organization, and how you can begin to assess those risks in "Securing Inherited Applications," which will be given in two parts. I'll be talking about automated virtual patching and how it can be successfully employed in "The Self-Healing Cloud."

These should be some great webinars. You can sign up for each below. If you're interested in the topic but can't attend the webinar, sign up to receive information after the webinar.

Monday, November 14, 11am (CST)
Securing Inherited Applications: Phase 1 - Gathering Information
Presented by John Dickson, CISSP

Security officers worry about the security of new applications being built, but what really keeps them up at night is the security of hundreds of applications they've inherited. This webinar will help participants understand how to begin assessing applications that are already build and are likely in production. The first phase of risk assessment is gathering information - Where did this application come from? Who uses the application? Does it fulfill any compliance requirements? What kind of technology does the application use? Attendees will learn what they need to know about inherited applications before they can assess their risks.

Thursday, November 17, 11am (CST)
The Self-Healing Cloud: Protecting Applications and Infrastructure with Automated Virtual Patching
Presented by Dan Cornell

Friday, December 2, 11am (CST)
Securing Inherited Applications: Phase 2 - Risk Ranking
Presented by John Dickson, CISSP

Many security officers worry less about the security of new applications being built and more about the security of hundreds of applications they inherited. What applications represent the biggest risk? What attributes make them more or less risky? What are the most cost-effective courses of action given budget constraints in today's business environment? In a webinar on Monday, November 14, John Dickson explained how and what kind of information to gather about inherited applications. This webinar will help participants create a risk-based approach to managing the security of an existing application portfolio using tools like the OWASP ASVS model. Attendees will get a basic understanding of the risk-ranking process that they can immediately apply to their work environment.

--Dan

dan _at_ denimgroup.com

Technorati Tags: application portfolio risks, application security, automated virtual patching, cloud security, dan cornell, denim group., john dickson, securing inherited applications, self healing cloud, webinars

November 08, 2011 in Training | Permalink | Comments (0) | TrackBack (0)

November 02, 2011

LASCON 2011 Recap: Virtual Patching and Real-World OpenSAMM

LASCON 2011 was last Friday and I have to say I had a great time. The speaker list was fantastic, the hallway conversations were thought-provoking and, as always, the speed debates were not-to-be-missed (and not-to-be-recorded to protect the participants). This bodes well for OWASP AppSecUS being held in Austin in 2012.

I talked about some work we have been doing auto-generating virtual patches in a presentation called “The Self-Healing Cloud” The slides can be found online here

The Self Healing Cloud: Protecting Applications and Infrastructure with Automated Virtual Patching

View more presentations from Denim Group

This talk describes taking the results from various web application scanners, normalizing them and then using that structured data to create custom rules for intrusion detection and prevention systems (IDS/IPS) or web application firewalls (WAFs). We have found this to be an interesting use case for both technologies. It can help make network-centric IDS/IPS systems more web-aware and it can help increase the protection you get from WAFs by teaching them about known vulnerabilities in the applications they are protecting. This has been discussed for a while so we finally set up a lab environment to run some tests and lay out exactly what to expect from this technique. Contact me (dan _at_ denimgroup.com) if you would like more specs on our lab environment so you can re-run the test scenarios and add new scenarios of your own.

Also, Scott Stevens from Denim Group and Phil Beyer from the Texas Education Agency (TEA) gave a presentation about their work using OpenSAMM to create a roadmap for their software security program. Slides are online here:

OpenSAMM in the Real World: Pitfalls Discovered and Treasures Collected Along the Way

View more presentations from Philip Beyer

We’ve had a lot of success working with organizations using OpenSAMM to help them evaluate the state of their current software security efforts as well as plan for the future. This is a great case study of just such an effort.

LASCON has grown to be a well-respected regional event and, as mentioned above, its success has made me excited for the upcoming OWASP AppSecUS conference in Austin in 2012.

--Dan

dan _at_ denimgroup.com