As with any form of security, the world of IT security is one of establishing and enforcing a set of allow / disallow rules – or more formally titled, security policies. And, simply stated, allow / disallow rules can be expressed as a ‘whitelist’ or a ‘blacklist’.
Back in the good ‘ole days, most rules were blacklist in nature. The good ‘ole days were when we trusted almost everyone to behave well, and if they did, it would be quite easy to identify bad behavior or anomalies. So, we would only need to write a few blacklist rules. For example, “don’t allow anyone into the network coming from an IP address in say, Russia”. That was sort of the same thing as your grandparents never locking the doors to the house on the farm, since they knew everyone within a twenty-mile radius.
Then the world changed. Good behavior became an exception, and bad actors / behavior became legion. Of course, it happened gradually – and in stages – dating to the beginning of the true ‘Internet’ back in the early 90’s. Remember script kiddies illegally accessing public and private sites, just to prove to their high school friends that they could? Ah, those were the days…
Fast forward to the modern age. Everything is on-line. And if it has value, someone on the planet is trying to steal or damage it – constantly. And they have plenty of tools at their disposal. In 2017, 250,000 new malware variants were introduced – per day. We used to rely upon desktop and network anti-virus packages to add new blacklist signatures – on a weekly basis – to counter the bad guys using malicious strings of code to do their bidding. But at over 90 million new malware variants per year, blacklist strategies alone won’t cut it.
Network whitelisting technologies have been a key line of defense for on-premises network security – and with most organizations rapidly moving workloads to the cloud, the same mechanisms will be required there as well.
Let’s take a closer look at both approaches.
A blacklist lines out known malicious or suspicious “entities” that shouldn’t be allowed access, or execution rights, in a system or network. Entities include bad software (malware) including viruses, Trojans, worms, spyware, and keystroke loggers. Entities also include any user, application, process, IP address, or organization known to pose a threat to an organization.
The operative word above is “known”. With 250,000 new variants appearing per day, how many are out there we don’t know about – at least until much later in time, which could be days, weeks, or even years?
So, what is whitelisting? Well, as you might have guessed, it is the opposite of blacklisting. Whitelisting starts from a perspective that nearly everything is bad. And, if that is true, it ought to be more efficient just to define and allow “good entities” into the network. A simple example would be “all employees in the finance department that are director level or higher are allowed to access our financial reporting application on server X.” By extension, everyone else is locked out.
Whitelisting is often referred to as a “zero trust” approach – deny all, and allow only select entities access based on a set of ‘good’ properties associated with user and device identity, behavior, location, time, etc.
Whitelisting is widely accepted for high-risk security environments, where stringent rules take precedence over user freedom. It is also highly valued in environments where organizations are bound by strict regulatory compliance.
Black, White, or Both?
First, few would suggest blacklisting is totally aged out. Certainly at the endpoint device level, it remains relatively easy to install and maintain and somewhat effective – especially if it is kept current by third-party threat intelligence service providers. But, in and of itself, is it enough?
Second, depending on your security background or experience, you’re likely thinking, “Whitelisting would never work for us. Our business applications are just too varied and complicated. The time, effort, and resources required to compile, monitor, and update whitelists at an enterprise level would be untenable.”
Fortunately, this isn’t really an either-or choice. It’s possible to take a “best of both worlds” approach – blacklisting for malware and intrusion detection, operating alongside whitelisting for system and network access at large.
Cloud Whitelisting with Ziften
The key to whitelisting comes down to ease of implementation – especially for cloud-based workloads. And ease of implementation becomes a function of scope. Think of whitelisting in two ways – application and network. The former can be a quagmire. The latter is far easier to implement and maintain – if you have the right visibility within your cloud deployments.
This is where Ziften comes in.
With Ziften, it becomes easy to:
- Identify and establish visibility within all cloud servers and virtual machines
- Gain continuous visibility into devices and their port usage activity
- See east-west traffic flows, including detailed tracking into protocols in use over specific port pairs
- Convert ‘seeing’ what’s happening into a discernable array of whitelists, complete with precise protocol and port mappings
- Set up near real-time alerting on any anomalous or suspicious resource or service activations
To learn more about how Ziften can help, read Simple Cloud Visibility & Security for Public Cloud Migrations.