Denim Group, Ltd. Blog

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

Posted via email from Denim Group's Posterous

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

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

--Dan

dan _at_ denimgroup.com

@danielcornell

Posted via email from Denim Group's Posterous

"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

Posted via email from Denim Group's Posterous

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.

 

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.

 

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.

 

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.

 

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

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.

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

 

Posted via email from Denim Group's Posterous