Written By Roark Pollock And Presented By Chuck Leaver
Similar to any form of security, the world of IT security is concerned with developing and implementing a set of allow/disallow rules – or more formally entitled, security policies. And, simply specified, allow/disallow guidelines can be expressed as a ‘whitelist’ or a ‘blacklist’.
In the past, the majority of rules were blacklist in nature. The good ‘ole days were when we trusted almost everyone to behave well, and when they did this, it would be quite easy to determine bad behavior or anomalies. So, we would only have to write a few blacklist rules. For instance, “don’t permit anyone into the network coming from an IP address in say, Russia”. That was sort of the same thing as your grandparents never ever locking the doors to your house on the farm, given that they knew everyone within a twenty mile radius.
Then our world altered. Good behavior ended up being an exception, and bad actors/habits ended up being legion. Of course, it took place slowly – and in phases – dating to the beginning of the true ‘Internet’ back in the early 90’s. Keep in mind script kiddies illegally accessing public and secure sites, just to show to their high school pals that they could?
Fast forward to the modern age. Everything is online. And if it has value, somebody in the world is trying to steal or harm it – continuously. And they have plenty of tools that they can use. In 2017, 250,000 brand-new malware versions were presented – daily. We used to trust desktop and network anti-virus programs to include brand-new blacklist signatures – every week – to counter the bad guys utilizing destructive strings of code for their bidding. But at over 90 million new malware variations each year, blacklist techniques alone won’t cut it.
Network whitelisting technologies have been a crucial form of protection for on premises network security – and with many organizations quickly moving workloads to the cloud, the same systems will be needed there too.
Let’s take a closer look at both approaches.
A blacklist lines out understood destructive or suspicious “entities” that should not be enabled access, or execution rights, in a network or system. Entities consist of bad software applications (malware) including infections, Trojans, worms, spyware, and keystroke loggers. Entities also consist of any user, application, process, IP address, or organization understood to posture a danger to a business.
The critical word above is “known”. With 250,000 new versions appearing per day, the number that are out there we have no idea about – at least till much later on in time, which could be days, weeks, and even years?
What is Whitelisting?
So, 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 ought to be more effective simply to specify and allow “good entities” into the network. A basic example would be “all employees in the finance 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 frequently described as a “absolutely no trust” approach – deny all, and permit just select entities access based on a set of ‘good’ properties connected with user and device identity, habits, place, time, and so on
Whitelisting is extensively accepted for high-risk security environments, where stringent guidelines are more important than user liberty. It is likewise highly valued in environments where companies are bound by strict regulatory compliance.
Black, White, or Both?
First, there are not many that would suggest blacklisting is totally a thing of the past. Certainly at the endpoint device level, it remains relatively simple to set up and preserve and rather effective – specifically if it is kept up to date by third party danger intelligence companies. But, in and of itself, is it enough?
Second, depending upon your security background or experience, you’re likely thinking, “Whitelisting would never work for us. Our business applications are just too different and complicated. The time, effort, and resources needed to assemble, monitor, and update whitelists at an enterprise level would be untenable.”
Thankfully, this isn’t really an either-or choice. It’s possible to take a “finest of both worlds” approach – blacklisting for malware and invasion detection, running along with whitelisting for system and network access at large.
Ziften and Cloud Whitelisting
The secret to whitelisting comes down to ease of implementation – specifically for cloud-based work. And ease of execution becomes a function of scope. Think of whitelisting in 2 ways – application and network. The former can be a quagmire. The latter is far simpler to implement and preserve – if you have the right visibility within your cloud deployments.
This is where Ziften comes in.
With Ziften, it becomes simple to:
– Identify and develop visibility within all cloud servers and virtual machines
– Gain continuous visibility into devices and their port use activity
– See east west traffic flows, including detailed tracking into protocols being used over particular port sets
– Convert ‘seeing’ exactly what’s happening into a discernable variety of whitelists, finished off with exact procedure and port mappings
– Establish near real-time notifications on any anomalous or suspicious resource or service activations