"It's Not All Black And White" or "Why You Should Switch From Blacklisting To Whitelisting"
I think the title says a lot here: if you want to defend your information systems, you should switch from blacklisting to whitelisting.
But what does that mean?
Most people hear "whitelisting" in terms of CND and think "application whitelisting". But there's so many more places to do it! You already hopefully do outbound whitelisting on your firewall. You aren't really allowing any system to talk out on TCP/3389, right? You do have a DEFAULT:DENY or DENY ANY,ANY down at the bottom of your firewall rules, right?
But have you considered whitelisting outbound web traffic at your proxy as well? Most people think of their web proxy reputation lists as block lists, and for good reason: most of them are incomplete. But did you ever consider that maybe that incompleteness as a defensive measure? If you block unknown websites at your web proxy, you're going to block a huge amount of malicious websites. You're probably thinking to yourself but what about the malicious category? And I reply, but what about the ones that aren't in the malicious categories yet? In the world of human knowledge, everything is either known or unknown. If you apply that partitioning to your web proxy, then malicious websites are either known and hopefully correctly categorized; or they're unknown, and you can block them by default denying outbound traffic to uncategorized sites. This should go without saying, but this applies to both GenCrim and APT - isn't that neat?
But what does that entail?
Fights with management, engineering, and the help desk. You are going to break things. A lot of things. I promise you that you have some mission-critical website that nobody outside your company knows about and as such will be in that uncategorized category. I've worked in organizations that have flipped from blacklist to whitelist at their outbound web proxy and I've seen the pains it causes. I know an engineer who, upon flipping from black- to whitelisting on their company's outbound proxies, broke the payroll system for a large portion of the company, resulting in C-suite people raining fury down upon this person and the rest of their organization. True story: years later they look back on it and laugh, because it has saved their butts thousands of times. Literally, in almost all instances of a system being redirected to a malicious site, or a user clicking a malicious link in an email, or a compromised host beaconing somewhere it shouldn't; the uncat block either stopped it or would have stopped it had another layer of defense not. (I should write a post about defense in depth and analytic completeness with the Cyber Kill Chain)
Ok, so how do I do it?
Testing: Be patient, this isn't an easy one. The story I mentioned above about breaking payroll occurred because management got antsy and decided to flip the switch before testing was complete. One of the most important things you need to do is test. And not just for a short period of time, but give it at least a month. Collect all the logs for a month and look at every that was uncategorized. This isn't going to be easy and will probably take a long time, but I promise you the up-front headaches are worth the payoff.
Roll-out: Don't roll this out to everyone all at once. Use a sample group of "early adopters" (voluntary or involuntary, your pick) so that you don't blow up your entire network and DDoS your helpdesk with users.
But what does that mean?
Most people hear "whitelisting" in terms of CND and think "application whitelisting". But there's so many more places to do it! You already hopefully do outbound whitelisting on your firewall. You aren't really allowing any system to talk out on TCP/3389, right? You do have a DEFAULT:DENY or DENY ANY,ANY down at the bottom of your firewall rules, right?
But have you considered whitelisting outbound web traffic at your proxy as well? Most people think of their web proxy reputation lists as block lists, and for good reason: most of them are incomplete. But did you ever consider that maybe that incompleteness as a defensive measure? If you block unknown websites at your web proxy, you're going to block a huge amount of malicious websites. You're probably thinking to yourself but what about the malicious category? And I reply, but what about the ones that aren't in the malicious categories yet? In the world of human knowledge, everything is either known or unknown. If you apply that partitioning to your web proxy, then malicious websites are either known and hopefully correctly categorized; or they're unknown, and you can block them by default denying outbound traffic to uncategorized sites. This should go without saying, but this applies to both GenCrim and APT - isn't that neat?
But what does that entail?
Fights with management, engineering, and the help desk. You are going to break things. A lot of things. I promise you that you have some mission-critical website that nobody outside your company knows about and as such will be in that uncategorized category. I've worked in organizations that have flipped from blacklist to whitelist at their outbound web proxy and I've seen the pains it causes. I know an engineer who, upon flipping from black- to whitelisting on their company's outbound proxies, broke the payroll system for a large portion of the company, resulting in C-suite people raining fury down upon this person and the rest of their organization. True story: years later they look back on it and laugh, because it has saved their butts thousands of times. Literally, in almost all instances of a system being redirected to a malicious site, or a user clicking a malicious link in an email, or a compromised host beaconing somewhere it shouldn't; the uncat block either stopped it or would have stopped it had another layer of defense not. (I should write a post about defense in depth and analytic completeness with the Cyber Kill Chain)
Ok, so how do I do it?
Testing: Be patient, this isn't an easy one. The story I mentioned above about breaking payroll occurred because management got antsy and decided to flip the switch before testing was complete. One of the most important things you need to do is test. And not just for a short period of time, but give it at least a month. Collect all the logs for a month and look at every that was uncategorized. This isn't going to be easy and will probably take a long time, but I promise you the up-front headaches are worth the payoff.
Roll-out: Don't roll this out to everyone all at once. Use a sample group of "early adopters" (voluntary or involuntary, your pick) so that you don't blow up your entire network and DDoS your helpdesk with users.
Comments
Post a Comment