Industry Observations-Vulnerabilities-Web Application Security

Re: Mandated Third Party Static Analysis: Bad Public Policy, Bad Security

Mary Ann Davidson wasn’t shy making her feelings known about scanning third-party software in a lively blog post entitled “Mandated ThirdParty Static Analysis: Bad Public Policy, Bad Security“. If you haven’t read it and you are in security, I do recommend giving it a read. Opinionated and outspoken, Mary Ann lays out her case for not scanning third-party software. In this case, although I don’t totally agree with each individual point, I do agree with the overall conclusion.

Mary Ann delineates many individual reasons organizations should not scan third-party COTS (Commercial Off The Shelf) software. The reasons include non-standard practice, vendors already scan, little-to-no ROI, harm to the product’s overall security, increased risk to other clients, uneven access to security information, and risks to IP protection. I think the case can actually be greatly simplified. Scanning COTS software is simply a waste of time because that is not where most organizations are going to find and reduce risk.

Take web applications, which is at the top of every CISO’s usual list of suspects for risk. Should every organization on the web perform a complete security review of every single layer in this technology stack? Or how about mobile? Should an organization perform a complete review of iOS and Android before writing a mobile app or allowing employees to use mobile phones? I’m sure the consulting industry would love this, but this is simply not feasible for organizations of any size.

So what are we to do? In my opinion, a security team should strive to measure and mitigate the greatest amount of risk to an organization within it’s budgetary and time limitations, enabling business to innovate with a reasonable amount of security assurance. For the vast majority of applications, that formula is going to lead directly to their own custom-written or custom outsourced software; specifically, their web applications.

Most organizations have a large number of web apps, a percentage of which will have horrific vulnerabilities which put the entire organization at risk. These vulnerabilities are well-known, very prevalent, and usually straightforward to remediate. A security program that provides continuous assessment for all the code written and/or commissioned by your organization both during development and deployment should be the front line of security for nearly every organization with a presence on the web, as it normally finds a trove of preventable risk that would otherwise be exploitable to attackers on the web.

So what is the problem with scanning our custom code and third-party COTS software? It is a misallocation of resources. Unless you have unlimited budget and time, you are much better off focusing and evaluating your custom-written source code for vulnerabilities, which can be ranked by criticality and mitigated by your development team.

Again, that is not to say there are no risks in using COTS software. Of course there are. All software has vulnerabilities. Risks are present in every level of a technology stack. For example, a web app may depend on a BIOS/UEFI, an OS, a web server, a database server, an application server, multiple server-side frameworks, multiple client-side frameworks, and many other auxiliary programs.

But the likelihood of your organization performing yet another evaluation of software that has most likely already gone through a security regimen is exponentially less effective in managing risk than focusing more of your security resources on building a more robust security program around your own in-house custom software.

Well, what should we do to mitigate third-party risk? The most overlooked and basic security precaution is to have a full manifest of all third-party COTS and open-source code running in your environment. Few, if any organizations have a full listing of all third-party apps and libraries they use. Keeping an account of this information, and then doing frequent checks for security updates and patches for this third-party code is obvious and elementary, but almost always universally overlooked.

This basic security formula of continuous scanning of custom applications, checking third-party libraries for security updates, and using this information to evaluate the biggest risks to your organization and working to mitigate the most severe risks would have prevented most of the successful web attacks that make daily headlines.

  • Jessica Dodson

    “Keeping an account of this information, and then doing frequent checks for security updates and patches for this third-party code is obvious and elementary, but almost always universally overlooked.”

    Good point. No code is fool-proof, and while you may not have all the time and money in the world one missed security issue could cost you 10x what it would have taken to catch it in the first place. You have to be a thorough as you can possibly manage through every step of the process.