Download our in-depth report: The Ultimate Guide to IT Security VendorsI'm going to guess that you've probably heard a firewall engineer'sattempt at pith that sounded something like, ''Deny everything that isn'texplicitly permitted.'' This is the conventional wisdom approach toconfiguring firewalls, and it (by and large) replaced the ''alloweverything that isn't explicitly denied'' mindset.
These two different ways of viewing network traffic are sometimesreferred to as whitelists and blacklists, respectively. What's more, wecan consider applying similar approaches in many different areas inInformation Security. They both have useful applications, depending onthe context of the situation at hand.
Let's explore a bit
The ''deny everything except...'' approach is particularly useful intightly managed and configured environments (think production datacenters) in which we really know and understand everything that theservers need to do their jobs. The advantages here should be prettyobvious -- if something isn't absolutely necessary to the businessfunction that the servers are running, disallow it.https://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=i That should span far more than just network configuration. It shouldinclude operating system configuration, application integration, and eventhe application software itself. I've seen a lot of situations where anintruder managed to break a site's perimeter security and then use theirown tools to dig deeper into the victims networks. Nothing good comes ofthat scenario...
Conversely, the ''allow everything except...'' approach is more commonlyused in desktop environments where you want to afford your users thegreatest flexibility in what they can do with their systems. The bigdanger in it is in the statement ''explicitly denied''. It implies youhave an accurate and up-to-date view of things that need to be denied.That, in turn, implies you actively maintain that list of things. And thebottom line is that missing any bad things can result in the systemsbeing compromised.
Sound familiar? It should.
That's how a lot of our IT security products function. Think anti-virusproducts that get nightly updates from their respective product vendors.Think intrusion detection systems that require signatures to recognizethe latest attack that's been posted to the Internet. This approach isalmost always used in configuring -- and I'm really using that termlightly -- file access control of our desktop operating systems.
It should be obvious that there's a great deal of danger in using the''allow everything'' approach, and it really should only be used when allother options have been exhausted. For starters, as I indicated, it'sprone to error. Miss one bad thing and your house of cards can comecrashing down. Why do you think IT Security suffers whenever a new virusor worm hits the net before our anti-virus and IDS vendors can developsignatures for it?
It's also closely related to the torrents of false positives that we seein many IT security products. IDS sensors, for example, diligently watchover a network or host for everything that they know to be bad. Wheneverthey see something that matches one of their signatures, they triggeralerts. What happens, more often than not, in our IDS and firewallmonitoring centers when products deliver false alarm storms? Yup, theyeither get removed or they get ''tuned'' to the point that they don'talert on much of anything of importance.
And that brings me to my central theme today -- the elusive set known as''anything of importance''. By taking these off-the-shelf products andwatching for everything that is known to be bad, even if we tune them toreduce the false alarm storms, we're still missing out on things thatshould be of real importance to the security of our applications.
That's because so many of these products are, in essence, executing an''allow all except...'' policy.
What's worse, the set of things that they define as being explicitlydenied, or, in the case of an IDS, explicitly alerted on, is a genericset of bad things that have been observed on the Internet, but may havelittle or nothing to do with the set of bad things that can happen toyour software.
I'll say it again because it is a key point here, the set of things thatmany of these products watch for may have little or nothing to do withthe set of bad things that can happen to your software.
So, you ask, how do I better determine the set of bad things that canhappen to my software? A fair question, although I'd still prefer to seedefined the set of good things that your software must do to execute itsbusiness mission.
But if you simply must take the ''allow everything except...'' approach,then your set of bad things that you define should be unique to yoursoftware. The only way that I know of getting there from here is to talkto the software developers and/or integrators, because they're not likelyto volunteer that information without being asked.
For example, your file access controls and audit alerting should befine-tuned to the files that are relevant to your software. Turn up theaccess controls using a ''deny everything except...'' mind set (e.g.,allow the application process to read, but not alter, the config filewhere you store start-up parameters like its home directory). Turn onevent logging on individual files, registry keys, etc., that are of greatimportance to your software. (If the application process ever tries toalter that config file, even if the access fails, someone should be paged-- even at 3 a.m.)
In my view, this practice is the intersection of operations security andsoftware security, and it's something that I see far too little of inproduction data centers. Don't get burned by an ''allow everything''attitude!