Security vs. Needs: the Great IT Divide
"slick rick", who is one of our students, made a comment on the last posting that raised a good issue, but one which took the conversation in a new direction. Since the topic raised is already on my list of things to discuss, I'll dive into it now so that anyone interested in this topic can participate. The issue in question is security on the Tablets. By security, I mean not just anti-spyware, anti-adware, security patching and password kinds of stuff, but the whole philosophy of how to secure a system from all manner of encroachments and harm, while having the least negative impact on the user.
"scottygu3" made a comment in that discussion that is interesting: "IT goals are incompatible with user goals. It is a continuing give and take battle between the two." It is interesting to me in part because I disagree with it, but more because I think it demonstrates a perception problem we in IT have with regard to security. (Now, I must admit that the perception has arisen because so many IT guys have the same opinion. They don't call themselves "sysgods" for nothing. While I think the statement is inaccurate, scottygu3 is dead on in stating it.)
Rather than seeing the goal of securing the box and the network (the two are inseparable) as "IT" goals and as at odds with the users' needs for using the machine, a proper IT perspective is that we need to accommodate security and usability both while the negative impact of either on the other. If our goal in IT isn't to make the system serve the needs of the user, then we don't understand the field. The converse is true too, however. If the user doesn't understand that part of serving them is making and keeping the systems secure, either from maliciousness or simple misadventure (or foolishness) on their part, then they don't understand it either. Our job is to manage the interface between these disharmonious needs.
Inevitably, circumstances will arise where one or the other need gets short shrift. At Vermont Academy, many students feel it is their "right" to install anything they want on their computers. Now, I agree that everyone who owns a computer has the right to do with it what he will. Just don't connect the damn thing to my network if you do, OK? (There's that sysgod attitude...) Because they do need and want to connect the Tablets to our network, I feel justified in putting "right" in quotes above. By dint of connecting to a shared resource, where their actions will inevitably have impact on every other user, their rights are to some extent abrogated--of necessity. There's the real rub. (Unless, of course, you disagree with this premise that connecting to a shared resource implies collective responsibility and risk which must be managed.)
We are at an uncomfortable spot right now in our seeking for a balance point. Our history is that we owned all the machines and therefore had full control of what was on them. Our security model and policies were developed in this rarified atmosphere. When we opened the network to student-owned machines, we didn't have everything in a state where we could comfortably give them the ability to install whatever they wanted while still keeping things secure. I am not sure such a state actually exists. (See Microsoft's 10 Immutable Laws of Security. Change "computer" to "network" and you have a glimpse of the reality of a network manager.) This year, students do not have access to the administrator account on their machines. (I can hear the gasps and screams from here.) That is the real issue Rick raised in his comment.
This causes no end of problems for students with legitimate need to install something, such as a printer driver. (Why Microsoft doesn't allow this function to be assigned to a non-administrative user is totally beyond me, but they don't.) Our solution for this year is to take the time to install what the students need or want for them. So far, beyond printers, all we have installed is iTunes and games. So much for educational needs.
From a security perspective, this policy has worked. It certainly doesn't mean less work for IT, but rather more as we have to install a lot of games. In my tenure here, we have never had a significant virus infection or, to my knowledge, security breach of any kind. We certainly have had students who have tried to install keyboard loggers and other mal-ware, but our policies cramped their style adequately.
The reality is, though, that this needs to change, and for reasons Rick and Scott raised. We are still working on the policy going forward, but our goal is going to be to find that delicate balance point that serves both usability and security. You haven't heard the last of this issue...
"scottygu3" made a comment in that discussion that is interesting: "IT goals are incompatible with user goals. It is a continuing give and take battle between the two." It is interesting to me in part because I disagree with it, but more because I think it demonstrates a perception problem we in IT have with regard to security. (Now, I must admit that the perception has arisen because so many IT guys have the same opinion. They don't call themselves "sysgods" for nothing. While I think the statement is inaccurate, scottygu3 is dead on in stating it.)
Rather than seeing the goal of securing the box and the network (the two are inseparable) as "IT" goals and as at odds with the users' needs for using the machine, a proper IT perspective is that we need to accommodate security and usability both while the negative impact of either on the other. If our goal in IT isn't to make the system serve the needs of the user, then we don't understand the field. The converse is true too, however. If the user doesn't understand that part of serving them is making and keeping the systems secure, either from maliciousness or simple misadventure (or foolishness) on their part, then they don't understand it either. Our job is to manage the interface between these disharmonious needs.
Inevitably, circumstances will arise where one or the other need gets short shrift. At Vermont Academy, many students feel it is their "right" to install anything they want on their computers. Now, I agree that everyone who owns a computer has the right to do with it what he will. Just don't connect the damn thing to my network if you do, OK? (There's that sysgod attitude...) Because they do need and want to connect the Tablets to our network, I feel justified in putting "right" in quotes above. By dint of connecting to a shared resource, where their actions will inevitably have impact on every other user, their rights are to some extent abrogated--of necessity. There's the real rub. (Unless, of course, you disagree with this premise that connecting to a shared resource implies collective responsibility and risk which must be managed.)
We are at an uncomfortable spot right now in our seeking for a balance point. Our history is that we owned all the machines and therefore had full control of what was on them. Our security model and policies were developed in this rarified atmosphere. When we opened the network to student-owned machines, we didn't have everything in a state where we could comfortably give them the ability to install whatever they wanted while still keeping things secure. I am not sure such a state actually exists. (See Microsoft's 10 Immutable Laws of Security. Change "computer" to "network" and you have a glimpse of the reality of a network manager.) This year, students do not have access to the administrator account on their machines. (I can hear the gasps and screams from here.) That is the real issue Rick raised in his comment.
This causes no end of problems for students with legitimate need to install something, such as a printer driver. (Why Microsoft doesn't allow this function to be assigned to a non-administrative user is totally beyond me, but they don't.) Our solution for this year is to take the time to install what the students need or want for them. So far, beyond printers, all we have installed is iTunes and games. So much for educational needs.
From a security perspective, this policy has worked. It certainly doesn't mean less work for IT, but rather more as we have to install a lot of games. In my tenure here, we have never had a significant virus infection or, to my knowledge, security breach of any kind. We certainly have had students who have tried to install keyboard loggers and other mal-ware, but our policies cramped their style adequately.
The reality is, though, that this needs to change, and for reasons Rick and Scott raised. We are still working on the policy going forward, but our goal is going to be to find that delicate balance point that serves both usability and security. You haven't heard the last of this issue...
posted by Mark Payton at 3:27 PM
4 Comments:
Greetings All, Secure and Not So Secure!
Mark is correct that security is indeed a big issue. I like to consider myself a “¬fallen sysgod” (the other ones are “the fallen” <g> -- with special emphasis on those in my district). That said, let’s kick around the idea security.
Earlier, I stated that “IT goals are incompatible to user goals.” That’s a strong statement and one that I should humbly modify to better reflect what I meant. It is my belief that IT’s security needs must be as unobtrusive, as transparent to the user as possible: that restrictions on what the user can do with his/her personal computer be minimal, as non-existent (as far as the user can tell) as they can be. Also, those restrictions that are made by IT need to be rational, and user concerns should be listened to. If IT cannot secure the network in as reasonable, as unobtrusive a manner as possible, they need to be fully prepared for all-out guerrilla warfare – that’s what’s going on currently in my district, and it’s just an “accident waiting to happen” IMHO.
Wow, that’s a very loaded paragraph!
Schools are very special places and are much like banks and hospitals in that they both contain computers and equipment that not everyone should have access to. I certainly wouldn’t want to be a patient in a hospital or have any major deposits in a bank where members of the general public have open (inside the firewall) access to the network.
And yet that is exactly what a school does when it allows students onto the same network that carries administrative information…when it places student computing inside the firewall. That is exactly the situation in our district: the student network and administrative network are one and the same. I worry. A lot. But I digress….
I think Mark is being pretty reasonable in his security measures by “locking up” the student’s pc’s while simultaneously being willing to take the time to install anything on them that the students reasonably want installed…very reasonable indeed! Hopefully, Vermont Academy is small enough that any backlog that this policy may cause is non-existent or negligible to the student users. If not, frustrated users will find a way around the roadblock that is preventing them from doing what they want. From what “slick rick” has said, it would seem that there is no noticeable backlog.. I don’t think that this a model that would work in a large, centrally administered district such as ours – although that’s pretty much how I ran our building network before our district IT took over.
I would like to see our district spend some money on separating the two networks physically, running the “student” network as if IT were an ISP and concentrating their skills on keeping an administrative network secure. Faculty members, because they will be using their computers to teach students, should have their computers on the student network and be should have to access any district administration services through the internet, passing through the firewall).
This is new ground for schools and I look forward to discussing this topic further! (so important that I'm writing this on Saturday!)
Thanks for the comments, Scott. You are right about our small size being an advantage with this policy. If we had 2000 students to support this way, it wouldn't be feasible. (Not with "reasonable" staffing levels, anyway.) Rick, by the way, has probably suffered more than any other student in getting an installation done in a timely fashion. Lot's of schedule conflicts...
I think you are right on with the need for security to be transparent (to the degree possible) and rational.
At one point I was working us toward two physically separate networks. We have enough fiber running to each building that we could keep student and faculty machines on entirely different wire. When we began to think about wireless, though, we saw a huge flaw to this way of thinking. After all, we couldn't as easily keep the airwaves separate.
Currently we are thinking about virtual networks with firewalls between them as a solution, but again we have some issues with that. An easy solution would be to assign VNs by MAC address, but then we aren't tied to the user, only to the machine. A student logging on to a faculty machine would be in the faculty network. Not good. We are still looking for a solution.
I am going to guess that not all of your machines are Windows 2000 or XP. We found that getting the last of the pre-2000 machines off our network eliminated a huge majority of our student-related security hassles.
Do your students own their machines or are they school-owned?
Mark
Mine is a public high school with about 1564 students (rainy days = more students; sunny days = fewer). Currently, we have 8 computer labs with 31 computers in each (all Win2K), one computer on every teacher’s desk (Win2K), an independent journalism lab (all OS/X iMacs), and some rooms with mini-networks (5-15 Win2K) machines… roughly 340 pc’s and 35 iMacs in all.
Unfortunately, your guess that we weren’t all Win2K is incorrect. However, all of our current network problems can be attributed to a rushed implementation of full Novell services district wide (100+ buildings) over the summer.
Before last summer, security wasn’t much of an issue… the only network we really had was the internet: no file services or anything fancy, just computers with a standard load of software.
[Lengthy section on how I maintained the computers in my school removed for brevity]
Then our district IT decided to implement full Novell services, eSIS (electronic student information system), and “security” on every computer in the district over the summer. #%^#@$%^@%!!!!
Let’s just say they didn’t ask the users any questions about how computers are used in the schools: they just “locked” them up tight (hence the “fallen” sysgods).
[Long diatribe detailing the failings of district IT removed for length]
Anyway, all of the computers are owned by our district. Teachers may use personal machines such as laptops and PDA’s on the network if they so desire (students may not).
- - - - -
I think you’re on the right track with VNs by MAC address: the faculty will just have to remember to maintain physical control of their machines at all times (biometric log in?). Any other solution will only be as good as where the forgetful teacher writes down his/her password (always fun to look on the bottom of the keyboard in my district).
The weakest link in security will always be human.
Well, I do see one major difference between our schools, Scott. We use AD on Windows Server 2003 machines. It gives us pretty tight control of security patches, user rights, and what not. We haven't had much problem with security as a result
We are still looking for good central control for AV and anti-spyware. The concensus seems to be building that Counterspy Enterprise is a solid, enterprise-ready product for AS, plus has one of the best records for catching things. It's on my list to evaluate. We use McAfee anti-virus and it is pretty well set-up, but had to be done by machine. Their e-policy orchestrator just didn't work for me.
I think one key reason our implementation was as successful as it has been (students may see if differently, but then they have very different goals) is that we live in the lab where much of their work gets done. Another is that all of us are or were teachers ourselves. Nothing beats good first-hand knowledge of real-world usage patterns to help set your security policies.
Another big factor in our success is our PacketShaper. It lets us block a lot of usage types that offer little of real benefit and lots of real risk. (e.g., p2p stuff).
Post a Comment
<< Home