1100 words, 4 1⁄2 minutes.
Preparation
“One of the best ways to keep peace is to be prepared for war” - Plato & others.
Today attacks come thick and fast. The chances are that all public IPv4 address space is regularly scanned. Time-to-compromise of an unpatched, non-firewalled, Microsoft Windows host is about 5 minutes. Systems are attacked not because they are valuable, but because they are vulnerable. Even an old cable-modem is a useful addition to a botnet.
When organisations started connecting to the Internet in large numbers, the standard method was to plug-in and add a few blocking rules to their border router. They would use public IP address space on their LAN. I wont say private LAN, because it wasn’t private. By the act of connecting to the Internet you became the Internet. This sounds insane to anyone starting work in the UK after about 1995. It was workable for the same 5 minutes a Windows host now lasts before being compromised. Each time a hacker found a new service to exploit, a new rule would be added to border router to block that service. Pretty quickly administrators started building bastion hosts and early firewalls and the perimeter security market was born. Everyone switched from what we call “default permit” (everything open unless you decide to block it) to “default deny” (everything closed unless you unblock it).
Default deny ought to be the DNA of Information Technology. It’s the one thing which allows us to flip the odds around against the hacker. The problem is default deny is almost never implemented fully. Default permit is still everywhere you look. Consider the Firewall, by definition the embodiment of default deny. I’m sure your firewall blocks inbound (ingress) connections with a few exceptions, but…
- Does it allow outbound connections (egress)?
- Can private LAN systems query external Domain Name Servers?
- Can they connect directly to external sites without a proxy?
- Can they use versions of SSL not explicitly permitted?
- Can they use ciphers of SSL not expressly permitted?
- Can they send/receive traffic outside the definition of the protocol/RFC?
If the answer to any of these questions is “yes” then you don’t really have default deny. You have a lazy and cosmetic version of it. You have a version long since overtaken by the nature and mechanism of the threat. Now consider your public web servers, they host a few tens, hundreds or thousands or URLs. Some of those URLs may accept parameters. You web server dutifully serves those URLs. What about all the other things the web server will do if asked?
- Executing CGI examples you forgot to remove.
- Displaying management interface pages.
- Showing the server filesystem.
- Displaying an arbitrary file.
- Displaying information about the web server binary.
In a default-deny regime a server wouldn’t be able to do any of those things unless you expressly permitted them. You only wanted 100 URLs to be served after all. Nothing else. Fortunately we can achieve default deny on a modern web server with a little extra effort. The problem is most people don’t bother, the web server will be left in a default-permit state. There are plenty of other examples, I’ll give just one more topical example for Microsoft Windows.
- Can desktops receive connections from non-server IPs?
- Can desktops access each other’s network services directly?
- Can desktops execute arbitrary programs you haven’t explicitly approved?
If the answer to any of the above is “yes” then you don’t really have default deny. The chances are that if a networked virus or worm makes it onto one PC it will spread uncontrolled to the rest of them. Unless of course your Anti-Virus/Anti-Malware software is 100% perfect. The chances are your entire private-LAN operates more or less on a default-permit basis. It may not even be IP addressed, VLAN’d, segmented, or internally firewalled in such a way that you could shut down default-permit in an emergency if you had to. You’ll regret that one day.
Do you do business with China? What about Russia? Or Mexico? Vietnam? No? Why allow inbound connections from IP addresses registered to those countries? If you’re worried about missing out on business, is it necessary to permit connections for anything other than Email and the public web site? Do people in Brazil need to talk to the web-login interface of your supplier extranet? Probably not. Default-deny and manage by exception. Unblock that lone company in Brazil you do need to have that access.
Default-permit is seductive. It requires no extra work up-front. No negotiation, no discussion, no compromises, no arguing the point with the business. It leaves you totally unprepared. You will spend the rest of your days fighting off incursions, reacting to probes, and worrying about whether or not your defences have the latest signature updates. With planning and automation, default-deny is achievable. The hard part is persuading the rest of your organisation, because it sounds like you are taking something away from them.
Remember, assets are attacked not because they are valuable, but because they are vulnerable.
Ask them to think about which operating model they prefer:
Operating Model 1
Take finite annual security budget. Pit that budget against;
- Technology which by default is insecure.
- A large and growing number of hackers.
- Who use automation as a force multiplier.
- To exploit known and unknown vulnerabilities.
- Vulnerabilities created at a faster rate than detected/fixed by vendors.
- When there is a breach, spend time/money to investigate and fix.
Operating Model 2
Take the same finite security budget, but a different approach to spending it;
- Start from a position of relative invulnerability.
- Figure out what users need to do for their job.
- Enable that capability, securely, using features/products/services.
- If there is a gap between what users need and (3) can provide;
- Look for an additional product/service to close gap.
- Or ask user to make slight adjustments to the way they work.
- Iterate around step 4. until the gap is minimal or of no consequence.
- Where there is a breach spend time/money to investigate and fix.
Neither provides perfect security, but the second model puts you at considerable advantage. It’s an iterative system. It starts from a position of relative strength. It uses budget to reduce security/convenience trade-offs over time. It allows an organisation to zero-in on a target of minimum vulnerability and minimum inconvenience for users. Remember, you don’t need perfect security. In most cases you just need to be less vulnerable than the next guy.
If you’re sold on default deny you’re ready to move on to the next winning system which reduces vulnerability even further.
If on the other hand you can’t face fully implementing default deny within your organisation, you’re going to need all the help you can get. You’d better read this.