TechTalks Transcript
Pandora's Box: Firewalls and Campus Security
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Clair Goldsmith [CG] |
 Randy Marchany [RM] |
May 3, 2001
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN Tech Talk series for spring of 2001 and to this session on "Pandora's Box: Firewalls and Security." 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 is coming to you today with the support of the CREN member institutions and World Wide Digital Security, Inc., the makers of SAINT tools for network security. Let me welcome Howard Strauss of Princeton as the technology anchor for Tech Talk and just would like to make a note that this is Howard's last Tech Talk of this season as he will be off to Australia.
HS: But I will be back next season!
JB: Yes.
HS: Well, that's good to hear!
JB: And while he is gone, we'll try and muddle along without him on the 17th when Bob Mahoney from MIT will be trying his hand at the tech anchoring. So we will miss you, Howard, but we'll try and get along without you.
HS: I'm sure you'll be fine! Thank you, Judith, though. I'm Howard Strauss, the technology anchor for the Tech Talk series of technology webcasts. Today we'll engage our guest experts, Randy Marchany and Clair Goldsmith, in a lively technical dialogue that will answer your questions about the emerging strategic technology of firewalls and campus security and we'll ask Clair and Randy those very important follow-up questions. You can ask your own questions by sending e-mail to expert@cren.net anytime during this live webcast. If we don't get to your questions during the webcast, we'll provide an answer in the webcast archive.
Once upon a time, in a land far, far away, there was a vast network of castles connected by broad bands of Darn Smooth Lanes, or DSL, that carried the agricultural commerce of the day. Unfortunately, the Darn Smooth Lanes also made it very easy for hosts of unsavory people to attempt to enter the castles' walls and rob, pillage and hack away at the castles' infrastructure and warehouses. Even when these hackers did little real damage, they tied up the Castle Protection Units or CPU's so that legitimate farmers were denied service when they brought the packets of foodstuffs that needed loading into the castles' storehouses.
Castles soon built moats with drawbridges to protect their portals. The moats also served as firewalls to the boiling oil that was sometimes flung at the castle. Since the drawbridges were always kept up for maximum protection, castles needed policies to decide who could pass through their gateways into the castle. For example, anyone delivering 40 large jars would be excluded, as would any large wooden horses, lest someone take advantage of the Horse Through the Portal, or HTTP trick. The problem with all this protection was that it severely restricted the free flow of goods and services.
To have really free commerce, there could be no defenses at all. And to have really good security, there could be no commerce at all. Since all oil was carried in large jars, for example, a policy not allowing groups of 40 of them to enter had the potential to create an energy shortage in the castle, and of course, anyone knowing the policy would just hide 41 thieves in 41 jars and get around the policy until it was revised to handle the new threat. The same walls and moats that kept people out also kept people in. If you wanted to leave, the drawbridge had to be lowered, which then also allowed people to sneak in. And once you left your castle, you had to hope that the castle you wanted to visit did not have a policy that would keep you out.
Furthermore, none of the castles' defenses protected against the bad people that lived within the castle walls and were trusted by the Castle Protection Units. If one of those bad but trusted people had the authority to lower the drawbridge, well, then you had such a severe breach of security that the entire castle was threatened.
On our campuses, we all have networked computer systems that carry the electronic commerce of our day. We'd like to have a free flow of information and services, but we are beset by the same problems and issues as the people in those castles in that land far, far away. We need firewalls and security policies. We need to know who to trust and how to hold people accountable. We need to assess threats and to react properly. If we overreact, we make our systems unusable. And if we underreact, we make our systems insecure and open to hackers, pillagers, Trojan horses and jars full of thieves.
While we need to look to the information technology experts on our campus for help, security is the responsibility of everyone in the castle. Everyone needs to know the rules, needs to protect their own parts of the castle, needs to avoid taking security risks and needs to keep educated about current and future threats. Perhaps the most difficult thing everyone needs to do is to report every breach of security they see, even when it is done by their friends or-worse yet-their managers. When we discuss firewalls and security today, remember that we are not just giving advice to the Castle Protection Units but to everyone in the castle. On today's webcast of Tech Talk, you'll see that when the castle is made secure, everyone will live happily ever after! Judith?
JB: Thank you, Howard. I'm just wondering, what role does the ivy play on the castle?
HS: We'll do that in the next webcast!
JB: Well, maybe our experts will have an answer to that. Let me introduce our experts for today. We have two experts on today. We have Randy Marchany of Virginia Tech and Clair Goldsmith from the University of Alabama at Birmingham. Randy is the senior member of the UNIX System Management Group at Virginia Tech and also Coordinator of VA CIRT, an instant response team from various VA-Virginia State Universities. Randy is co-author of a number of key security documents available from the Sands Institute and also available on our website event page today. These documents include the "Ten Top Internet Security Vulnerabilities," and "Computer Security Incident Handling Step-by-Step." And Randy is also working on a new Sands publication describing how to design Internet security audit programs. Welcome, Randy.
RM: Hello.
JB: And our second expert, Clair, is also very active in the higher ed community with a special focus on security and privacy policy, those things that we perhaps have to keep revising all the time. Clair is currently the Vice President for Information Technology and the Chief Information Officer at the University of Alabama at Birmingham. Many of you probably remember Clair from his many years at UT Austin, both in the academic computing area and also his time with the U Texas Health [inaudible] Center at San Antonio. Clair is also currently the co-chair of the Educause net@edu PKI working group. Welcome, Clair.
CG: Hello. It's good to hear all of you!
JB: Great for that introduction and we'll talk about CPU's.
HS: Castle Protection Units! That'll change the way you feel about CPU's. Clair, it sounds like you've been very involved in campus security plans. Maybe you can tell us, what does a campus security plan look like? What are the parts of it and what's the purpose of it?
CG: Well, the purpose, of course, is to provide a reasonable environment for people to use computer systems and essentially get their work done, whether that's the work of the student or the faculty member or the staff member. In fact, I like to say that the purpose of security is to permit doing a secure transaction over an untrusted network.
HS: Sounds like that's not possible.
CG: Well, I think it's possible. I think it's possible. I think you have to plan for it and be very careful about how you go about doing it because you want to protect, first of all, the servers and you need to protect them in such a way that they aren't being easily entered. And that's a full-time job! I'll further go on to say that though security really is a full-time job, I do believe that if you haven't checked your major vendors' security patch list today, you're vulnerable. You have to do it every day.
HS: But who puts together this plan, this security plan?
CG: I believe that security plans, as we're going into this era of computing, is actually going to have to be done by someone whose specialty is security - in other words, a security officer who reports reasonably high in at least the IT organization. I don't believe that that person necessarily has to have a large staff.
HS: If I'm a full time person, then I don't do anything but security?
CG: In effect, yes. Security and policy is one way of approaching it. Some places approach it that way. Others approach it more from a technical standpoint. But policy and security are so closely related that it's reasonable to have a security officer who is policy-knowledgeable.
HS: Yeah. Randy, you had said that Virginia Tech was talking about requiring people to have a network driver's license. Are you really going to do that, and if you are, what's that going to be?
RM: Well, it's not so much a requirement. One of the big things that we're trying to do is to develop enough of an awareness program for the general university community - and that's faculty, staff and students - which-�
HS: I saw that you put faculty first.
RM: Yeah. And what you find out is that people really don't want to be known as the idiot that left their systems open, that the hackers took over and then caused damage somewhere else. And they really are looking for some help in trying to balance the security vs. their needs. And so training programs, in my opinion, are one of the best ways to get this awareness out and they have to be at different levels. To sort of reinforce what Clair was saying, we have a security officer here.
HS: That's a full-time person, I mean, everybody knows the security officer?
RM: It's a full-time person that's known as the Information Systems Security Officer. He reports directly to our Vice President for Information Systems who reports directly to the President, so basically in our hierarchy, this Information Security Officer is four levels from the President. President, Vice-President-well, three. President, Vice President and then him. So he's pretty high up in the infrastructure. But he's coordinating a lot of awareness programs for general staff, administrative help. He's coordinating awareness programs for faculty. He coordinates technical security awareness programs for, like, sysadmins and PC and lab managers. And so a lot of what we're trying to do is to get that word out and the model that we're using is the one that's similar to the DMV, the Division of Motor Vehicles.
HS: And that's why you're calling it a driver's license?
RM: Right. In most states. Not everybody is a car mechanic. Not everybody is a car whiz, you know. I can do simple maintenance on my car but if something major breaks, I take the car to a specialist. But I know the rules of the road. I know that I drive on the right, I stop at stop signs, I stop at red lights, go on green lights. You know, those are basic rules everybody knows and everybody already knows that if you drive your car and you leave it in a bad neighborhood, you lock it! Unless you want to get rid of the car. So simple things like locking the car when you leave, making sure the window is up, which won't defeat a determined attacker, but they'll keep the crimes of opportunity type people out. And that's the concept that we're trying to approach with this network driver's license.
HS: Clair, you've been talking about some of these policies. I wonder if you could tell us how we go about creating reasonable policies and are there any places that we could look to that are exemplars for having created really good policies?
CG: Policies should - it's really interesting for, I think, the higher ed community because we have a number of issues with policies such as academic freedom and privacy. But we also have a campus culture. We have private institutions, we have public institutions. Public institutions are constrained in some sense by law and by how they have to approach things. So your institution didn't just develop its own set of rules yesterday. It's done it through a tradition that's become your institutional culture. And I think your IT policies, your acceptable use policies and so on have to reflect that culture because there are private institutions that have very specific values that they are going to want to incorporate into their policies. How you do that, in a sense, it lets you go back and you look at what your institution has already done.
Your institution has probably already said something about stealing. It's probably not acceptable to steal, either from the university or from other members of the community. Well, you don't do that using technology, either. If your institution has harassment policies, well, those same policies will apply regardless whether you're speaking words one on one or whether you're using electronic media. And so I think the most important thing to realize is that you already have a lot of this policy and you don't need to rewrite it. What you need to do is figure out how to make people aware of the potential for abuse in the electronic environment. As to good places to go look for it, you can-probably the biggest gold mine for policy is the Cornell website that has attempted to index all of the policy that's available on the Internet.
HS: Isn't there a group at Educause now doing a lot of that, too?
CG: It also, Educause has done some. There is a policy web page there. It will point back to Cornell as well, and then you can go look at specific institutions such as the University of Texas at Austin. If you look at their signature block on the very first page, it will have a pointer to their policies and theirs are interesting because theirs are rooted in their Regents' Rules and so, although it may say you can't do advertising, it will take you all the way back to the Regents' Rules that says you can't do advertising.
HS: You were sort of saying that we just have to build on what we have, but it seems to me there's lots of new stuff. I mean, there's passwords and there's just abandoning computers and Randy was saying you could do things from bad neighborhoods. There's got to be something, the equivalent of having your computer in-I think a bad neighborhood, is that anywhere outside your university?
RM: Not necessarily!
CG: Some universities have that problem.
RM: But see, I think that Clair has a valid point, though. Stealing is stealing and it doesn't matter how you're doing the stealing, whether it's a physical thing or through the Internet. And I'd like to really strongly agree with what he said in that you already have existing policies for staff abuse, staff misconduct. You have existing policies for faculty misconduct. You have existing policies for student misconduct and the acceptable use statement in the Internet world simply gives some examples of what these offenses would be in the cyber world. But as far as an enforcement mechanism or anything like that, you already have those mechanisms in place and so you don't need a large volume for an acceptable use policy.
HS: I guess I'm still convinced there's all kinds of new stuff here. For example, a student lending somebody their password. It seems like you don't have a policy.
CG: Well-�
HS: And a student might think it's reasonable. "Oh, yes, my friend needs some�"
CG: Well, we do!
HS: Well, I mean before computers were around, you didn't have a policy - or did you - about lending passwords?
CG: We had one about giving away keys.
RM: Yeah! You had one about sharing keys and usually the person who signed out the key was responsible for anything that had originated, so to speak, from that key. And any type of lab access, paper access. If I wrote a paper and I gave you a copy of the paper, well, you know, it was your responsibility not to pass it off as your own.
JB: So what about where are we right now as far as holding students' feet to the fire on this, you know? Are students complying with the rules about passwords and is that part of your license implementation, Randy, that you were talking about?
RM: Well, what you find out is you put it in the context of the students-make some sense to them. First off, you tell them, "If you don't do some basic things, it's possible that you'll lose your academic work and then you'll have to explain to your professor�""
HS: That the dog ate it.
RM: That the dog ate it, yeah. The cyber dog ate it.
HS: I thought that was it, you know.
JB: I thought you were going to the fact that you had to explain to your parents why you had to go home, you know.
RM: Well, you know, there have been cases, if the offenses are severe enough, yeah. That certainly can happen. If you decide to sent something to whitehouse.gov and the Secret Service come down to visit, you know, they have no sense of humor. And so-�
HS: That's some advice to people listening.
JB: There you go.
RM: Yeah, don't do it! Big people show up and if they even suspect there's a reason, they have no qualms about taking everything in the room. But you know, you frame it in that context and then you just say, "Look, this is just simply�" In our case, all of our computer abuse, so to speak, is run through our standard judicial review.
CG: Right.
RM: It goes to the Dean of Student Affairs, if it's a student. If it's a faculty, it goes to the supervisor or Employee Relations. I mean, I'm sorry, if it's staff. If it's faculty it goes to the Provost and the Department Head. And then it just simply enters the normal channels for judicial review.
CG: Let me comment on what Randy just said. I really agree with that because there is, particularly in private institutions, an issue of due process. And IT folks, like all others, are guilty of having biases about what you think is acceptable, sometimes in terms of content and other things. And that's not a decision that the IT group ought to have to deal with. All that the IT people ever should have to do is assemble the facts and run that through a judicial process that actually makes the decision as to whether or not it has overstepped the limits of that institution.
HS: Clair, on another topic, getting just a little bit away from policy but not too far away, if we're going to have all this security, it seems that that's going to limit academic freedom. At least people are going to say that.
CG: Oh, boy!
HS: Is it, and how do we deal with people who feel that way?
CG: Students don't feel that way, faculty feels that way! Those of us who have used-�
HS: Well, all these students who are using Napster, they don't - well, maybe that's not academic freedom. Maybe that's commercial freedom.
CG: Yeah, that's another tirade I'll go on, but the faculty really feels like when you begin to place restrictions of any kind, you are probably infringing on academic freedom and some of the institutions that have tried to implement the Sands Top Ten Threats have discovered that some things they do, in fact, does impinge on things faculty are trying to do.
HS: What kind of things rankle the faculty? I mean, are faculty upset about having to type in passwords? What upsets them?
CG: No, no, no. It's usually either something that appears to be in content or appears to restrict an ability to do something. For instance, one of the things in the top ten is NET BIOS activities which tend to shut down the streaming video activities and so you discover that one thing that you're trying to do in security is now hampering your research effort.
RM: Or distance learning.
CG: Or distance learning, yeah.
HS: How does this hurt distance learning? What are we doing to make distance learning hard?
JB: Yeah, and what is the particular threat from the NET BIOS that's causing them?
RM: Well, the particular threat from NET BIOS is basically global file sharing. When you share a file, Network Neighborhood takes on a whole different meaning. So that's the danger and the danger is that basically people don't realize that they have it, A, turned on and B, that it's set to read/write so there's a potential disclosure of information. What you would try to do, like Virginia Tech and Alabama Birmingham and every institution where we have remote campuses, and so in some cases, we're building online courses and to do that, you want to use some type of streaming video to show videotapes of the class or examples or whatever. And if you are too restrictive, you can prevent that type of traffic from entering or leaving your network.
JB: So these are restrictions in a config file that you would set up that would cause-�
RM: At the border usually, the firewall or a router or something like that, yeah.
JB: Okay.
HS: How do we deal with that? I mean, people do want to do distance education. [inaudible] streaming video and people want to do all this stuff.
RM: Yeah, the way we framed some of the stuff for the Top Ten-and we run into the same problems that Clair has run into-is we try to take an approach that said, "Look, if you don't do this, you have the potential of someone stealing your research. Do you want that to happen?" And the answer almost always is, "No, I don't want it to happen!" And then you just say, "Okay, if you don't want it to happen, do these simple things and this will take care of that to some extent." What we try and do is we try and frame it again, you can lose your data if you've got a research project that involves sensitive medical or health research, like in AIDS or defense contracts or something like that. You want to safeguard that data for the research agency you're doing the work for. If you don't, they're not going to want to come back to you.
JB: So they - go ahead, Howard.
HS: Okay. But again, you know, is what you're doing - are faculty coming around and saying, "Okay, I'll give up some of the things I want to do," or are they trying to get around you?
CG: Well, it depends. If it's sometimes you end up in a situation where you say, "Well, we can't do that on a commodity network where we're going to have to protect and what we'll have to do is raise the cost of what we're doing and we'll do a separate network."
RM: Right. Again, if you frame it in the context of a training program, you're not restricting it. If you act like you're the heavy, they're going to try and get around you. But if you act like you're trying to help them, you know, they'll try and cooperate. And when they run out of options, then they'll try and get around you! But at that point, at least you know who they are.
JB: What about those ten top security threats? Maybe you can talk about one or two that are easy to implement and then maybe talk again about a couple that aren't so easy. Are there two or three that are just really easy to implement, that it's easy to get people to-�
RM: Oh, yeah, I mean, there are a couple. One of the issues with the top ten has to do with - the very first one which had to do with the Bind, which is the name service for campus. In almost all of the situations with the top ten, the solution is to simply apply the vendor patches or update the code. So the solution is easy, that you have to do some testing obviously, because you may have some software that may break, but you've got to test it. But basically what you're talking about is applying the vendor patch. So an easy one would be the very first one that's listed in the top ten list with Bind. Every campus has a name server. It's not a heavily logged-into machine but it is a heavily used machine and so you can do that. Common Gateway Interface, the CGI programs, that's the second one in the top ten list. When you're designing your web applications, you just make sure that they're done in accordance with the established practices.
HS: But everybody knows these top ten. These are pretty widely published, right? And the fixes are pretty well known too.
RM: Right.
HS: Why haven't people just done this?
RM: Clair, you want to take a shot at that one?
CG: Yeah, I'll try.
JB: [inaudible]�
HS: If this was secret stuff that you couldn't discover and it hadn't been around, you could say, "Well, people aren't doing it because they don't know," but I mean, everybody must know this stuff. Don't they?
CG: No.
JB: And while Clair is answering that, let me remind our folks that now is a good time to ask more questions of our experts. And with that, Clair, what do you think?
CG: Because it's work and security things usually get fixed once there is a specific breach and the institution gets a sufficiently black eye because it's work. It's cost to do it and it's not glamorous. If you implement the Top Ten, nobody sees an improvement in the effectiveness of the network particularly. So it's hard sometimes for institutions to get the resources. I've asked on a couple of different lists of other R1 institutions and I was surprised at how few have implemented Sands Top Ten. It's much more prevalent in industry where they have a higher degree of control over and a higher degree of centralization, which is another aspect of higher ed.
RM: Right.
CG: Than we do. And so I say it's because it's messier in higher ed. It's harder to do.
HS: If we do these ten things, every now and again - in fact, with increasing frequency, there's virus attacks that hit universities and things come in from outside. If we did those ten things, would that stop that from happening?
CG: Nothing's going to stop anything from happening, but it'll certainly reduce the frequency of it happening and the frequency is spreading. One of the other reasons why it's not done is when there is an incident, you have that little timeframe when people want it fixed. And then it takes time to implement these changes and then you've got other needs. You've got somebody says, "Hey, I need this project done. Listen, can you work on this project? Just for a second." And the moment you get pulled away to work on that project, then you never come back to the actual fixing piece.
JB: Is there anything emerging that's really timely that's happened in the last six weeks or so that people might not know about, Randy, that should be fixed?
RM: Actually, now it still really is the top ten, just like Howard said. What has changed is a number of security scanners, freeware scanners are starting to adopt the Center for Internet Security's rulers and what the rulers are are basically line item actions that you could use to find out if your machine is vulnerable to a top ten. And in addition to that maybe it would try to correct some of that stuff. I know, for instance, SAINT or one of their sponsors here, their security scanner does check your system for the top ten vulnerabilities.
HS: If only you would install it and use it.
RM: That's right.
HS: It seems like these universities who aren't going to pay much attention to the top ten probably aren't going to have much interest in installing.
RM: Well, believe it or not, I think really some of the problem is they don't know the top ten exist. I think it's much more prevalent in the commercial world and this is - it's embarrassing to say, but this is probably one time when the commercial world is ahead of the academic world when it comes to their net awareness, but you will find a lot of institutions that don't know anything about it.
HS: Okay, Randy, one of the things - in fact the title of this session suggests is that our firewalls - are firewalls going to protect us in some way? Could you tell us what they are and the things they're going to protect us against?
RM: A firewall is nothing more than a filter. A firewall-�
HS: It's a filter that lives on the network.
RM: It's a filter that lives on the network and all Internet traffic, all Internet traffics are done through a mechanism called ports. You can think of ports as TV channels. And so what a firewall does is basically, a firewall can control the traffic in both directions-outside coming in and inside going out. And basically you give the firewall a list of ports that you want blocked. You don't want any traffic to go through. And so the idea behind that is that it reduces the number of chances that a hacker has to gain access to your machine by severely restricting the ports.
HS: So you leave just a few doors into your university, a few electronic doors.
RM: You leave a few electronic doors open. Now, the weakness in firewalls is the doors that you have to leave open because you have to make things easy for your users-you want people to use the net - and almost always you let through e-mail and you let through web.
HS: So you don't even look at e-mail.
RM: No, you don't. Not necessarily. And so now you have, I can't tell you how many organizations that had firewalls were hit by Melissa and the I Love You virus.
HS: Because they just traveled as attachments on e-mail?
RM: That's exactly right. There are tunneling tools now. You can go out on the net and find a tunneling tool that will let you route any protocol through the open ports of a firewall.
HS: What's that mean? Tell us in something closer to English.
RM: Yeah! Let's say that you block everything but e-mail.
HS: Okay.
RM: And nothing else is allowed into your academic network except e-mail. There is a tool called SMTP Tunnel which is basically a mail tunnel tool.
HS: So everybody listening's going to go out and get this.
RM: Yeah. Well, it's out there and it's been out there so you know, there's a tool there that basically would let you run Web Access which is on a completely different port through the mail port. It basically puts the web packets and embeds them as e-mail packets.
HS: So if you were one of these countries that was trying to restrict web access to all the bad things out there, folks could still sneak through as e-mail and look at whatever sites they want to.
RM: Sure. And now you know, you have to say, "Well, look, there has to be something on the inside that can decode what's being sent to it or receiving from it, but I send that to you as an e-mail attachment." So you know, as a protection device, I don't think-and this is my own personal opinions - I don't think firewalls are very effective. As a detection device, in other words, who came into my network or who left my network, yeah, they're extremely effective.
HS: But in addition to just leaving a few doors open, are they looking at every packet that comes by and deciding some packets are good packets and some are bad?
RM: No, no, no.
HS: They're not looking at IP addresses and saying, "These IP addresses are okay, those are bad"?
RM: Some could. Well, that's different from what you just asked me.
HS: I asked you two different questions, so they were different.
RM: Yeah. The first one, if you were talking about looking at the content of the packet-�
HS: That's what I meant. But you're saying no.
RM: No, they don't do that at all. They can't keep up with the traffic.
HS: Okay.
RM: In terms of blocking stuff from bad people, yes, they can do that and yes, they usually do do that. The problem is that the bad people aren't always necessarily the bad people. They may be unwitting accomplices and so what may happen is that I may have attacked a system at your site in Princeton and used that machine to come into my network here.
HS: Okay, and we're a trusted machine so you let us in.
RM: Right.
HS: And the bad guys have control of us. So you're just saying it's real difficult to keep the bad guys out because they're sneaky.
RM: Um-hum.
CG: And some days, you actually use a firewall to stop an attack. In other words, you won't permit traffic to go to an IP address that's internal.
JB: So you could even track - you could even cut off the e-mail port for a time if you wanted to.
CG: You could shut down all traffic to a certain IP address [inaudible].
HS: That would be like the Melissa attack. It's one way to - you'd shut everything down, try to clean the thing out from your system and not let anything new come in while it was happening.
RM: Right. There's six phases. You have what we call a preparation phase. What you do ahead of time, before an attack. You have the detection phase which is where firewalls can help you, which is you've detected an attack. Then the next phase is containment where you want to try and limit the scope of the attack to give you time to catch up. Again, a firewall is effective there. Then you have the eradication phase. Firewalls aren't going to help you there but they'll at least keep bad guys out, to give you time to eradicate it. Then you recover in terms of backup if you lose data because of a virus or some malicious attack. And then the last phase is a follow-up. This is what worked, this is what didn't. A firewall helped us in this area but it let the virus through, whatever. And it's a postmortem analysis of what you've got.
CG: Yeah, I have a couple of one-liners that I use with respect to firewalls. One is if a firewall, if I can't see it, I can't firewall it. In other words, you can firewall a network segment.
RM: Right.
CG: But firewalling a university, I think it's UVA that says that the effectiveness of a firewall is inversely proportional to the number of IP addresses behind it.
CG: So you can destroy it fairly quickly. That said, personal firewalls may make an awful lot of sense, particularly if you have DSL or cable modems at home.
HS: What's a personal firewall?
CG: It's a piece of software that runs in your desktop that in effect monitors the traffic coming to your machine to see what people are asking of your machine.
HS: Why wouldn't you do that centrally?
CG: Oh, but if you're at home!
HS: Okay, you're home. You're not talking, when you say desktop machine, I kept thinking on my desktop machine at work.
CG: I'm also thinking, and this is getting a little bit further down the road. We are actually looking at the possibility of doing site licenses of firewalls and deploying them, particularly in the medical environment, at the desktops because again, it's this problem of how do you know who is having access and with a couple of things going on now like wireless and people bringing laptops in, you really want the firewall at the desktop.
RM: Yeah, Howard, what we're talking about is you know how some cities are doing gated communities now and you have to check in with a guard at a gate to get into a neighborhood.
HS: Yeah.
RM: Well, a personal firewall is like putting in an alarm system at your home. So now you're relying on two things. You're relying on the guard that lets the person into the neighborhood and once that person's in the neighborhood, you still have a way to defend yourself if somebody manages to bypass that guard.
HS: If they come in on a bicycle so they don't have to go through the gate.
RM: Right. And so the desktop firewall concept, yes, we're moving in that direction, too. There are two examples, Black Ice Defender is one of the products and Zone Alarm is another one that's out there.
HS: How much do those things cost?
RM: We actually got a site license, I believe, for Zone Alarm and it's somewhere around 12 to 14 bucks a machine.
HS: Okay, that's not too bad for protecting your system.
RM: Right.
HS: But you're saying that firewalls don't protect you against everything. It seems like you're saying that you ought to have them but you ought to do a lot more than just a firewall. Is that sort of the sense?
RM: Absolutely.
CG: Sure, I think that the education thing that we've talked about, you asked early on about passwords and students and if you go around the country and you look at some campuses, kids trade passwords. They don't mean anything. Other campuses have a history of the password being associated with the identity of the individual and the person being held accountable for it and there's a very strong sense of what you do about passwords, so the key to this is going to be education.
HS: You both sort of mentioned wireless, and it's not only wireless but it's these little PDA's and all that kind of stuff. Does that make the whole problem a lot worse or is it really just the same problem?
CG: Actually, in some sense, I think, and one can argue - it's a tad worse. It's a manifestation of the same problem but we discovered that we had residents that were pointing their Palm Pilots at each other and exchanging information when the shift changes. And that's, of course, all unencrypted patient data.
JB: Ooh. Okay.
HS: So you're saying anybody could pick that up that was nearby.
CG: If they were around, you know, and that's probably not going to happen with infrared kind of stuff. But it sets a bad precedent for those people.
HS: Does that mean that universities really - I mean, everybody's going to wireless. I think there's no getting around the trend. Some folks will be a little later than others, but everybody's going to [inaudible]. Does that mean that we really should be encrypting all the data that we send across networks?
CG: I believe that we should be.
HS: You both agree with that?
RM: Oh, absolutely. In fact, I think it's easier to sell to the public if we go wireless because, everybody's watched a war movie where they know that, oh, golly, we can listen in on the enemy transmissions. And again, that model is in their heads, so forcing the encryption probably will be easier when we go to - it'll be an easier sell.
HS: Is SSL enough for encryption, or do we need something?
CG: For the time being, but I think you have to watch it and you have to stay on top of it and stay with SSL as it goes along and I think you can set your minimum standards.
RM: SSL is good if you're just using web traffic, but if you're using other stuff, no.
CG: See, I believe that if you're moving [inaudible] data across your institutional network, it should all be encrypted.
HS: And again, you're saying that it should be encrypted stronger than what SSL is going to do. Is that what you're saying? I mean, if we're all going to use SSL, that's that every web server should be a secure web server.
RM: That's right.
HS: That's right?
JB: Is that a trend right now? Is that starting to happen?
CG: Yeah, I think you find that a lot of universities are doing that-�
RM: Sure.
CG: Especially with online registration.
RM: Right.
CG: We use Banner from SUT so yes, I think that's definitely something that's in there because you want to help protect that data. Certainly, with any type of e-commerce things-�
RM: That's right.
CG: If you're doing anything, paying tuition online, that type of stuff.
HS: Yeah. Do we expect to see the secure web servers use something stronger than SSL or do we expect to see SSL get to be a stronger encryption algorithm? It sounds like that's not going to be strong enough too long. It's probably not strong enough for some things right now. Are we just going to use a different scheme on top of SSL or is SSL going to get stronger itself?
CG: I don't know, I'm not that technical. Honestly, all I can say, the precedent would seem to be that we'll continue to work on trying to strengthen the encryption and you'll replace SSL with something that's stronger.
RM: Yeah, I mean, the encryption algorithms will get stronger. You know, it's always attack/defense, attack/defense.
CG: That's right.
RM: But at some point in time, yeah, they'll be getting stronger. Wireless, I think, will force it because here's what-there was a small college in Clairmont, California, that recently went wireless in their dorms and I remembered a guy saying that they discovered that you could be two or three miles away and pick up a stray transmission. So I think in a sense, wireless is going to make it easier to force encryption of all traffic.
HS: One other trend that I see that I wonder how this is going to effect security is the movement toward web portals where people are going to be doing single sign-on, instead of people authenticating to each application, they're going to authenticate to the portal once. Is that another wrinkle that's going to take some special effort to deal with?
CG: Again, it's going to be on the education side because if you take that far enough, where you're really dealing with a digital credential, one can argue that it is in fact a stronger security mechanism because your password never even leaves your machine.
HS: You authenticate to some little device, gadget, chunk of software-�
CG: Exactly.
HS: --that has aggregated all your other passwords and things.
CG: And really your credential is somewhere in LDAP directory and all the applications authorize off of the LDAP directory, then your single sign-on never leaves your machine.
JB: Okay, I think there's a couple of folks that wrote in asking about, given all of our references to the top ten vulnerabilities, let me just share with everyone that if you click on the WWSI logo on the side of the event page, that will take you to a front page to the Sands Institute which, in fact, has - I'm sorry, it'll take you to www.dsi.com and from there it'll have the top ten on there. Also to take a look at the Sands Institute and there is just all of Randy's publications from there. Howard, we're getting really close to the end here. Did you want to mention the note that we got in from Brian Muller from Ohio State?
HS: Well, yeah. Brian Muller from Ohio State, he actually made a few notes about things that made his firewall technologies successful, but there's a lot of them.
JB: Yep, there's a whole bunch.
HS: Perhaps we could just publish this.
JB: That's what I was thinking, maybe put it on the website.
HS: Yeah, so thank you, Brian, for doing that. I think instead of reading them and having them disappear, we'll just publish them. Since we are getting close to the end, I wonder if Randy or Clair, whoever would like to, what's some of the interesting stuff that's being done by universities right now involving security? Are there some interesting projects going on? Clair?
CG: There is the Shibboleth Project, the middleware work that's going on and the Directory of Directories which could be used to both locate people within all the participants in higher ed, all the higher ed participants in the Directory of Directories, and could be used for some authorizations, interesting.
HS: Randy, anything that you'd like to bring up?
RM: Well, in addition to Shibboleth and that, we're seeing for now one of our big projects is we've purchased some frequency spectrums from the FCC and we're working on a fairly large project to introduce wireless Internet to the southwestern part of Virginia.
HS: Why did you have to purchase some frequency? I thought that everybody's using wireless just because the band's available.
RM: Well, the bands are available but we wanted to lock it down so that we could have a specific set, cover 16,000 square miles of the state.
HS: That's a little bit bigger than our campus.
RM: Yeah, a little bit. And so the attending things with encryption, security and things like that. The terrain out here is not really conducive to cable infrastructure so wireless is certainly one way to go. And that's one of the places where we're seeing a lot of activity. Also user education, classes, both professional development classes and academic classes in what we call hands-on security, not theory courses like cryptography or graph theory, anything like that, but practical engineering style courses.
HS: What should universities be doing right now to make their places more secure? Do you have any quick suggestions, Randy?
RM: First of, make sure you have an acceptable use policy and it doesn't have to be very large. Ours is one page long. The second thing is to start with the top ten list and see how much of the top ten you can apply at your campus. And as Clair has said, there's some instances where you're going to run into trouble, but for the most part, you'll close some other holes And I think that really is the thing to do, the easy one to do.
HS: Clair?
RM: Give somebody the job responsibility for security.
HS: So actually get that security person on your staff and make that person-�
CG: Whether it's full time or not. Your institution may not be large enough where you can afford to put somebody on it full time, but at least make it part of somebody's job responsibility so they're keeping up with it and you know what's going on in the contyr.
JB: And then so much of what we've been talking about today seems to user education. It's not necessarily an IT person who has to do it all.
CG: No, no.
RM: No. One thing to add to what Clair said is when it comes to actual incident response and if you have an incident, how do you respond to it?
JB: Yeah.
RM: We follow a model kind of based on the volunteer rescue squad. We don't have a full time CIRT team. We have people that do other things because, you know, money is limited. But once there's a call, we have management backing to drop whatever it is we're working on and respond to the incident.
JB: Okay.
RM: And then write up the reports and go back, so you can set it up as-and this is once you have an incident, you can set it up like a volunteer rescue squad.
CG: And that works for another reason, too. You don't always need the same sets of expertise on every incident.
RM: Absolutely.
CG: And a final word before we wind this up. Get to know your- END OF SIDE A�
CG: --President won't enforce them because the lawyers have never seen them.
RM: Right.
CG: Even though they're published.
RM: Right. Ours was reviewed by our legal staff, the University legal staff, before it was adopted.
JB: Okay. All right, great, Howard, do you have a final comment or question here?
HS: Sure. I can give you - would you like another final 30 questions here? I believe that some-�
JB: We only got to 34 today, right?
HS: Yeah, I believe that somebody broke into my system clock and changed it. I think we've only been talking for 20 minutes, but my clock is closer to an hour. I'll ask you how that can happen. But it does seem today, at least to me and to a lot of people I've talked to, that there's more security breaches today and that we're more vulnerable today than we've ever - it seems that way, but yet you'd think that we're more mature today. I mean, we have better systems, better procedures. People have done this for a longer time. How come we have all this experience and yet it seems to me that things have gotten worse?
CG: The experience is on both sides.
HS: Oh, you think the bad guys are going to better schools than we are?
CG: No, but if you take an open operating systems that has been out there and you've got more sets of eyeballs looking at it, looking for timing issues and trying to find those vulnerabilities. There are just more and more people doing it. And besides, those same people have automated hacking. I mean, you go pick up a route kit someplace and go just click and attack a machine and take control of it.
HS: If the longer we go, the better they get relative to us, what's the future look like?
CG: Well, I think some of the thing is I think we've become more aware that the attacks are there and that's why we see that it has been on the increase. I don't think it has really increased that much. I just think that-�
HS: We're doing better detection?
CG: We're doing better detection and more people are aware that, "Oh, my God, hey, I'm being probed!" Whereas before, it didn't matter and you know, I think if you took the same ratio of probes to legitimate traffic, the ratio is probably the same back 15 years ago as it is now. It's just that we notice it now. We notice that the emperor has no clothes and I think that's part of it.
HS: Okay, that's great.
JB: Okay, well, with all that, the top ten - I just got a note from Terry saying that the top ten link is almost at the top of the web page now so it's very visible and people will have an easy time of finding it and send you lots of questions, Randy and Clair.
JB: Okay. It is time to close out. I agree with Howard, this hour has gone so fast. I'd like to invite everyone to join us two weeks from today on May 17th for our closing session for the spring of 2001 when we will have a first look at the new Office Suite from Microsoft called Office XT and also discuss general issues surrounding upgrading and Office Suites on our campuses. Our two experts are Greg Scott and Tony Saxeman from the Oregon State University College of Business and we'll have Bob Mahoney, Howard, taking his shot at doing tech anchoring.
HS: I'll check for that when I get back!
JB: Okay, great. Many thanks to the CREN member institutions and World Wide Digital Security, Inc., for their support of CREN and these Tech Talks. They are the makers of SAINT tools for network security and which we can now know all the different kinds of reasons why it's good to have those. A special thanks to our Tech Talk experts, Clair Goldsmith and Randy Marchany; to technology anchor, Howard Strauss; to Terry Calhoun, Tech Talk web guru; to Jason Russell, Gayle Terkeurst and the support team at Merit Network; to Susie Berneis, audio file transcriber; and finally a thanks to all of you for being here and helping us scale those Castle Protection Units.
HS: Those Castle Protection Units.
JB: All right! You were here because it's time. Bye, Randy. Bye, Clair. Bye, Howard, see you all.
HS: Yep. That's great. Bye-bye.
JB: Bye-bye.
END OF WEBCAST
