Whether you have a large facility or a small facility, you should have computer use policies in place. Such policies are useful to administrators and users alike.
Lack of written policies leaves your facility open to poor decisionmaking in the name of expediency. If you've just discovered that one of your users is using your machines for trading illegal copies of software in violation of copyright law, what do you do? Remove her account and hand her over to the authorities? Delete the files and do nothing else? Warn her never to do it again? If the user is the son of the chairman of your department, does your decision change? If you have a well thought-out acceptable-use policy, the decision will be clear, and the action clearly prescribed.
Written policies additionally serve as "recipes" to be followed in times of crisis. In the event of a security breach of your site, who is in charge? Does the system administrator sitting at the console who sees a break-in happening have the authority to shut the system down? Or is her head going to be on the chopping-block in front of users whose "important work" was more important (to them) than the security of the system at large? Does the apprentice system administrator sitting at the console who observes a break-in in progress even know what to do in a crisis, and is he going to remember how to do it all properly? A written policy that provides a recipe to follow in case of an emergency and gives the administrator-du-jour the authority to act covers both these bases.
Written policies should be in place and available for review by both users and administrators alike. Policies should detail what users can expect from administrators, what administrators can expect from users, and yes, even what administrators can expect from administrators. You should have policies detailing the following:
User account request procedures
Acceptable use guidelines for the facility
Acceptable use guidelines for your network
Response procedures for security problems
Administrator rights and responsibilities
Mission statement and budgetary policy
For a facility with individual user accounts, you need a user-account application form that solicits enough information for you to verify the users' identities and to track them down if you need to find them while they are away from the system. (Keep in mind that using a user's Social Security number for identification purposes is against the law in some circumstances, though you will find many corporations that use a copy of the SSN as an ID number as well.) This form should include as much contact information as possible. Address and phone number are a must. Possibly require the name and signature of the user's supervisor if you're running a business facility, or a secondary contact if your environment is something more like a library. I also find it useful to include some space on the form for administrative comments and data that I need to have on hand when I create the accounts. Include your "Users who cause trouble get in trouble" policy statement right on the form, so that there's no question what they're getting themselves into by applying for an account.
The second thing to keep in mind when creating your system's policies is generating some acceptable use guidelines for your facility. You need a detailed document that gives guidelines for acceptable and unacceptable user behavior. You need to evolve this policy over time as you encounter new problems and situations that need to be documented. At a minimum, your acceptable use policy should detail all the reasons you can think of that would make you want to take drastic actions such as deleting a user's account. You'll obviously want this to include things such as conducting illegal activities, but you may want to include things such as sharing passwords, or reading other users' files without permission as well. If you can think of any situation in which a user should be denied access for an action, it's best if you codify that in the rules and adhere to the decision with any users that transgress. You should give a copy of your acceptable use policy to every user that has an account, and to any user who requests an account. Make certain that users have a paper copy available, even if you also have an online copy.
You also need to consider what the acceptable use guidelines will be for your network. These guidelines may or may not be considered part of your facility's acceptable use guidelines. Largely, this depends on whether users can install their own machines on the network. Requirements that you should consider include such things as disallowing cracking attempts against the facility, or unauthorized sniffing of traffic on the network. Additionally, the person responsible for machine security should be granted physical access to any machines on her network segment. You don't want to put the person in charge of security emergencies in the position of needing a fireaxe to get to your machine when she's been called out of bed at 3:00 a.m. to deal with a remote break-in that is being perpetrated by your hardware.
When compiling your network's policies, keep in mind what your response procedure will be for security problems. In addition to the obvious procedural document ("press this button, shut down that machine, yank that cable"), you need documented personnel procedures. Who is responsible for acting in response to security problems? Who has the authority to detail this response? If these are not the same person at your site, you are in for a nightmare of administration problems. Upper-level management often wants to assign some "director"-level manager to be the person with the authority to make decisions in a security crisis. This is often a bad idea; frequently the "director"-type isn't available when a crisis hits, or isn't even a system administrator. Waiting to find and procure authority for something like an emergency shutdown can cause extensive damage to user files, and long periods of downtime to make repairs . Don't allow the separation of the person with the responsibility from the authority to act. Generally, you want the person with hands closest to the keyboard to have complete authority to act quickly and decisively. Requiring the person with hands on the keyboard to track down a manager-type before executing an emergency halt in response to a break-in is very similar to requiring a pilot to get authorization from the navigator before turning the plane to avoid an imminent crash.
The best possible policy is one that gives the administrator closest to the machines absolute dictatorial control in an emergency, and requires her to immediately notify all senior (in experience) administrators available. The procedure for transfer of authority to the most senior administrator (and who this is should be detailed on paper as well) available should also be detailed: The last thing you need in a real security crisis is confusion over who is calling the shots.
Your network policies should, of course, include guidelines for user responsibilities. When granted an account at your facility the user should automatically be expected to assume certain responsibilities. Among these are responsibilities such as keeping the password secure and cooperating with other users who need to use the machines. Even though some of these ideas will seem like common sense, you need to spell them out for your users. Things such as keeping passwords private might not sound like a serious responsibility, and it's one that many users might be inclined to ignore. However, you need that policy on a piece of paper because you will eventually have the user who doesn't believe password loaning is a serious problem. He will lend it to a friend who then uses it to try to crack your root password. A written policy lets you demonstrate to the irresponsible user just how serious a problem it was.
When your policy addresses user responsibilities, it also must address user rights. Along with the responsibilities users assume when using your machines, they also get some rights. Certain rights depend on the purpose of your site, such as the right to put up Web pages if your site's purpose is as a Web server. Others are rights that you need to define for the smooth running of your site, and tend to run along the lines of enforced common courtesy ”such as the right to equal usage of the system (no tying up all the machines with one user's processes). Finally there are the legal rights that the users have, like the right to the privacy of their files and electronic communications. You should detail these in a policy document as well.
Although users have standard rights and responsibilities, at most places administrators don't have many rights, and they have many undocumented responsibilities. Take the time to work out some detailed documents regarding administrators' rights and responsibilities. Include things like "We don't make house calls," and "If you bought it without asking us if it would work, we reserve the right not to fix it."
Who watches the watchers? Administrators need administration too. Who makes decisions about granting administrative access? Are there "limited" administrative accounts and who can use them? What limitations are there on the administrator's authority? All these are decisions better committed to paper than to memory.
Network policies should also include a mission statement and budgetary section. You'll be hard pressed to run a facility well if you don't have a written statement of what it's there for. A defined budget allows you to make intelligent purchasing decisions and to decide when and where you can "splurge" on improvements. At a minimum a defined budget should include money for any salaries you need to pay, software licenses your facility needs, and funds for hardware maintenance and any consumables you may have. You should keep in mind that hardware is in fact a consumable and that machines that are the cat's pajamas today will be barely viable antiques in three years . A reasonable budget must include money for replacing machines as they become performance liabilities, rotating them out and putting new machines in on a regular basis.
Depending on the type of facility you have, you should also consider policies and procedure documents concerning the following:
Your first login ”getting started . Include information on how to log in, responsibilities of the user, how to set a password, and how to get help. It's okay if you don't detail all their rights here, but you want a document that both sets their boundaries and provides them the help they need to get started.
Account creation and deletion procedures . How do you create and delete accounts at your site? What logging procedures do you use? Where do you put the accounts? Who gets notified? and so on. Creating accounts isn't a very interesting or difficult task, but it will run more smoothly if there's a written recipe to be followed.
Shutdown and downtime notification procedures . What sort of notice do you give your users when you're about to shut the machines down? How do you go about notifying them? It's downright rude (though sometimes necessary) to simply halt a machine under a user who's working at it. You should detail scheduled and unscheduled downtime notification procedures and do your best to stick to them. Users may not like having to work around a scheduled shutdown, but they'll like it a lot less if you take a machine down while they're in the process of doing real work. If you have to shut a machine down without advance notice, have a policy that states under what circumstances and how this is to be done, and how users are to be communicated to regarding the event.
Acceptable passwords . Users are notoriously bad at choosing good passwords. Help them out by explaining the differences between a good password and a bad password. Make it a policy that users are held responsible for the security of their passwords, and then actually hold them to it. You don't need the security problems inherent in having a user who just cannot pay attention to rules and will not choose and maintain passwords securely. In addition, administrators who are highly concerned about passwords on other Unix flavors have frequently installed "improved" password software with features such as password aging, prevention of the use of commonly guessed password patterns, prevention of reuse of old passwords, and so on. We aren't aware of replacements of this nature being available for OS X at this time. We also aren't certain of the merits of software that encourages a user to write down his password because nothing vaguely recognizable is "secure enough" for the system. Still, if you're interested in the ultimate in password security and control, this is something to keep an eye out for.
Administrative staff responsiveness . Users will want a policy that says that administrators must jump at their every whim, but administrators will want a policy that gives them more control. You've no reason to give your users less service than you are capable of, but it often seems that providing virtually instant service only inspires users to demand actually instant service, and to take offense when service cannot be provided instantly. Because there are many instances when you have a real need to delay response to some user issue ”such as when you need time to study the impact that complying with that request many have on other system resources ”it's often a better idea for policies to have a built-in delay. If you get things done faster than policy indicates, you make your users happy, and if you really need the time to address an issue, you'll have it available to do the work, instead of spending it answering constant questions about why you aren't finished.
Software installation requests . As you'll read many times throughout this book, a sure route to disaster is installing software that you don't know the entire function of. Unfortunately , if you're supporting a system for users who have divergent software needs, it's almost inevitable that they'll end up asking for software that you don't know, and that you won't be able to thoroughly test. It's a tough position to be in, but if you're there to support their needs, and they need the software, you've little choice but to provide it for them. Avoid rush installs , and consider using a sacrificial machine for software that's truly untested and that has no track record. Try to strike a reasonable balance on software requests and handle them in a fair way that still allows you the ability to make certain that the software is properly installed and isn't a risk to the system. A user who bullies a system administrator into installing a security hole is not unheard of in the business.
Hardware installation requests . Hardware installation requests can be a nightmare, especially if it's some specialty piece of hardware with which administrators have no experience, but that the user has purchased and with which he absolutely needs support. A policy that requires administrative staff preapprove any purchase before hardware will be supported is a good idea; otherwise , your facility's administrators could end up spending time on one user's needs and neglecting the needs of many others.
Backup procedures . Backing up the system can eat a significant amount of time. Outline a backup procedure and stick to it. After you have the backup procedure outlined, inform your users so that they know the safeguards they can expect, as well as the limitations that have been placed on their data security.
Restore from backup requests . To avoid the potential problem of your facility's administrators' work being regularly interrupted to restore lost data for users who accidentally deleted their data, create a policy on restoring data. Maybe restoring data should be done once a week or only after 5:00 p.m.
Guest access . Occasionally users will request that guests be allowed to use the system temporarily. How you handle this is entirely up to you and the purpose of your facility. If you're running a high-security lab for a research project, you probably want to have a "no guests, ever" policy. On the other hand, if you're running a university teaching lab, there's no real reason that you shouldn't make guest access available so that students can show friends and family all the fun things they're doing. Whatever your policy, put it down on paper so your users don't get the impression that you're arbitrarily deciding whether their requests should be granted.
When writing policies, state in plain English what the rules are. Don't obfuscate the issue by making vague references to activities you wish to prohibit; state them plainly. A policy that says "Users will attempt to keep their passwords secret" is much weaker, and much more difficult to enforce than one that says "Users will not write down or otherwise record or divulge their passwords."
When making rules, it's crucial that you state the results of not following the rules. A policy that says "The system administrator on call will immediately inform the lead administrator in the event of a break-in" is almost useless. If you examine the part of the policy "will immediately inform the lead administrator," you should ask yourself "Or what? What happens if they don't?" A policy with no teeth is almost useless as a policy.
State acceptable practices in terms of hard and fast rules, not personal judgement. A policy that says "Users will not attach personal Unix machines to the building network unless the network administrator judges the machine to be secure" leaves the security of the machine up to conjecture on the part of the network administrator. A devious user could configure her machine to appear to be secure, thereby passing the "judgment" test, while in fact it remains insecure . Much better would be wording to the effect "unless the machine adheres to security guidelines as defined by the network administrator."
If your machine or machines are connected to the Internet, and they are intended for Internet access, remember that the Internet is the great intellectual equalizer, and one of the truly great examples of freedom in action. This is kind of a "warm and fuzzy" policy comment ”unless you've a good reason to be draconically restrictive , it's probably a good idea for your policies to stand for open-mindedness and tolerance. A large part of what makes the Internet a great place is the free exchange of ideas. You will undoubtedly have users with whom you have deep philosophical disagreements . If part of your mission is providing Internet connectivity for your users, it's not your place to make judgments regarding their philosophies, skin color , sexual proclivities, or favorite sport. If you're providing Web services for something like a college research lab, and you allow users to place some personal material on the Web, you really need to allow them to place any (legal) personal material on the Web. Of course, you can make it subject to disk-space or bandwidth constraints. Before you decide that this means that you shouldn't allow any personal material, you need to keep in mind that what makes the Web such a useful tool, and such a neat place, is people who make useful things available. If the usage isn't affecting your other users' business or research use of the network or machines, what reason is there for you to not let your users give something back to the Web community? They might not all have the most brilliant or useful Web pages, but remember that if you write policy that bans one, you need to ban them all. And if you ban them all, that might mean banning the one person who really would make a valuable contribution back to the community. Don't let the "importance" of your site's mission get in the way of the benefits of letting users express themselves creatively.
And finally, remember that all policies you have must be understood by both administrators and users. They must be enforced fairly and consistently.
READ THIS PARAGRAPH ”READ IT WELL! Never never NEVER! write policy that indicates that you will enforce any sort of censorship or up-front control over your users' activities. Policies that state that you will react appropriately if informed of inappropriate or illegal actions on the part of your users are fine. Policies that even hint that you will attempt to prevent such activities can automatically make you liable for their enforcement.
For example, you may be concerned that your users might make use of your system to illegally pirate software. Writing a policy that states "To prevent piracy, any software placed on the FTP site will be checked by the administration" makes the administration potentially liable for any commercial software that is discovered there. You might not like that fact, but that's the way lawyers work the law, and system administrators who claim to monitor their user's activities have been successfully sued as a result of those activities. You're much safer if you write a policy that states "We do not condone software piracy and will cooperate fully with the authorities in investigations resulting from illegal software found on the FTP site."
Write your policy so that you react to complaints regarding your users' behavior. If you should be the one to notice that behavior, so be it, but do not write policy that indicates that you will attempt to preemptively monitor and prevent the activity. This goes for FTP sites, Web sites, and any other data your users own or activities they perform.
Here's an annotated copy of a network and security policy that is similar to the one we use at our site, The Ohio State University College of Biological Sciences. Following each section of the policy are italicized comments on why that respective section of the policy was written in that particular fashion. This should give you some ideas for building a policy suitable for your situation.
Guidelines for System Security Requirements
Users wishing to make use of corporate computing resources or network resources agree to have, read, and understand the following:
A breach of system or network security is any attempt to connect to, view data on, or otherwise access or utilize computing resources without authorization. This includes, but is not limited to: use of computer facilities or network facilities without an account or authorization, accessing files belonging to other users without the written consent of said user, and use of facilities by authorized persons for purposes outside the intent of the authorization. An action that causes a breach of system or network security constitutes a direct violation of corporate computing security policy. Employees found to have willfully violated corporate computing security policies will be remanded to corporate disciplinary affairs.
This is rather draconian, but covers the entire gamut of using others' passwords, trying to break into the system, dangling personal computers off the corporate network, and otherwise causing trouble. We don't get to define disciplinary action such as terminating employment, unfortunately .
Account security on the facility Unix machines is the responsibility of the account holder. Passwords are not to be shared. Passwords are not to be written down or otherwise recorded. Loaning of passwords to other users will be considered a direct breach of system security and additionally will be considered grounds for immediate revocation of your account. Discovery of recorded copies of passwords will also be considered a direct breach of system security and dealt with in the same manner.
We take password security seriously; you should, too. You would not believe the number of times I find scraps of paper with user IDs and passwords sitting next to machines.
Non-Unix Machines Attached to the Building Network
Execution of system-crashing or system- compromising software such as (but not limited to) "Win-nuke" and "Nestea," or propagation of viruses, worms such as "Sircam," or Trojan horse applications such as "Nimda," constitutes grounds for removal of a system from the building network. Intentional execution of such software constitutes electronic vandalism and/or theft of service, and subjects the person executing the software to potential legal liability. Users can be assured that facility staff will provide any assistance necessary to track and prosecute anyone found to be conducting such attacks.
There is a whole genre of "crash a PC" programs out there that won't actually crash Unix machines, but that can make life annoyingly slow, and make network connections unstable for Unix users. Users on your network shouldn't be allowed to run this software against either PCs or Unix hardware. Users caught doing this should be punished ”we remove their systems from the network wholesale. Users caught doing this to remote sites are likely to have remote site administrators calling and threatening legal action. Users may think it's all fun and games , especially if you're providing support for a college facility, but the person whose computer crashes and who loses a research grant as a result isn't going to think it's so funny .
Collection of network traffic that is not destined for the user and the machine in use (via, but not limited to, such methods as packet sniffing or ARP spoofing) constitutes grounds for removal of a system from the building network. Collection of network traffic without court authorization or a direct and immediate need to diagnose network problems constitutes execution of an illegal wiretap. Users should be comfortable that their data and electronic transactions are secure against eavesdropping.
Suffice it to say, unless you've got a policy in place that says all data on the system may be monitored at any time, anyone caught monitoring network traffic that isn't intended for him could be in deep trouble ”including you!
Additionally, users can be assured that facility staff will not intercept network traffic without legal authorization or an immediate need to diagnose an existing network problem.
Always a good idea to tell users what their rights are as well, and the right to privacy is an important one. Users need to feel comfortable that they are not going to be "found out" if they discuss an unpopular opinion with a co-worker, or fear reprisals for the content of personal information kept on the system.
Execution of port-scanning software, or other software that attempts to discern or determine vulnerabilities in Unix or non-Unix hardware without facility staff approval will not be tolerated. Execution of such software will be considered an attempt to breach system security and will be dealt with as such.
There is a lot of software out there that's freely available, and which any user can run, which nonetheless they should be strongly discouraged from running. Among this software is a subset which searches for vulnerabilities in Unix hosts . Depending on your environment, you may or may not want to treat running this software as a direct attack on your machines.
Users will not run FTP, HTTP, or other data servers that provide illegal data (commercial software, or other illegal data types). The facility staff cannot and will not attempt to police the building network for such behavior, but reports of copyright infringement or other illegal behavior will be forwarded to the appropriate authorities.
Notice that we explicitly claim that we won't monitor the network for this type of usage. If someone reports it, we'll certainly act, but we don't want the legal liability that even trying to monitor for it would bring.
Users will not run software designed to provide unintended gateways into services that are intended to have a limited scope. Depending on the service and the manner in which the service is gatewayed to unintended users, execution of such software may constitute theft of service. The facility staff cannot and will not attempt to police the network for the execution of such software, but will cooperate fully in any investigations brought by users whose services have been compromised.
Again, note that we explicitly refuse to monitor for this sort of activity. The legal status of some of this software is questionable, and we don't want mixed up in legal troubles. If somebody comes to us with a problem, we deal with it.
Execution of software similar in purpose to any of the software detailed in the "Non-Unix" section will be dealt with in the same manner as detailed above, and/or users' accounts will be terminated without recourse.
Execution of password-cracking software against the computational facility password database will be considered an attempt to breach system security and will be dealt with as such.
Notice that we prohibit only attempts on the facility password database. This may seem a little peculiar, but proactively, we're really concerned only with our facility's security. If a user tries to actually break in to some other machine, then she'll be violating a law and we have something on which we can take action. Until she does something like that, she's only behaving questionably, and we get back to the "don't go looking for trouble" idea. If we claimed that we'd prohibit anyone from trying to crack any password file on our machines, we'd instantly be liable for letting the one we didn't notice get away with it.
Now if we notice one of our users trying to crack someone else's password file, we're likely to tell that someone else, and we're also likely to very pointedly glare at the back of the user's head until he gets so self-conscious that he stops, but we're not about to put it in policy that we're going to prevent him from doing it. Too many cans of worms to go near there.
Users wishing to install Unix machines on the building network can do this in two ways.
Because this policy was designed for a college computing environment, it's important to address that we allow users to connect both "lab owned" and personal machines to the network. Personally owned Unix machines have been a big problem, especially the Linux variant, in that lots of people know how to put the CD-ROM in the drive, but very few know how to manage the machines after they're up and running. Unfortunately, some Linux versions have shipped with just about the world's largest collection of security holes, all wrapped up neatly in one box. The end result is that if you let a poorly administrated Linux machine on your network, you've essentially invited the entire world to come watch all your network traffic and to probe your machines from inside your network.
Machines that are considered by the computational facility System Manager to be of general use and interest to the facility at large, may, at the discretion of the System Manager, be allowed to be set up as part of the facility. Machines handled in this fashion will be administered by the facility staff as full peers in the facility Unix cluster, and system security will be handled through the facility staff. Machines administered in this fashion remain the property of their respective owners and are to be considered primarily intended for the use of their owners. As full peers of the facility Unix cluster they may be used by other facility users (at least remotely) when they are not fully utilized by their owners .
We've found it productive to grow our facility resources by offering administrative services in exchange for allowing general facility use of the hardware. This seems to be a productive arrangement for other groups around campus as well. Some go so far as to have an arrangement whereby anybody interested in buying hardware gives their money to their computational facility staff. The staff then seeks out other users interested in the same type of hardware, pools all the money it can find and provides a far better machine to be shared than any of the "investors" could have afforded individually.
If you decide to go this route, make certain that you have discretionary control over what hardware you'll take on as part of your facility and what you won't. Although we said "avoid personal judgment as part of the policy" earlier, here, you really want to be able to avoid taking on that 16-year-old clunker that someone dragged out of a dumpster and now thinks is going to be just the ticket for their archive server. It seems near impossible to write a policy that covers allowing everything you'd want to allow, and disallows everything you'd want to disallow, so personal judgment will have to do here.
Security for these machines will be handled in the same manner as security for all computational facility Unix cluster machines. Users can be assured that all reasonable security precautions have been taken, and that known potential security problems will be dealt with in a timely fashion.
Should a security violation occur involving one of these machines, it will be dealt with by the computational facility staff and should not require significant time or effort from the owner of the machine.
The users taking this route to machine acquisition and maintenance need to know that they're getting something out of the deal as well. Putting this down in writing also helps when you need to point out to the occasional problem user what the costs and benefits of "working with you" are.
Machines that are to be administered by their owners or their owners' assignees will be maintained at a level of security at a minimum in compliance with the requirements in this document and with security guidelines as defined by the computational facility staff.
Notice how it "requires compliance with security guidelines," rather than something like "requires acceptable security." Don't get caught with wording that's easy to misinterpret, either accidentally or deliberately. Notice also that the guidelines are defined by the facility staff. The "System Manager" referenced a few items earlier isn't actually a Unix administrator at our facility; he's an overall director-type. So he is not the best person to define acceptable administration guidelines for Unix machines. We wanted to keep this flexible enough so that the staff who actually had the experience to define the guidelines could do the job without having users complaining that "person X doesn't have the authority to tell us we can't "
Violations of policy laid down in this document are to be dealt with as defined in this document. Requirements for account maintenance and termination will be strictly enforced.
Administration security guidelines will be based upon current security problems as reported by corporate network security and the online security community. These guidelines will be provided by the computational facility staff on a set of Web pages dedicated to building network security. It is expected that administrators will bring their machines into compliance with the guidelines within seven (7) days of the guidelines being posted.
The guidelines referenced here are things like: Shut off all those $@%@#@#$% services that Linux starts automatically. No outside-accessible accounts for nonemployees. Install security patches when CERT (or the alert site/sites of your preference) publishes information on them. And anything else that happens to be pertinent at the time.
Also, seven days is probably too long a period to allow for securing against new-found threats, as these things make their way around the Internet amazingly quickly. We've had whole clusters of machines hit within 24 hours of the power being turned on here at OSU. If you can get away with being more strict with this, you probably should.
Computational Facility staff will keep a database of independently administrated Unix hardware and administrators and the administrators will be notified immediately when guidelines are updated.
It wouldn't be very fair to the administrators if we didn't make some attempt to notify them when we discover something they need to update.
Periodic scans of the building network for known security problems will be conducted by computational facility staff. Results will be made available to administrators of self-administrated machines as soon as the data is available. Facility machines will be protected against any vulnerabilities found by facility staff. Independently administered machines will be brought into compliance by their respective administrators. Failure to bring a machine into compliance will result in the machine being removed from the building network.
No, we're not scanning for security violations here, but for security holes. If a new way to break in to the sendmail service is discovered, we want to know whether any of our users are running vulnerable versions, and we want them to fix it if they are.
Because of the normal speed of network security breaches, the potential for rapid damage during a break-in, and the fact that most security problems occur during off hours, the following access abilities are necessary for computational facility staff:
Computational facility staff may require physical access to any computing or network hardware in the building at any time. To facilitate such, master-keys for access will be kept in a sealed package in the facility safe. Access to these keys will be logged, justification will be given for using them, and the party whose area requires access will be notified immediately upon opening this sealed package.
You absolutely need a way to get to any computing hardware that's attached to a network for which you have any responsibility. If there is a security problem and the owner of a machine is not available, somebody needs to be able to get to the machine and stop the problem. If you don't have a key, get a fire axe. I'm serious. If a machine under your control is actively being used to cause damage to someone else's system, and you've got a choice between breaking a $250 door, or allowing the machine to do possibly untold amounts of damage, what are you going to do?
Computational facility staff may require administrative access to any computing hardware on the same network at any time. To facilitate such, administrators of independent machines will provide the computational facility staff with root or other appropriate administrative passwords, to be kept sealed unless needed in a crisis. Independent administrators will keep these passwords up to date at all times. Access to these passwords will be logged, justification will be given for using them, and appropriate administrators will be notified immediately should use of these sealed passwords be required.
See previous rationale. Also notice that both here and previously, if access is required to hardware without the user's presence, we've put on paper that we will log the usage and notify immediately. Users need to feel secure that their offices and machines won't be invaded needlessly. They're reluctant enough to provide for this type of access, but it's one of the costs of being on the network for them. One of the costs of accessing their machines is a lot of paperwork and apologizing for you, but it will help keep you honest.
Responsibility and authority for maintenance of security guidelines and for definition of, and action upon, network security threats lies with the computational facility System Manager. In the case that the System Manager is not, or is unavailable to be, administrating the facility Unix cluster, the responsibility and authority pass to the facility Unix cluster Lead System Administrator. Facility assistant administration staff have the authority to deal with immediate crisis situations as necessary until the Lead System Administrator can be contacted.
Our higher-ups here require that the "System Manager" be at the top of the chain of command. This isn't an ideal situation in an emergency, because he isn't a Unix administrator, and he's just going to call the Lead anyway. Therefore we've worded this policy in such a fashion that he'll almost never actually be the person who has to call the shots, yet he retains the authority to do so if he needs to.
Our facility has one real full-time administrator and a number of assistant administrative staff (students) who are available on odd schedules. The assistant administrators have the authority, in the absence of the Lead System Administrator, to deal with any security issues that arise. This, as mentioned previously, is a trust issue. So they're students ”so what? They've proven themselves trustworthy, and are trusted completely and implicitly whenever they're logged in as root. If we weren't certain we could trust them and their judgment, we wouldn't have given them the root password in the first place. They're also trusted, within the bounds of facility-defined policy, to make responsible decisions regarding the necessity for actions regarding system security.