How can security vendors reduce their own attack surface?

News by Davey Winder

Following the news that Trend Micro's Password Manager would allow hackers to execute malicious code we ask, how secure are security applications?

Trend Micro is the latest in an increasingly long list of security vendors found wanting when it comes to securing their own products. The Trend Micro 'Password Manager' vulnerabilities which would enable hackers to execute malicious code and the contents of the password vault, were uncovered by Google Project Zero researcher Tavis Ormandy.

Trend Micro moved quickly to fix the vulnerability, working with Ormandy to identify the flaw and then creating a patch. ActiveUpdates in the product can't be turned off which means that when the update was rolled out, it was quickly uploaded to all customers.

By their very nature, antivirus and security solutions have a large attack surface; they offer lots of layers of protection and are comprised of myriad component structures. It goes without saying that there is a lot of code, often running with high privilege, that has the potential to be flawed.

According to Risk Based Security there have been more than 1,700 vulnerabilities reported in security solutions during the last six years, 372 of them in 2015 alone.

Kaspersky Lab even went as far as to include attacks on security vendors as being a trend to watch for in its 2016 predictions list – perhaps not too surprising as Kaspersky was targeted by Duqu 2.0 malware which it discovered (and stopped) trying to exfiltrate data from its servers last year.

Adrian Sanabria, senior security analyst with 451 Research, told that we should remember the infamous 'Trusted Computing' memo by Bill Gates which celebrates its 14th anniversary on 17 January. This is every bit as relevant today as it was then, with Gates pointing out that trusted computing is about more than just building as secure a product as possible.

It's about how the product is designed to be used and how the company handles vulnerabilities and issues when they are discovered. Will the vendor readily admit its mistake, act quickly and transparently? It all comes down to whether the customer trusts the vendor to handle the situation appropriately or not.

"After more than a decade of publicised breaches," Sanabria says, "we've seen that the more responsive, honest and transparent a vendor is about issues, the more likely customers are to forgive them. A vendor's true character tends to show when that vendor is under duress, and that can have a big effect on how people perceive the company and its products."

All that said, Sanabria admits that ultimately it's down to the organisation buying the security product "to assume the worst and depend on their own due diligence process".

Paul Fletcher, cyber security evangelist at Alert Logic, agrees that there should be a certain level of trust because a security company should be securing its own code and safeguarding its products. However, that said, ultimately security teams need to "trust but verify" as Fletcher puts it. "Organisations need to dedicate resources in terms of time, training and people in order to completely understand the security solution they have," he advises, "to know the features and strengths and weaknesses of the security tools they are managing."

Splunk security evangelist Matthias Maier reminds us that we are living in "the age of the inevitable breach" and that if you "review the CVE Database, you'll see every major security vendor has reported their product vulnerabilities." So in light of the recent flaws across a whole raft of products, how secure are endpoint security solutions and how much trust should we place in them?

Maier suggests that organisations should "run additional basic penetration tests before software gets rolled out" to uncover not just software vulnerabilities, but also the mis-configurations that can lead to a vulnerability.

Minimise harm

As these type of products present such a large attack surface, do vendors not have a responsibility to ensure the strictest of secure development standards are enforced to minimise the potential for harm?

Professor Steven Furnell, a senior member of the IEEE and professor of IT security at Plymouth University, doesn't mince his words when he says, "Given that they are offering products and services that are claiming to protect our systems and data, it is entirely reasonable for customers to assume that such offerings will be sufficiently secure."

And, indeed, given the business they are in, it's reasonable for us to expect that security vendors will be developing and testing their products to appropriate standards, standards which, you might think, would arguably be higher than the average.

"In reality," Prof Furnell admits, "100 percent security will be just as elusive for security vendors as it will be for anyone else." We need to be realistic, therefore, that some flaws may still be discovered. "What we not expect to see," the professor concludes, "is predictable and easily avoidable stuff slipping through."

Slawek Ligier, vice president of engineering at Barracuda Networks, insists that security solutions are already under a much higher level of scrutiny than any other software and for a very good reason. "This scrutiny will lead to better, more secure solutions," he told us. "Security vendors have a responsibility to ensure that their products can stand up to scrutiny, but also have the know-how to do this."

Ligier knows that, as security vendors, there is an important responsibility to ensure that solutions are as secure as can be. This starts with the development process: engineers need to be fully aware of the best, most secure coding practices and the latest attack vectors. "As an example we conduct training and regular hackathons using both sample applications with known vulnerabilities as well as our own solutions," Ligier says. "Understanding attack techniques helps engineers think like an adversary and develop code that is less likely to be exploited."

In the sandbox

Why aren't more 'antivirus' unpackers, emulators and parsers sandboxed rather than running with system privileges? Why isn't sandboxing a generic part of the secure development roadmap? "This is most likely a requirement to supersede any viruses' access or file permissions, but it's a good point," concedes Robert Hansen, VP WhiteHat Labs at WhiteHat Security. "It will probably go more that way as performance increases and sandboxes become less of a burden to CPU time and batteries."

Stephen Love, the security practice lead at Insight, told that to add sandboxing to the solution roadmap would require the vendor to provide a cloud sandbox solution that the endpoint client could send a file up to the service for testing in the sandbox. "But the issue with that is it could then be reliant on the scale of the solution," he warns.

Lorenzo Grespan is a developer with application security specialists Pentest who suggested in an interview with SC that when it comes to assessing the security of any software, there are two approaches: trust them to be secure until proven otherwise, or assume they are insecure and mitigate the impact that a vulnerability will have before it happens.

"While it is in the best interest of a vendor to try to convince us that their product falls into the former category," Grespan explained, "experience tells us that it is wiser to use the latter approach." Indeed, better safe than sorry would seem to be a good fit in any security scenario.

Unfortunately, as Grespan pointed out, for some vendors and for certain products they are ill suited for mitigation strategies as their approach is an all-or-nothing one as far as requiring system or network privileges is concerned.

Grespan advocates a system of public independent assessment when it comes to security products and for good reason. "Information asymmetry between buyers and sellers lowers the product quality," he concludes. "Economists call this a lemon market. Because of the closed nature of commercial security products and the lack of public assessment, customers can't distinguish a secure product from one that isn't until the damage is done.”

Ian Trump, the LOGICnow security lead, simply isn't surprised by the continued revelations of backdoors and poor implementations of cryptography. "Implementing security is hard, and requires a unique skill set," Trump told us. "We are seeing an erosion of trust in real-time as several vendors' products fail to meet the advertised level of security."

Fraser Kyne, principal systems engineer at Bromium, is equally pragmatic in his responses when we asked how vendors could reduce the attack surface of their products. "Software will inevitably contain bugs," he said, "and the more software you add, the more bugs you introduce."

Indeed, it seems that we have a fundamental problem to solve: developers are fallible (and busy) and users are gullible (and busy). "Flaws will exist," Kyne concludes. "Bad guys will exploit them, and users will click on the wrong thing. This isn't ever going to change."

John Vestberg, CTO of Clavister, meanwhile, is more concerned about how security vendors buy-in modules and use open source coding. "When security vendors utilise technology that they haven't developed themselves they leave themselves open to the possibility that it hasn't been tested properly," he said. "This increases the probability of human error rendering their solutions vulnerable."

Vestberg insists that it's simply not good security practice to use third-party coding as part of a security solution (at least not without rigorous checking) because then you're trusting that another party has properly reviewed the code, and issued appropriate patches for it. 

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Video and interviews