Denim Group's Posterous

Application Security and Software Development

Outsourcing Security Fixes: The Good, The Bad, The Ugly

Img_2362

Jeremiah Grossman from WhiteHat Security recently posted a list of firms willing and able to fix vulnerable code for you. Denim Group was on the list - we've been doing software security remediation for quite some time now - and we really appreciate the mention. The point of this blog post is to start a discussion about situations where outsourced security remediation makes sense - as well as where it doesn't. We've had the opportunity to do a lot of software security remediation projects, and we've also talked folks out of using our services on more than one occasion where it wasn't their best way forward. Outsourcing can be a powerful option, but it is one that comes with tradeoffs.
The good:
  • Security-Smart Developers - If you rely on an outside firm to do your security fixes you can (and should) expect that the developers working on your project are trained in secure coding, understand the issues they are fixing and are in a position to make recommendations on your best options for fixing vulnerabilities as efficiently as possible. Ideally all of the developers on your in-house teams would have these capabilities but the reality is that there is still a pretty significant knowledge gap in this area. A classic reason for hiring a consultant is to get access to skills that you don't have - or don't have enough of - in-house and this holds true in these circumstances. One important thing to focus on if you make the decision to outsource security fixes is what sort of knowledge transfer you should expect so that your in-house development teams can learn lessons based on past mistakes.
  • Flexible Capacity - I've never met a development team that felt like they had too many resources or too few bugs or feature requests. Good developers are expensive and as a result most organizations tend to keep theirs pretty busy. In a case where you have to get things fixed on a specific timeframe, outsourcing can be a great option. In one organization, the development manager told me "All of my people are fully committed for the next six months; we simply don't have the time to devote to fixing these issues." That's a tough situation to be in and outsourcing security fixes can make a lot of sense if you find yourself in it.
The bad:
  • Unfamiliarity With the Application - Though it might seem like a great idea to parachute in a team of secure coding ninjas just be done with it, you also need to remember that there is going to be a learning curve for any developer working on a new application. If in-house developers understand the application to be remediated then using an outsourced team might not make a lot of sense because you're likely going to have to pay them to get up to speed.
  • Unfamiliarity With the Environment - Making changes to code to fix vulnerabilities is great. However you really only get the benefits of those code changes when those changes get pushed live. In addition to understanding the application, the people making security fixes are probably going to have to understand the environment in which the application is deployed so this represents another ramp-up cost that applies in outsourcing situations but might not apply if the fixes were performed by in-house development teams.
The ugly:
  • Fixes Can't Be Done in a Vacuum - At Denim Group we use an outside firm to deliver bottled water and to fill up our water coolers and this is a pretty "hands-off" relationship. They show up from time to time, drop off bottled water and, I assume, they eventually invoice us and we pay them. Super-easy. Outsourcing security fixes is not like this. As mentioned above, the team making the security fixes is going to need information about the application they are fixing and they are going to need help getting updated code deployed. As an external developer, I don't want to have (nor should you want me to have) the root password to your production servers. Outsourcing security remediation can allow you to make a lot of progress in a short amount of time, but you will still need to devote some internal resources to making these projects successful. Ask up-front about how much time will be required from your team and what support you should expect to provide.
So when does outsourcing security fixes make sense? Here are a couple of example situations:
  • Overwhelmed Development Teams - If you have vulnerabilities that must be fixed, either because of a compliance mandate or because identified vulnerabilities are so high-risk that you cannot let them remain, then it can make a lot of sense to call in a 3rd party to do your security remediation. It will cost you some money, but you can get things fixed quickly and you have minimal disruption for your internal teams.
  • End-Of-Life Applications - We once did a security remediation engagement for an application that was 10 years old and had been end-of-lifed for the last five of those years. Anyone who knew anything about the application was long-gone and everyone was afraid to touch it. Outsourcing remediation made a lot of sense in that case because anyone would have had to learn how the application worked - why waste the time of the internal development team to get up to speed on an application they all hoped they'd never have to touch again.
