by Bill Pennington
WhiteHat Security recently went in search of a new customer service application and decided we wanted to go with a SAAS based service. Given our line of work we included a security review of the application as one of the steps in our due diligence process. What happened is a text book example of the wrong way and the right way to handle an audit and the subsequent findings.
First a few quick points. If you go to our website above you can see we do web application security for a living, 24x7x365 on some of the largest web sites on the planet. We know what we are talking about when it comes to web application security. Naturally our customers expect us to have the highest level of security for our web applications. Just because we are using an SAAS vendor does not give us an excuse to have a vulnerable web application. Also, we did this assessment on these vendors for free and walked each through our findings. With that out of the way:
Vendor 1: We loved the solution from a functional perspective; it did everything we needed and more. The price was excellent so we started our assessment. We soon discovered the application had numerous serious flaws ranging from Cross Site Scripting to SQL Injection to Insufficient Authorization. This was not completely unexpected, although this application was a little worse than most due to the volume and severity of issues. We set up a call with the vendor’s security and development team, and this is where things went sideways. Their first tactic was to tell us all the vulnerabilities were false positives. This is highly unlikely, since we review all our findings for accuracy. When we asked them why they thought these were false positives, the vendor explained they had a very complex filtering system that would block these attacks “if they were real”. We then explained a few of the findings and showed the results of the test that verified that there was no filtering in place or it was not working. At this point the vendor’s story changed, and they began to explain to us that because users had to be logged in, they did not see these as high risk issues. When asked what would prevent someone from creating an account , the vendor stated “Nothing, it is a self service portal.” With that we thanked everyone for being on the call, offered to answer any further questions they might have and hung up. We told the sales person the next day that we were not going to use their solution.
Vendor #2: This vendor had a solution that was not exactly what we wanted, but that performed the basics we needed plus a few things we did not need. We started the assessment process and found a few high severity issues. Within a day, and without even a phone call, those issues were fixed. The vendor had a few questions about the other issues so we quickly set up a call. The attitude from vendor #2 on the phone was exactly opposite of vendor #1. They were clearly interested in making their software more secure and were not defensive about what we had found. We walked them through a few of the issues they needed help with and they told us they would have them fixed with their next release in about a month.
Needless to say, we are going with Vendor #2.
We do not expect perfection from vendors, nor do we expect them to drop everything to fix all the issues. What we (and you) should expect is the right attitude to examine the issues, correct the highest risk issues and address the lower risk in a time frame that makes sense for both sides. As more and more software moves to the web, more and more of your corporate data moves with it. You can’t outsource risk and liability, so hold your vendors accountable for the security of their solutions. Ask them what they are doing to ensure the security of their web applications. If you get defensive answers or answers that have nothing to do with web application security like, “we use Qualys or Nessus,” I suggest moving along.