Do you like the approach of De-Perimeterisation (moving the firewall from a centralized position to each host) ?

I've heard of this concept under a variety of names before; it's been around for a long time. The problem is that, by itself, it won't work.

Why push security down to the individual host level? Well, the obvious reason is that the network is not trustworthy. But, if the network is not trustworthy, how can any 2 hosts communicate safely? Most of the application protocols in use are still insecure and unencrypted. So, you set up little VPNs between each host, and you tunnel some applications over SSH or SSL. But that still doesn't work because you've now got a problem of transitive trust. If host A talks to host B and host B talks to host C, then a vulnerability in host B leaves host A open to attack from host C. Transitive trust is the "secret killer" of computer security but most of the time we never bump up against it in practice because it's easier for hackers to get in via simpler methods.

We recently saw a case where a hacker made significant penetrations into some very secure systems using an attack against the trust relationships between the different systems in a large research community. The hacker compromised one researcher's account at a university and trapdoored the researcher's SSH client. When the researcher logged into a system at another research facility, the hacker now had the researchers' SSH password and was able to penetrate the next facility, set up a trapdoored SSH client there, and eventually he got the root account as the administrator SSH'd into a local server. The hacker had several months worth of fun and by the time it was all over, he had compromised several hundred systems and gained administrative privileges in 5 different research facilities across the Internet. Having per-desktop firewalls would not have helped at all in this type of scenario, unfortunately, since once the hacker was into the first system, they were operating entirely at an application level.

To really secure systems, everything needs to be done 100% right at application layer, kernel layer, network layer, and at the boundary of the network. That's a huge undertaking and nobody has made any effort to tackle it directly because the resulting system would probably be unusable. The guys who wrote the rainbow series in the 1980's understood this and tried to get security practitioners to think about the problem, but solutions like that simply aren't commercially viable. So the security industry and many security users have been bouncing back and forth between, "let's secure the networks with firewalls and forget about host security," and, "let's secure the hosts and forget about the networks" Neither by itself will really work.

I've seen some practitioners (coincidentally, the ones who sell file encryption products) saying "let's just secure the data! forget firewalls and network security! forget host security!" but that's an even worse idea. If you just secure the data, the the first person who installs a keyboard sniffer has your password and it's all over.

Whenever someone tells you that there's a novel, easy, solution to security, it's either because they don't understand security or they're trying to sell you something that isn't going to work.

What about buying a switch that includes a packet filter? This solution should provide a trustworthy network with the added bonus of isolating and filtering each host.

It's not a technology problem, it's a management problem. There are plenty of tools that can be used to control inter-host trust, but they are generally not used because they're "too hard" or "inconvenient" or whatever. For example, the big Cisco switches all have the ability to process ACLs at high speed. Isolating and filtering each host is very possible and would be very effective using existing technology.

Let's imagine a simple scenario: suppose I have a subnet consisting of 150 hosts that all access a local departmental server with file serviceand print service, etc. Further, let's imagine that the hosts on that subnet need Internet browsing access and access to an enterprise Email server (IMAP + SMTP) that sits someplace else on my corporate LAN. And, perhaps, some of my users need access to the mainframe for SQL, while others don't. So, I could put ACLs in the switch to, "allow all/all to the local subnet server," "allow IMAP, SMTP to the off-network mail server," "allow all, port 80, to the web caching proxy off-network," "allow {list} SQL to the mainframe," "default: deny all." That's not very hard, is it? Does Bob's workstation need to talk directly to Jane's? No? Then don't allow it.

And a network like that is going to be extremely resistant to worms or active penetration. Of course nobody does that kind of thing: they just plug it all together, make it work, and then ignore it and hope it doesn't get hacked.

In order to build really secure systems you need to understand the trust relationships between your systems and then build your systems to enhance and support your mission based on those trust relationships. But that's hard work that very few people have the courage and patience to undertake. So instead, they want to just throw technology at the problem - which won't work - because there is no amount of technology that can effectively build your trust relationships for you if you don't understand them yourself.

The computer security industry is trapped in this backwards mindset in which its practitioners keep trying to "list and deny all the things that are bad" rather than "list and permit all the things that are necessary and good" It may have worked for a while, back when there were only a handful of attack techniques being used, but nowadays there are far more attack techniques than there are legitimate forms of traffic. Security system designers who focus on permitting only what is known to be good will always build systems that are more reliable, durable, and hack-proof.

Do you see a growing gap between common hosts on the Internet and hosts managed by security people?

Not really! Security practitioners these days have very little power to encourage other IT professionals to actually secure their systems. In fact, I'm pretty convinced that a lot of security practitioners really don't know how to secure systems at all. It's always a surprise to me when I talk to a security practitioner and they say something like, "I recommended against running [pick your favorite stupid online chat program] through our firewall but was overruled by one of our VPs who wanted to use it." Most of the firewalls that I've seen are configured with rulesets that are ridiculously loose. And the results show: 80% of corporate desktops are infected with spyware, 15% of them are infected with keystroke loggers. Is that better than the common home user's system? Maybe a bit, but hardly enough to make a difference.

If we consider the Internet as a big local network, we will see that some of our neighbours keep getting exploited by spyware, virus, and so on. Who should we blame? OS producers? Or our neighbours that chose that particular software and then run it without an appropriate secure setup?

There's enough blame for everyone.

Blame the users who don't secure their systems and applications.

Blame the vendors who write and distribute insecure shovel-ware.

Blame the sleazebags who make their living infecting innocent people with spyware, or sending spam.

Blame Microsoft for producing an operating system that is bloated and has an ineffective permissions model and poor default configurations.

Blame the IT managers who overrule their security practitioners' advice and put their systems at risk in the interest of convenience. Etc.

Truly, the only people who deserve a complete helping of blame are the hackers. Let's not forget that they're the ones doing this to us. They're the ones who are annoying an entire planet. They're the ones who are costing us billions of dollars a year to secure our systems against them. They're the ones who place their desire for fun ahead of everyone on earth's desire for peace and [the] right to privacy.