And when does outsourcing security fixes not make sense? Here's a counter-example:
  • Applications With Strong Agile/DevOps Practices - A number of Agile and DevOps practices such as continuous integration, automated testing and one-click deployment both help reduce the cost of fixing security issues as well as make it much easier to address security issues in-house. If environment set-up, testing and deployment are very low-cost for your in-house teams then the costs of outsourcing become even more pronounced.
There is more than one way to approach fixing security vulnerabilities and more than one way to approach outsourced security remediation. This list of pros and cons isn't exhaustive, but it should start to provide some background for making decisions. Also we've released a free HOWTO Guide that should be helpful whether you decide to do your remediation in-house or via a 3rd party:
Contact us to have a frank discussion about your options for getting vulnerabilities fixed.
--Dan
dan _at_ denimgroup.com

Upcoming Webinar: Keeping Your Data Safe

By John Dickson

 

We’ve got a great webinar coming up later this month. We’re partnering with Inspired eLearning, a web-based training solutions provider, to put on this webinar about protecting sensitive credit card data. If you work with customer credit card data and are struggling with PCI DSS compliance, this webinar can help your organization.

 

Keeping Your Data Safe: Protecting Your Organization from Web Hackers

Thursday, May 31

12 p.m. CT

 

Businesses store and process sensitive credit card information today more than ever before. Yet companies don’t always protect that data well, leading to expensive public breaches that cost the organization both money and customer trust. It is vital that businesses keep consumer credit card information safe from malicious users. Join us to learn how to identify technology and process vulnerabilities that pose a risk to the security of cardholder data, and how your software developers and IT department can help keep your organization safe. Join Denim Group and Inspired eLearning to find out what your organization needs to know about application security.

 

Register now!

 

Contact us for help with PCI DSS compliance.

--John

dan _at_ denimgroup.com

@johnbdickson

Outsourcing Security Fixes: The Good, The Bad, The Ugly

By Dan Cornell 

Cody

Jeremiah Grossman from WhiteHat Security recently posted a list of firms willing and able to fix vulnerable code for you. Denim Group was on the list - we've been doing software security remediation for quite some time now - and we really appreciate the mention. The point of this blog post is to start a discussion about situations where outsourced security remediation makes sense - as well as where it doesn't. We've had the opportunity to do a lot of software security remediation projects, and we've also talked folks out of using our services on more than one occasion where it wasn't their best way forward. Outsourcing can be a powerful option, but it is one that comes with tradeoffs.

The good:

  • Security-Smart Developers - If you rely on an outside firm to do your security fixes you can (and should) expect that the developers working on your project are trained in secure coding, understand the issues they are fixing and are in a position to make recommendations on your best options for fixing vulnerabilities as efficiently as possible. Ideally all of the developers on your in-house teams would have these capabilities but the reality is that there is still a pretty significant knowledge gap in this area. A classic reason for hiring a consultant is to get access to skills that you don't have - or don't have enough of - in-house and this holds true in these circumstances. One important thing to focus on if you make the decision to outsource security fixes is what sort of knowledge transfer you should expect so that your in-house development teams can learn lessons based on past mistakes.
  • Flexible Capacity - I've never met a development team that felt like they had too many resources or too few bugs or feature requests. Good developers are expensive and as a result most organizations tend to keep theirs pretty busy. In a case where you have to get things fixed on a specific timeframe, outsourcing can be a great option. In one organization, the development manager told me "All of my people are fully committed for the next six months; we simply don't have the time to devote to fixing these issues." That's a tough situation to be in and outsourcing security fixes can make a lot of sense if you find yourself in it.

