Written By Roark Pollock And Presented By Charles Leaver
As with any kind of security, the world of IT security is concerned with developing and implementing a set of allow/disallow guidelines – or more officially entitled, security policies. And, simply stated, allow/disallow guidelines can be revealed as a ‘whitelist’ or a ‘blacklist’.
Back in the good ‘ole days, a lot of guidelines were blacklist in nature. In those days past we trusted almost everybody to act well, and if they did, it would be rather simple to identify bad habits or abnormalities. So, we would just need to write a few blacklist guidelines. For instance, “do not enable anyone into the network originating from an IP address in say, Russia”. That was sort of the same thing as your grandparents never ever locking the doors to the house on the farm, given that they were aware of everybody within a 20 mile radius.
Then the world changed. Good behavior became an exception, and bad actors/behavior ended up being legion. Of course, it occurred slowly – and in stages – dating to the start of the true ‘Web’ back in the early 90’s. Remember script kids illegally accessing public and private websites, simply to prove to their high school friends that they were able to?
Fast forward to the modern age. Everything is on-line. And if it has value, somebody on earth is aiming to steal or damage it – constantly. And they have plenty of tools that they can use. In 2017, 250,000 brand-new malware variations were presented – per day. We used to count on desktop and network anti-virus packages to include new blacklist signatures – on a weekly basis – to fend off the bad guys utilizing harmful strings of code to do their bidding. But at over 90 million brand-new malware variations per year, blacklist strategies alone will not cut it.
Network whitelisting technologies have actually been a crucial line of defense for on premises network security – and with many companies rapidly moving their work to the cloud, the exact same systems will be required there also.
Let’s take a more detailed look at both techniques.
What is Blacklisting?
A blacklist lines out known destructive or suspicious “entities” that should not be allowed access, or rights of execution, in a system or network. Entities include bad software applications (malware) including viruses, Trojans, worms, spyware, and keystroke loggers. Entities also include any user, application, process, IP address, or organization known to position a danger to a business.
The essential word above is “known”. With 250,000 brand-new versions appearing daily, how many are out there we don’t know about – at least till much later on in time, which may be days, weeks, or even years?
So, what is whitelisting? Well, as you may have thought, it is the opposite of blacklisting. Whitelisting begins from a point of view that nearly everything is bad. And, if that holds true, it should be more efficient simply to specify and enable “good entities” into the network. A simple example would be “all employees in the financial department that are director level or greater are allowed to access our financial reporting application on server X.” By extension, everybody else is locked out.
Whitelisting is typically described as a “zero trust” method – reject all, and permit only certain entities access based on a set of ‘good’ properties associated with user and device identity, habits, place, time, and so on
Whitelisting is extensively accepted for high-risk security environments, where strict guidelines take precedence over user freedom. It is likewise extremely valued in environments where companies are bound by stringent regulatory compliance.
Black, White, or Both?
Initially, few would tell you that blacklisting is absolutely aged out. Definitely at the endpoint device level, it is fairly simple to set up and maintain and somewhat efficient – especially if it is kept up to date by third party hazard intelligence companies. However, on its own, is it enough?
Second, depending upon your security background or experience, you’re most likely thinking, “Whitelisting could never work for us. Our company applications are just too diverse and complex. The time, effort, and resources needed to compile, monitor, and upgrade whitelists at an enterprise level would be untenable.”
Thankfully, this isn’t really an either-or option. It’s possible to take a “best of both worlds” stance – blacklisting for malware and invasion detection, running along with whitelisting for system and network access at large.
Cloud Whitelisting with Ziften
The key to whitelisting boils down to ease of execution – specifically for cloud-based workloads. And ease of execution becomes a function of scope. Think of whitelisting in two ways – application and network. The previous can be a quagmire. The latter is far easier to execute and maintain – if you have the right visibility within your cloud environment.
This is where Ziften scores well.
With Ziften, it becomes easy to:
– Identify and develop visibility within all cloud servers and virtual machines
– Gain constant visibility into devices and their port usage activity
– See east-west traffic streams, including detailed tracking into protocols being used over specific port pairs
– Convert ‘seeing’ what’s taking place into a discernable variety of whitelists, complete with exact procedure and port mappings
– Establish near real time notifications on any anomalous or suspicious resource or service activations