Monday, September 21, 2009

Are we being hampered by insecure vendor software?

Well, it's that time of the year when EDU IT staff recover from the initial "school's back in session" marathon. Now, we get to evaluate vendor software offerings for a wide range of IT services ranging from remote desktop support, data encryption to physical surveillance.

Got a tweet from someone saying ""Colleges' decentralized IT systems & open networks are a recipe for the disaster we've experienced." http://bit.ly/3wfwy". I found it interesting that that a group founded by "consumer advocates and experts from the financial industry and law enforcement" rips into EDUs for being the source of most data breaches. One only has to take a look at the Chronicle of Data Breaches at www. privacyrights.org to see that this isn't really the case. In addition, the group doesn't attempt to examine the causes of these breaches. Certainly, business practices and attitudes at EDUs can contribute to the problem, they fail to note that in some cases vendor software provides the vector into an institution's sensitive databases.

Time after time, we run across vendors who try to sell us software that is inherently insecure. We're not talking about some obscure race condition in a software module. We're talking about simple things like input validation and sensitive data in the clear. Why do we still let vendors do this to us? A couple of years ago, security researchers discovered that Oracle passwords were converted to upper case, the hashing algorithm was weak among other errors (http://www.sans.org/reading_room/special/index.php?id=oracle_pass&ref=911). Physical surveillance camera systems transmit video images in the clear. Can you say "Look what's on You Tube?". Sure, software has bugs but you know, I'm tired of the customer being the one to discover a security flaw or worse, be victimized by a security flaw. Whatever happened to vetting software before it's released?

Application vulnerabilities now outnumber OS vulnerabilities. For once, the OS vendors finally got the clue and started to release relatively security bug free code. Application vendors on the other hand haven't answered the clue phone. In fact, in most cases, they've taken extensive measures to modify their EULAs to absolve them of any damage their code may or may not cause. Take a look at the EULAs today and you'll find subtle changes in the EULA wording. Years ago, I was interviewed by USA Today and I made a comment about how I was surprised there weren't any software liability lawsuits against vendors who sold poorly written code. I fear that all that comment did was get company lawyers started in modifying the EULAs rather than fix the real problem.

The latest SANS Institute "Top Cyber Security Risks" (http://www.sans.org/top-cyber-security-risks/) confirms application bugs are more commonly the cause of a security/data breach. This paper shows that SQL Injection Attacks and Cross Site Scripting (XSS) vulnerabilities account for ~80% of web application vulnerabilities today. You know, the solution to these attacks is simple input validation. Why aren't vendors testing their apps for these vulnerabilities? If they are, they need to revise their testing procedures. We've found this flaw in numerous vendor apps when we run a simple vulnerability scanner against the product. We're not rocket scientists and if we can find vulnerabilities, surely a vendor can.

It's time for consumers to issue a set of security requirements that must be met before a software package is purchased. This is nothing new. DISA distributed a draft Application Security Requirements doc (Google for it) back in 2003. OWASP has formed an Application Security Requirements Project group (http://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project) to address this issue. If you want a template that you can modify for your site, take a look at the template doc at http://www.sans.org/appseccontract/ or google for "application security procurement language". This doc is the holy grail for security practitioners but in reality, it will be very difficult if not impossible to find a vendor who would be willing to agree to those requirements.

At least, we'd be putting software vendors on notice that they must take our efforts to secure our enterprise seriously.

rcm, 9/21/09