TechTalks Transcript
Securing the Network: Emerging Technologies
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Jeff Schiller [JS] |
October 3, 2001
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN Tech Talk series for fall of 2001 and to this session on Network Security and Emerging Technologies. You are here because it�s time to discuss the core technologies for your future campus. This is Judith Boettcher, your CREN host for today, and our session today is coming to you with the support of the CREN member institutions and Chrysalis ITS. Chrysalis ITS is the leading vendor of hardware-based PKI Root Key Protection solutions. Let me welcome our technology anchor for today, Howard Strauss of Princeton. And Howard, as you all know, is a well-known web technology expert and portal expert, calling in from, I believe, your office in Princeton today, Howard.
HS: Yes, I am.
JB: Okay.
HS: Thank you, Judith. I�m Howard Strauss. I�m the technology anchor for the Tech Talk series of technology webcasts. Today we�ll engage our guest expert, Jeff Schiller, in a lively technical dialogue that will answer the network security questions you�d like answered and we�ll ask those very important follow-up questions. You can ask your own questions by sending e-mail to expert@cren.net any time during this webcast. If we don�t get to your questions during the webcast, we�ll provide an answer in the webcast archive. We all know the basics of making our homes and personal property secure. The first and most important step is prevention, an ounce of which is worth a pound of cure. We put locks on our windows and doors, install lights that turn on when a human approaches and post signs warning of ferocious guard dogs. If we can convince potential attackers that our assets are too difficult to subvert, then we will have won the battle before any damage is done. Our next security layer is detection. No amount of prevention will stop all threats, so we need to insure that if an attack is successful, it will be detected. If someone is draining our checking account despite our best precautions, we need to be warned of it as early as possible, preferably while it�s happening for the first time. Once we detect a security violation, we need to have an immediate appropriate reaction that will end the attack, alert others and possibly trap the perpetrator. We might close our checking account, for example, and have the bank look at the last few transactions to that account. Having detected a security violation and reacted to it, we then need some recovery plan. We�d like to get our money back, but we�d also like to make sure that our credit cards weren�t also attacked, and we need to revise our security plan to make it less likely that this attack will be successful in the future. Like our personal property, our networks are vulnerable to breaches of security. But our networks are much more available to many more people than our personal property. Hackers from Europe, Asia and Indonesia, for example, will not be routinely checking the locks on our houses for weaknesses but they are out there now actively probing our networks. And they are smart, determined and very knowledgeable about our network systems and the latest defenses we created to deter them. They may want our data or they may just want to deny us the ability to use our networks and systems. Whatever they want, we need a plan to prevent, detect and react to their threats and to recover from them. This is not a new problem, but it has increasing urgency as networks have become more important to everything we do. There are very clever bad guys out there. Jeff Schiller is one of the very clever good guys. He�s here with us to give us some valuable insights on how to deal with these threats on today�s webcast of Tech Talk. Judith? HB: Thank you, Howard, and I think we�re all looking forward to hearing about how we might deal with some of these threats that we have in our computerland. Let me welcome our expert for today, Jeff Schiller, who is the Network Manager at MIT since 1984. Jeff is the author of MIT�s Kerberos authentication system and the Area Director for Security for the Global Internet Engineering Steering Group. In this role, Jeff is responsible for overseeing security related working groups of the IETF, the Internet Engineering Task Force. He was responsible also for releasing a US legal freeware version of the popular PTP encryption program. Jeff is also responsible for the development and deployment of an X.509 based public key infrastructure at MIT and also the technical lead and advisor for the Higher Education Certifying Authority being operated by CREN. More about Jeff is at the website. Welcome back to Tech Talks, Jeff. It�s been a while since you�ve been a guest on Tech Talk and we�re just really pleased to have you back. Want to tell us where you�re calling in from today?
JS: Yes, thank you, Judith. One of my other activities is I�m a rabbit and cavy breeder and I�m calling in today from the Topsfield Fair in Topsfield, Massachusetts, America�s oldest agricultural fair, founded in 1818. And I�m sitting here wearing sweats and covered with bunny fur.
JB: And are the rabbits secure?
JS: Oh, very!
HS: We were going to talk about the security of rabbits and we were going to ask you a lot of questions about cavies, which we know nothing about. But instead, just as an alternative here, we�d like to talk about the kinds of problems that we�re facing with network security. I believe that earlier you said that there were some problems that encryption can help and the other problems were things caused by bugs in programs. Could you talk about those two kinds of problems?
JS: Yeah. Basically, if you look at security problems that we have, they roughly fall into two categories. There�s one class of problems that encryption technology can certainly help. If somebody is monitoring or eavesdropping on a network or reading your e-mail, encrypting your e-mail will help. In fact, one thing people traditionally do is they spy on an Ethernet in an attempt to steal usernames and passwords. Again, appropriate use of encryption will help against that problem. The second class of problems, encryption cannot help you. And that�s people taking advantage of what we call buffer overruns which is a class of bug that is very common to have when programming in the C programming language, and just about every application people use today is written in C. And these program bugs allow an intruder, through the bug, to actually obtain very often administrator access on the target computer. Recent programs we�ve seen that do this are everything from the Love Bug, as it was called, the Melissa Virus and more recently Code Red, Code Red II and its various variants.
HS: The way you�re talking about these, Jeff, it sounds like the encryption problems are easier to deal with. We just encrypt things and if we encrypt them with some good algorithm�and we do that pretty well�that all gets taken care of. And bugs in programs problems is more difficult. Is that what you�re saying?
JS: Well, actually, they�re both difficult. I mean, for example, Howard, if you and I want to exchange encrypted mail, we really can�t do it unless we have programs to do that. And whereas I might have such a program because I�m a security person, the average person won�t have such a program until the makers of software sort of make those programs easy to use and obtain. And similarly, software bugs and buffer overflows have their own set of hardness in terms of software developers have to actually do a significant amount of work to avoid them. So both are hard, though hard in somewhat different ways.
HS: Are these equally dangerous?
JS: Are they equally dangerous? Yeah, I think so. A comment you made��
HS: Because not many people are using encryption, are they?
JS: No, in fact, not only are not many people using it, but the people who tend to be using it are not the people who we need to have use it. If you look at a typical organization, the higher you go in the organization, the more important it is to protect information. I was once on a plane trip and the gentleman sitting next to me was the CEO of some company and he was using the airline phone to talk about mergers and acquisitions that his company was going to be engaging in. And so he was sharing it with me in the next seat, but
HS: Oh, yeah, you and probably half the airplane!
JS: But more importantly, with people in about three states since anybody could listen in to that telephone conversation if they had the right kind of radio.
HS: But when we hear about people breaking into networks and things like that, are they exploiting the lack of encryption or are they exploiting bugs in programs, or both?
JS: They actually do whatever�s easiest. Most people doing break-ins today are not developing their own break-ins, they�re using a toolkit that they get from someone. And in fact, some of those toolkits take advantage��
HS: Not our sponsor!
JB: I don�t think so!
HS: They don�t provide the toolkits.
JB: And we don�t want to give that out, right?
JS: I�m talking about toolkits provided by the underground.
HS: Okay, so there�s underground toolkits.
JS: Oh, yes!
HS: And these are just a bunch of tools that people keep building on and passing around from one bad person to another?
JS: Yeah, and a lot of times�it used to be on bulletin board systems, now it�s on bulletin board systems and websites, or via Internet-relay chat or any other number of mechanisms.
HS: So you don�t have to be too sophisticated, then, to do some of these things because a lot of the tools have already been built by people?
JS: Oh, yeah. I mean, if I give you the name of one of the tools, your listeners could probably go to Google, do a web search and probably find four or five copies of that tool that they can the download and use to break into other people�s sites.
JB: What about the sophistication of trying to protect oneself from these kinds of threats, Jeff? Have they gotten more sophisticated?
JS: Well, one of the things that we have is it only takes one person who�s very sophisticated to create the toolkit and then share it with 100,000 of their best friends on the Internet. And so sometimes people say, �Well�� And you know, when I�ve talked to vendors about security and vulnerabilities in their products, they may say to me, �Well, that�s a very hard one to exploit. You�d really have to understand what you�re doing.� And I said, �Yeah, that may be true, but it only takes one guy to figure that out and to write the program, and then overnight you have a very big problem.
HS: Okay, why don�t we take one of the questions that we have already here? Since I think that�ll get us into an interesting area here. We have an e-mail from Thomas Pischel at the University of Wisconsin at Parkside, and Tom says, �Our library does not require any logon when using the numerous hard wired computers spread throughout the library. With the advent of a wireless network, identification arguments among the staff are exasperated. Do you have any suggestion for keeping open access, as the librarians wish, for any and all library users and having adequate control over the security of the network, as the techies desire?� No logon at all! That�s something!
JS: One of the things we have to do�and this question takes us off into an interesting territory. Today, if you go to a lot of typical corporate managers and you say the word �security,� they say the word �firewall.� We put firewall around our company and that�s our security perimeter. And one of the things that we�re learning is that�s not sufficient. We need to have secure applications that are secure even in the presence of an Internet that has people on it who may not like us. And the reason I say this as part of this question is we cannot defend the Internet at its perimeter because, frankly, the Internet perimeter is the perimeter of the planet earth. People, as you said earlier, can get on from every country that you can think of, directly have access to the Internet. They don�t need to use our libraries to get access to the Internet. And so frankly, allowing anonymous access via libraries is, in fact, just fine and we shouldn�t figure out how to restrict it. I think people who would try to restrict anonymous access from libraries would go around tearing out pay phones. I mean, pay phones are a fact of life and anonymous access to the Internet is a fact of life. And to be fair, a bad guy who is going to attack the Internet is probably going to do it from overseas, not from a library within the United States, not if they�re smart.
HS: But you�re saying that if somebody did attack this thing, I mean, if somebody used this anonymous connection to attack other things on campus, that�s somehow not worse than forcing them to log on? Because they�d be so clever if they were going to attack the system, you wouldn�t know who they were anyway.
JS: Well, it�s just that I�m more worried about attackers coming from overseas where I have no hope of identifying them. If they�re coming from my library, effectively, I have them because if they keep attacking from the library, we�ll just stake out the library and catch them in person.
HS: Okay. I mean, Tom was also talking about the impact of wireless networks. Does that change anything, the fact that we have wireless connections rather than hard-wired connections?
JS: Not really. I mean, again, there�s the possibility that somebody sitting in your parking lot could get access to your network, but the wireless, like the 802.11 networks that are deployed today, you really have to be very close. You can�t be half a world away. You have to be in the general vicinity. You have to have yourself very close.
HS: Yeah, but you could be just outside the campus. I mean, if the campus runs�if there�s a campus building that runs along the street, you could be in a car outside the street, outside the campus.
JS: But for example, if somebody was doing us harm from that location, we could figure out within probably about 150 feet where they physically were. So they�re not really anonymous when they use a wireless network. We can actually find them. And so they put themselves at considerable risk by being right there.
JB: So in terms of Tom and the library question that he has here, then, what kind of control or security for the library would you recommend, Jeff?
JS: For a library, I think having open access terminals is just fine. And I don�t think you have to worry about it beyond that.
HS: Okay, if we�re talking about these two kind of threats again, the threats involving encryption and ones with bugs in programs, if we take the first one, the encryption thing, what kind of things do we do? I mean, what kind of reasonable policies should we have on a campus about encryption that would protect us?
JS: Well, one of the things we�ve been trying to do in the IETF for a very long time is to say �No passwords on the network unencrypted.� And so we should not use products that depend on passwords being sent in the clear over the network. And when vendors come in to sell us something that works by sending passwords over the network, we say, �We�re not interested in your product. You need to put in better security than that.� And to be honest with you, we�re beginning to make headway with that argument. A few years ago, people would say, �Hey, where�s your firewall? That�s what your firewall is for.� And now people are beginning and vendors are beginning to understand that that�s really not a sufficient answer. And so I think the first level policy is no applications sending in-the-clear passwords over the network. So for example, if on campus, some administrative department wanted to set up a website that people would have to log into to get access to sensitive information, that website should be using SSL protection and encryption and shouldn�t be taking people�s names and passwords and then giving out sensitive information unencrypted over the network. That would be a policy.
HS: SSL is good enough?
JS: SSL for most cases is good enough, yes.
HS: What kind of encryption does that use, do you know?
JS: Well, it depends on what you�re running on the server and what you�re running on the client. If you�re running anything like modern software, that�s going to be using a 128 bit RC 4 which, I think, is quite adequate for what we have. To my knowledge, I�m not aware of any security systems that have been broken by somebody breaking that.
HS: Okay, so they�re not using RSA or something like that. RC 4 is strong enough.
JS: Well, no, RSA is�you have to be careful. RSA is an asymmetric algorithm. In fact, when you do use SSL, you are using RSA. But you�re also using RC 4 as well.
HS: Okay, so at any rate, though, somebody running web applications, if they�re running SSL, you�re saying that every web application that uses authentication ought to use SSL. Should we just use SSL all the time, for all applications? Wouldn�t that be easier, safer?
JS: Well, you actually have two problems. One of the things we�ve been doing at the MIT campus, of course, is we use SSL protected websites for all of our administrative access and we�ve been using X.509 client certificates for authentication to those websites. But at a very beginning, I think, if everybody said every administrative website, whether it�s the Registrar, the Bursar, Human Resources, should be using SSL on any website that has any information on it that isn�t completely public. So if employees need to log in to check on their health benefits or their medical open enrollment, all that should be encrypted.
HS: What about encryption and e-mail? Should everybody be using encrypted e-mail? Is that a policy campuses should have?
JS: Well, I would love to say that that would be a policy everyone should have, but the reality is, the software is not widespread enough. I mean, today, if you have a copy of Netscape Navigator, you have a copy of Internet Explorer, you have encryption in your web browser. Period. End of sentence. But it�s not the case that I can tell everybody that they have encryption technology. E-mail requires a bit more infrastructure than I think we have. I�d love to be able to do it and we�re certainly working right now on the MIT campus to try to deploy encrypted e-mail in a way that everybody can use it without having to become an encryption expert, but I would say right now for most places, the technology isn�t quite widely deployed enough to be able to say �Thou shalt���
HS: What�s it going to take to make that happen? What are we missing here?
JS: Well, we have a user education problem. Many people just assume that their e-mail is secure and they just don�t think about it. And we need to establish, I think, the norms in society that that�s unacceptable. And HIPA, the Health Information Privacy laws may help because when doctors start sending e-mail to patients, there needs to be some standard as how that�s protected.
HS: Okay, there�s been lots of talk about these viruses and worms and other things coming in to attack us. How do we prevent those things from happening, or how do we minimize the impact of those things?
JS: Well, there�s two answers to that. One obviously is if what you�re doing is writing an application, you have to put some real concern and security care into the design of your application up front. But if you�re like most people, using applications that you get as effectively commodities from certain vendors we all know, we didn�t write the code and we really can�t fix the code and we�re sort of at their mercy. But one thing that anybody can do is keep themselves up to date. For every security situation I�m currently aware of, everything from Code Red to Code Red II to NIMDA, there are patches out there that will make you safe against them. You have to put them in.
HS: I mean, but the patches came after those things happened, weren�t they? Or were the patches there already?
JS: No, the patches were there already.
HS: So people who had every patch that came down the pike installed were not infected by these things.
JS: That�s correct.
HS: Wow!
JB: So do system admin folks on a regular basis, then, they need to be doing this once a week or once a day?
JS: Well, part of the problem is, you know, the desktop operating systems, everybody�s their own system admin.
JB: Right, that�s true!
JS: And so that means if all system admins need to do this, it means all users need to do this.
JB: Right. And that sounds like that�s pretty hard.
JS: Yeah, it�s pretty hard. It�s hard because, to be honest with you, a lot of times the installation process of these patches is risky/�
JB: Yeah?
JS: I talk to people and I say, �Why aren�t you up to date?� And they say, �Well, the last time I put a patch in, my computer was a brick for three days!��
HS: Well, I think when that happens to you�and that kind of thing has unfortunately happened to me and unfortunately for more than three days�I mean, obviously people are going to be reluctant to turn their computers into bricks for periods of time. What can we do to make it so that doesn�t happen? If it didn�t happen, people would be more willing to do this.
JS: You know, we have to make it clear to the vendors of software that have these bugs that it�s unacceptable to turn out software that has this type of bug and it�s really important because even no matter what you do, we�re all human. There�s always the chance that there�s going to be a bug. But you need to design patching systems and upgrade systems that aren�t risky for people. And to be honest with you, we need better operating system software because my own opinion is a lot of these problems were solved in the 70s. They just didn�t get where they need to be because the desktop computers we use today evolved from microcomputers which left a lot of that stuff off because it didn�t run on those tiny machines.
JB: What do you think about the mechanism of automatic patches, that when you do sign on, when you boot your computer up, if you�re missing a patch that something automatically does that?
JS: Well, I have two opinions of that. Three. Three opinion. One is, if we can do it right, it�s a great thing. But doing it right means two things. One is, we have to secure that system lest we have a bad guy use that system to propagate their malware.
JB: Good point!
JS: The second one is we have to make patch systems that don�t turn people�s computers into brick so that they will feel comfortable turning on the automatic update. And that�s a consumer confidence issue. But what I tell people when they say, �I don�t want to upgrade my computer because it might turn into a brick,� I say, �Well, guess what? If you catch one of these worms or viruses, your computer�s going to turn into a brick. You only get choice over what color brick it is, whether it�s a red or a green brick.��
HS: You said there was a third point you were going to make?
JS: Well, my third point really was that we have to get people to want to do it.
HS: Yeah, I mean, isn�t there another way to do that? I mean, another way to get these automatic updates is to have the updates come from the central system at your university rather than to come from the software vendor. I mean, this way, you could actually look at the patch and decide that this is an okay patch and so it would make it more difficult for somebody to slip kind of a patch in disguise.
JS: Well, I can tell you, that�s actually a controversial statement and the reason it�s controversial is imagine a vendor that had a confident, capable team putting together patches that only they could distribute to everybody. By the way, one way to do this is to have the patches be digitally signed. A lot of that technology is already deployed. They�re probably going to get it right, but if you said every corporation or every institution could control what the patch looked like, chances are they�re more likely to make mistakes. And so it�s a near thing. You know, probably the best solution would be the patches must be signed by the vendor, but whether they get distributed or not is a decision that can be made at the corporate level.
HS: Right, so the corporation or the university could sit there and try the thing in their environment and say, �Yeah, this works okay, let it go.��
JS: Yeah, except the risk is that those organizations might add enough delay. You know, a lot of times these patches come out�what happens is a bad guy invents the program that takes advantage of the security hole. The vendor hears about it, they develop a patch. And meantime, at the same time the vendor heard about the problem, all the bad guys in the world heard about the problem and they�re off coding their latest worm or virus.
HS: So get around the patch, because they got the patch, too.
JS: Well, not that they get around the patch. It�s just that they�re going to try to slip in the window. What I�m saying is that the patch may come out and you may only have three days to put it in before some worm will kill you. And if your university takes a week to evaluate the patch, you know, you can have a situation where the operation�s a success but the patient�s good and dead!
HS: Okay! Since you know that putting these patches in in a timely fashion is a good thing, obviously at MIT, all the patches get in in a timely fashion, right?
JS: Well, actually we�ve been very successful at MIT. I can�t say that everybody patches their computer right away, but on any given day, if we had one computer with one of the Code Red worms, that�s a lot. We have been very aggressive at shutting people off who get these things and that, of course, provides motivation for people to install the patches.
HS: How do you discover that? That�s the question I really had, was that obviously some of this stuff slips through. Once it does slip through, what do you do or what should universities do?
JS: Well, each one of these worms has its own signature and you learn to recognize that signature. So for example, Code Red, Code Red II and NIMDA actually have a very common signature which is they all try to talk to lots of different computers on Port 80, the web port, in order to propagate. But they pick lots of IP addresses, Internet addresses that don�t exist. Now, our border routers, we can look at what�s called the flow cache. Flow caching is a feature of most Cisco routers. And I can see computers in that flow cache that are trying to talk to nonexistent Internet addresses. If I see a computer that�s trying to talk to a thousand nonexistent Internet addresses within the last minute or so, that�s a pretty good indicator that it has one of the code red variants and we track it down and turn it off.
HS: So you are, from some central point in your network, you�re going out and you�re looking at the traffic level of every machine?
JS: Well, no, what I�m looking at�it�s quite complicated. I�m looking at the routing table in the root and what�s actually called the flow cache, which is a cache of the routing table. And it turns out it�s easy to spot machines that are trying to talk to lots of different addresses, particularly if the addresses don�t exist. Stands out like a sore thumb if you process that properly.
HS: You said you also detected machines on your network that were vulnerable. Could you tell us what that means and how you do that?
JS: Okay, there�s two different things here. One is, of course, detecting machines that have been broken into by the telltale signatures, if you will, that they leave. But we also have an active program where we will scan machines. If we know, if there is some way that we can detect if a machine is vulnerable remotely�and that may not always be the case, but it turns out that for Code Red it is the case�there�s a special way that you can construct a URL and you can sort of hit the machine and it will respond differently whether it�s vulnerable or not. And so we will scan our range of IP addresses looking for machines that are vulnerable. And obviously, once you find them, you try to get them fixed before they�re broken into.
HS: And by vulnerable again, you mean it doesn�t have all the patches on it, or what?
JS: Right, I mean, in the case, say, that it would be vulnerable to Code Red would mean it does not have the patches that would defend against Code Red such that if a machine infected with Code Red chose its IP address, it would then get the infection.
HS: And you turn that network connection off on that machine?
JS: Well, we have a very strong policy that machines that are broken into, we will turn off. Period. End of sentence. No appeal, no�and we have this right up to the level of the president of the institute that says we can do this. It gets dicier when you deal with machines that are vulnerable because you have to sort of ask yourself, �What�s the likelihood that this vulnerable machine will be exploited?� Now, in the case of Code Red, that vulnerability being exploited is very high. And so in the case of Code Red, we have been turning off machines that are vulnerable. But the decision really depends on the worm and the situation and it�s one of those things we have to do very much on a case-by-case basis.
JB: Once you turn those off, what�s the average--you know, how long does it take someone to get back online and get their machine fixed, given that we�re so dependent on these machines?
JS: Well, let me give you the straight answer on that.
JB: Yeah.
JS: If a machine is compromised, that machine must be erased. It must be wiped clean and reinstalled because that�s the only surefire way to know that the various worms�these worms leave back doors that bad guys can get in and the only way to know that you�re really gotten them out is to completely reinstall.
HS: Could you explain that a little bit more? They leave back doors? Tell us what they really do. What�s that mean?
JS: Well, for example, if you get NIMDA�Code Red, it turns out, did not leave a back door but Code Red II did and NIMDA does. And what that is�it varies by worm�but for example, if your computer had NIMDA or Code Red II, then from my computer, I could actually go to your computer and issue any command, install any program and modify your computer in any way I chose. You don�t even know me!
JB: So it�s a back door that�s open, in other words. It�s an open door.
JS: Yeah, in fact, in the case of Code Red and NIMDA, it is a wide open back door. And anybody on the Internet who knows your machine�in fact, one of the ways NIMDA propagates is it looks for back doors left by Code Red II!
HS: One worm looks for the fact that another worm has been by.
JS: That�s exactly true.
HS: Well, it�s nice they work together. Good that we see some cooperation.
JS: So for example, if I got to your computer that was hit by Code Red II I might choose to install Back Orifice which is another one of these programs that lets me remotely control your computer. And so I�ve taken over complete control of your computer, and it turns out in the case of Code Red II and NIMDA, I do it via web browser and a properly reconstructed URL and I�m in.
HS: If a place like MIT, where you seem to have some pretty good controls in place, still gets infected to some degree anyway, what are you folks going to do to make it even less likely that this thing happens?
JS: Well, we have a very aggressive network security team that, like I said, is turning off machines that are already infected or vulnerable to infection. We also have our own distribution site for various virus protection programs and we have an active education program. And you know, word travels. If you turn off somebody�s drop in their dormitory, for example, in their dorm room because of this, everybody on the floor learns what the problem is. And so word gets out. If you get a computer that has one of these vulnerabilities, that you do have to install the patches right away.
HS: Do you insist that there be virus scanning software on every computer on campus?
JS: No, we don�t require that. We strongly encourage it and we make it easy for people to install. And we�ve site licensed several different products. But we don�t have a rule that I�m aware of that absolutely requires it.
HS: Would that be a helpful thing to do? Why don�t you do that?
JS: Well, it turns out that we haven�t needed it because for the most part, most people have been installing the software. Like I said, we�ve hardly been affected by Code Red and Code Red II.
HS: We hear a lot about CERT. What are they up to, what are they doing?
JS: Well, they were originally chartered to do one thing and they�re doing a different thing. Specifically, what they�re doing is they�re acting as a coordination center for alerts of security problems so for example, if I discovered a security problem, I might notify the CERT and say, �Hey, there�s this program that�s out there and it can be broken into in this fashion.� And what they would do is they would go to the vendor of that program and say, �Hey, we had somebody report to us that there�s a way to break in and this is how you do it and you should really get a fix out.� And then the CERT will make a decision at some point to alert the community at large by sending out their advisories that there�s a problem and here�s how you fix it.
HS: So they just sound some warnings.
JS: And they also act. Their advisories tell you how to fix it.
JB: If one wants to keep up-to-date with what�s going on, do you have a favorite place that you recommend, Jeff?
JS: Well, I tend to look in two different places. I tend to look at the CERTS website, cert.org. I also tend to look at securityfocus.com. And then there�s various mailing lists like Bugtrack and NT Bugtrack that tend to have very early information about problems.
JB: Okay, and in terms of the campus situation in terms of the protection for the individual computers, once you�ve actually�if a campus were to choose only two or three tools, are there a couple of or a couple of policies that you would recommend every campus look at?
JS: One of the things that we agonized about a long time was what to do about security scanning software, particularly since if you�re running a computer, how do you know the difference between a legitimate security scan by the security people on campus vs. some kid in their dorm room trying to see if they can break into your computer.
JB: Good point!
JS: And so what we�ve done is we only do our security scans from a limited number of machines which we carefully guard because, you know, it would be very embarrassing for somebody to break into those machines to use them to do a security scan for bad purposes. So we have a limited set of machines that we will use centrally campus-wide for scanning. We permit a department to scan their own machines, so if a department administrator wants to buy a product and do some scanning, we say, �That�s great, but you can only scan your machines. You can�t scan other people�s machines.� Otherwise those other people will call us up saying they�re being broken into.
HS: Okay, I think we�re going to take some e-mail that we got, actually, from Blair Powell from our sponsor here. He sent this in before the Tech Talk and we�d like to remind you that you can send e-mail in before the Tech Talk or during it. And in fact, if you�d like to do that right now, that would be a very good time to do it. Blair Powell has two questions. One is, �Where do you see encryption strength in the next two or three years?� Blair says, �Currently, most CA�s recommend 2,048 bit RSA. Is 4,096 bit far behind, or will competing technology such as ECC replace RSA? What is preventing ECC from being more widely accepted?� Maybe you could tell us what all these things are, too.
JS: Okay, this is actually a complicated question so unfortunately, the answer will be complicated. In the encryption business, one of the things you have to do is you have to look at what you�re doing and say, �Is this the right technology to apply to this job?� Just like when we eat our meals, we have the knife and the fork and the spoon and we use them for different functions, not all encryption algorithms are--you know, they�re like the knife, the fork and the spoon. There�s different kinds that solve different problems. Now, as far as RSA is concerned, my gut feel is that 2,048 bits is probably good enough for at least the next ten years. Keep in mind breaking RSA is an exponential process, so when you�ve doubled the key lengths, today, quite frankly
HS: Square of the effort, right?
JS: Well, it�s worse than that. Exponential is even worse than squared. It blows up very quickly. And it�s only very recently that people went from 1,024 bit keys to 2,048 bit keys and that more than doubled the work that a bad guy has to do and similarly, when you go from 2,048, if you went to 4,096 it would be just a phenomenal amount of work. Now, there�s always the risk that the RSA algorithm itself will be compromised, but if the algorithm is compromised, it doesn�t matter how long your keys are. The game is over. So on that basis, I think given that we can efficiently use 2,048 bit keys and CA applications, that�s probably fine. I would be willing to say five years, maybe even 10 years. If you held a gun to my head and said, �Bet your life,� I�d say, �Well, maybe five years.� Now, when we start looking at other algorithms, ECC is the Elliptic Curve algorithm. These are a variant of the Diffey-Hellman algorithms that use elliptic curves instead of number theory and I�m sure it�s beyond the scope of what we can talk about today to go into all the details.
HS: But we�ll recommend a good math course for listeners to take before we describe it.
JS: ECC algorithms are attractive because they use shorter keys and they are mathematically much more efficient in computation when you actually use them.
HS: So you don�t need as big a processor.
JS: Exactly. In fact, where they�ve become very popular has been in smart cards because in general smart cards don�t tend to have a lot of memory or a lot of processing power. And so they�re a really nice fit there. The problem with ECC algorithms�and problem is not the right way to describe this�is they haven�t been around as long and they haven�t been as studied. RSA has been around since 1977 when it was first invented and people have been trying to poke holes in it ever since. ECC is much newer than that. I don�t know exactly how much newer, but it�s much newer and unfortunately, ECC is actually a range of algorithms, each one of which has to be studied separately. And so if you put the gun to my head and said, �What�s the length key to use for this ECC curve?� as they call them, I wouldn�t be able to give you a good comfortable feeling that a given key length would be okay.
HS: So you see ECC being used for smart cards and other special applications and really just playing a different role than RSA?
JS: Yeah, it plays a very different role. I mean, if you consider smart card applications, many of them, the cards only last a certain amount of time just because of physical destruction, physical deterioration. If you had an application and we said we�re going to issue somebody a smart card ID card and it�s going to be good for a year, you�d say, �Okay, I�m willing to say that the ECC curve that this might use might be good enough for the next year. And more importantly, next year, I have an opportunity to change my mind.��
HS: Okay, and by the time, well, you break the code, somebody�s using a different card anyway.
JS: Exactly. So whereas when you pick a key for a certifying authority and you might want that key literally to stay unchanged for ten years, then you want a long key and you want an algorithm that you have a bit more confidence in.
HS: Okay, Blair has another question here which is sort of a follow-up on this thing. Blair says, �For the future, can we not devise a better solution for the problem of needing to upgrade encryption strength? In other words, is there a way to effectively distribute certificates and keys so that the root key and certificate�s encryption technology can be upgraded without affecting the PKI infrastructure?��
JS: Well, you know, building PKI has bee a very big problem. I mean, we are not there yet and indeed, one of the problems of building PKI is how do you build the root, how do you replace the root? But to be honest with you, we have other problems we have to solve which is how do we get the software out there, how do we get people to use it, how do we make it easy to use? And it�s really the case that pretty much today, people are not using software that�s ten years old. Yeah, some people are, but for the most part, people are using newer software. And I say that because I think we have a few years to figure out how to solve the root replacement problem and so I would say people�s time would be better spent trying to figure out how to deal with the other problems that are causing PKI to be not universally adopted.
HS: What are some of the problems that are making it not being universally adopted?
JS: To be honest with you, if I could tell you the magic bullet that would make it be adopted, boy, we�d be there now. Part of the problem is ease of use. If I look at the PKI applications that are out there, they really require the end user to have more understanding of how the technology works than end users want to have. I mean, we live in a day where people don�t read instruction manuals. Things have to be intuitive, they have to work the way they appear to work, and PKI technology from what I�ve seen hasn�t yet made that leap to it�s intuitively obvious how to use it.
JB: And yet the browsers are making progress in that direction.
JS: Yeah, in fact, the browsers, if you look at SSL, it�s a success story. It�s a success story. It�s getting it in other applications like e-mail would be like one of my most important applications for getting this technology deployed. I mean right now, for example, if I wanted to send you encrypted e-mail, Judith, you would have to e-mail me a signed message so that my browser would store your public key in my own private space and I could then send you an encrypted message. But that means that I have to ask you to send me a signed message which means I have to know why I want to do that.
HS: And then if you use two or three different computers and you�ve stored her message on one of them, right, she has to send you another message?
JS: Right. And some people say, well, the answer is a directory. We should have a directory and we should put these certificates in. But that raises the whole question of how do we build directories? The directory community has yet to be able to deploy directories that, in fact, work. And that�s a problem all by itself because one way is maybe I would get you the certificate out of a directory. But that means Judith has to have one certificate and it has to be installed on all of her computers.
JB: Well, that�s right and if I don�t, what about when we get to the point where we want something that�s smaller than a computer, that we want as we start moving to handhelds?
JS: Well, the only challenge that handhelds add, of course, is their lower amount of memory and CPU. And when I talk to vendors of handhelds, you know, they argue over every byte of storage and they have to be convinced that they should dedicate the storage space for the security technology that they have not yet perceived a market for. If you went to Compaq�not that I�ve done this, mind you�but if you said to them, �We want you to put all this security technology into the I-Paq,� just to pick a product as an example, they might come back and say, �Well, how does that improve our market share? How many more I-Paqs will we sell if we do that?� And in today�s market, the answer is probably �none.��
JB: Right.
HS: So this thing is going to be market driven. I mean, you�re saying it�s happening with the handhelds. Do you think that�s happening in other places, where people are just not putting the security in because they don�t see them getting the market share or the additional revenue out of it?
JS: Well, I mean, this is a complicated question because indeed, I think one of the reasons we don�t see security technology is twofold. One is security technology is hard to get right and hard to do and therefore takes time, and yet we have a market that�s driven by how quickly can you get the application out? People talk about doing things in Internet time. Well, doing things in Internet time and doing things securely are not quite compatible and the market is asking for security. Now, Bruce Schneir makes an interesting point. I don�t know whether this is in one of his books or I think was in the Risks digest. He said, �Security is a lot like safety. We don�t have seat belts in our cars because the market said we want seat belts. We have seat belts in our cars because the government said, �Thou shalt have seat belts because we�re going to stand for safety.�� And security is a lot like safety. The market doesn�t tend to ask for it. You sometimes may need government intervention.
HS: Is that what it�s going to take? Do we need the government to say, �You�re going to have whatever, the equivalent of seat belts and airbags and things�?
JS: Yeah, I�ll be honest with you. The problem that we have is that the government, particularly the US government, has discredited itself in the security area because when you talk about computer security to the US government what always comes up is, what back doors can we put in? And it�s almost as if you said�if the US government mandated safety belts, they put in the feature than when a bad guy�s being chased by the police, they could press a button to unlock his seatbelt so he should go through the windshield.
JB: Sounds like we�re in a real Catch-22 as far as that is concerned.
JS: Yes, it�s a real problem.
HS: Somebody in the government�s going to be listening!
JS: Say again?
HS: Somebody in the government�s going to be listening to that idea, Jeff.
JS: There you go!
JB: There we go. Coming back, trying to take a look at both where we are today, Jeff, and where we might be, let�s say two years or five years down the road, what should we be thinking about or doing in the area of security as we look at the future?
JS: Well, if you actually look out toward the future, the government actually may play an important role. And if you look at what�s happened in HIPA, where they said, thou shalt treat patient records in a confidential way, the government isn�t setting the security standards�which I think is good. They�re saying the security will be the proof of the pudding. If records get compromised, we�re going to want to understand how that happened. And then industry needs to develop the tools to do that. If that type of mentality can take over in other areas such that the market actually says, �We really need it to be secure.� First of all, I think the market needs to be convinced that it can be done securely and that it should be done securely and to be honest with you, I see two different visions. One vision is the market does that and we get improved security. And another vision is the market doesn�t do that and what happens is over time, we stop depending on our computers for our most sensitive information because we can�t trust that it�s not going to be compromised.
HS: What will we do instead?
JS: We�ll do any number of strange ad hoc things, I think. It�s hard to predict now, but certainly I know that when we on the IETF developed the SNMP, the Simple Network Monitoring Protocol, security got second place, let me put it that way, in the design of that. And as a result, network operators use SNMP to look at their networks but they don�t use SNMP to change their networks because it�s not secure enough. And so we may have people using e-mail to send pictures of their baby to Aunt Marge but we may not have people using e-mail to discuss their medical condition with their doctors. And so what�ll happen is, I think, a lot of electronic communications may get relegated to the trivial instead of being used more widespread.
HS: One of the things you had said at one point was that the Internet was not designed with security in mind. Does that mean that there�s no hope for making it so that security is an integral part of it?
JS: Well, I never say there�s no hope! Indeed, the Internet was never designed with security in mind. It was never, to be honest, designed�I�m sure if you went to the original inventors of the Internet and said, �One day, you will see host names on billboards�� They didn�t know what a URL was in those days. They would be shocked. Even in 1988, that something like the Internet worm would be on television, I think they would be shocked. And so security was never one of the cornerstones of the Internet. But on the other hand, the Internet is not security-hostile. It is not impossible to do things securely. And in fact, my own personal bias is that security should be in the application and shouldn�t demand a secure Internet. We should look at the Internet as an insecure medium. A good analogy I like to use is the highway system. We don�t have a secure highway system. The highway system doesn�t protect your home from being broken into. It�s the locks on your doors, the quality of the police force in your area, but it�s not the highways. That�s not the role of the highways to in some way protect your house. And I think we need to look at the Internet that way. It�s not the role of the Internet to provide security, it�s the role of ourselves and our applications to provide security.
HS: To toy with your analogy, though, the highway system does have center barriers and guard rails and carefully banked curves and things like that. So it seems like it does do some things to help your security along.
JS: Yeah, but the Internet has those things, too. In some sense we need ISPs, Internet Service Providers, to secure their routers so that their infrastructures can�t be taken down.
HS: But I think what we�re coming around to is that network security is a shared responsibility and the people who build the software and the people who build the routers and the people who sit in front of their computers all share in this thing.
JS: Yes, exactly so. And in some sense, one of the problems is a lot of people have been unwilling to do that. People say, �Oh, security, that�s the firewall problem or that�s the network�s problem or somebody else�s problem other than me.� And really, the Internet should be secure in that it should be robust. It shouldn�t be itself vulnerable to being brought down. It�s like the power networks should be strong against being brought down. Vendors of applications need to be considering security so that their applications are secure and users need to be security conscious so they install patches, because no matter what the vendors do, we�re all human and people will make mistakes and there will be bugs. And so they need to share in that responsibility to properly install, upgrade and configure those products.
JB: Let me just remind the folks that are listening that you might have time to get in one more question before we have our closing comments.
HS: If you type fast.
JB: Type very fast, right! And as we start moving towards kind of a summary and leaving folks with an important message here, Jeff, you had mentioned about certain design criteria for, I think, both the campus network and then moving forward. In terms of summary, would you mention, perhaps, what you think are one or two of the most important design criteria going forward?
JS: Okay, for building campus network, when I said in this call today that we turn off computers that are broken into and we scan for vulnerabilities, in order for us to do that we have to be able to identify which computer�s on which port and we also need to be able to turn off individual network ports. So for example, we use SNMP manageable hubs so that we can turn off a single computer on a single desk in a single place without affecting a huge infrastructure and so that�s a very important design criterion, the ability to turn off individual ports. Another design criterion is to have as good a record as you can as to which ports go into which offices so you can contact the person responsible. But then you have to realize that no matter how well you do that, people move things around and you really can�t control what they do, particularly in a university environment. So you have to be prepared occasionally to figure out where the computer is because it will never�well, not never but it will often not be where your records say it is. And that means using hubs that, for example, can record the MAC address of the computer that�s connected to the port. And there are hubs out there that do that and we use them.
JB: And what about, do you monitor the network 100% of the time?
JS: Well, actually we don�t. The network security team seems to never sleep. In fact, it�s very interesting. It�s a virtual team inasmuch as it�s coordinated by a central trouble ticket database and extensive use of instant messaging, in our case, the MIT system Zephyr and e-mail. And so we tell people, they want the telephone number for network security and we say, well, no, there isn�t one. You really have to send e-mail to this mailing list which goes to the trouble ticket system because a lot of people who monitor network security are working from home. We have one guy in another country who�s sort of a friend of ours who�s part of the team and helps out so we have round the clock coverage. But we don�t do that. In fact, we also do no intrusive monitoring of the network. I�m not reading the e-mail when the Provost sends mail to the President. I�m not in a position to read that. I look for, like I said earlier with the routing table and the cache, for indicators of malbehavior but I�m actually not violating people�s privacy by spying on the network.
JB: Okay, good. Howard, how are we doing on our questions for Jeff today?
HS: Well, we have lots more questions. I think we have 32 more questions we could ask Jeff here just from our list. We�re obviously not going to get through them in the next 30 seconds, which is about what we have. But I�d like to get one last question in that wasn�t even on our list. That�s one of our problems, of course, is there�s so many interesting things to ask.
JB: That�s true.
HS: But Jeff, you were saying that people, just common users, have some responsibility towards security. I wondered how MIT or how anybody should make these people more security conscious. Do you train them, do you put up posters, what do you do?
JS: Well, we try to have awareness. We actually have seminars but
HS: Web security seminars?
JS: Yeah, we�re going to try to have one, I think, this January although I�m not 100% sure on that at this moment. But the other thing we do is word travels. You tell somebody their computer�s broken into and the only way they can get it reconnected it to erase its hard drive and reinstall, that�s a lot of pain!
HS: I figure they just change jobs at that point.
JS: Right. They just don�t want to do that. And by the way, if they lie to us, if they say, �Oh, yeah, I did all that and please turn my network drop on,� if their computer gets broken into within the next two or three days, then it takes them a lot longer for them to convince us to turn their network drop on for the second time.
JB: Trust you once but not twice, right?
JS: Yes. Trust but verify.
JB: All right.
HS: Oops, there is one�can we get this? Yes, I think we can get this one last question in, Judith. There�s one that just came in here.
JB: Okay.
JB: This is from Rick Danielson at ViaNet. And Rick you just came in just under the wire here. Rick says, �What is the price difference between a hub which can read MAC addresses and one that can�t?��
JS: Ah! That�s a good question. Unfortunately, I don�t have the answer off the top of my head.
HS: But is there a big difference in price?
JS: Well, the problem is if you don�t want any management capabilities, you can buy hubs out of the Black Box catalog at like $100 and you know, as soon as you start wanting serious management capabilities, that throws you into the thousand-plus category. So yes, it can easily be a huge cost difference if you try to include those commodity things, which we don�t like because they tend not to be very high quality anyhow.
HS: So you�re saying, yeah, you can get cheaper stuff but it�s not worth it.
JS: If you have a large network, the problems you can have if you don�t have control can more than outweigh the cost of equipment. I mean, in our case, we value our time and people time to deal with these problems is much more valuable to us than equipment. We�d rather spend the money on equipment and not have a problem.
HS: Okay, so this is a penny wise, pound foolish kind of thing.
JS: Yes
HS: Buy the good stuff.
JS: Yeah, but the good stuff.
HS: Okay, Rick, go out and spend the money.
JB: All right, good. Well, with that, Jeff, do you have any final comment before we wrap it up?
JS: Well, all I can say is again to implore people to keep themselves up to date and to make sure their fixes are installed and consider when they look at how they want to design a system what operating system they want to run and what server software they want to use. I�d say maybe security should be one of the things they think about before they rush off and make that decision.
JB: Okay, so we want to move security up higher on our priority list, it sounds, for all of us. Okay. Very good. Thank you all for being with us here today and be sure to continue to block off your Thursdays this fall, and particularly two weeks from today when we will have two guests discussing the state of digital video and hopefully how to use it in an ordinary, everyday sort of way. Our two guests will be Bob Dixon from Ohio State/OARNet and Jill Gemmill from the University of Alabama, Birmingham. Also, you will want to be sure to download and print the DO NOT DISTURB sign to enable you to focus on participating in the Tech Talks and tell your friends who missed the session that the Tech Talks will soon also be available in MP3 format. That was going to be up very soon. If it�s not up this week, it will be up very, very soon. Many thanks to the CREN member institutions and to Chrysalis ITS for their sponsorship of today�s session. Join over 160 other institutions in using Chrysalis ITS for your hardware-based PKI root key protection systems. A special thanks to our Tech Talk expert today, Jeff Schiller, coming from the rabbit barn at the Topsfield fair, and to technology anchor, Howard Strauss; to Terry Calhoun, Tech Talk web guru; to Jason Russell, Bonnie Boyles and the support team at Merit Network; to Susie Berneis, the audio file transcriber and finally, a thanks to all of you for being here. You were here because it�s time. Bye, Jeff. Bye, Howard. Everyone. We�ll see you in two weeks.
HS: Good night, Judith. Good night, Jeff.
JS: Bye-bye.
END OF WEBCAST