The bad:

  • Unfamiliarity With the Application - Though it might seem like a great idea to parachute in a team of secure coding ninjas just be done with it, you also need to remember that there is going to be a learning curve for any developer working on a new application. If in-house developers understand the application to be remediated then using an outsourced team might not make a lot of sense because you're likely going to have to pay them to get up to speed.
  • Unfamiliarity With the Environment - Making changes to code to fix vulnerabilities is great. However you really only get the benefits of those code changes when those changes get pushed live. In addition to understanding the application, the people making security fixes are probably going to have to understand the environment in which the application is deployed so this represents another ramp-up cost that applies in outsourcing situations but might not apply if the fixes were performed by in-house development teams.

The ugly:

  • Fixes Can't Be Done in a Vacuum - At Denim Group we use an outside firm to deliver bottled water and to fill up our water coolers and this is a pretty "hands-off" relationship. They show up from time to time, drop off bottled water and, I assume, they eventually invoice us and we pay them. Super-easy. Outsourcing security fixes is not like this. As mentioned above, the team making the security fixes is going to need information about the application they are fixing and they are going to need help getting updated code deployed. As an external developer, I don't want to have (nor should you want me to have) the root password to your production servers. Outsourcing security remediation can allow you to make a lot of progress in a short amount of time, but you will still need to devote some internal resources to making these projects successful. Ask up-front about how much time will be required from your team and what support you should expect to provide.

So when does outsourcing security fixes make sense? Here are a couple of example situations:

  • Overwhelmed Development Teams - If you have vulnerabilities that must be fixed, either because of a compliance mandate or because identified vulnerabilities are so high-risk that you cannot let them remain, then it can make a lot of sense to call in a 3rd party to do your security remediation. It will cost you some money, but you can get things fixed quickly and you have minimal disruption for your internal teams.
  • End-Of-Life Applications - We once did a security remediation engagement for an application that was 10 years old and had been end-of-lifed for the last five of those years. Anyone who knew anything about the application was long-gone and everyone was afraid to touch it. Outsourcing remediation made a lot of sense in that case because anyone would have had to learn how the application worked - why waste the time of the internal development team to get up to speed on an application they all hoped they'd never have to touch again.

And when does outsourcing security fixes not make sense? Here's a counter-example:

  • Applications With Strong Agile/DevOps Practices - A number of Agile and DevOps practices such as continuous integration, automated testing and one-click deployment both help reduce the cost of fixing security issues as well as make it much easier to address security issues in-house. If environment set-up, testing and deployment are very low-cost for your in-house teams then the costs of outsourcing become even more pronounced.

There is more than one way to approach fixing security vulnerabilities and more than one way to approach outsourced security remediation. This list of pros and cons isn't exhaustive, but it should start to provide some background for making decisions. Also we've released a free HOWTO Guide that should be helpful whether you decide to do your remediation in-house or via a 3rd party:

Contact us to have a frank discussion about your options for getting vulnerabilities fixed.

--Dan

dan _at_ denimgroup.com

@danielcornell

Handling Challenge/Response Logins in NTOSpider

This is the latest in a series of blog posts we've been doing looking at how various web application scanning tools handle different real-world application login scenarios. You can see the previous posts we've done:
We also set up a GitHub repository with a mock-up of the example login so you can try it out on your own.
This post looks at handling that login example using NTObjectives NTOSpider to handle the same login - many thanks to Dan Kuykendall and Drew Flickema from NTO for putting this together and sending it along.
The first part of the login can be handled by NTO's standard Forms Authentication handling - just enter the username and password.

Then to handle the second login question you use a regex for the input population name/value customization like this:

Note that if you wanted to handle different login questions (answer_1, answer_2 and so on) you could enter those values specifically rather than using the blanket regex.
So - thanks again to the NTO folks for sending this along. If any other scanner vendors want to weigh in please take a look at the GitHub site, give it a try and send the info my way. I'll get it posted online for you.
--Dan
dan _at_ denimgroup.com

(download)

ThreadFix Thursday: Application Criticality Ranking, User-Requested Features and Reporting Updates

