Signature updates vs BCP


Aleksander Czarnowski

AVET Information and Network Security, Poland
Editor: Helen Martin


Would you ever expect a well established anti-virus company to fail to provide you with signature updates? Would your company's security policy be ready to deal with such a situation?


From time to time we witness events that seem so unlikely or unwanted that they almost defy belief. Occasionally, such an event occurs within the IT security business. This article has been inspired by events that have been described by many as 'unbelievable'.

The story

The story is short and simple: recently, a local AV vendor had some serious problems with producing signature updates for its product, and failed to update its scanning engine for as long as two weeks. (Unfortunately it seems that, at the time of writing, the problems have yet to be resolved and updates are still sporadic and infrequent.)

Would you ever expect a well established anti-virus company to fail to provide you with signature updates while the company was still operational? Many security officers probably did not. We have seen buyouts of anti-virus companies, and even bankruptcy in the past, but in these cases measures have usually been put in place to ensure continuity in malware protection for customers.

Broken or invalid signature updates are also something with which we are familiar, but this situation is something new and worrying – especially considering that the ie_xp_pfv_metafile [1] exploit was used widely and Microsoft security bulletins MS06-001 [2], MS06-002 [3] and MS06-003 [4] were all released during the period in which no updates were provided.

Learning from the past

This got me thinking about the past. Historically, security policies have been shaped by critical events. Consider, for example, corporate security policies dated prior to 2001. In how many would you find reference to scenarios involving terrorist attacks or BCP (business continuity planning)?

Despite the various mathematical models we use for risk analysis, we always seem to learn the hard way in the security area. So what we can learn from this story? I think the following are the most important points:

  • The failure of a safeguard may not always be the result of a direct, easily foreseen technical issue. Even risk management-driven security policy can be flawed simply due to incomplete threat and risk catalogs. This might pose an even more important question: is risk management the right approach? After all, in evaluating risks and threats we rely partly on historical data. If a particular event has a very rare occurrence, then we might wrongly ignore it.

  • The defence-in-depth strategy suggests that we should never rely on one safeguard to protect a particular asset. This may be tricky to implement in the case of malware protection as many organizations use a single product that operates at different levels of the network.

  • The use of a multiple-engine product won't necessarily provide continuity in malware protection if, for example, the vendor of that product encounters problems.

Some might say that the situation described above is unlikely to happen where the well established vendors who operate worldwide (the 'big players') are concerned. Try telling that to Arthur Andersen or Enron shareholders.

We have to ask whether our security policies and BCPs are ready to deal with such a situation. It seems that using two different products from different vendors (based on different engines from different vendors) could be a wise move.

The introduction of stack protection mechanisms and IDS/IPS systems might seem like a good solution too. But we could be very wrong – for example, the MS06-001 [2] vulnerability is not stack overflow-based – so we should remember that DEP and MS/GS mechanisms are not the final solution to system security. While it's easy to filter out well known attack web servers that contain exploits, it's far from being the final solution – even in the case of this particular vulnerability. Not every vulnerability exploitation process is easy to detect using a signature-based approach – even methods based on code emulation can have serious problems. Along with Dave Aitel [5], I'm curious as to how IDS/IPS vendors will approach this problem.

So as you can see, we have entered the new year with new vulnerabilities and new challenges. I wonder what the maximum length of time is that an AV vendor can stay operational without providing updates. I hope that none of VB's readers will ever have to find out.



Latest articles:

VB2018 paper: Internet balkanization: why are we raising borders online?

Nowadays, walls are not just being raised in the real world, but on the Internet as well. Countries want to isolate themselves and shut down the information they are not comfortable with, or the companies they don’t want to do business with. Freedom…

VB2018 paper: Where have all the good hires gone?

Much ink has been spilled on the subject of the information security skills gap, and how difficult it is to hire and retain people for these positions. And yet, we all know someone who has had a hard time finding a suitable position despite having…

VB2018 paper: Little Brother is watching – we know all your secrets!

In their research, Siegfried Rasthofer, Stephan Huber & Steven Arzt evaluated the security level of the most popular family-tracking apps on Android. They assessed the security of the respective apps and conducted assessments of the corresponding…

VB2018 paper: Inside Formbook infostealer

Formbook is an infostealer that has been advertised for sale in public hacking forums since February 2016 by a user with the handle ‘ng-Coder' but only came to public attention after it was extensively used in spam campaigns in late 2017. This paper…

VB2018 paper: From Hacking Team to hacked team to...?

In this paper (presented at VB2018), Filip Kafka looks at the resurfaced Hacking Team spyware, and at what has changed since the company behind it faced a number of prominent hacks.

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.