Application Security Questionnaires - The Time is Now!

Back in 2009, I posted a note talking about vendor software security vulnerabilities and how they undermine our security. Way back in the early 2000's, I was quoted in a USA Today article on Cybersecurity saying that I was surprised that there weren't many product liability lawsuits against software vendors. In my 2009 blog post, I said I feared that comment only caused software vendors to modify their EULAs instead of fixing the problem.

This problem has been around since the first program was written. The difference is that people are actively searching for these bugs to gain access to an organization's network and data.  I believe it is the fundamental vector for APT (I hate that term) attacks. Mudge told President Clinton about this problem in the late 1990's. 

I still hope vendors will actually check their code for common vulnerabilities. However, here are some recent instances that are telling me otherwise.

1. Vendor www application fails a standard vulnerability scan from a commercial and freeware scanning tool. XSS flaws across multiple pages in their hierarchy were the most common error.

2. Vendor supplied password of "changeme" resulted in a compromise while they were onsite installing the software. They were surprised to find out our network was "open" to the net.

3. Vendor password requirements undercutting our password strength requirements.

We're in the process of modifying a Security Questionnaire for Software Vendors doc that we had in place for a number of years. It's outdated now but it did ask www app vendors if their software was vulnerable to any of the flaws mentioned in the OWASP Top 10 Security Risks ( https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project ).  There have been a number of efforts to create an Application Security Questionnaire but they haven't gained acceptance.

Why? These questionnaires are site-specific by nature. It's hard nee impossible to create a consensus document that addresses all sectors (.com, .mil., .edu, .org, etc.) of business or government.  There is vendor resistance to any "requirements" clause. The recent flap caused by such a requirement in one of the recent Federal cybersecurity bills in Congress are examples of this resistance.  To them, I say "if you had done it in the first place, there wouldn't be this attempt to 'regulate' you."

Some of these include:

1. http://www.sans.org/appseccontract/
2. https://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project
3. http://searchsoftwarequality.techtarget.com/answer/Security-requirements-for-any-Web-application

For more links, google "application security requirements" for some useful links.


Here is my wishlist for software vendors:

1. Train your programmers in secure coding techniques. If they still leave security holes in your code, find another place for them in your organization.
2. Run a vulnerability scanner against your products. Your customers will start doing that soon. It's much worse for your reputation if the customer runs a scanners and finds errors.
3. Pay attention to the results in #2 and fix the problems before releasing it.
4. Do NOT assume the network will "protect" your application. 
5. Follow some sort of best practices for password strength guidelines. Don't ever convert everything to upper or lower case only.
6. Never store user passwords in the clear. That's just plain idiotic.
7. Store sensitive data in an encrypted format. It can be done with the common database systems properly. See #1.

The purpose of a site questionnaire is to provide the customer with information about the security of the vendor applications they are considering purchasing. "Failing" the questionnaire isn't an automatic no-buy action. It informs the customer that additional security controls must be in place.

The questionnaire is another component in a risk-based security management strategy. If the software is needed for business purposes and the user accepts the risk, then purchase can continue.

The time of software vendors letting the customer debug their code has to come to an end immediately. OS vendors have done this and the number of OS issues has been reduced. It's time for application vendors to step up and deliver.

1/2/2013 RCM