Moving along here in the ThreadFix world and making some great progress. There have been a couple of recent developments:
  • We've just released the Beta14 build which can be downloaded from the Google Code site. Improvements include some bug fixes, importer updates, application criticality ranking and a cool report showing the most recent scans for applications based on their criticality.
  • We've seen a real increase in user-requested features coming in through the Google Code bug tracker as well as to me personally via email. Keep 'em coming! Feedback is the breakfast of champions.
  • I'll be putting up some blog posts over the next week or so outlining specific ThreadFix use cases and integrations with various tools. Keep an eye out and if there is something you're interested in seeing let us know.
--Dan
dan _at_ denimgroup.com

SOURCE Boston Video Online: What Permissions Does Your Database User REALLY Need

The good folks from SOURCE Boston now have the video from my session "What Permissions Does Your Database User REALLY Need?" posted online:
You can also check out the slides online here:
Code samples can be found up on the sqlpermcalc site on GitHub.
--Dan
dan _at_ denimgroup.com

Handling Challenge/Response Logins in Mavituna Netsparker

This is the latest in a series of posts we've been doing looking at how different web application scanning tools can be configured to handle a somewhat complicated login routine we ran into a while back. We originally posted a solution that chained IBM Rational AppScan with BurpSuite, the IBM folks demonstrated how it could be done natively within AppScan and the HP folks also sent along info on how WebInspect could be configured to handle it as well. This even inspired us to put a mock-up of the authentication routine up on GitHub.
So - now the folks at Mavituna Security sent along some notes on how to configure their Netsparker scanner to handle a login scenario like this. You can see a screencast showing the configuration of the tool here:
They also send along example C# and XML configuration files.
The C# code from the video is:
using System;
using System.Text;
using System.Text.RegularExpressions;
using MSL.Core.Components.Forms;
using MSL.Core.Process.Authentication;
using MSL.Core.Process.Extensibility;
using MSL.Core.Process.Network.Http;

[ExtensibilityClass]
public static class MyScriptMethods
{
    private static string TwoFactorAnswer;
    private static string TwoFactorQuestion;

    [ExtensibilityMethod(typeof(FormAuthenticationBeforeRequestHandler))]
    public static void BeforeAuthenticationMacroRequest(IHttpRequest request)
    {
        if (request.Id == "Request2")
        {
            request.Body = request.Body.Replace("{{q}}", TwoFactorQuestion);
            request.Body = request.Body.Replace("{{a}}", TwoFactorQuestion);
            request.Body = request.Body.Replace("{{answer}}", TwoFactorAnswer);
            TwoFactorAnswer = string.Empty;
        }
        else
        {
            return;
        }
    }

    [ExtensibilityMethod(typeof(FormAuthenticationAfterResponseHandler))]
    public static void AfterAuthenticationMacroResponse(IHttpRequest request)
    {
        if (request.Id == "Request1")
        {
            string TwoFactorHttpResponseBody;
            string TwoFactorString = "";
            TwoFactorHttpResponseBody = request.Response.Body.ToString();

            Match TwoFactorChar = Regex.Match(TwoFactorHttpResponseBody, "answer_[0-9]*", RegexOptions.IgnoreCase);

            if (TwoFactorChar.ToString() == "answer_1234")
            {
                TwoFactorAnswer = "apple1";
                TwoFactorQuestion = "1234";
            }
            else if (TwoFactorChar.ToString() == "answer_817")
            {
                TwoFactorAnswer = "apple2";
                TwoFactorQuestion = "817";
            }
            else if (TwoFactorChar.ToString() == "answer_423")
            {
                TwoFactorAnswer = "apple3";
                TwoFactorQuestion = "423";
            }

            TwoFactorString = "";
        }
        else
        {
            return;
        }
    }
}

And the XML login macro used in the video is:
<?
xml version="1.0" encoding="utf-8"?>

<request>

<headers>

      <header>
        <name>Accept-Language</name>
        <value>tr-TR</value>
      </header>
      <header>
        <name>UA-CPU</name>
        <value>AMD64</value>
      </header>

