The Living Dead Anti-Virus

Posted by    on   Feb 2, 2017

A former director of testing at AV-TEST and a one-time VB conference speaker, security consultant Hendrik Pilz is passionate about the quality of security products. In a guest blog for Virus Bulletin, he explains why he doesn't think anti-virus products should be disabled.

hendrik pilzJust recently, security expert Robert O'Callahan (a former developer at Mozilla) published an article in which he argued that users should disable all anti-virus software running on their machines other than Microsoft's own Windows Defender. He accuses AV vendors of writing insecure software, and of impeding the implementation of security features in software such as web browsers.

But while these arguments are true for some AV vendors, the suggestion that users should uninstall every AV product except for Microsoft Windows Defender is terribly wrong. I've been working in the security industry for more than a decade. I was the director of the AV-TEST testing lab, which publishes regular reports on the performance of AV software (similar to Virus Bulletin's testing). I was involved in the development and automation of so-called 'real-world tests'. Such tests simulate real user behaviour in order to test the full spectrum of security features included in today's AV software. During an automated test, a malicious URL is accessed with a web browser. Then, either a download dialog appears or else the AV has blocked the access to the URL. When one wants to create a comparative test that includes all the major AV programs (we usually tested 20 to 30 programs at a time), one quickly discovers that there is no common way in which the AV software interacts with the browser. This was the cause of many headaches in developing the automated tests.

And this is what O'Callahan is really complaining about. Due to the many 'tricks' AV vendors use to check web traffic, browser developers are faced with countless errors and bugs that are hard to reproduce and fix. Yet, in all the years I’ve been working in this industry, I've never witnessed a discussion between browser developers and AV vendors in an attempt to fix these issues. Instead, we regularly read about AV breaking encryption with various methods in order to scan the web traffic in the browser. The major browser vendors, Mozilla, Google and Microsoft, could create a standard for interaction between AV and the browser – in the past few years, we’ve seen many new W3C recommendations for technologies that are to be implemented in browsers, but there has never been a recommendation regarding the interaction between anti-virus (or third-party applications in general) and the browser. Instead, browsers have implemented their own security features, such as Google's Safe Browsing.

Users can rely on Safe Browsing and other security features integrated in browsers to stay safe. But soon many users will demand more options, such as the creation of group-based security policies or the central monitoring of web activities. For example, parents may want to restrict the Internet usage of their children, and corporate administrators may want to allow or disallow access to certain websites. While corporate administrators could move such policies to a network device such as the Internet gateway (having IP-based policies vs. user/group-based policies as a trade-off), parents can’t do that so easily. Now, the parents can request this feature from Google or Mozilla (or Apple, Opera etc.), or they can install a third-party product to provide it. I’d really like to see browser developers adding such a feature to the core of their browsers.

With Windows 10, Microsoft has introduced the Anti-Malware Scan Interface (AMSI). AMSI can be used by application developers to request a scan of any object (e.g. a file or a piece of JavaScript code embedded in a web page) with an AMSI-capable security application. This is a good start, but it remains something of a chicken-and-egg situation: as long as application developers don’t utilize AMSI to request scans for untrusted input, AV vendors don’t need to implement AMSI support. When Mozilla and Google start to include AMSI support in their browsers, AV vendors will easily be able to adopt AMSI in their products, with the result being that most developer headaches will be eliminated. This goes for the AV developers as well, as they will no longer have to resort to using their own root certificates to break encryption in the browser, and other workarounds. So the AV software will become less complex and thus more secure.

There is a need for security applications which extend basic security features. AV developers and browser developers need to discuss their respective requirements in order to find a proper solution to the problems of interaction between AV and browsers. AMSI could be the beginning of this solution.

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest posts:

VB2017 call for last-minute papers opened

Today, we open the call for last-minute papers for VB2017. Submit before 3 September to have your abstract considered for one of the ten slots reserved for 'hot' research.

Five reasons to come to VB2017 in Madrid

We're not ones to make bold claims about our conference, and we suggest you ask past attendees for their opinion, but here are five reasons why we think you should come to VB2017 in Madrid.

DMARC: an imperfect solution that can make a big difference

US Senator Ron Wyden has asked the Department of Homeland Security to implement DMARC. Martijn Grooten looks at what difference this could make for phishing attacks impersonating the US federal governent.

Advanced and inept persistent threats to be discussed at VB2017

Unsurprisingly given today's threat landscape, the VB2017 programme contains several talks on various advanced persistent threats - but also a talk on what may be the polar opposite of such threats: an inept persistent threat.

Password security is 1% choosing a half-decent password, 99% not using it anywhere else

Password security advice focuses too much on password strength and too little on avoiding password reuse, Martijn Grooten argues.