Interview with Marcus Ranum

2005-06-23 09:09

http://www.securityfocus.com/columnists/334 Federico Biancuzzi 2005-06-21 Could you introduce yourself? I am Marcus Ranum, Chief Security Officer of Tenable Network Security, Inc., the producers of the Nessus vulnerability scanner and a suite of security vulnerability management tools. I've been working in the computer security arena for about 20 years, now, and was the designer and implementor of a variety of security solutions in the past, including firewalls, VPNs, and intrusion detection systems. I like to think I've been around long enough and done a wide enough variety of things that I've achieved a pretty good perspective on the trade-offs inherent in security technology. I was the designer and implementor of the first commercial firewall product, the DEC SEAL, in 1990, and was the "inventor" of the proxy firewall concept. In 1992 I wrote the TIS Firewall Toolkit and Gauntlet firewall, and set up and managed The President's email server (whitehouse.gov) during its first year of operation. I was founder and CEO of Network Flight Recorder, an early innovator in the IDS market, as well. IPv6 should be the future. Do you see a more secure future then ? No, IPv6 isn't going to solve anything. IPv6 is just another network protocol, and if you look at where the problems are occurring in computer security, they're largely up in application space. From a security standpoint IPv6 adds very little that could offer an improvement: in return for the addition of some encryption and machine-to-machine authentication, we get a great deal of additional complexity. The additional complexity of the IPv6 stack will certainly prove to be the home of all kinds of fascinating new bugs and denial-of-service attacks. Also, don't forget that the current version of IP has encryption and authentication built in already - and that hasn't helped solve any problems at all. Do you think that the problem is that we can't develop a secure protocol, or that people who define standards underestimate security threats ? That's a profound question. There are a lot of factors that combine to defeat security in up-front design. For example, there's basic human nature: the guys who are defining standards can't resist the urge to leave their personal stamp on the future - which results in standards that generally have been assembled based on a process of negotiation by committee. That doesn't really work. That's what gives us these insanely complex multi-optioned heavily layered standards that nobody really understands: every person on the committee had to lobby to get his or her favorite feature included. I don't think that process in any way helps bring about useful security standards. A case in point would be the IETF's terrible fruitless attempts to establish a standard on IPSEC (IP crypto) It only took something like 9 years. Those of us in the commercial world who needed solutions just went ahead and solved the problem for ourselves while the IETF kept arguing. If I recall correctly, when we added IP crypto to our Gauntlet firewall in 1993, it took my engineer on that feature about two months to come up with a complete proprietary implementation. I don't think that the standards committees underestimate security threats; I just think they're too busy doing things that are more important to them -- like holding meetings and writing minutes, or whatever it is that they do all the time. The standards I've seen that try to address security all seem to be over-engineered and too late, while the standards that ignore security are usually rapidly adopted and full of security problems. It's a no-win situation either way. Do you have any idea how to improve the way RFCs get created ? I think the whole RFC process is obsolete. In fact, it never would have worked at all, if not for the fact that in the early days, nobody cared about the Internet. So the IETF could have their meetings and write their RFCs in a vacuum that was free of commercial interest. Once the Internet became a commercial phenomenon, you can see that the IETF's productivity basically went to zero because the vendors were all trying to pack the working groups with their people to make sure that their existing implementations got selected as the standard. That's pretty much what happened with IPSEC, for example. IETF nearly converged on an IPSEC standard several times until Cisco and other large vendors began making rumblings about "we won't support this" and "we hold patents on that" to try to keep the market divided. How would I improve it? I think if you look at what standards committees have become today, they're really little more than ratification bodies that rubber-stamp the de facto standard. Usually they tweak it a little bit to salve their pride but that is about it. I think we could do away with the whole standards thing very easily if a few customers just exercised their economic power a little bit intelligently. Big customers have huge power, but they seem to have forgotten that. If the CTOs of 10 FORTUNE 500 firms announced that they were deferring further purchases of VPN products until they saw proof of interoperability, and open published specifications that weren't encumbered by patents or licenses, the whole market would standardize practically overnight. Because the truth is nobody cares about standards - everyone cares about what you can do with interoperable systems. If customers just openly refused to do business with vendors that produce non-interoperable systems, the whole thing would clear up really fast. The RFC idea could be brought into the present day if it came from customers not vendors and dilettantes. How about if the CTO of AT&T announced "We're going to standardize on XYZ's implementation of online telephony" and the CTOs of GE, Verizon, Ford Motor [Company], and Citibank announced "we're doing that, too." Game over. Big customers need to drive standards by not tolerating market-dividing games from vendors. Sitting back and waiting for vendors to come up with standards means that they can divide the market while they're waiting to see who becomes the dominant player. Then everyone has to standardize on the dominant player anyhow. Right now, the whole way we do standards is 100% backwards. Just flip it around and it might work a whole lot better. If a standard protocol is broken or insecure, what is the best solution? Maybe supporting only some features or adding a crypto layer? If it's broken, adding crypto just makes it broken and hidden. If a standard protocol is broken, the best solution is to deprecate the standard and use something else. Just fix it and move on. It's not like standards are some kind of holy writ; nobody is going to be punished for ignoring bad standards, right? Remember the ISO networking protocols? Too late, too complicated, and everyone said "no thanks." We can do the same, and we should. Big customers should feel empowered to tell vendors (or standards committees, for that matter), "Nope. That sucks. No money for you, until you fix it." The customer is always right. Have you ever chosen to avoid a protocol because you considered it completely broken by design? All the time. I avoid 90% of the current internet protocols. It's a hard fight, though. When I was CTO of one company I kept having to fight to keep our sales team from using those stupid, "remote control your PC to give a customer demo" technologies. What kind of customer would give a vendor's sales rep control of their desktop? But people keep/kept asking for it. Eventually, these problems migrate from being technical problems to political problems, and then security goes out the window. What about WiFi? I waited for 8 years until the technology was fairly sorted-out before I spent any of my money on it. So, unlike all the "early adopters" who bought wireless access points with buggy crypto and huge security holes, I got something fairly decent for under $100, and it supports WPA which, by all accounts, is pretty good. Sometimes, patience is a terrific strategy. Wait and see what happens to the early adopters. If they're all getting hacked to pieces or spending tons of money on patches and upgrades and fixes to the stuff they bought - then it's not ready, yet. This seems obvious to me, but a lot of very senior IT managers don't appear to understand it. The longer you wait the more desperate the vendors will get, and, if you can articulate your requirements clearly, the more likely they'll listen to you. Do you see any new, interesting, or promising path for network security? Nope! I see very little that's new and even less that's interesting. The truth is that most of the problems in network security were fairly well-understood by the late 1980's. What's happening is that the same ideas keep cropping up over and over again in different forms. For example, how many times are we going to re-invent the idea of signature-based detection? Anti-virus, Intrusion detection, Intrusion Prevention, Deep Packet Inspection - they all do the same thing: try to enumerate all the bad things that can happen to a computer. It makes more sense to try to enumerate the good things that a computer should be allowed to do. I believe we're making zero progress in computer security, and have been making zero progress for quite some time. Consider this: it's 2005 and people still get viruses. How much progress are we making, really? If we can't get a handle on relatively simple problems such as controlled execution and filesystem/kernel permissions, how much progress are we going to make on the really hard problems of security, such as dealing with transitive trust? It's 2005, and IT managers still don't seem to know how to build networks that don't collapse when a worm gets loose on them. Security thinkers realized back in the early 80's that networks were a good medium for attack propagation and that networks would need to be broken into separate security domains with gateways between them. None of this is rocket science - I think that what we're seeing today is the results of this massive exuberance in the late 1990's in which everyone rushed to put all their mission critical assets onto these poorly protected networks that they then hooked to the Internet. That was a dumb idea, and that fact just hasn't sunk in, yet. 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. Copyright 2005, SecurityFocus _________________________________________ Attend the Black Hat Briefings and Training, Las Vegas July 23-28 - 2,000+ international security experts, 10 tracks, no vendor pitches. www.blackhat.com

News URL

http://www.securityfocus.com/columnists/334