"Making them apply a quick and dirty patch, followed by a better one two weeks later is much more disruptive and difficult," Hope says. "Small businesses might tolerate that sort of thing, but big regulated businesses cannot patch willy-nilly."
Catalin Cosoi, chief security strategist at Bitdefender, reminds us: "There is no practical way to impose a standard timeframe for patching bugs and even if there were it would be of very little use."
The thing to insist on is a development process that introduces as few bugs as possible in the first place. "Open sourcing software can also help," Cosoi suggests. "Although the quagmire that is web development using PHP teaches us that this tactic can also backfire and lead to lowest-common-denominator software that is exploitable by design."
But is time really the issue? Surely getting the quality of the fix right is more important as a metric of both success and security than simply looking at the headline time-to-patch numbers? How can vendors ensure they are getting this delicate balance right? Tod Beardsley, engineering manager for Metasploit at Rapid7, rather bucks the trend of saying that the quality of the fix should come before the speed at which it is delivered.
He told IT Pro that time to fix is more important than delivering more complete fixes. Done is better than perfect is the mantra that many organisations try to adhere to for regular feature development, Beardsley insists.
"Consider the real world consequences of an imperfect patch," he explains. "An adversary is already using this vulnerability to perform mischief, and likely has already automated his attack to some extent. By doing something simple like blocking an API call or requiring a reauthentication could put him out of business, perhaps for a while as he tries to troubleshoot what's changed."
Admittedly security-by-obscurity is only a problem if that's the only control in place to hide vulnerabilities from attackers. "As long as there's real effort to develop more perfect solutions to vulnerabilities," Beardsley says. "Getting something out today rather than two weeks later can help stem the losses caused by unpatched vulnerabilities in production."
Ron Gula, CEO of Tenable Network Security, argues that if the web service is internet-facing, it will be scanned and if a vulnerability in that service is public, it will be attacked. At the same time, if the patch is of poor quality, it will have a performance or availability impact to your site. "Since most web applications are often part of a more complex deployment of web sites and web services, it can be difficult to understand the true impact of a security vulnerability on a web site when making a decision to take it offline to deploy patches" Gula insists, adding "the best way to ensure a balance is to invest in the ability to make reliable changes. If your web application patches are being deployed by your web application developers as custom changes, and not as a repeatable process or one that can be quickly backed out, you will always have a problem reacting to security issues."
What about flipping the debate on its head? Let's look at this from the enterprise perspective, rather than the vendors. When it comes to best practice in terms of mitigating the security risks of using web apps which will, in all probability, be exposed to vulnerability during their life cycle?
Righard Zwienenberg, senior research fellow with ESET, told IT Pro that "it is therefore important to have policies in place that web applications cannot be used until they have been code reviewed both internally as externally. This minimises the risk of an inside job and makes sure that Safe Programming was used."
A common approach used by hackers is trying to get into databases using SQL injection; making sure that the input for the forms and fields are validated and restricted using Type Safe SQL Parameters makes it a much safer environment, for example. Less specifically speaking, you can create web apps for complex software and then the answer to this isn't really any different than the usual best practices, according to Beardsley. He advises: "Run your software with least privilege. Keep on top of fixes. If it's open source, vet the codebase for obvious errors. If it's proprietary, consider an open source alternative. In either case, black-box validation and fuzzing can help identify problem areas."
The thing is, web apps are different; they don't usually offer avenues of attack like stack-based buffer overflows but they do tend to offer environments for straight code execution and on-disk data manipulation. "The skill sets used by web app attackers is necessarily different from the skills used by more traditional reverse engineers," Beardsley concludes. Organisations that recognise this make better hiring decisions for their on-staff security staff and deployment staff.
"Above all, if, as a customer, if you can keep in close contact with a vendor," Beardsley says. "You can provide feedback and testing resources for security fixes and, ultimately, make your chosen software environment better for both yourself and everyone else. Heck, maybe you'll get some favourable pricing the next time your renewal comes up for your efforts."
