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

By Dan Cornell

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 1st, 2012 at 9:30am in Room 302. Hope to see folks there!

Contact us if you want to meet up at RSA.

--Dan

dan _at_ denimgroup.com

@danielcornell

OWASP AppSecUS Video/Slides Online: Self Healing Cloud

By Dan Cornell

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:

Contact us if you want to discuss expediating software remediation with virtual patching.

--Dan

dan _at_ denimgroup.com

@danielcornell

Remediation On Rails: Executing Your Software Security Remediation Project

By Dan Cornell

[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:

Contact us for help making your software security remediation projects successful.

--Dan

dan _at_ denimgroup.com

@danielcornell

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

By Dan Cornell

[See yesterday’s post “’FIX IT!’ Ain’t Gonna Cut It” for more informaiton 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 exerpt 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 scheduled 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 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:

Contact us for help getting software security remediation projects off to a solid start.

--Dan

dan _at_ denimgroup.com

@danielcornell

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

By Dan Cornell

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:

Contact us for help getting software security remediation projects off to a solid start.

--Dan

dan _at_ denimgroup.com

@danielcornell

Webinar: The Self-Healing Cloud

 

By Dan Cornell

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.

 Register Now Button

Contact us for if you are interested in talking more about virtual patching.

--Dan

dan _at_ denimgroup.com

@danielcornell

New Application Security Webinar Series

By Dan Cornell

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.

 Register Now Button

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.

 Register Now Button

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.

 Register Now Button

Contact us for if you are interested in talking more about virtual patching or application portfolio risk ranking.

--Dan

dan _at_ denimgroup.com

@danielcornell

LASCON 2011 Recap: Virtual Patching and Real-World OpenSAMM

By Dan Cornell

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

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:

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.

Contact us for if you are interested in talking more about virtual patching or crafting a software security program.

--Dan

dan _at_ denimgroup.com

@danielcornell

 

Denim Group at LASCON 2011

By Dan Cornell

LASCON 2011 is coming up Friday October 28th and there will be two talks from Denim Group folks. I had to miss LASCON last year because of a last-minute trip to India so I’m really looking forward to this year. The speaker lineup is fantastic and the Austin OWASP gang knows how to throw a party. It should be a really valuable event and a great preview of next year’s OWASP AppSec conference.

Phil Beyer from the Texas Education Agency (TEA) will be presenting with Denim Group’s Scott Stevens in a talk titled “OpenSAMM in the Real World: Pitfalls Discovered and Treasure Collected Along the Way”  The talk abstract is:

In "Pitfall!", a player must maneuver Pitfall Harry through a maze-like jungle to stay alive. Along the way, he must negotiate numerous hazards, try to recover treasure, and do it all in a limited time. Implementing OpenSAMM in a large organization is kinda like playing that classic game.

It's a little dangerous, requires vision, planning, and precision, and promises rewards. Like many of its size and with its mandate, the Texas Education Agency already has an SDLC. Enter Pitfall Phil. In an effort to build a stronger program, Pitfall Phil shifted the focus of TEA's application security program to align with OpenSAMM. We will present the hazards he discovered and the treasure he found while playing the game.

Also, I will be giving a presentation on some automated virtual patching work we have been doing titled “The Self Healing Cloud: Protecting Applications and Infrastructure with Automated Virtual Patching”  That talk’s abstract is:

Organizations often have to deploy arbitrary applications on their infrastructure without thorough security testing. These applications can contain serious security vulnerabilities that can be detected and exploited remotely and in an automated manner. The applications themselves and the infrastructure they are deployed on are then at risk of exploitation. Configuration changes or vendor-provided software updates and patches are typically used to address infrastructure vulnerabilities. However, 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 (WAFs) or other IDS/IPS technologies to help mitigate specific known application vulnerabilities. This allows applications to be “virtually” patched prior to actual code-level patches being applied. These virtual patches are most often applicable to vulnerabilities that have a strong detection signature such as SQL injection and cross-site scripting (XSS) because the detection rules can be targeted to detect these signatures, but limited only to specific parts of the application attack surface where the application is known to be vulnerable.

This presentation examines the automatic creation of virtual patches from automated web application security scanner results and explores scenarios where this approach might be successfully employed. It discusses theoretical approaches to the problem and provides specific demonstrations using Open Source tools such as the skipfish and w3af scanners and Snort and mod_security protection technologies. Finally, it looks at opportunities to apply these techniques to protect arbitrary applications deployed into arbitrary infrastructures so that short-term protection against common web application attacks can be consistently applied while minimizing false blocking of legitimate traffic.

Again – this should be a great conference.  Contact us if you want to meet up at OWASP LASCON in Austin.

--Dan

dan _at_ denimgroup.com

@danielcornell

Physical Security and Application Security - Where the Two Worlds Collide

By John B. Dickson, CISSP

I recently had the opportunity to attend the ASIS International Annual Seminar and Exhibits in Orlando, Florida. ASIS is the largest physical security conference in the world and arguably one of the oldest security trade groups in the US (they have been around since 1955). With 20,000+ in attendance, it’s hard to argue that this wasn’t one of the premier conferences in the security industry.  I’m probably more of an information security guy than a physical security person, whose limited exposure to the physical security world has been through the CISSP certification (one block of instruction) and during the infrequent red team exercises I’ve participated in during my career where breaking and entering a client’s office complex was part of a contracted project.

What brought me to the ASIS conference was the ISC2, the International Information Systems Security Certification Consortium, and its Security Congress. The Security Congress tracks ran concurrently with the ASIS conference, attracting nearly 1,000 attendees from the traditional information security field. ISC2 had separate speaker tracks that addressed application security, cloud security and social networking. My session had about 40 attendees – a little light but a good group. The interaction was solid and the questions insightful. In short, the speaker session might as well have been at any mainstream information security conference.

Where I experienced culture shock the most was on the ASIS expo floor. For those that argue that the physical security and information security fields are converging, my first ASIS led me to believe otherwise. For starters, more than half of the exhibitors wore dark suits, as did many of the attendees (and, yes, I did see a fair share of three-piece suits). This was in stark comparison to RSA, where most of the booth workers look liked they just hopped off the 18th hole, albeit with matching company golf shirts.

There was a formal air to the expo, including several dark panel wood booths that looked more like a law office library room than a trade show expo stand. Like the info security world, 85-90% of the attendees were men, but the average age at ASIS felt 10-15 years older than RSA, by comparison (I did not quantify that!)

(download)

The biggest difference between ASIS and RSA/Blackhat, etc., were the vendors. Very, very little overlap existed between those at ASIS and the information security conferences I’ve attended recently, and I’ve spoken at and attended a bunch. The big names were 3M, Ingersoll Rand, Honeywell, and not RSA, Symantec, IBM and the usual suspects from the infosec product and service world.

Having said that, there were some very cool things I saw at ASIS that I would never see at a mainstream information security conference. Barbed wire, for example. Seeing a barbed wire display actually jolted me into full awareness that I was not at an infosec conference. The company selling remote-controlled helicopters for SWAT surveillance tickling the geeky side of me. Seeing the fully-Kevlared out SWAT booth worker could not have been cooler too. And who could knock the executive security folks and their booth video showing how they whisk high-profile executives out of harm’s way. I want that.

My head was totally on a swivel as I walked through the acres of trade show booths. I guess it makes sense, but there were a ton of security badge vendors hawking their wares too. Not proximity badge guys, just the guys that actually manufacture the plastic badges and lanyards.  

We get pretty wrapped up in the infosec and appsec world, so ASIS was a good reminder that the physical security world is a robust industry that is as highly valued, if not more valued, than our own. There appeared to be some heavyweight buyers on the tradeshow floor, if the elaborate booths were any indication.

I’d like to see more events where the two worlds converge, but candidly, after ASIS it struck me how far they are in fact apart. Different people, different vendors, and different concerns. I know physical security guys will jump all over this, but my vote is that convergence is still more an aspiration than a reality, at least as evidenced by ASIS 2011.