Written By Roark Pollock And Presented By Charles Leaver
Similar to any type of security, the world of IT security is one of establishing and implementing a set of allow/disallow guidelines – or more officially titled, security policies. And, simply stated, allow/disallow rules can be expressed as a ‘whitelist’ or a ‘blacklist’.
Back in the good ‘ole days, the majority of guidelines were blacklist in nature. The good ‘ole days were when we relied on almost everyone to behave well, and when they did this, it would be rather simple to determine bad habits or anomalies. So, we would just have to compose a few blacklist rules. For instance, “do not allow anybody into the network coming from an IP address in say, Russia”. That was sort of the exact same thing as your grandparents never ever locking the doors to your home on the farm, considering that they knew everybody within a 20 mile radius.
Then the world changed. Behaving well ended up being an exception, and bad actors/behavior became legion. Naturally, it took place gradually – and in phases – dating to the beginning of the true ‘Web’ back in the early 90’s. Keep in mind script kiddies unlawfully accessing public and private websites, simply to prove to their high school pals that they could?
Fast forward to the contemporary age. Everything is online. And if it has value, somebody in the world is attempting to take or damage it – continuously. And they have a lot of tools that they can use. In 2017, 250,000 brand-new malware variants were introduced – each day. We used to count on desktop and network anti-virus packages to add brand-new blacklist signatures – on a weekly basis – to counter the bad guys using malicious strings of code to do their bidding. However at over 90 million new malware variants each year, blacklist methods alone won’t cut it.
Network whitelisting technologies have been a crucial form of protection for on premises network security – and with the majority of companies rapidly moving their work to the cloud, the same mechanisms will be needed there too.
Let’s take a closer look at both approaches.
What is Blacklisting?
A blacklist lines out known malicious or suspicious “entities” that shouldn’t be enabled access, or rights of execution, in a system or network. Entities consist of bad software applications (malware) consisting of viruses, Trojans, worms, spyware, and keystroke loggers. Entities likewise include any user, application, process, IP address, or organization known to posture a risk to a business.
The essential word above is “known”. With 250,000 new versions appearing each day, the number that are out there we don’t know about – at least until much later in time, which may be days, weeks, or even years?
What is Whitelisting?
So, exactly what is whitelisting? Well, as you may have thought, it is the opposite of blacklisting. Whitelisting begins from a viewpoint that almost all things are bad. And, if that holds true, it should be more efficient just to define and enable “excellent entities” into the network. A simple example would be “all workers in the financial department that are director level or greater are permitted to access our financial reporting application on server X.” By extension, everyone else is denied access.
Whitelisting is typically described as a “zero trust” approach – deny all, and permit only certain entities access based upon a set of ‘excellent’ properties associated with user and device identity, habits, location, time, etc
Whitelisting is commonly accepted for high risk security environments, where rigid guidelines take precedence over user liberty. It is also extremely valued in environments where organizations are bound by rigorous regulative compliance.
Do you go Black, White or mix it up?
First, there are not many that would tell you that blacklisting is totally aged out. Definitely at the endpoint device level, it remains fairly simple to set up and keep and rather reliable – specifically if it is kept up to date by third party risk intelligence service providers. However, on its own, will it suffice?
Second, depending upon your security background or experience, you’re most likely thinking, “Whitelisting would never ever work for us. Our service applications are just too diverse and complicated. The time, effort, and resources needed to put together, monitor, and upgrade whitelists at an enterprise level would be untenable.”
Fortunately, this isn’t actually an either-or option. It’s possible to take a “best of both worlds” approach – blacklisting for malware and invasion detection, operating along with whitelisting for system and network access at large.
Ziften and Cloud Whitelisting
The secret to whitelisting comes down to simplicity of implementation – especially for cloud-based work. And ease of implementation becomes a function of scope. Think about whitelisting in 2 ways – application and network. The former can be a quagmire. The latter is far simpler to execute and preserve – if you have the best visibility within your cloud environment.
This is where Ziften comes in.
With Ziften, it becomes simple to:
– Identify and establish visibility within all cloud servers and virtual machines
– Gain constant visibility into devices and their port usage activity
– See east-west traffic flows, including in-depth tracking into protocols in use over specific port pairs
– Convert ‘seeing’ what’s happening into a discernable array of whitelists, complete with accurate procedure and port mappings
– Set up near real time alerting on any anomalous or suspicious resource or service activations