TechTalks Transcript
The Top Ten Mistakes That Make Security Tough!
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Mark Bruhn [MB] |
November 2, 2000
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
HS: --this 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, there were three little pigs, Fiddler, Fifer and Practical, who just wanted to live peaceful lives deep in the woods. Unfortunately, also living in the woods was Zeke, the Big Bad Wolf. His idea of fine dining was to gobble up those very same three little pigs. All of the piglets, therefore, took what they believed to be the necessary security precautions and built houses to shield them from the danger of the Big Bad Wolf.
Fiddler, a junior faculty member in the Music department, built her house from straw. Straw, she pointed out, was the ideal material for a musician's house, since it absorbed sound, reduced echoes and that kind of thing. Of course, since it could be built so quickly, there was more time for her to download music from the World Wide Woods.
Fifer, a freshman in philosophy, built his house from wood. Wood, he knew, provided a solid platform from which to discuss the many security threats in the forest and since wood is so abundant in the woods, his house wasn't very hard to build. Thus Fifer found more time to read e-mail attachments and challenge colleagues in chat rooms.
Practical, a nurse in the Health Center, built her house from bricks. Brick had to be arduously transported into the woods, but Practical thought that bricks were the best preventative medicine against the formidable threat of the Big Bad Wolf. We all know how this story turns out, but our faculty, students and staff seem to forget it when they play it out on our campuses every day.
The Big Bad Wolf on our campuses is everywhere. The wolf is sniffing packets on our wired networks, taking advantage of overspray on our wireless networks, lurking over our shoulders when we enter our secret passwords, and dressing up like a sheep to fool us when his smiling grin appears at our doorsteps. On campus, we have an advantage over the three pigs in the forest. We have a skilled team of Information Technology folks that are expert at keeping the wolf at bay and expert at suggesting steps we need to take to keep the wolf from blowing our systems apart. But like Fiddler and Fifer, we have more important things to do!
We leave our computers vulnerable to being ravaged by the many Big Bad Wolves that view our data and systems as just the tasty morsels of their next meal. If leaving your personal computer system unprotected only hurt you, your IT staff might not be all that concerned about your reckless lack of diligence. But in the Internet forest, breaking through the door of the flimsiest straw house often gives the wolves access to every house in the forest, even those made of the strongest brick. Unless we all do our part, the IT security folks can't do theirs. Chances are that you and your users are making security mistakes that have the Big Bad Wolf licking his chops.
Today, Mark Bruhn will tell us some ways that we can insure that Zeke goes hungry, or at least goes to another part of the forest where straw houses are still being built. You'll learn how you can do your part to protect your systems so that we can all live happily ever after on today's webcast of Tech Talk. Judith?
JB: Hey, thank you, Howard! You did surprise me. I didn't expect a pig intro! At any rate, thank you so much and we'll all look forward to talking about the challenges for securing our Internet forest and all the forests beyond our immediate campus forests. So I'm very pleased to welcome Mark Bruhn from Indiana University back as a returning Tech Talk expert.
Mark is Information Technology Policy Officer for all of Indiana University's campuses and a recognized expert in information technology policy and security issues. Mark has been with the Central Information Technology organization at IU since 1985 and over time has had experience with almost every fact of the digital infrastructure, might I say, the Internet forest there, including applications development, security administration, database administration, computer operations, information services and basically most of the whole enchilada there on campus. Welcome back to CREN Tech Talks, Mark.
MB: Hello, everyone, and Howard has named our enemy and our enemy is called Zeke!
HS: Okay, that-as best I could determine, having researched that story on the web, that is his name! At any rate, Mark, if we could get away from the forest just for a moment - or we'll use the forest, whatever. When we talk about security, what do we mean? Do we mean network security, the integrity of files, the availability of service or what kind of security are we talking about that is being threatened?
MB: Well, the short answer is "yes." Inattention to security can effect problems in all of those areas from permitting network intrusions to loss or destruction of data to business interruptions caused by denial of service attacks. So we worry about network security, we worry about system security, we worry about the security and the integrity of files on the grades clerk desktop, on the mainframe, on FTP servers. So yes, I mean, again the short answer to your question is "yes."
HS: And who are the people? I mean, in an organization, in a university organization, who are those people who are responsible for security and who worry about making sure that it's there?
MB: Howard, that's a trick question! The answer to that question is "everyone"! I mean, the fact is that anyone who orders a computer of any kind, unboxes it, puts it on their desk on the university, the campus network, the institution network and plugs into the wall are immediately systems administrators. You know, systems administrator, that title used to be fairly weighty. Any more, you can apply that title to anyone that uses a computer on the institution's network and so everyone that uses a computer on the institution's network or, indeed, accesses electronic data on the university's network is responsible for security of those systems, of that data and of the university's network.
HS: But Mark, when you say a systems administrator, in Windows systems - especially Windows NT systems - a systems administrator is a very particular person, or at least we're talking about some very particular privileges. Are you saying that even somebody who doesn't have system administrator privileges is sort of a systems administrator anyway? If you get a computer, does that do it for you?
MB: They are, because unless you have a very coordinated, very formal technical support mechanism within your organization-whatever size it might be-the individual that unboxes that computer and the individual that sets that computer up on their desk generally is going to have those administrator rights. There is no user rights and there's no administrator rights in that case because there is no separate user and separate administrator. It's the same person.
JB: So you're really raising the bar if we think about, instead of thinking about ourselves as computer users, but that we're also computer sysadmins for our own systems, that we basically not only have on our desktop but that we carry around with us, then.
MB: Oh, absolutely true. And you know, I'm not raising the bar. The vendors of these computing systems, the vendors of these technologies, they are raising the bar because they are making things-and this is going to sound a little strange, certainly-they are making things more complicated and they're making things more easy. They're making things easier because they are building operating systems and installing those on PC's that we as, if you will, everyday consumers are buying every day. It's not that a high-end, sophisticated operating system is only available in an institution's machine room any more. It's available in the office, in the cubicle, in the home office. It's attached to the cable modem service, it's attached to our modems. They're all over the place, so these sophisticated operating systems, these sophisticated systems are available and are being purchased by everyone. The easy--that's the easy-the complicated part of it. The easy part of it is that they're not making it easy for those people to maintain those systems securely. In other words-�
HS: But is there something really - I mean, we're going to talk about these, the ten most difficult problems - or at least, your ten problems. But are you saying that this is a failing of the people who make the computers and the software, that they could do something to get around these problems?
MB: I think so. I think that things are too complex. I think that there are-now, I say that and then I know that there are other tools that you can buy to make administration of these systems easier, you know, kind of off-the-shelf other tools. But in order to, for example, install a particular program in an NT system, you know, you have to know what it is that you're doing. You can't just, you know, put the disk in there, run SETUP, you've got to answer these questions, you've got to make sure that the registry isn't messed up. So the complexity is in using and administering the systems. But the difficulty is that the vendors aren't supplying, I think, a good enough resource for the everyday person to use to make sure that their system stays secure. The advisories that come out, certainly we see advisories all the time. But you know, we - our experience is that the advisories are complicated, they're complex, they're [inaudible].
HS: So they're kind of really aimed at real systems administrators, you're saying?
MB: Exactly.
HS: And we're asking students, faculty and staff who are just sort of systems administrators by proxy-�
MB: Yes.
HS: But they [inaudible] stuff.
MB: That's exactly right. They're not keeping up well with the audience of those machines.
HS: And do these security threats apply to even things like PDA's and network appliances and low-level things like that?
MB: Oh, sure. They're all operated by some software. They're all operated-�
HS: So when my watch is an Internet watch, it's going to have security threats associated with it.
MB: Well, I'm not sure if I would go that far! You know, your security in making sure that you get to the next meeting, if someone's messing with that central service, might be jeopardy, but yeah, I mean, if you take it that far - and you can take it that far. There's something that allows your watch to interact with the networked community.
HS: There is - Seiko makes an Internet watch that has a URL, that does a lot of things a net appliance does.
JB: I was going to say, kind of depends on how complex and how many add-ons you have to that Internet watch, Howard.
HS: Yeah, but I mean, it seems like what we're saying is that potentially any appliance on the Internet has potential security threats.
JB: Yeah, wasn't there just a scare this last week about a virus hitting the PDA appliances?
MB: We're seeing more of those.
JB: Yeah.
MB: I mean, if you can name an operating system, someone has written some bit of malicious code to access that.
HS: Are there things that are more vulnerable? For example, are wireless networks - do they have more security problems than the wired networks?
MB: Well, I don't know about more, but they certainly are different. I mean, what we worry about with wireless, for example, is overspray.
HS: Which is?
MB: The fact is that you're putting a transmitter in a facility and you really don't have too much control. You do have some, but you don't have too much control about where that signal's going to go. So if you mount that access point on the outside wall of a building-especially this building that I'm in--you know, you're going to provide network access to the people inside the room and to the people outside the room.
HS: And that could be pretty far away, actually.
MB: Yes.
HS: In fact, you don't know how far away it is.
MB: That's exactly right. In fact, I don't remember the context, but we were at Internet 2 meetings the other day and someone was joking about having a wireless transmitter, a wireless WAP in a location where, as the subway train went by, someone may be able to pick up that signal as they went by. And, you know, that's a bit off, but still, you know, if there's a park outside of your building, if it's frequented by a lot of people, certainly any overspray into that park, if the wireless installation isn't done properly, people in that park are going to be able to gain access to your network. Again, it's one of those out-of-the-box problems, though, because by default, when you install one of those systems and you don't turn on the encryption, you don't turn on the secret key mechanism, if you just install it out of the box, you know, this system is going to have a default term of, you know, 301. This other system's going to have a term of ANY and as long as you can try those, someone who can figure what those are, they're going to have access to your network and you're not going to know it.
HS: Okay, if I could just give you one more question and then we'll go to the top ten here. And that is, are there some programs like e-mail programs or some operating systems like Linux or one of those that are more vulnerable or have more security problems than others? Is an e-mail program something that we really have to watch out for, and we don't have to watch out for, say, a text processing program very much?
MB: Well, with all the problems with the Microsoft Word virus, the word processing software's a big problem. But you know, SendMail has traditionally been problematic over the years. SendMail being kind of the basic [inaudible].
HS: It underlies all the mail programs, you mean?
MB: Right. Most mail programs are based on SendMail. And if you don't keep up with the appropriate versions of SendMail, if you're running an older version of SendMail, then there are going to be known problems with that version. But if you're using the most recent version of SendMail, if you make sure that you're applying whatever bug fixes are coming out, even that program can be made secure. The fact is that it really isn't one program or one operating system that's a particular problem. Most operating systems can be operated fairly securely if good attention is paid to them. There are bugs, there are advisories that come out, that sort of thing to deal with, on all systems.
Some systems, as we talk about it, are more complicated to manage than others are, but with adequate monitoring, maybe even some intrusion detection software that just about anybody can get now, I would say that it really isn't the system that would be the sole problem but a combination of the system and the person. If the system's complicated and the person isn't capable, then obviously, you're going to have much, much more trouble than if that wasn't the case. I mean, I wouldn't suggest, for example, that too many of us would install and maintain an [inaudible] mainframe in our living room, right, because not a lot of people-�
HS: Keeps the place warm, though!
MB: That would be true! But not a lot of people are going to have that expertise.
HS: Okay, and I think we're going to turn to the top ten now. And if you'll permit me, I'm going to do them in whatever random order I feel like doing them. Start at the bottom! But do you want to mention to us, Mark, where these things came from, how you happened to come across these top ten?
MB: Actually, these are the pet peeves of our security officer, that is, the Indiana University IT security officer, Tom Davis. He has a staff of six security analysts. I know that's not typical. I get grief about that on occasion from my colleagues, but-�
HS: [inaudible] right here. We have fewer.
MB: And these are the things that really, they come back in griping about when they come in off campus. I mean, these are the things that they deal with on a regular basis and these are the things that they're getting tired of dealing with, frankly. So that's where those came from.
HS: You said something interesting when we talked about this before, about - I don't know if it was you who had done it or somebody had done it, but they had - if they found a machine sitting idle that was doing something, had some kind of egregious security problem - maybe even just sitting unattended - that somebody was either putting a sticker on the screen or doing something to say "This machine has violated security"?
MB: Well, in fact, I do something like that. If I'm walking through this building in the computing center or in the VP suite or in a place like that and I do come across a computer that's unattended and logged on, I will go to an input field and I will put something like "I was here at" and then I'll put the time and the date and I'll put my initials. And then I'll leave it just like that.
HS: You won't erase all the files or anything?
MB: No!
HS: That's very nice.
MB: I do have what's called a network ticket and I can't remember where I got this. I just have one sample of it, where it has, in fact, a little sticky portion on the back. It looks like a traffic citation. It has a bunch of things listed on there, two of which are "Reckless cluelessness" and "Clueless recklessness." So it runs the gamut. But if, for example, in my scenario where someone left their machine unattended and logged on, there was a little place for a check mark there on that and there's a box there and you know, it looks like it's a carbon so it looks like someone else has a copy of this. And then you stick it to the front of that device when you come across one of those situations. A very interesting idea.
HS: Yeah, as long you don't stick one on my machine here! That's-�
JB: I was thinking that's a new little handout that one could give at security conferences, right, is a packet of stickies that you can go around and put up and post. But it does certainly bring up, emphasizes that we just probably don't think about these things often enough and think about the impact of what we're doing every day. And I guess that leads us into the ten top mistakes or ten top behaviors that we'd like users to avoid.
HS: Yeah, can we start with number four, which is opening e-mail attachments from unknown people? Don't we mean not just unknown people, but I mean, the I LOVE YOU virus, whoever got a copy of that, they got it from people they knew. So could you expand upon that?
MB: Yeah, and in fact, that statement should be expanded on because that's absolutely true. Now, in the case of a large organization, maybe you know that person, maybe you don't. But if you went to whatever online address book or phone book or what-have-you that was available to you, you would certainly see that that person was in your organization. And if they weren't, you had some connection to them because you were in their address book for some reason. So the fact of the matter is that, you know, when you got an I LOVE YOU virus, other than the fact that it might be very curious to you why, you know, your colleague Joe or your colleague Jane down the hall were sending you a message that said "I love you," certainly you would recognize the return address.
HS: And it seems like you'd have to have a pretty big ego to think they must mean it!
MB: Right. Yeah. So there is that, but certainly, you know, something a bit, you know, worded a bit more professionally, that would absolutely cause us-and did cause us-more problems because of that. And the corollary effect, the peripheral effect of that was that people were responding back to that person. "Well, this is somebody in my own department. This is this person right down the hall. I'm going to send him back this message and I'm going to say, you know, 'What is this about? You sent me this message.'" They didn't know anything about it, of course, but you had all of that other mail, you know, all over the network. People communicating back and forth with one another before they realized what was going on.
HS: But I mean, if I got - anytime, if I got a message from Judith or you while we were setting this thing up that had an attachment, I guess I would - I'd open it. And I would-�
MB: I would suspect, then, that Howard, your anti-virus program would take care of that problem for you.
HS: Well, I, you know, I hope so. But again, what does one do? Since I, I mean, I do get attachments from people I know. I agree, if it's from somebody I don't know, I'll be real, real cautious and if it has a strange subject. But if it has a subject like, you know, "Tech Talk whatever" things on it and it comes - I mean, somebody who knows enough about you, it seems like they could still sneak through. Are there things you could do to even stop those things? You suggested that if I had a good anti-virus program, even if one gets in, it'll stomp it out.
MB: Well, there's always going to be a scenario wherein you're going to get infected, and that is where you're expecting something from someone, like the Judith and Tech Talk attachment that you use as an example. It's a new virus, they're being developed every day. There's a lot of people out there that have nothing better to do. They are developing those every day. They're either modifying some that have already been released into the wild or they're developing new ones and you're - as good as your anti-virus program might be on your desktop, it may in fact not yet recognize that new virus.
HS: So it's just that we're really trying to address number three on our list, which is not installing anti-virus software and keeping its virus patterns current.
MB: Right, except I'm being a bit more pessimistic than that, even, because if your virus patterns file is current, it may still not recognize, you know, a virus that was release 82 minutes ago and Judith's attachment just happened to have been infected by it.
HS: What do you do about that?
MB: You don't. You clean up afterwards. I mean, the problem is that that scenario, there's nothing that you can do about that scenario unless-unless you call everyone that sends you an attachment and ask them if that attachment was created by them, on their PC and "Are you sure your PC is not infected with any viruses?" You know, that's not very feasible. It's not [inaudible].
HS: Are there easy ways to keep my virus software up to date?
MB: No, it really depends on what virus software that you have, but most of them now, most of the well-know ones, you can do that automatically at a time period specified by you in the configuration. Mine, I happen to use Semantics Norton Anti-Virus. I update my virus patterns from their website every Friday.
JB: Hm!
MB: Automatically. I don't see it happen.
HS: Wouldn't it be nice [inaudible].
JB: You've got your machine set up?
MB: Yes, my machine is set up to automatically contact that website and automatically download those new virus patterns. And we encourage everyone within the Indiana University environment to do exactly the same thing.
JB: So that's something that you'd have on your ten top things to do is to set your machine up to do that?
MB: Absolutely! Absolutely, no doubt.
HS: Yeah, it sounds like something that, you know, everybody should do, although I'm sure somebody will raise the question about, well, how do you know that that thing that comes down to update your virus thing doesn't have a virus in it? But in fact, that's not a threat.
MB: You can follow those paths ad nauseam.
HS: Okay, let's just grab another of the top ten. We'll actually go back to the first one here, which is installing unnecessary programs and services. What's an unnecessary program or an unnecessary service? And why is it a bad thing?
MB: Well, two things. First off, if you're not using something on a system that you're operating, that you're administering, then don't have it active. In other words, if you're using a Linux workstation and you're not supporting any electronic mail on that system, then don't have SendMail installed. Don't have any services that you can disable or remove running on that system.
Number one, you're not going to be paying attention to those. In fact, if an advisory comes along, you might look at that and say, "Well, we're not using SendMail so that advisory doesn't apply," even though SendMail is active on your PC. The second thing is that because you're not using them, you're not going to notice if they change in configuration. You're not going to notice if the footprint of the executable changes, it gets bigger, it gets smaller, because you're not paying attention to that service and to the associated programs. So someone comes along, recognizes that you have, you know, this service on your machine. They know that there's a vulnerability, they see that you've not patched that particular program. They use that to gain access to your machine. Maybe you can see that, maybe you can't, so if you don't have those unnecessary programs and services installed, they can't be exploited in those ways.
JB: Mark, which of the unnecessary programs and services might your security analysts, for example, tell folks to get rid of, off their system? Are there problematic ones that, you know, you just have a list that says for general purposes, don't install these things?
MB: I don't know what those are, right off the top of my head, but our Technical Security staff, when they're consulting with a system administrator, will list those for them. They will say, "Are you using the ALL LOGIN? And if you're not, then take it off." So I don't know what those are specifically, but certainly, there is such a list.
HS: Mark, your second thing here sounds like something that really does apply to systems administrators, not to regular folks. But maybe you can tell us more about it. It says problem is not keeping current on software patches. I think a lot of people probably don't even know what they are. Especially security related ones, and that seems even more like a systems-type person as opposed to somebody who just has a machine sitting around in their office.
MB: Au contraire! We have-�
HS: I knew you would do that! [inaudible] because I think that a lot of people, really, would believe that it doesn't apply to them, since they don't know what this is all about.
MB: Right. The fact of the matter is that - well, as an example, we have on our Security Office website a subscription service. What it is is, you can go there, you can identify the system that you are using and you can either ask for all advisories for all systems or you can ask for the advisories of the system that you're particularly interested in or using. And there are advisories for all of those systems-some of them certainly more often than others-but I happen to be using Microsoft NT 4.0 Workstation. I subscribe to NT advisories, I subscribe to Microsoft Office advisories, you know, the software that I use on my desktop. And I get advisories from the Security Office automatically for my workstation whenever they come out.
What I mean by saying that is that you have to know that your machine is going to be out of date. You have to know that your operating system, your system software, your applications software, they're all very complicated. There are bugs and problems identified in that software in a daily basis and the vendors are sending out fixes for those problems. Now, many of those problems are not security-related. Many of those problems are security-related. You know, in keeping with our topic, you absolutely should know when an advisory is sent out related to a security problem with the operating system or the applications software suite that you're using on your desktop.
HS: It seems like we-wow! If we're trying to tell our users, really, I think you're saying you really have to stay current with a lot of the systems and things. And yet, I think a lot of times we tell our users to not stay current because the very latest thing often has problems in the thing. Is that a fine line that we're trying to walk?
MB: Oh, it's a bit different, I think, because what you want to make sure that they do is that their-that the new system, the new thing is given sort of a shakedown period. Now, let those brave souls work with those systems and make sure that they're able to keep those secure, but in general, what you say is true. We say, you know, "Stay with the current, most widely-used system and make sure that that is maintained securely." If, in fact, there is a major security problem with whatever it is that we're talking about, whatever that component is, and the next release fixes that, then we would encourage them to upgrade. But in any case, you need to maintain the current architecture, the current technical environment that you're using, up to date with patches and with fixes. Everyone. Everyone [inaudible].
JB: And this is a service, then. If we go back to this idea of software patches, then does your organization provide them that subscription service or does that come from the vendor?
MB: Well, what they do, what the Security Office has done, they have subscribed the Security Office to-it's probably 100 different vendor lists, different bug tracking advisory submitting lists, out there in the world. And when they come in, then this smart engine-and sometimes the smart engine is someone's brain, because some of these things, it's hard to determine-but the smart engine determines what operating system or what application the advisory applies to and it attempts to pull out some good information. Again, some of the advisories are very complicated. And then it sends that to the people that have subscribed to the list for that particular operating system. Sometimes, they have to rewrite them. Sometimes they have to look at an advisory-and again, we understand that there's a lot of neophyte users that don't know, you know, this techno-jargon that some of these advisories use. They actually have someone that sits and rewrites those in order for that end-user to better understand what the problem is and certainly entertain questions from them should they have any about that advisory or how to apply that patch.
HS: Okay, Mark, your number nine thing is kind of an unusual one. It seems like a bad thing to do, which is propagating virus, hoax and chain mail. It's probably something that's against university regulations, but why is that a security threat?
MB: Well, the virus hoax part of it is a security threat in that what we see is someone that gets a virus hoax in the mail may not, in fact, treat the next virus report all that seriously.
HS: Okay, so it's a crying wolf problem.
MB: Exactly. Or crying Zeke problem!
JB: Yeah, we're back to Zeke here.
MB: As the case may be. But we do see that. We will see that someone will send the Security Office a virus, then they've got resources and references to check. We'll send back a note saying, "No, this one isn't valid," and we always add the statement, "But please remember that the next one that you suspect may, in fact, be valid, so don't hesitate to send that on as well." We want them to understand that, you know, they could inundate us, but that's probably better than them just ignoring something that they suspect.
HS: And what about the chain mail problem? I see a lot of these chain mail things that are just annoying.
JB: Yeah, I see an awful lot of them, too, and I just am always conflicted as to what to do with them, actually.
HS: Yeah, I just delete them. But I figure if every time you get one, you send back to the person who sent it to you something that says DON'T DO THIS, you'll get [inaudible] worse. But why is it a security threat? I just throw them away.
MB: It's really not, it's an annoyance. Unless there's an attachment related to that mail, which puts it in the other category. The chain mail certainly, some of it's illegal, which means that we have to deal with it a bit more seriously. The reason why we prohibit chain mail-it's on this list, by the way, because there's a lot of it.
HS: [inaudible] it's a nuisance, and I get it from family and friends who actually believe them.
JB: Yeah, I do too.
MB: Yeah, getting $2,000 from Walt Disney, Jr., who doesn't even exist! Or it does exist, but isn't related to Walt Disney, Sr., of Disney World fame. Chain mail basically chokes the network. I mean, once one of those things gets going, if you don't stop it, that mail-we have seen, you know, 50,000 pieces of mail in the space of a couple of hours related to, what was it? It was Tickle Me Elmo. Remember that?
HS: Oh, yeah!
MB: Well, it's been a couple years now, but Tickle Me Elmo caused us a boatload of problems here on the university network because it was so popular and we didn't get to it as soon as we needed to and it was bouncing around here. It sounded like ricocheting bullets in an old Western, there was so much!
HS: We could move on to number six, which is lack of adequate training to administer the system. I certainly agree that that would be helpful, but what kind of training are people getting and how are you getting it to them?
MB: Well, again, that's going to be on two levels. I mean, we are trying to talk about a certification system here at the university whereby if a department is going to hire someone that they're going to label a Systems Administrator or a Technical Support provider, we want that person to be certified in whatever it is that that department, whatever their favorite technology is within that department. The other level, though, is what we're talking about with the individuals who just take it out of the box and put it on the desktop. There are many, many resources.
What comes to mind is that whole series of, you know, Something for Dummies, that whole series of books. There's really some very excellent ones out there. And is this user or systems responsibility? In other words, is it the user? Is it the department? Is it the security office? You know, whose responsibility is it for that user to be adequately trained on that system? I would suggest that the user bears a great deal of responsibility for that. But the department that they work for must recognize the level of expertise that that person has related to the technology that they're putting in front of that person and they bear, I think, the brunt of responsibility for training that person adequately.
JB: Mark, is Indiana at the point where they're looking at all these different ways of getting the word out to users as well as staffers and professionals in this area? It sounds like there's just, you know, a multitude of things that one should do. Are you doing any classroom programs, say, for taking this perspective of "You're a user, you're really a SysAdmin, so here's a three-hour class on securing your system and things that you have to do." Are you going that route at all?
MB: Well, we are, in fact. We have - that is, the URTS, the computing department, has a very comprehensive education program and in that program, they teach - you know, it's educational program, free for students through the student technology fee. Faculty and staff can register, charge it to the department, or pay for it themselves. We have gone through that and continue to go through that program with the manager of the Education Programs department and we look for opportunities in all of those classes to drop the word, you know, and encourage users to better understand security and to take better care of themselves and of their environment.
JB: Um-hum.
HS: Yeah, but these things are taught as part of something else. This isn't - nobody goes out and gets security training.
MB: Not formally here. But certainly there are certifications in the world. The CISSP comes to mind. The-�
HS: What's CISSP?
MB: You ask me that, now I'm going to have to pull out the acronym. The Certified Information Systems Security Professional, CISSP.
JB: Okay.
HS: We'll accept that. We'll accept those [inaudible].
JB: Yeah, it's enough for the right letters.
MB: Right. That is a security professional certification. There's the Security Institute, I think it's at George Mason. It may be George Washington. It's one of those two Georges, and there is the program at Purdue, SIRIUS, which I won't be able to tell you the acronym for, or the spelling out of the acronym.
HS: Yeah, I think once you get past three letters, it gets harder.
MB: Right! There are many resources. There are Computer Security Institute, the ISSA, the Information Systems Security Association. There are many, many, many security resources out there that have many training courses, all around the world, and if someone claims that there is no security training available to them, they are, well, just plain wrong.
HS: Okay, if we can go on.
JB: Howard, before you go on, let me invite our users to do two things, one of two things. To go ahead and now is a good time to send in some questions for Mark at expert@cren.net, and also if you have your own favorite little advice to add to the top ten, either top ten things to do or top ten things not to do, that would be a good thing, too. Howard?
HS: Sure. Mark, number eight was not deploying encryption where available. What kind of encryption should we be doing? Should we be encrypting our e-mail, our files, everything and are there ways that, like, regular users can do that? Suppose I want to encrypt my e-mail. Do I need to run over to my systems people to figure out how to do that?
MB: No, in fact. Right now, it is fairly easy to get a free piece of software based on PGP which is Pretty Good Privacy, PGP. You can get that from the MIT website or you can buy commercial versions of software that support PGP, that environment. You can get web-based plug-ins, you can get Outlook plug-ins, you can get Eudora plug-ins. You know, you generate your keys, you follow the instructions, it's not one-two-three-four, but it's fairly easy to do. And then you're equipped to encrypt mail that you're sending to other people.
However, what that means is that the other people need to be likewise equipped. They need to have PGP, they need to know what their keys are, you need to know what their public key is. So there's obviously some setup. But it really depends, Howard, on what business you're in. If you are in the business of-and heaven forbid you should do this-but if you are in the business of transmitting highly sensitive, highly confidential proprietary information over e-mail to a colleague at another university, by gum, there's no reason for you now to send that information across that network in the clear because PGP is available and easy to use. If you do that on a regular basis, shame on you for not doing that!
HS: But should people be doing that? I mean, should people generally just be encrypting their e-mail? You're saying it's easy to do. Should people just generally do it?
MB: Well, it's easy for an individual to become equipped. The problem is having everybody equipped. So, for example, within our university environment, we have 17,000 faculty and staff. You know, obviously many of them communicate back and forth with each other. Many of them obviously communicate back and forth with students. In order for all of that mail to be secured to be encrypted, all of those people would have to be equipped with an encrypting program. All of those encrypting programs would have to be compatible with each other, understand the encryption algorithms of the others, and you know, in that kind of environment that we have, that's very difficult to do. What we say now is that if Jane on a daily basis interacts with Tom on e-mail and the information that they send across e-mail is of any sensitivity at all, they either shouldn't be doing that over e-mail or they should each go get an encrypting program and trade keys.
MB: Do you send your e-mail encrypted? I got some e-mail from you that was in the clear, fortunately, so I could read it.
MB: Any communication-I can't say all, but most communication now amongst my staff in the Policy Office and the Security Office, most of that mail is now encrypted.
HS: Using PGP?
HS: Okay, we have three more of these to do here, actually, so we're really, I think, making a lot of progress here. We'll take number seven here, which is inadequate handling of sensitive data, and in parens it says, "Gathering more than what we need, keying files off Social Security number, etc." Want to just talk about this inadequate handling of sensitive data?
MB: Well, I hate to speak poorly of my institution but we're still-�
HS: Well, you can talk about institutions in general. Of course, that's what you mean.
MB: Yeah, okay. Okay, most institutions are still using the Social Security number as the student ID and the employee ID, which is not a good idea, probably isn't legal to do that in general, other than in payroll and the tax areas.
HS: Yeah, by the way, we just got some kind of new health benefit plan and they said that when you logged on, your ID was already set as your Social Security number, that's what you were going to use. People cringed.
JB: Absolutely, mine was that way, too. I finally, they did give me the choice, however, of changing it. But the initial one was set for that, which was very surprising after all the messages that's gotten out. But it's hard to change once you've got an entire system all based on that.
HS: Yeah, but some of these systems look like systems that they're building brand new right now. I just think there's new people that have never programmed in their lives before who are just-�
MB: They've probably been out of high school all day.
HS: Yeah, and they're saying, "Hey, this is nice! It's unique and the government assigns it!"
MB: But in this area, what we see and what we worry about is the extract and the storage of institutional and personal information on systems out there on campus. You know, it used to be almost solely on the central systems, especially when we were back in the old S and A network days and we had an IBM mainframe and you had a dumb terminal on your desk and, you know, you were excited when you got color. You know, back in those days. But now, we see those files and those databases out there on campus and that means that we have to go where the data goes. So we have to worry about any Excel file, we have to worry about any Word document, we have to worry about any Paradox database out there in the departments, out there on faculty desks, out there on administrator desks, where they have them stashed.
HS: Or in PDA's now. I mean, you could download files of anything to PDA's, to laptops, and these things circulate all over. They just go right through the boundaries of your door. You take them home, you leave them in your car, you know, your kids can look at them, that kind of thing.
MB: And laptops. We just did a piece, it's on the Security Office website. We did this with Risk Management about stolen laptops, stolen PDA's. You put your password file on a laptop or on your Palm Pilot and it gets filched in an airport, why, there you go!
HS: Okay, we're down to our last two. Let's talk about number five. I'm saving number ten for last here. But number five is bringing up lab or test machines and forgetting about them. Tell us what that's all about.
MB: Well, I'll tell you what that's all about. That's fairly specific, but it certainly could be applicable generally. We discovered two machines that had been installed as what they call test machines. And they were brought up, they were attached to the network, then whoever was going to do some testing on that machine got busy, went off and did something else, were reassigned to another department, what have you, and that machine just sat there spinning on the network until we get a call from the FBI indicating that a distributed denial of service master and some of the zombie clients, the client-clients, were installed on that machine. Now, when we tried to find out who [inaudible] that machine, when we tried to find out what department owned that machine, it was very difficult to do. It drove these security guys nuts!
HS: So if you're done with something, turn the darn thing off.
MB: Sure.
HS: Clean up after yourself kind of thing.
MB: Absolutely.
JB: Mark, do you actually encourage everyone on the university campus to turn their computers off at the end of the day, you know, if their desktop machines may stay in the system?
MB: You know, as simple as you think that might be, that's a religious war. I mean, that's akin to, you know, Microsoft vs. Linux. It's one of those things, you know, they think-there's this whole camp that says that that's damaging to the hardware, it uses electricity, you know, it doesn't make any difference at all.
JB: Um-hum.
MB: There's all of this difference, so we don't say anything.
HS: So what do you say-�
JB: I was kind of wondering about that. Yeah, what do you think?
MB: Uh-�
JB: Ah, he doesn't want to say!
MB: I don't.
HS: Well, I will. It could influence all kinds of people now. [inaudible] We understand that people in your own university are going to ignore you. We understand that.
MB: Okay.
HS: But people outside may [inaudible]�
JB: They might really know this.
MB: I think that if they're - I think the machines ought to be turned off. I think that especially over a weekend, if someone goes on vacation, there's no reason for that-unless it's serving some other operational purpose, there's no reason for that desktop, that workstation to be on, and it should be turned off. Now, overnight, you know, it's--you know, you come in, you've got to boot them up, it takes a little while, what have you, you know. But even overnight, if it fits within that person's procedures then I think they should be turned off at night, too.
HS: How could - just tell me how "off" is "off" in that if I take my NT machine and I bring it to the point where I've locked the workstation and there's a little thing that sits in the front of the screen which would require you to log in to use the thing. Is that "off" enough?
MB: That's not "off" enough. I say it's not "off" enough and it all goes back to what we started with. If the machine is secure, that doesn't matter, but nothing is 100% secure. You're not watching that machine, you're not seeing what's going on with that machine. Someone could be on there doing this and that. You're off in Tahiti somewhere on the beach.
HS: Sounds great!
MB: You don't know what's going on in that machine.
JB: Well, actually, while the machine is on, then, it might be attacked from the network attack as [inaudible] office area.
MB: That's right.
HS: Our last of the top ten, of your top ten-�
HS: Okay. Is the question of sharing passwords. But of course, I'd like you to talk about the whole password problem in general. It's not just sharing passwords, right? It's keeping passwords in files and doing all kinds of-using easy passwords. Why don't you just address the whole password issue?
MB: Well, you know, we've been talking about sharing passwords forever, since we first, you know, started passing bits and bytes on a computer, we started talking about sharing passwords. And people have access to, you know, maybe five, maybe six. Some people have access to 15 or 20 different systems on their campuses. We're not to the point, though we're working on it feverishly, we're not to the point where one set of credentials is used on all of those systems. If they synchronize their password on all those systems, then, you know, they have the one password. If one system is compromised, all of those systems is compromised for their account purposes. If they have different passwords on all those systems, you know that they're going to maintain a little black book and it's going to have the name of the system and it's going to have the password in there. Or there's going to be a sticky note on the bottom of their desk drawer, you know, one for each system that they have access to.
HS: Or there's going to be a file, a local file that's going to have all the things that would be in the clear.
MB: But nobody on this call does that, I bet!
HS: Yeah, sure.
JB: Right.
HS: Everybody I know does it.
MB: You know, and I-�
JB: I have a very complex system.
MB: And this is what I tell people. If you're going to do that, then encrypt that file. It just goes right back to the other thing. Encryption software is easy, it's free. Encrypt that file. When you need that password, unencrypt the file. Re-encrypt it and you're taken care of. I mean, you know-�
JB: Actually, that is a very good piece of advice.
MB: That's what our folks here do, our e-mail system administrators these days are responsible for many systems and the e-mail system administrators have, you know, not only do they have eight Exchange servers, they have ten Linux servers running Pine and they have all these servers they're responsible for and while we can certainly encourage them to have different passwords, they're either going to have all the same password, all of them know it, or they're going to have different passwords and they're all going to have to be written down. And the ones that do that encrypt them in a file.
HS: Is biometric authentication going to solve a lot of the password problems?
MB: You know, that reminds of that scene in the Visa commercial where the James Bond character goes through this myriad authentication schemes, you know, fingerprint and voice print and all, he gets to the other end and the woman behind the desk asks him for an ID card. But-or the Mission Impossible where the server administrator goes through 15 different authentication mechanisms and our hero gets into the room via an air conditioning duct, right? So it doesn't matter. There's always going to be something, so if you combine five or six, you know, you're going to have physical security problems. Or if you use one static password, then that--you know, then we go back to the sharing passwords thing.
One of the problems that we see with biometric-now, the feasibility of employing a biometric scheme in our environment is actually much better than it used to be. I mean, we talked about using a fingerprint system on the new technology building that we're building at the IEPY campus. Now, the immediate problem that you have is where people are now understanding that you're going to be storing something about their physical being in a database. They have enough of a problem with photos, with images in the database, and that's [inaudible] protected information because of that. So if you start storing fingerprints, even though they're digitized, if you start storing retinal patterns, even though they're digitized, people get very uncomfortable about that. So it may not be any longer even a cost problem, but certainly not a technology problem. It may be more of a cultural, sociological problem than anything else.
JB: And you really do wonder. Well, you know what, there is one question that came in early on that we haven't actually addressed, and so I would suggest we go ahead and take that right now if-�
JB: Yeah, the question came actually from Frank Poblano from - who is a software systems specialist at UT El Paso, and he had a suggestion, kind of a combination of suggestion and question that says that he'd like to suggest that one of the main problems with security is that people use operating systems that don't have any security at the folder or file level. And he goes on to talk about, you know, the problem that without that, it's very hard to get real security. What would you respond to that, Mark?
MB: Well, I certainly don't know exactly what operating system he has in his mind-�
JB: Well, he does mention Windows NT and Windows 2000.
MB: Now, both of those operating systems have, certainly, the Microsoft file sharing capability, but both of those also have - if you disregard any bugs or security problems inherent in the code - both of those have ways of turning file sharing off. I share a public folder on my NT box, but I don't share any more of that drive. If I want somebody to have access to a file that I'm not worried about other people having access to, I drop it into that public folder and when you try to connect to my machine on the network, that's the only folder that you're going to see. So unless there are technical issues with that that I don't know about, there are ways built into the operating system to protect those files. And if you use the protection scheme correctly, you should be okay.
JB: Well, I think the combination, it was not only being able to use that kind of a system but also actually implementing it and using it. Just because it's there, you know, then many folks don't simply use it.
MB: Right, and that goes back to the first thing that we talked about. I mean, you can pull something out of a box and you put it on your desktop. Maybe you know that file sharing is there, maybe you don't. I don't think it's on by default. So someone would have to-someone with more technical knowledge than I am is probably going to jump in here on me, but I think that's not active by default and I think you have to specifically hit that radio button to turn that on.
HS: Yeah, I believe you're correct on that, too.
JB: Okay, Howard, would you like to do a final question or a comment?
HS: Sure. We should mention that we are way out of time over, probably run out of tape any second here. We certainly covered, you know, a lot of the threats in the forest out here, but Mark, could you just give us a last few words on what we should be doing to keep things under control here in the forest?
MB: I think understanding the environment is probably the most important thing that any of us can do, from the desktop user to the high level systems administrator. It doesn't matter who you are. You have to understand what it is that you're using, you have to understand how it affects the people and the network around you, and you have to play with the rest of us in making sure that that environment is secure.
JB: Well, thanks very much. Let me wrap up here. I'd like to thank everyone who was with us here today and to continue setting aside Thursdays at 4:00 PM Eastern Time for this series of Tech Talks. Our next session is two weeks from today, on November 16th, and it features Linda Cabot from Georgia Tech and John Bucher from Oberlin College, talking about a very hot topic, and that is the recruiting and retaining IT professionals on our campuses. So be sure and plan on being with us at that time. Many thanks, too, for the institutions who support these Tech Talks, and again, to Internet Security Systems for their special support of this Tech Talk. Links to their site are available on the event site. We invite you and your institution also to help support the Tech Talks for community and I'm going to start doing a little poll as to whether or not we should start offering Tech Talk t-shirts and coffee mugs, so do let me know!
Thanks to everyone who helped make this event possible today. A special thanks to Mark Bruhn, our Tech Talk expert; 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. You were here because it's time. Bye, Mark. Bye, Howard. Bye, Zeke! Should we say-�
HS: Bye, Judith. And send me one of those t-shirts as soon as we get them.
JB: All right, great. Take care.
HS: Sounds great to me! Bye bye.
JB: Bye bye.
END OF WEBCAST
