3 Key reasons Whitelisting should be a separate function to Anti-Virus
It’s very busy in the lead up to the end of financial year. There’s lots of discussion and lots of projects kicking off while funding is available to implement whitelisting. The customer I’m speaking with say they need it and want to get it rolling now.
Why? In my view there are two drivers:
1. Our friends at the ASD (Australian Signals Directorate) have updated their ISM (Information Security Manual) for government, and while that is not mandatory for all organisations, it’s a great document to baseline a path to better security. They also have this great page which many commercial and government organisations are referencing as a catalyst for change.
2. Good ol’ ransomware. The original Cryptolocker was detected back in September 2013 and was isolated almost a year ago in June 2014. Despite that, client after client has suffered from these types of attacks. A recent article on Threatpost talks about kits available to help hackers customise and replicate these attacks, and the increase in their regularity.
What’s the answer? Whitelisting of course! This is spelled out by the ASD as one of its Top 4 recommendations to mitigate the risk of targeted cyber intrusions. But what are the main challenge with whitelisting? Just implementation and its ongoing maintenance, that’s all.
“My antivirus (AV) supplier has a whitelisting function,” I hear you say, “why don’t you just turn that on?” I understand, but let’s look at three reasons why, in my view, this should be a separate function.
1. One size doesn’t fit all.
Much like a cheap suit, you don’t want to squeeze all your users into the same model. It just won’t fit. And if it does fit, they might have to work in a totally different way to make it fit, and then you’ll be left with cranky users.
Just because comparing files to a database of signatures or online service is accepted as a mechanism for antivirus doesn’t mean it’s a good fit for whitelisting. After all, you could argue that if antivirus was effective, we wouldn’t need whitelisting at all. I know from conversations with clients this is just not true.
Whitelisting needs to use a different, more controlled approach, maybe even one which puts more responsibility on the user.
2. Security is about layers.
Nobody just puts in the latest and greatest firewall and thinks, “There we go, we’re secure.” Security is always in layers and one of the most effective strategies is to use different products and even different vendors for the layers. I would argue that whitelisting is a separate layer and can benefit from a different product and vendor. So should you just blindly accept whatever your AV vendor has to offer? Maybe you shouldn’t. Look at what the market is doing. Look at what companies like yours and what security organisations are choosing for a whitelisting solution.
3. Antivirus is a different world.
You’ve heard of the saying, “jack of all trades, and master of none”? It’s also true of any focussed software vendor doing whitelisting. As much as they like to think they can do it all, the reality is we all have our own specialities and sweet spots. For vendors, it’s where they spend most of their research and development effort. Antivirus is a complex field and takes a lot of focus and resources to keep up to date—not only with the virus landscape, but also with competitors.
My recommendation is to look at products specifically designed to provide easy to manage whitelisting functionality.
Go out and talk to organisations that have done it. Make a decision that fits with your company’s goals and ongoing maintenance requirements. Implement a whitelisting solution that ticks all the boxes for you, rather than your incumbent antivirus vendor.
And, as always, test and make sure you are getting what you need. Brochures look good, but comments like, “they said it would do it”, usually don’t cut the mustard when a project stalls.
This article is brought to you by Enex TestLab, content directors for CSO Australia.