TechTalks Transcript
Responding to Campus Security and Virus Incidents: Good Practices
January 24, 2002
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Kathleen Kimball [KK] |
JB: Welcome to the CREN Tech Talk series for spring of 2002 and to this session on Responding to Campus Security and Virus Incidents�Good Practices. 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 with the support of the CREN member institutions. I�d first like to welcome Howard Strauss of Princeton, our well-know web technology expert and portal expert and our technology anchor. Welcome, Howard.
HS: Thank you, Judith. I�m Howard Strauss, the technology anchor for the Tech Talk series of technology webcasts. Today we�ll engage our guest expert, Kathy Kimball, in a lively technical dialogue that will answer the campus security questions you�d like answered and will ask those very important follow-up questions. You can ask your own questions by sending e-mail to expert@cren.net anytime during this webcast. If we don�t get to your questions during the webcast, we�ll provide an answer in the webcast archive. In 1988, Cornell University graduate student Robert T. Morris released what has become known as the Morris Worm which brought down much of the Internet and demonstrated the growing network susceptibility to attack. In November of 1988, the CERT Coordination Center�originally called the Computer Emergency Response Team�was established to prevent and respond to such incidents. During 1989, CERT�s first full year of operation, 132 incidents were reported. The following year, the number had almost doubled to 252. Although a single incident might involve one site or thousands of sites, 252 incidents was still just a nuisance that could be dealt with. In the year 2000, almost 22,000 incidents were reported and in the following year, 2001, the number more than doubled to almost 53,000 incidents. Ten years ago, what was a minor menace has grown to be a deluge of very sophisticated attacks on every network-connected computer. From 1988 through 2001, there were a total of 100,369 incidents reported to CERT. Over half of them occurred alone just in 2001. There�s nothing new about attacks that use deception to take control of your resources. In the twelfth or thirteenth century BC during the Trojan War, the Greeks hid a large number of well-armed soldiers in a beautiful horse that they left for the Trojans as a gift from Athena. Many of the computer attacks that we see today are Trojan horse attacks. You get a very nice e-mail message from a close friend that claims to include a screen saver that they know you�d just love to have. Opening the attachment that contains the screen saver actually exposes your computer to a virus and makes your computer an instrument for the further spread of the virus. The attacks we see today are not just more numerous, but also much more sophisticated. We no longer get a Trojan horse with soldiers inside, we get a Trojan horse filled with hundred of adorable Trojan horses that we are tricked into distributing to our best friends. Inside those Trojan horses are yet more Trojan horses and so forth. Like Matriushka, the ornate Russian nesting dolls, current attacks use many layers of deception to guarantee that any attack will be very widespread and very difficult to trace. With near certainty, every network-connected device will be attacked and attacked repeatedly by many different sources with varying degrees of sophistication. Blink your eyes or lower your guard for a second and the hackers will control your computer. Extrapolating search data into the future, there will be 12 incidents reported to CERT during the hour of this webcast and every hour after that. One or more could be aimed at your campus. Obviously, it�s time for immediate action. Kathy Kimball will get you started on understanding how to deal with the hostile world out there on today�s webcast of Tech Talk. Judith?
JB: Thank you, Howard, and it sounds as if what used to be just an occasional event now becomes something that requires our constant vigilance, which is probably why Kathy came to Penn State. Let me introduce Kathy. She is the Director of Penn State�s Computer and Network Security Office and has been at Penn State since 1993. Her duties include development and implementation of university-wide computer and network security policies, analysis of the security aspects of new and evolving technologies, and security incident response and security education and training for the university community. We�d like to welcome you to Tech Talks, Kathy, and gosh, it sounds like was this a new position that you came to at Penn State?
KK: Well, yes, it was. I was the first ever overall Director of Computer and Network Security. We had an administrative security officer but my position was university-wide in scope.
HS: When did that start, Kathy?
KK: Well, I was hired in�actually came to work April first, 1993 which is
JB: A joke in itself, right?
KK: Yeah.
HS: Because I hadn�t realized that CERT had just been around since 1988 so it�s a relatively recent kind of thing. And I was just amazed when I saw that there were 53,000 incidents last year. That�s much more than I would have thought.
KK: Actually, it was probably more than that. A lot of us who have instant response teams, we advise CERT of the major incidents or the overall statistics, but I would expect there are many more actual incidents.
HS: So you�re saying even those��
KK: That�s low.
HS: --incredibly large numbers are low.
KK: That�s low.
HS: That�s incredible! What kind of threats are people really concerned about?
KK: Well, we�re concerned about a number of things. First, as security people, we tend to be worriers anyway, but basically, the things that I am most concerned about are things that are self-replicating or easily-downloaded attack scripts from the Internet, things that would facilitate distributed attacks where you can leverage the power of multiple computing systems and things that can be destructive to either people�s systems or overall infrastructure.
HS: A lot of the things that we hear about seem more annoying than destructive. Is that really true, or are there a lot of really destructive things out there?
KK: Well, there are destructive things out there and also you can leverage�if you have control, remote control Trojan and I decide to do something that maybe you would consider annoying, like set up a ware site, if I run out of room, I may delete user files. So anything can be leveraged to be destructive.
HS: When we think about securing things, what assets are we really trying to protect? What things are we really concerned about?
KK: Well, probably the things that most people don�t think about, the thing that people think about, obviously, is data. But I think all of us who work in this field who�ve heard before, �But I�m not concerned if somebody gets my data!��when you attack a university system, a lot of times people are going after the capacity of your machine and the speed of your network. And it really has very little to do with data.
HS: But what are they doing with that? You�re saying the capacity of your machine and the speed of your network. Computers are cheap.
KK: Right, but basically they want to take over banks of computers to do, say, distributed attacks or else they�re part of a copyright software pirating ring.
HS: Could you say
KK: Basically people can take it over for any number of reasons.
HS: Could you say a little bit more about distributed attacks, tell us what these are?
KK: Sure. Well, the classic that we started seeing a couple years ago now, I guess, would be something where you are the bad guy, you do a scan of, say, Penn State and several other universities and find several non-secure systems�gosh, imagine that! And then you implant things like masters and slaves that can be directed, then, to do a flooding attack somewhere else or do some other kind of attack. So it�s leveraging the power of multiple computers to engage in whatever kind of attack you want to engage in.
JB: Kathy, from your comment, it sounds as if you almost kind of chuckle at the irony of the fact that there would be insecure systems. Is it true? I mean, are there lots and lots of insecure systems on most campuses?
KK: Oh, yes.
JB: Okay.
KK: There are a lot of reasons for that and it�s not isolated to universities. Particularly people with cable modems have the same kind of problem we do, and that�s inexperienced users who are responsible for implementing relatively complex security on their desktops who don�t either have the knowledge to do or the time to do it, and oh, by the way, we�re attached to the high speed networks that they guys want to get access to. So we�re frequently targeted.
HS: What do you mean by an insecure system? How would somebody know they have an insecure system, or what would one look like?
KK: Well, basically, any vendor�s system right out of the box. I can�t say any vendor, but most of them out of the box require you to actually configure something in order for the machine to be actually secure as it sits. They don�t come from the vendor secure. You have to do something with them. And even if you knew what you were doing, you have to keep up with the patches and the hot fixes from the vendors.
HS: And you�re not talking about just operating systems. You�re talking about any software?
KK: Operating systems and applications, both. So the user has to be pretty savvy in order to maintain a secure environment unless they have defense in depth where you�ve implemented multiple layers of security to include intrusion detection, firewalls and all the other things that you read about.
HS: So you�re saying that even an application as common as Microsoft Word could�has features in it that would make the thing more secure?
KK: Well, Microsoft Word allows macro programming. There are certain things you could do, I suppose, to check it, but you have to watch out. If there�s a vulnerability in the way a particular application was coded, say an Instant Messenger application or something like that, then obviously, it can be leveraged to either take control of a particular part of the system or, worse yet, administrative control of the system. Buffer overflows are a biggie.
HS: When we�re talking about threats, are we talking about internal threats and external threats? What are the differences between those two?
KK: Both. Well, internal would be kind of, say, students or faculty, staff, themselves initiating a hostile attack. External tends to be what we see a lot more of now than we used to, which is someone in the greater Internet running an automated probe, looking for vulnerable systems in our whole address base and then taking them over and doing something with them. Insider threat could also be more directed towards data. It would be much more likely that we�d have an insider threat trying to change grades than somebody in Singapore trying to do it.
HS: And I mean, these internal threats are necessarily inside the firewall, aren�t they?
KK: Well, yeah, they would be on our side of any firewall implementation we might have.
HS: The firewall keeps these bad people in.
KK: I know! One of the things that, when you�re talking about insider/outsider, it�s also very difficulty to categorize that because a lot of times, we will have a machine that appears to be a Penn State machine attacking somewhere that�s actually been taken over itself. So it�s not really us-us doing it, it�s somewhere out there in Internet-land using one of our systems and it�s identified by our IP address, so it looks like it�s Penn State.
HS: Okay, we had a question come in a little bit earlier from Carol Huff at University of Maryland.
KK: Okay.
HS: And she says, �Kathy, I work at a university that is comprised of many schools that are, for the most part, autonomous. It�s recognized that security is vital to our campus but because of the autonomy, developing a cohesive plan is a challenge. Do you have any suggestions for how to develop a good campus security strategy given this circumstance? And do you have any examples of somebody that�s been able to do this?��
JB: Actually, it sounds not unlike Penn State, Kathy.
KK: I think a lot of particularly large universities are that way. I�ve heard us described as almost feudal fiefdoms where we have independently ruled baronies that marginally accept the power of the king, but really, central control is very difficult to manage. What I would do in that kind of situation is kind of what happened, really, before I got to Penn State and that�s to get committees together to determine how you want to run central coordination because there are some things that should be done centrally, or at least coordinated centrally to include incident response.
JB: So you had mentioned when we were talking earlier, I think, Kathy, about the fact that there�s more than central and non-central, that there�s probably three or four levels of security that a campus generally�that you want to plan for. Do you want to describe those levels?
KK: Well, right, any security weenie will tell you that you want defense in depth. And that means you start from the desktop itself out to the perimeter of that LAN, out to the integrated backbone level, and you employ the security technologies that you are capable and can afford to do, to include intrusion detection systems where applicable, to include firewalls where applicable, to include encryption of communications where applicable. You need an overall strategy, of, okay, suppose you were in the military. You wouldn�t just arm your brigade with tanks. You�re also going to have to have foot soldiers and you�re probably going to have to have air support. And designing, you know, a secure environment for computer systems is roughly the same. You need different kinds of protections.
HS: Can we talk about some of the kinds of protection, especially some of the central stuff? I mean, do we have stuff out there looking at what�s coming in and deciding whether it should get in or not?
KK: It depends on your individual campus. Some do and some don�t. Firewalls are a little bit more difficult to implement in a university environment, particularly at the front gate because we do so many weird things, you�d be poking holes through them all the time. But you can certainly distribute them. We�re looking now at distributing more or less very high speed intrusion detection that would try to match the signature of an attack pattern and then either render an automated response or notify us. So there are a number of things you can do centrally as well as when you get down to the departmental LAN level.
HS: I hear that there�s stuff that will stop certain kinds of e-mail from coming in.
KK: Sure. Filtering systems. If you have your mail architecture sufficiently compact enough that you can filter, say, virus attachments, that�s great. You�d want to do that at the server level. Our particular central mail system is not designed for that because we�re doing two and a half million messages a day. So putting filtering in there would really inhibit a lot of things. So the filters that we have of that nature tend to be down at departmental mail server levels.
HS: But these filters, just to understand this a little bit better, these filters actually prevent certain kinds of messages from coming in at all? So somebody tries to send me e-mail and I don�t get it, right? It just never gets to me because the filter is
KK: You can set things up that way.
HS: What?
KK: You can set things up that way.
JB: You sound like you might not want to do that, though.
HS: No, I just think it�s an interesting question. I mean, I think that there�s a bunch of things that have the phrase, say, �make money from home� that I would be just as happy to never see.
KK: Those are SPAM filters. You can block that.
HS: But I just wonder if, you know, how you do that without having somebody fuss about the fact that that�s, hey, the mail was sent to me, I want to get it, why should you be stopping it? How do you��
KK: Well, we don�t run into that quite as much because our central mail server does not do that level of filtering. But the things that you would be filtering are things that are very well-known.
HS: So you look for some kind of virus signature or something like that?
KK: Right. It�s the same as an anti-virus software package would look for, only it�s server-based. You�d probably want ideally to have both server-based and desktop-based viral protection.
HS: The desktop-based viral protection, at Penn State, do you put that on every desktop?
KK: Well, we�d like to! Again, you�re sort of in the fiefdom area. We rely a lot on distribution. We do now have an overall site license for anti-viral products and we would definitely want people to install them and keep them up to date. It�s also difficult to do in the residence halls because remember, we have residential computing and we have to get to each and every one of those students in some way, shape or form. We try to��
HS: But if you have a site license, can�t they just download the product from the network?
KK: Yes, they can. It�s a matter of getting them to do it!
JB: So do you feel as if, what kind of penetration level do you have with virus software on the desktop, even though it�s available?
KK: It�s getting better and better because there are so many of those going around now.
JB: People are more responsive?
KK: I�d like to see something, if we�re talking about desktop, in the personal firewall space and that tends to shut out traffic that you don�t want let into your system. So if I don�t want people Telnetting into my desktop, I block Telnet.
HS: Once you get the stuff out there and it sounds like it�s a little bit of trouble to get it everywhere, but then they have to get the updates.
KK: Yes, that�s critical.
HS: I mean, the virus software, that�s not going to do any good because there�s always new viruses and this protects against the old viruses.
KK: Right, in fact, we find that a lot from new students who are very na�ve about this. You�ll ask them, �Do you have anti-viral software?� and they�ll say, �Sure, it came with my computer.��
HS: Right, back in �88.
KK: �When did you buy your computer?� �Two years ago.� And that�s not an effective update strategy.
JB: What about, you said there�s a site license. In fact, we got a number of questions that came in from Ed Goray at the University of Illinois Champaign/Urbana and one of his many questions was, �Who should pay for virus software?� How was that handled?
KK: That, again, okay, I can only give you my personal opinion on that, but I think that should be a central expenditure of some sort and not left just to the units. In that way, you can have a more uniform strategy. And at least our experience, it needs to be free. Even asking the students to spend ten dollars, they have other uses for ten dollars.
JB: Right, that pizza. Right?
HS: Yeah. Or if you can get a pizza for ten bucks any more��
JB: Well, that�s true. But anyway, so basically, what about what you�ve seen at other universities? Is that generally the way that they�re going?
KK: I think most people now are definitely going into site licensing and tending for it to be in some way, shape or form centrally funded, either through the IT organization or some other central mechanism.
HS: If we look at the cost, you just mentioned one of them, just getting a site license for virus software. But if we look at the other costs involved in putting together a good security plan for a university, what other costs are there? Where do we have to spend money to make the campus network secure?
KK: If we want them more secure than just every desktop naked on the Internet, then you�re looking at coming up with an integrated security strategy and you�re going to have to spend money on hardware and software. So it�s not cheap, but considering the possible lost opportunity, lost staff time trying to clean up these things, preventative measures are actually a bargain. It�s a matter of convincing management of that.
HS: You think of your group as one of the preventative measures at Penn State?
KK: Yeah. Well, right now, we have a number of roles and I think I left our org chart at the website. We do policy, we do training, we scan for different vulnerabilities and we also do incident response. And a lot of our time is spend in reactive mode until we can actually get deployed some of these more effective, proactive measures.
HS: How many incidents are you seeing?
KK: Over the last two years, it�s about 4,000 each year.
JB: And does that include, then, incidents at a personal desktop level?
KK: It certainly does!
HS: Okay, but when you say �incident,� that might be something that came in and attacked 2,000 machines. That�s one incident.
KK: Right. That�s one incident.
JB: Okay.
KK: Now, that�s one of the problems that we�ve traditionally had in the university security community is that we all count incidents differently. So if you took my 4,000 and matched them against somebody else, they might not equate because I count things that other people would not count because I count nuisance incidents, too. SPAMs and chain letters, all of those. And not everybody does count those so it�s very difficult to get a frequency measure for how often is this happening because we don�t have a standard way of measuring.
HS: When you find that a machine has been attacked, especially when it�s been attacked successfully�so one of your servers gets attacked. What do you do?
KK: Yes.
HS: In fact, how do you know?
JB: That�s a really good question, too.
HS: Before what you do.
KK: Well, if you have an intrusion detection system, you might know that way. If you don�t, we find out a couple of different ways. Either the machine is behaving in some way, shape or form strangely and the system administrator calls us or else we�re notified from outside, you know, �Why is this Penn State machine attacking government laboratory X?� And so I�ll call the system administrator and they�re usually shocked to get that call.
HS: That�s because, right, why their machine? Their machine is pristine!
KK: Right. And then we�ll usually dispatch�depending on whether we know the unit or not and know the system administrator, we�ll usually dispatch somebody to help them look over that system. Now, if it�s an ongoing attack, we may filter it at the router so it can�t get in and out on the Internet until we get there and then we�ll take a look at it. It does take a trained analyst to do that anymore because of the sophistication of attacks. A lot of time the code is hidden in areas that the average system administrator or average user would not even think to look.
HS: So you actually go out, look at the machine, really look at all the files
KK: Yes.
HS: �and things. Who do you get advice from? I mean, this attack comes in. Probably somebody else has seen it somewhere else in the world. I assume you talk to somebody.
KK: Well, generally, we get hit by attacks that are fairly well known. I think that�s true of all universities, that a lot of times we�re hit by this what they call a script kiddy attacks, so it�s a fairly common signature.
HS: What kind of attack?
KK: Script kiddies.
HS: What�s that?
KK: That�s someone who�s not very knowledgeable about computers but goes and downloads the hacking tools from some website and runs them. And unfortunately, those are still very successful. But you know, once you�re notified of it, it�s fairly easy then to go in and check. We also have membership in FIRST, the Forum of Instant Response and Security Teams. They have mailing lists that talk in some detail�they�re encrypted and talk in some detail about vulnerabilities and things so we learn some that way. From other university security officers, those who do have a central capacity, we learn from them, �Hey, what are you seeing? Are you seeing this?� And every once in a while, we�ll uncover something that will have a piece of code, like we did when the first distributed denial of service attacks started happening. We had a piece of that puzzle and we could, you know, kind of take a look at what the code was doing and we knew it was part of a larger something. And that�s when you go to something like the FIRST list and say, �We have this thing. Has anybody seen anything similar?��
HS: So usually when you go to one of these machines, you know what you�re looking at. It�s something you know something about already.
KK: Generally, but not always. Occasionally, we�ll get something new and different. It helps to have a professional, more or less, incident response team look at it also because it�s very easy for a system administrator or a user to, while we�re examining things, step all over evidence. So in the rare instance where we might be able to prosecute, they may have made the evidence invalid and we�re not as likely to do that.
HS: Like wiping out the fingerprints and things like this.
KK: Right, or just changing, you know, file times. What we would do first if we thought there was going to be some possibility of prosecution is to make a mirror image copy of the whole drive. And we would then isolate the original drive so it couldn�t be changed and we could testify in court that this was how it was.
JB: Once you have��
HS: Have you ever done that?
KK: Yes. We do it, I wouldn�t say quite often, but we do it frequently.
HS: Once you do this, you�ve secured the machine, you�ve figured out what�s wrong, do you then wipe out the disk, rebuild the thing from ground zero, or��
KK: Again, it depends. I would say that most of our machines that have been attacked, that are attacked by a daisy chain of other machines where hackers hack something somewhere else and then subsequently hacked another and, gosh, they�re coming in to us through Germany or whatever, the most expeditious route is to, you know, take a look at what happened, take it offline, rebuild it from scratch, be sure it�s secure and get it back and operating again.
HS: You rebuild it because, of course, everybody in your campus backs their machines up frequently.
KK: Oh, of course!
HS: It seems like that�s�I mean, it seems like that�s part or should be part of a security plan to make sure that people have their machines back up because once they�re attacked like this, you�re going to have to throw a lot of stuff away.
KK: Right. You have to be a little bit careful. You don�t want to restore system files directly from backup because if you�ve been had at the root or administrative level, you can�t trust those anymore because you probably backed up the back doors.
HS: [inaudible]�
KK: So you tend to want to rebuild from kind of virgin media and then bring back the data.
JB: Um-hum. We have a�if we can go back to the question about the virus software and who pays for it, etc., etc., another question that Ed had asked and he�s not from Urbana-Champaign, by the way. He�s University of Illinois Chicago. But he was asking, �What about, in addition to Windows and Mac and other kind of virus software, what about�is there virus software now available for the Pocket PC, Palm OS, etc., etc., and other flavors of Unix that are site licensed as well?� Or are some of those--
KK: Well, we don�t have site licenses really for that, but Palm OS is only now starting to see true viruses for it. There is antiviral software out there. It may be something that increases over time. Unix, you can write a virus for it. There isn�t that much that�s out there in the wild so I don�t lose sleep over Unix viruses.
JB: Okay.
HS: Okay, another question about this kind of thing is what about machines that are off campus? Are we concerned about those? I mean, people have machines at home and personal machines and��
KK: If it has a Penn State IP address, by definition I�m worried about it.
JB: So people coming in via proxy servers, etc. would��
KK: If the end IP is not a Penn State IP, then I really don�t have jurisdiction, but if the end point where you�re originating from is a Penn State IP, then I�m worried about it.
JB: Okay.
KK: And it doesn�t matter, you know, exactly how you�re connecting.
HS: So you consider those machines as part of the Penn State network and things?
KK: As long as they have one of our addresses, yes. If there off in, you know, at home or something, then no, not really that concerned about it. That would go to the Abuse and Security contacts for at home.
HS: I don�t understand. There�s another group that handles this, or are you saying��
KK: No, I would handle anything where they�re actually using a Penn State IP address and we�re their service provider.
HS: Okay, so you�re saying�sure. If it�s a home machine and they�re using AOL, that�s not your problem, obviously.
KK: Right. That goes to AOL Abuse and Security.
HS: Yeah, okay. What about the role of wireless in this whole security thing? Does that make things worse or create any additional problems?
KK: Well, I think, you know, the initial implementations in wireless, we kind of made the same mistakes. If you don�t learn from history, you�re doomed to repeat it and we did a little bit of the same mistakes that we did early on with wired networks. Poor authentication mechanisms, poor encryption. Things are looking up, but the state of wireless security hasn�t been great to date. And it�s very easy for, you know, the average user to set up a non-secure wireless network that you can war-drive around and watch packets.
JB: What about�I think we�ve kind of been talking around the whole question about security training. Just how is a problem like this addressed, since it sounds as if the need for this is just growing astronomically, given the number of attacks and the vulnerability of our systems? How do the employees, the students at Penn State get security training?
KK: Well, there�s not enough of it, I�ll admit that up front.
JB: Okay!
KK: But for system administrators, we have a number of different paths that we follow. I will arrange to bring in things from commercial providers that will provide hands-on training for system administrators, focused on security, and those are maybe four or five day classes. I have a lady that I hired in my office in the past year who�s developing a course on Your Desktop PC�How Do You Secure It? From the Ground Up. And we�ll offer that. We offer, through the Center for Academic Computing and Center for Educational Technology Services training classes geared to system administration because that�s really kind of what you�re talking about, and it�s one of the bigger problems. At a university, you have a wide range of system administration expertise, all the way from probably people I would say are some of the best in the world down to a graduate student gets hauled in by a professor who got a grant and the professor says, �Tag! You�re it! Administer my systems.� And they�re definitely not knowledgeable enough to do it, at least not at first.
JB: Okay, sounds good. Let me take the opportunity right now to remind folks out there that it�s a good time to send in questions to Kathy at expert@cren.net.
HS: Let�s say that you have some kind of a university security policy. What�s it look like? What kind of things are in it?
KK: Well, I can only really speak for ours, but ours tends to�at the university level, it�s reasonably top level. It divides out kind of the expectations and the �thou shalt nots� for me, for deans and administrative officers, for system administrators and then just for general users.
HS: And for general users, I mean, do you tell students things like you�re not allowed to share your passwords or other things? What kind of things are in the policy?
KK: Things like that. Thou shalt not share passwords, thou shalt not try to crack passwords. There are a number of things like that. Thou shalt not violate copyright. Kind of the things that you would logically expect. It also says, since early on we got a claim that, �But I�m not violating Penn State policy by attacking Canada!� and I�m going, �Yes, you are!� So no matter what machine you�re connecting to, if you�re connecting from us, you�re bound by our policy.
HS: And how do you enforce that? I mean, you tell students, �Can�t share passwords.� And students, of course, do that all the time.
KK: Well, if we find out about it, then normally a shared password, unless some dire event occurred because of it, would probably be a warning. For more serious categories of incidents, we work with our Office of Judicial Affairs that�s under Student Affairs and they handle it from there because we�re technology experts. We don�t want to get into adjudicating human behavior. We have offices that are way more skilled at doing that.
HS: Okay, so you�ll just work with those offices. I mean, if somebody comes up to you and says, �Somebody got some nasty e-mail and they think it came from this person,� you�ll go off and try to make sure that it really did come from that person?
KK: Right. Any e-mail related offense, we would need what�s known as the header data, which is the lines of garbage that show above the FROM and TO line, but tell you the real IP address that it originated from. That gets us to the machine it came from and��
HS: Right, and that�s it, too.
KK: Then if the administrator for that machine has adequate authentication and logging, he should be able to get us to the user ID that initiated that and then it�s a matter of discussing with the user, you know, and trying to determine whether they in fact did it or they accidentally had their password compromised, but at least we have somebody to talk to.
HS: Yeah, or they just walked away from their machine.
KK: Right.
HS: Which is, I mean, I see that a great deal. Student will just abandon a machine they�ve authenticated to.
KK: Right. HS; Do you, in your public machines, your public labs�when I say public, I mean machines your students have access to�do you do timeouts and things like that to protect against abandoned machines?
KK: We do. They�re reasonably generous, though, so we haven�t totally eliminated that problem and I don�t know that you ever could. But there are some other ways you can do things, too. Some of the labs are in more or less residential areas and the kids that use them are fairly well known to each other so if something dire happens at a particular work station, we can contact the people who were logged in right around that workstation to say, �Did you see who was on last night?��
HS: And you�ll do things like that?
KK: We have done things like that before, yes.
HS: But you don�t have security cameras and things like that around?
KK: In some labs, we do.
JB: Another question that had come in had to with the whole new trends for roaming and mobile computing applications. Any special hints or ways to kind of �bulletproof� authentication to some of these mobile applications?
KK: Well, if you�re bringing in a laptop to, say, our public labs, we will force you to go through essentially a firewall device and you can�t do anything but get your Internet address and authenticate. And then, you know, the world is open to you.
JB: Okay.
KK: Because the basic line in policy is that we want everyone to be able to trace to the user ID responsible in the event of an incident and that includes even if they�re computing using a laptop. So if it�s an open port, it�s not truly open if we can help it. It�s going to go back through this device mechanism that will only allow you to get an IP address and authenticate before it opens the world up to you.
JB: So that works even in�do you have any wireless networks where you�ve got this implemented?
KK: Well, wireless in terms of centrally supported solutions is fairly new and we�re going to do that more through a VPN mechanism and authenticating that way, at least in terms of the centrally supported solutions. Now, I know there�s a lot of wireless out there where people really didn�t think about the ramifications and just put it in there and that�s going to be one where we�re going to have to work with the units and try to get a more secure environment as we go along.
JB: Um-hum.
HS: Kathy, people always like to download things to their computers. I mean, there�s all kinds of neat stuff out there, games and screen savers and all that kind of stuff. How do you get people to stop doing that? At least to stop doing the dangerous ones.
KK: That�s a toughie because how do you know what�s dangerous and what isn�t?
HS: Right. So I mean, we go around telling folks, you know, �Be careful with attachments! Even attachments from friends.� And then they say, �Okay, I�ll be real careful with attachments� and then they see some little window pop up that says �Get your new screen saver! Go over here!� And they say
KK: And they�ll do it anyway!
HS: �Oh, that looks great! That�s not e-mail!��
KK: That�s just where you have to continually try to educate users and combine that with an effective antiviral strategy. Though not all of those are viruses that you could theoretically get. But it�s a tough problem.
HS: When there is an attack, do you attempt to alert the general population, and how do you do that? Do you send e-mail out to the world?
KK: It depends on the level of attack. I�m not going to alert for every incident we have, not at 4,000 a year, but if we get something like Melissa or I Love You or something that�or Code Red, first generation of�that has some possibility of having widespread university penetration, then we will issue alerts. Those can either be issued through the Center for Academic Computing web pages, it can be disseminated through a number of mailing lists that we have for network contacts. It can also be put�we have before put alert messages on the Penn State home web page.
HS: Yeah, but I mean, people look at the homepage now and again.
KK: Right. The best way that I have to reach people is through a mailing list that goes to all of our network contacts. To get a subnet on the backbone here, you have to have an administrative, technical and security contact so that�s probably�that group of people for each of our subnets is where the first alerts will go to.
HS: When you get one of these things that does affect a bunch of machines and it�s the kind of thing that�s then going to go out and try to infect other machines, when you detect that, do you take those machines off the network?
KK: Again, it depends on which particular kind of attack it is. If it�s a self-replicating thing, say a Code Red, yeah, I�ll filter it.
JB: You know, that brings up a whole raft of questions that, you know, have come in having to do with just what happens if a machine is so infected and the people responsible for the machine won�t fix it. I mean, who fixes it and how long might such a computer be off or disconnected from the network?
KK: If it�s presenting a real risk to the rest of the university and to the outside world, we will filter it off and we will filter it off until it�s fixed. The network contacts are ultimately responsible for trying to insure that the system administrators actually do take action and we do have our instant response mechanisms, so it could be somebody from my office going out to try to help the person. We won�t actually do all the system administration work necessary to bring it back up but we will tell you what you need to do and then when the network contact says it�s okay to come back online again or the system administrator we�re dealing with says it�s okay, we�ll bring it back up. We would also combine that, though, in some of the more extreme cases with a scan from our office to be sure that at least to a standard commercial security scanner, this box looks pretty good.
JB: Okay. So in other words, though, the person that is�say it�s a tenured faculty machine, but still the person responsible for making certain it�s clean is that network contact or that system admin person.
KK: Well, ultimately, it�s the user. The user is responsible, but the system administrator or network administrator for that area is going to have to help the user out if they�re not capable of doing it.
JB: Okay.
HS: But suppose that�I mean, when I go on vacation or whatever I�m doing, my machine�s always live. I just kind of leave it here live and so you�re saying if my machine gets infected with some kind of virus, you�ll cut me off the network?
KK: Yep!
HS: But I�no, that�s completely reasonable.
KK: How rude of me!
JB: That sounds really reasonable, doesn�t it?
KK: You don�t have��
HS: It�s completely reasonable. I mean, attempts to contact me will be useless because I�ll be off in Fiji somewhere.
KK: Right!
HS: But you�ll just keep me off until I come back and I�I mean, how��
KK: Until it can be cleaned up. Now, if you have a system administrator who actually has root privileges on that machine, we probably will go take a look at it. We reserve the right to do that, even if you were on vacation.
HS: And how will you verify that the machine is safe? You know, you call me up and say, �You�re infected with this deadly virus. Clean it up!� and I say, �Sure, Kathy, it�s cleaned up. I�m happy now!��
KK: Well, like I said, you know, we do have limited ability to check remotely. We would use a commercial scanning tool to try to at least insure that you were marginally secure when you came back up. And if you had one of the types of self-replicating, if you truly haven�t cleaned yourself up, we�re going to see you again!
HS: Oh, yeah! [inaudible]�
JB: I guess that is a good point, isn�t it?
HS: Yeah. When you think about this network security problem, what�you�re in this group that tries to make things secure. What do you see as your really big challenges today? What�s the most difficult things you have to do?
KK: Oh, gosh, that�s the $64,000 question.
HS: Well, I�m just trying to think of what the really big problems are. It sounds like there are some things that you sort of have good control over, you know what to do, but what are the real tough things out there that
KK: Well, the toughest things that we�ve always had are kind of linked together. One is that we don�t have�and probably never will have�enough well-trained system administrators for the number of systems that we have. And that by and of itself leaves us vulnerable.
HS: So you think of all the system administrators, it�s sort of your kind of distributed security team.
KK: Yep.
HS: Really part of the team.
KK: Um-hum. And every place has that issue. You can�t hire enough really well-trained people.
JB: So then what�s another part of the solution long term that people might want to really wish for or hope for or legislate for?
KK: Well, I�m going to try and give you a two-part on that. Part of it is technological, you know, employing more security at the varying levels, the defense in depth issue. The other is putting pressure on the vendor community. There�s no reason�it�s an unrealistic expectation to think that, you know, my aunt who bought her computer at Wal-Mart is going to know how to secure it. And she�s not going to care about patches and if she did, she�s going to be too afraid because she�s not entirely computer literate to actually put it on her machine.
HS: Right. She thinks patches go on elbows.
JB: Or knees.
KK: Right. And so the vendor community, I think, needs to adjust and realize that it needs to deliver products that are at least reasonably secure for the average user, out of the box. And I think they�re beginning to come around to that position, if I kind of trust what Bill Gates said in his memo to Microsoft a few days ago.
HS: That security was going to��
KK: That security was going to be now considered even over and above features in terms of new releases.
JB: Kathy, what do you think about the whole�all the press about and driving towards a single sign-on? Do you think that�s a good idea, from a security viewpoint? It certainly would make�it certainly is much easier use for people, if they only
KK: It depends on the security of the mechanism you�re using. If you have all your eggs in one basket and you drop the basket, you�ve got a problem. But if you have a secure enough single sign-on mechanism, it�s certainly a lot more convenient and it gets you away from users writing down passwords and doing ugly things that we don�t want them to do.
HS: Yeah, on the other hand, if somebody gets his�if you have a single sign-on��
KK: They get the keys to more than one asset.
HS: �that�s [inaudible] or sees it or whatever, they have access to the whole world.
KK: That�s right.
HS: Do you think in the future that biometrics is going to play a big role in trying to solve that problem?
KK: I thought that biometrics have quite a bit of potential. I mean, they�re not going to make much penetration quite yet, but the kind of thing that security weenies talk about is something you know, something you have, something you are. Something I know is the user ID and password�and we know how effective that is!�users pick bad ones, they�re stolen. Something you have would be something like a token card, maybe a secure ID that changes time-based, and then something you are and can�t change is your biological self. Now, I�ll caveat that by saying that even to authenticate biometrically, somebody�s digitizing something corresponding to your biology and if they�re doing that and I can somehow find a way to spoof that, even biometrics aren�t 100% effective.
HS: Yeah, sure.
KK: But yeah, I think that offers a lot of hope and I think you�ll see that coming in more and more in the future, that there will be more biometrics as the price comes down.
HS: In fact, I�ve heard there�s some interesting little tricks. For example, if you scan somebody�s face or their hand or whatever, you know that every time you scan it, it�s going to be a little different. So if you see the same thing twice, you know somebody�s spoofing.
KK: This could be a problem.
HS: It�s got to be different, [inaudible] it�s got to be enough the same.
KK: Yeah, it�s certainly�almost anything is going to be better than just user ID and password. There are just so many problems with that and people share them, people pick bad ones, people put yellow stickies under their keyboard and think that�s secure. User ID and password is just a really flawed idea, but it�s what we�re stuck with in most cases.
HS: Yeah. We noted that the attacks are getting more and more sophisticated. Are the tools to track these things down and lock things up, are they getting more sophisticated?
KK: Yes, but not at a rate parallel to the growth in the ability to break into systems. So I would say overall, the good guys are behind the bad guys right now.
HS: That�s a bad situation.
KK: Oh, yeah.
HS: What kind of new tools are becoming available now?
KK: Well, you mentioned the biometrics. I hold out some hope for improved intrusion detection mechanisms. Those are more like the burglar alarms, so I know in more real time which elements of the university are being had.
HS: What kind of things is Penn State doing or are other people doing in general to get a handle on this thing? I mean, you mentioned that you have some good policies and things, but what about your relationships with the other communities involved in this kind of thing/�
KK: Well, we try to keep a presence with all of the different players that are involved in Internet-land. I mean, we have commercial contacts, we have law enforcement contacts, certainly the other incident response teams.
HS: But they have formal groups that you�re part of? I mean, are there some groups that people should be members of for security people?
KK: Well, I mentioned FIRST. FIRST is one of those. That�s Forum of Instant Response and Security Teams. Security people tend to hang out at conferences. That sounds bad, but there are conferences that are devoted to security and that�s a good place to start learning. USENIK, certainly. Some of the big technical conferences where a lot of security people may gather in one place at one time.
HS: Is there a security conference that you wouldn�t miss, this is the one to go to if somebody was saying [inaudible]?
KK: I don�t know that there�s a single one to go to. A lot of it depends on where you are in the learning curve. If you�re newer to the field, some of the CSI�s and things like that are good. There�s SANS, there�s the FIRST Conference if you�re into incident response. There�s the USENIK Security Symposium which is always good. There�s just a lot of them out there that are pretty high caliber and really, it�s worth the money to start sending people to those because it�s hard, at this particular stage of the development of technology, it�s kind of hard to pick it up on your own. You need to go interact with a lot of different people.
JB: Okay. We�re getting kind of close here and I think we�ve got perhaps one or two other questions we�d like to kind of perhaps wrap up with. One has to do with attachments, Kathy. Are there any safe attachments?
KK: Pure text!
JB: What?
KK: If it�s pure text! But you can�t trust the extension there. In order to do something bad to your system, something has to execute. So if it�s just plain text, it�s not likely to hurt you very much. If it�s RTF, it�s not likely to hurt you very much because there�s nothing executing. But you don�t know that when you first get the attachment.
HS: Right, and if it�s a dot-DOC, it can have a macro in it.
KK: Right.
HS: Looks like text, but
KK: So you want to definitely have any attachment scanned and not just trust that it is what it says it is.
JB: And what about sending attachments to lists?
KK: Hmm.
JB: Any particular thought on that?
KK: I�m not a real big fan of it, particularly the huge attachments that bulk up mail servers. I�m not necessarily [inaudible] that, but
JB: [inaudible]�
KK: �it may be necessary in some cases.
JB: Okay. What about going forward in terms of all that has�moving forward with really a strategic plan for IT security? Any thoughts for what campuses might be doing or should be doing in this area?
KK: That was really beneficial for us. I was very frustrated right about the 1997 timeframe and started�that was when Titanic was released and I started comparing us to that. But that caused a strategic planning effort to commence in this area and identified the things that I thought we needed to improve over a five year period. And then I report directly to the CIO which is a good place to report in the organizational structure. I�m high enough that we do have some visibility. After we had more or less gone over that with a group of concerned users from a lot of different technology organizations, the CIO took that forward and the president and the deans discussed it and came up with a funding mechanism for it. So not only do we have a plan, we actually have money to implement it which is wonderful, given the budget climate.
JB: It sounds like you recommend that as a strategy.
KK: Yeah, I would recommend that! I would definitely recommend it because, well, I can�t say it�s actually worked for us because we haven�t actually implemented the results of it yet, but it�s certainly brought visibility to the issue, got people thinking about, well, yes, our assets are worth protecting. What�s in this plan is reasonable and we need to fund it. So yeah, it�s an approach I would recommend.
JB: Okay, Howard, any other final questions from your end?
HS: Yeah, I have a final question here, Kathy. I was looking at the CERT data and I noticed that for the last few years, every year, the number of incidents reported has doubled and last year it was 53,000 and things like that. I mean, if this keeps going on, in just a few years, we�re going to be getting like half a million of these things a year or something like that. Are there things out there that�s going to slow this thing down? Right now, it seems like we�re reactive. Are there things we can do to be proactive, to stop these things from happening?
KK: Well, again, I think having an educated consumer base that can relate to the vendors that this is really important. Cars were not first made with seat belts in them or shatterproof glass. It took the users demanding those kinds of features. So that�s one thing. Firewalls help. They�re not the answer to all problems, but say I had a port�I don�t know, give me a port number�1401-based attack that�s absolutely brand new. Well, it�s blocked by default if I have 1401 blocked. If it�s something I haven�t needed before and it�s blocked, I�m not going to be vulnerable to this new attack.
HS: Do you think it�s helpful to prosecute these people?
KK: If you can figure out who they are, and that�s one of the biggest problems. Remember, if I can break into a system, one of the first things that I�m going to do is run a root kit which will essentially hide all my tracks. So trying to trace back�probably when we�re attacked, we�re attacked through a daisy chain of multiple systems and if even one of those has all the log data erased, altered or otherwise tampered with, we aren�t ever going to be able to trace who did it.
HS: You were talking about vendors doing things to make their systems better and things. Is that one of the things they need to do is to make it so that people can�t hide? I mean, if people couldn�t hide, wouldn�t that solve the problem? At least
KK: It would, but it�s awfully difficult to do. If I can get in and assume administrative privileges and administrative privileges mean that I can modify logs and things of that nature, then I can hide my tracks. There are certainly things that the community could do, making it more difficult to spoof IP addresses, making it more�maybe writing log files somewhere where they become immutable or something. And I�m kind of talking off the top of my head there, but yeah, it would be nice if we could get to that. I don�t think prosecution�s the answer just because of the difficulties in finding out who really did it. And also, prosecutions are incredibly time-consuming, having gone through several of them now. That�s like three or four months of one of my top analyst�s time if we�re going to actually prosecute.
HS: So we�re just going to see those numbers increase at least for the��
KK: For the near term, you�re going to see them continue to increase, I would think. Until we can get better technological solutions, both in the traceability range and in the proactive measures range. I don�t think the incident count�s going to go down anytime soon so this is a problem we�re going to be living with.
HS: Yeah, that�s not a wonderful prospect.
KK: I�m just so happy, filled with joy!
JB: In other words, we�ll all be spending probably a little bit more of our time on security issues in the near term is what you�re saying.
KK: Yes. In the near term, I would think that, yes, we are.
JB: Okay, good. Well, thanks so much for being with us here today. Any final comment, Kathy, before we wrap it up or��
KK: No, it�s been my pleasure to be here and I hope it was helpful to people in some small measure.
JB: Okay.
HS: It�s recorded forever, Kathy, so people [inaudible]�
KK: Oh-oh, I�m in trouble! Putting out [inaudible] knowledge. Actually, my identity was stolen. I�m not really Kathy Kimball.
JB: You�re really Julie somebody, right?
KK: Right.
HS: [inaudible]�
JB: Well, thanks so much for being with us here today. Join us again in two weeks, on February 7th for a session with Dave Lambert from Georgetown University here in D.C. and our topic will be Budgeting for IT Infrastructure, always a timely topic. Many thanks to our CREN member institutions for their support of today�s Tech Talk; also thank you to our Tech Talk expert, Kathy Kimball; to technology anchor, Howard Strauss; to Terry Calhoun, our Tech Talk web guru; to Jason Russell, Bonnie Boyles and the support group at Merit Network; to Susie Berneis, audio file transcriber; and Gayle Terkeurst as well and thanks, finally, to all of you for being here. You were here because it�s time. Bye, Kathy. Bye, Howard.
KK: Bye.
JB: See you all on February 7th.
HS: Right.
KK: Thank you.
JB: Bye!
END OF WEBCAST