</headers>

    <body />
    <id>33520784-0434-496d-be2c-c16da42fcfb5</id>

<method>GET</method>

</request>

<request>

<headers>

      <header>
        <name>Accept-Language</name>
        <value>tr-TR</value>
      </header>
      <header>
        <name>UA-CPU</name>
        <value>AMD64</value>
      </header>
      <header>
        <name>Pragma</name>
        <value>no-cache</value>
      </header>

</headers>

    <body>username=testuser&amp;password=password</body>
    <id>Request1</id>

<method>POST</method>

</request>

<request>

<headers>

      <header>
        <name>Accept-Language</name>
        <value>tr-TR</value>
      </header>
      <header>
        <name>UA-CPU</name>
        <value>AMD64</value>
      </header>
      <header>
        <name>Pragma</name>
        <value>no-cache</value>
      </header>

</headers>

    <body>questions={{q}}&amp;answer_{{a}}={{answer}}</bo

HPIO Video: The Permissions Your Database Users Really Need

By Dan Cornell

While I was at SOURCE Boston this year I had the opportunity to speak with Lisa Vaas about database user security permissions. Video from this discussion has been posted to the HPIO site:

(Their original post is here)

Also we've posted slides from the presentation discussed in the video "What Permissions Does Your Database User REALLY Need?"

A number of people have been reaching out about the sqlpermcalc tool we released so hopefully we'll be pushing out some updates soon to make the query handling more robust.

Contact us for help securing your web-attached databases.

--Dan

dan _at_ denimgroup.com

@danielcornell

Handling Challenge/Response Logins In HP WebInspect

By Dan Cornell

About a week ago we posted some info about how we chained AppScan and BurpSuite together to handle a site with a somewhat complicated challenge/response login scheme. Apparently this got the Twitter-world all excited – you can read all about it on Dinis Cruz's blog. A really cool outcome of all this discussion is that some of the scanner vendors have started publishing information about how their scanners can be configured to handle similar login situations based on some mock-up code we released on GitHub. This post is to highlight the response from the good folks at HP about how to configure WebInspect to handle this login scenario.

They put up a blog post about it here: Challenge-Response Authentication? No Problem

They also put together a rather extensive set of slides describing the target scenario as well as some more complicated twists here:

(Original slides link is here)

Many thanks to Rafal Los and Hans Enders from HP for putting this together and making it available. I agree with Dinis that talking about these real-world scenarios is really valuable and I appreciate you all taking the time to write-up and release this information. I've got stuff from a couple of the other scanner folks that I'll be reviewing and posting soon.

Contact us for help getting the most out of your investment in web application scanners.

--Dan

dan _at_ denimgroup.com

@danielcornell

Automated Application Scanning: Handling Complicated Logins with AppScan (Only!)

By Dan Cornell

We put up a blog post two days ago demonstrating how to get IBM Rational AppScan to perform a complex login routine by chaining it together with BurpSuite. Ory Segal (@orysegal) from IBM Rational reached out with a simpler method to handle this natively in AppScan. It involves configuring AppScan to add a custom parameter to each request. For the sample case in the authexamples GitHub repository it would be handled like this:

App_scan_login_screenshot

This then handles the same gymnastics we were doing with BurpSuite's inline editing before – resulting in a successful login sequence and a valid session:

App_scan_login_screenshot_2

Fun stuff! Many thanks to Ory for sending this along – we really appreciate the insight. For other scanner tool vendors – how would YOU recommend your users accomplish this same task? Either put up a blog post about it and send me the link or if you send me some notes and a screenshot or two I am happy to do it.

Also I've been talking with our web application pen test folks to get more examples to add to the authexamples GitHub repository. If you have any suggestions please send them my way.

Contact us for help getting the most out of your application scanning tools.

--Dan

dan _at_ denimgroup.com

@danielcornell