Written By Roark Pollock And Presented By Chuck Leaver
As with any type of security, the world of IT security is concerned with developing and implementing a set of allow/disallow guidelines – or more officially entitled, policies on security. And, simply stated, allow/disallow rules can be expressed as a ‘whitelist’ or a ‘blacklist’.
In the past, most rules were blacklist by nature. In those days past we trusted nearly everyone to act well, and when they did this, it would be rather simple to recognize bad behavior or anomalies. So, we would just need to compose a couple of blacklist guidelines. For example, “do not permit anyone into the network coming from an IP address in say, Russia”. That was kind of the very same thing as your grandparents never ever locking the doors to your home on the farm, given that they knew everyone within a twenty-mile radius.
Then our world changed. Behaving well became an exception, and bad actors/habits ended up being legion. Naturally, it occurred slowly – and in phases – dating to the beginning of the true ‘Internet’ back in the early 1990’s. Remember script kiddies unlawfully accessing public and secure sites, simply to prove to their high school friends that they could?
Fast forward to the modern-day age. Just about everything is on-line. And if it has worth, someone on the planet is trying to steal or damage it – continuously. And they have lots of tools that they can use. In 2017, 250,000 brand-new malware variations were presented – each day. We used to rely upon desktop and network anti-virus packages to add brand-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 variants annually, blacklist methods alone will not suffice.
Network whitelisting innovations have been a crucial form of protection for on premises network security – and with most companies rapidly moving their work to the cloud, the exact same systems will be needed there too.
Let’s take a more detailed look at both approaches.
A blacklist lines out known destructive or suspicious “entities” that shouldn’t be permitted access, or rights of execution, in a network or system. Entities include bad software applications (malware) including viruses, Trojans, worms, spyware, and keystroke loggers. Entities also consist of any user, application, process, IP address, or organization known to posture a hazard 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 in time, which may be days, weeks, and even years?
So, exactly what is whitelisting? Well, as you may have thought, it is the opposite of blacklisting. Whitelisting starts from a viewpoint that nearly everything is bad. And, if that holds true, it ought to be more effective just to specify and allow “good entities” into the network. An easy example would be “all workers in the financial department that are director level or higher are permitted to access our monetary reporting application on server X.” By extension, everybody else is denied access.
Whitelisting is often referred to as a “absolutely no trust” technique – reject all, and permit only certain entities access based upon a set of ‘excellent’ characteristics related to user and device identity, behavior, place, time, and so on
Whitelisting is widely accepted for high risk security environments, where stringent rules are more important than 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?
Initially, there are not many that would tell you that blacklisting is totally a thing of the past. Definitely at the endpoint device level, it is reasonably easy to set up and maintain and somewhat efficient – especially if it is kept current by third-party risk intelligence companies. But, on its own, is it enough?
Second, depending on your security background or experience, you’re most likely thinking, “Whitelisting would never work for us. Our company applications are just too diverse and complicated. The time, effort, and resources required to assemble, monitor, and upgrade whitelists at a business level would be unsustainable.”
Luckily, this isn’t truly an either-or choice. It’s possible to take a “finest of both worlds” approach – blacklisting for malware and invasion detection, operating together with whitelisting for system and network access at large.
Ziften and Cloud Whitelisting
The secret to whitelisting comes down to ease of execution – especially for cloud-based workloads. And ease of application ends up being a function of scope. Consider 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 ideal visibility within your cloud environment.
This is where Ziften comes in.
With Ziften, it ends up being easy to:
– Identify and develop visibility within all cloud servers and virtual machines
– Gain continuous visibility into devices and their port usage activity
– See east-west traffic streams, consisting of detailed tracking into protocols in use over specific port sets
– Transform ‘seeing’ exactly what’s happening into a discernable selection of whitelists, complete with precise protocol and port mappings
– Establish near real time notifications on any anomalous or suspicious resource or service activations