Newsgroups: comp.sources.unix From: bbh@mtek.mtek.com (Bud Hovell) Subject: v25i139: policy V2 - tools for providing interactive timeshare policies, Part03/03 Sender: unix-sources-moderator@pa.dec.com Approved: vixie@pa.dec.com Submitted-By: bbh@mtek.mtek.com (Bud Hovell) Posting-Number: Volume 25, Issue 139 Archive-Name: policy/part03 Return-Path: oliveb!mtek!nosun.West.Sun.COM!bbh Received: by cognition.pa.dec.com; id AA04521; Tue, 25 Feb 92 06:53:25 -0800 Received: by uucp-gw-1.pa.dec.com; id AA09068; Tue, 25 Feb 92 06:53:14 -0800 Received: by oliveb.ATC.OLIVETTI.COM (smail2.5) id AA08062; 25 Feb 92 06:52:46 PST (Tue) Received: from Sun.COM (sun-barr) by sun.Eng.Sun.COM (4.1/SMI-4.1) id AA03211; Tue, 25 Feb 92 06:27:16 PST Received: from nosun.West.Sun.COM by Sun.COM (4.1/SMI-4.1) id AA12979; Tue, 25 Feb 92 06:27:00 PST Received: from mtek.UUCP by nosun.West.Sun.COM (4.1/SMI-4.1-900117) id AA00558; Tue, 25 Feb 92 06:26:51 PST Received: by mtek.mtek.com (Smail2.5+apb/mje900117) id AA10558; Tue, 25 Feb 92 04:07:34 PST Subject: Policy Package, part 3 of 3 To: vixie (Paul Vixie) Date: Tue, 25 Feb 92 4:07:30 PST Reply-To: policy@mtek.com X-Mailer: ELM [version 2.4dev PL52] Message-Id: <9202250407.AA10558@mtek.mtek.com> From: bbh@mtek.mtek.com (Bud Hovell) #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'misc/art.rt' <<'END_OF_FILE' X X X X - 1 - X X X X $Id: art.rt.N,v 5.3.2.5 91/09/03 09:55:27 policy USENET $ X X The following was first published in ROOT magazine, Volume X 1, Number 4 and 5 X X Copyright 1989 Bjorn Satdeva. X X Permission granted to distribute this article for nonprofit X purposes, as long as this header and copyright notice are X kept intact. X X On the Human Aspect of UNIX X System Management X X by Bjorn Satdeva X X Have you ever stopped for a moment, and thought about what X the job as system administrator really is about? Try to look X past the backups done last night, and the new user account X which was created this morning. What is the real purpose X behind the work which is done by the system administrator X every day? X X Traditionally, the system administration job is described in X terms of technology and programming. But the core of system X administration is really about something completely X different. It can actually be described with just three X letters: ``TLC''. Tender Loving Care. X X The work of a responsible system manager is to support the X users on his or her systems, to assist the management in X setting policies, and to help everybody to decide the future X needs of the site. All too often, a system administrator X will say that his job is to take care of such and such a X system. In my opinion, that is only a part of the truth. X X The real job is to care for a number of fellow human beings, X which in one way or another are dependent on the computer X system which the administrator has been entrusted to X maintain. And in this process, the UNIX system manager will X become known as a hard worker, always ready to do what is X necessary to keep the system running. Right? X X No. Wrong. Dead wrong! Unfortunately, in the world of X realities, this is not usually the case. The system manager X will only be visible to the world outside the computer room X when something goes wrong. In this context, the question is X how can he avoid being the guest of honor at the ``necktie X party'' which inevitably follows a major system crash? In X fact, there is a lot which can be done through establishing X a good rapport with both the management and user community X X X X X X X X X X X X - 2 - X X X X within the system manager's company. And good rapport X requires lots of ``TLC''. X X Some of the ways the UNIX system manager can provide this is X by always being ready to listen to and act on the problems X in the user community, and by clearly communicating X situations and requirements which may affect the operation X of the system to the company management. Last but certainly X not least, he must provide documentation. Not necessarily X documentation in technical terms, but rather easily X understandable and clear statements of the policies and X procedures which have been established to govern the site. X X Dealing With People X X The purpose of this article is to show some of the ways a X UNIX system manager can improve his relationships with both X the management and the user community at his site. It will X be presented in two sections. First, we will discuss the X system administrator's relationships with his management, X and then, in our second article, with the user community at X large. X X We will explore these relationships in this sequence, not X because the management is a more important factor than the X users, but because this is the sequence in which these X relationships must be established. Any attempt to build X strong relations to the user group of a system can easily be X undermined by a few negative management individuals. It is X therefore extremely important for company management to be X totally in alignment with the goals of the system X administrator. X X What follows is a story of how these solid human X relationships can be established. X X Linda is the UNIX system manager at Buildmore Technologies, X Inc. This company is, in many ways, a typical UNIX site. X It has a large number of UNIX systems which are used mostly X by the engineering departments, while other company X functions such as accounting, payroll, and word processing X are done on non-UNIX systems. X X Linda has the responsibility for the administration of the X UNIX systems. She has two system administrators and three X System Operators to do the daily work. Linda is reporting X to Dave, the MIS manager, who knows nothing about UNIX and X therefore, is totally dependent. X X Linda has only been with Buildmore Technologies, Inc. for a X few months. When she started, the UNIX systems were in a X X X X X X X X X X X X - 3 - X X X X state of extreme chaos with just a single system X administrator trying to keep the systems working. What he X was able to do could hardly be characterized as proper X ``administration''; fire fighting comes to mind as a much X better description. X X The situation was further aggravated because Dave considered X UNIX to be a maverick system which was hopeless to X administer, and many of the users were convinced that the X MIS UNIX support was the last place in the world they could X expect any real help with their system problems. X X This is the story behind some of the the things Linda did to X change the UNIX site at Buildmore Technologies from total X chaos to being a well administered and productive site. X X Analyze the Situation X X Linda very soon realized that if she was going to have any X kind of success in cleaning up the UNIX system problems at X Buildmore, she would definitely need the full support of her X MIS Manager, Dave. Therefore, she spent the first weeks in X her new position getting the situation in the Data Center X under some kind of control, and then quickly started X outlining some of the long term programs which had to be X undertaken to create a secure and properly administered X site. She immediately began presenting and communicating X those needs to Dave. X X Because Dave knew so little about UNIX, it was part of X Linda's responsibilities to inform and educate him about X what needed to be done at Buildmore Technologies, Inc. She X did that by writing a number of memos, outlining the X strengths and weaknesses of UNIX in a number of areas such X as backup and security. She further outlined some X suggestions and possible solutions in these areas. X X In just a few months, Linda and Dave were able to come to an X understanding and an agreement on the requirements for their X site, and a strategy for how the site should be administered X began to emerge. Linda began writing a number of documents X which, in an official manner, described how the UNIX site X would be run. The first document she wrote was a Site X Policy. X X Getting It In Writing X X Before we continue, perhaps we should define a ``Site X Policy''. The Site Policy is the ``Constitution'' for the X site. It must describe in general and nontechnical terms the X policies which both the system administrator and the users X X X X X X X X X X X X - 4 - X X X X must follow when using the equipment and software at the X site. X X It allows the top management to state the policies governing X the site in general terms, and provides the system X administrator with a platform upon which more specific X documents can be built. Remember, the purpose of this Site X Policy is not to establish a mindless bureaucracy, but to X create a foundation on which the UNIX system manager can X build the correct system administration guidelines. X X Linda's draft was written in exactly that manner. Here are X some of the topics it covered: X X +o Statement of purpose for the site X X A very general description of how backups should be X done. Linda decided that each machine should be backed X up fully once a week, and incrementally on a daily X basis. She also described how many generations of X backup would be kept, and what generation of backups X should be kept offsite. X X +o Knowing that site documentation and planning is very X important, but would take more time than she had for X her initial proposals, Linda requested that a Disaster X Recovery Plan and a Security Plan should be written as X soon as possible. She further stated that sufficient X documentation describing the daily operations of the X site be properly maintained. X X +o And finally, she described in general terms her X intentions to create a Security Plan for the site, X which included proper password protections, management X of dial-up lines, root permission access, and an X overall security audit. X X Because of the many constructive and well-planned memos, X meetings and discussions which Linda encouraged with Dave, X she was able to easily write the Site Policy and Dave was X able to have the CEO of Buildmore Technologies sign off on X the document after just a few minor changes to Linda's X original draft. Buildmore Technologies, Inc. now had an X official Site Policy in place for its UNIX machines, and X Linda could continue with the task of further improving the X administration, operation, and documentation of their UNIX X sites. X X Security Plan X X With the Site Policy in place, it was time for Linda to X X X X X X X X X X X X - 5 - X X X X start to work on the other documents which her original Site X Policy stated would be required for their system. This X definitely included the development of a well thought-out X Security Plan for their system. X X General system security had not been taken very seriously X before the Fall of 1988, when the Internet Worm crippled X hundred of UNIX systems and received a great deal of X publicity. Since that event, many sites began at least X paying lip service to the type of system security which X Linda knew to be essential to protecting their UNIX site. X X Linda knew that since Buildmore Technologies was connected X directly to both Internet and to UUCP, she would have to pay X special attention to security. A large amount of electronic X mail was exchanged over their system every day through these X connections. X X In her outline for the site security requirements, and how X it would be implemented in their ``Security Plan'', she X included some of the following important factors: X X +o All user accounts would be required to have a password, X and a user account would only be created after X receiving a written request from an authorized manager. X X +o All direct incoming modem lines were only allowed to be X used with UUCP. Dial-in access for employees would be X required to go through a data switch with callback X facilities, to insure that calls were originating only X from authorized locations. X X +o All systems would have an automatic security audit X program executed every night, and mail the results to X Linda for inspection. To achieve this, Linda was using X the security utility in UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm SSSSeeeeccccuuuurrrriiiittttyyyy (Kochan X and Wood). Although it did not do everything she X desired, it was still a very good beginning. X X +o Knowing that the question of who would be allowed X possession of the root password is a controversial one X at many sites, Linda was determined to create a X sensible and secure policy to manage root permissions X in her initial documents. In keeping with her sound X understanding of UNIX system fundamentals, she X determined only those key individuals who were X absolutely required to have root permission on their X system, and bypassed the inevitable random requests of X other users for root access as a matter of site and X company policy. X X X X X X X X X X X X X - 6 - X X X X Disasters Happen X X The last big piece of documentation Linda wrote was the X Disaster Recovery Plan. Before we actually look at the plan X which she proposed for Buildmore Technologies, Inc. a X general word about Disaster Plans is appropriate: X X Many UNIX users and managers think that only large X commercial sites need a Disaster Recovery Plan, because they X have high demands for immediate continuation of their data X processing after a disaster. X X However, even very small UNIX sites should have a Disaster X Recovery Plan. It need not be a solution with alternate X data centers or standby equipment, but every Unix system X manager needs to consider what they will do if they lose X essential parts of their equipment due to natural disaster, X fire, theft, or just plain failure. X X In creating this plan, it is often helpful to have everybody X at the site play a game of ``what if...?''. What if we lose X the root disk on our main file server? What happens if our X only tape drive fails, and we cannot restore any of our X backups for another week? And so on. X X The most important part of this exercise and in writing the X Disaster Plan, is to analyze the possible manners in which a X site can fail, and what realistically can be done to prevent X excessive loses and recover from that situation. All too X often, a site has no such prior planning in place. When a X disaster hits, and notice that I have used the word ``when'' X and not ``if'', a lot of time and money is wasted with X managers and technical personnel alike running around in X small circles like chickens without heads. X X Knowing that intelligent site management demands foresight X and prior planning, the Disaster Recovery Plan Linda wrote X for Buildmore Technologies required offsite storage of a X major part of their backup tapes (tapes were sent offsite X daily). And, it further required that a good quality X hardware maintenance contract on all important equipment be X secured with a reputable company. X X If a big disaster, like a major earthquake or a fire should X hit their site, Linda planned on purchasing new equipment X and installing a new site over a five month period. While X this solution was far from ideal, it was an acceptable X compromise between actual needs and the practical cost of X implementation. X X X X X X X X X X X X X X - 7 - X X X X The only piece of standby equipment she purchased X immediately was a hard disk, which was pre-formatted and had X the UNIX system files pre-installed on it. By taking this X relatively inexpensive precautionary step, if the root disk X on any of her file servers should fail, she could cut the X repair time of her system down to only three or four hours, X instead of one to nine days. X X Linda also knew that it is extremely important for every X UNIX system manager to write a weekly status report. This X document would serve a number of different and important X functions for her as System Administrator. Firstly, it was X a formal method to inform her manager, Dave, about progress X with ongoing projects, what tasks had been completed, and X what was needed for the system in the near future. She also X used the status report to convey any outstanding problems X which required solutions beyond the scope of her X responsibility. Any unresolved problem stayed on the status X report each week, until a satisfactory solution had been X found for it. X X In the beginning of her work with Buildmore Technologies, X Linda discovered that there was not a sufficient number of X tape drives on their UNIX system, and that it was impossible X to provide adequate backup coverage for their systems. She X listed this as a special and important problem on her weekly X status reports to Dave, but the top management of Buildmore X Technologies were reluctant to spend the large sum of money X which was necessary to implement a functional solution. X X When a huge disk drive was lost a couple of months later, X and there were no recent backups of that drive, Buildmore X Technologies suffered an estimated loss of over 800 hours of X engineering time. Because Linda had consistently turned in X her weekly status reports for the last two months stating X the existence of that situation and requesting funding for X additional tape drives, both she and Dave were in the clear X (some people call this site status reporting method ``CYA'', X an abbreviation which refers to covering a specific part of X the body which we will have to leave to the reader's X imagination!). X X Summary X X This concludes the first part of our story about Linda's X work with Buildmore Technologies, Inc. We have described X how she developed her relationships with management, X organized a well-documented plan for proper site management, X and did her professional best to protect the interests of X her company from the potential economic losses incurred from X system failures. X X X X X X X X X X X X - 8 - X X X X She did so by using a combination of two very important X principles: X X First, she exercised exceptionally good judgment in abiding X by the simple and sound principles of proper UNIX system X administration and site management. X X Second, and very importantly, she remembered that both X managers and system users are, after all, human beings. She X understood that fulfilling her technical responsibilities as X system administrator meant that she would have to X communicate her plans and the overall system requirements in X a manner which could be easily understood, accepted and X supported. X X In my next article, I will discuss some of the basic X requirements for establishing an equally strong rapport with X the users of a UNIX system. We will see how the same type X of rapport and clear communication of sound UNIX practices, X which Linda established with her management at Buildmore X Technologies, can be extended to the ``user community'' of X any UNIX site. X X Remember, a well managed UNIX system is a happy, secure, and X reliable UNIX system! See you next issue! X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X - 9 - X X X X The Human Aspect of UNIX System X Management (Part 2) X X by Bjorn Satdeva X X This is the second of two articles about some of the X human factors in UNIX system administration. In the last X article, I stated that traditionally system management is X seen as a technological task, while the real job is to care X for a number of fellow human beings. Based on this I showed X how Linda, a UNIX system manager at the imaginary site X Buildmore Technologies, created a good working relationship X with management. In this article, we will look at how a X similar good relationship can be built with the user X community. X X As I stated last issue, the work with management and the X work with the user community are not two unrelated X processes. Even though they have been described separately X in these two articles, they are very closely interconnected. X Many of the decisions Linda and Dave, the MIS manager, made X were based on input from the users. X X The important factor here is ``the users''. They are often X seen as a gray mass of disturbance. A system manager who is X able to remember that the users are individuals, each in X many ways dependent on the computer in their daily work, X will be able to create a better working environment for X everybody. Many system managers have ruined the reliability X and security of their sites by being unresponsive to their X users. When a system manager is not supporting his users, X then they will attempt to bypass him in order to get their X work done. The system manager has created an environment X where the security of the system is under constant attack X from users, and he is the one who is responsible for the X security violations, although indirectly. X X The method Linda used to establish rapport with the user X community was almost identical to the manner she used with X management. By keeping the users informed about the current X state of the systems, and being doubly sure to communicate X possible problems and scheduled downtime, she slowly created X an environment where the users were more understanding of X the occasional need for downtime or reorganization of the X systems. X X Linda found that most users are reasonable people. They X often accept even severe restrictions, if they have been X notified ahead of time, and it has been explained how and X why the new solution is for the good of the user community X at large. X X X X X X X X X X X X - 10 - X X X X Of course, Linda was not able to fulfill every user's X request. Whenever she was presented with a request which X could not be fulfilled, she always made sure to have a X meeting with the involved users to explain why the request X had to be rejected. At the same meeting she also presented X what she thought could be workable alternatives. In most X cases one or more of those alternatives was acceptable to X the users, but in cases where no alternative could be found, X she always made sure two things were done. First, she X finished the meeting with a suggestion that people should X contact their direct manager in order to have the problem X escalated in the management hierarchy, and she notified her X own manager about the situation. X X By doing so, she first of all ensured that the users felt X they had been heard. Through their manager, they felt they X had an avenue to continue pursuing their requests. By X notifying her own manager, she had given him a chance to be X able to support (or reject) her position. In many such X cases, the item of discussion involved purchase of more X expensive equipment, and the whole discussion had been X escalated to a higher level of management, where such X discussion belongs. In this way good relations with users X will most likely be kept intact. X X How To Say No Nicely X X Let's look at a few examples of the kind of requests Linda X got, where she could not provide the requested service. X X One day Joe User came to her office and asked for more disk X space on the system he was using. When she looked into the X request, she found that Joe already was occupying more than X 75 Mbyte of disk space, while the total sources for the X project he was working on only required 45 Mbyte. X Confronted with this, Joe explained that he was keeping X backup copies of his files, so he could go back to previous X versions. Linda's response was to teach Joe about SCCS X (Source Code Control System -Ed.), and showing him how he X could keep old releases without making a copy of the entire X source tree. Joe was satisfied, and Linda was able to X reclaim a significant amount of disk space. X X Another example is the day Jim Smart walked into her office, X and demanded to know the root password. Linda was able to X reject Jim's request on the spot, and expect to be backed up X by her manager, because Linda had written the Site Policy, X and had top management sign off on it. X X In all such cases, information, education and communication X proved to be essential. X X X X X X X X X X X X - 11 - X X X X Let UNIX Help You Manage X X UNIX provides a number of tools which help the system X manager or administrator communicate with the user X community. Most of these are well known and used at most X sites, but for completeness, let us see how Linda used these X tools. X X The classical method is of course email. One of the first X things Linda did was to establish a mail alias, ``all'', X which could be used to email all users about downtime, X changes, or other inconveniences. She wrote a small script X that ensured this alias always was automatically updated X from the password file, and therefore always representative X of the existing user community. For communication from the X users to the system administrators, she made a special X account, ``sysadmin'' which was forwarded to the operators. X X She also made it a policy that all messages sent out by X email should be reflected in the Message Of The Day file X (/etc/motd) and vice-versa. By making the information X redundant, she was able to reach more users, although few X users did log in on a regular basis, in the workstation X environment at Buildmore Technologies. X X A third method for communicating this kind of information is X found in UNIX System V with the news command. This command X allows the system administrator to maintain a number of X files with information about system status which is shown to X the users during login. Because Buildmore Technologies was X using mostly BSD-based workstations, Linda decided not to X use this facility on the few AT&T systems on the site (news X should not be confused with the Usenet news). X X Besides using these methods for communicating with the X users, Linda also circulated all the memos she wrote for X Dave (see the first article) to all the users, with requests X for comments. All the relevant feedback she got was worked X into the final documents. This worked especially well in X her case, as she was new to Buildmore Technologies. Lots of X information about previous decisions and configurations was X explained to her by engineers who had been at Buildmore for X years. As this information was documented nowhere other X than in the brains of those people, she was able to obtain X information which kept her from making several important X mistakes. X X Most important, Linda wanted to ensure that communications X with her users were working both ways. She therefore let X everybody know that she always was available for a chat X about problems or suggestions from the users, and many X X X X X X X X X X X X - 12 - X X X X potential problems were avoided or easily solved by such X informal meetings. It would not have been possible to run X the site without the framework Linda had put in place in the X form of policies and procedures, but none of these created X so much trust and rapport with the users as these meetings. X X Dealing With Humans Is Necessary X X By treating both managers and users as human beings, and by X establishing sound policies for the UNIX system management, X she was able to protect Buildmore Technologies from serious X system failures. Through establishing both functional X procedures for system management and establishing good X rapport with people using UNIX - whether manager or user - X she created effective feedback which helped her prevent most X of the problems seen in less well-run sites. X X The picture painted of Linda and Buildmore Technologies may X seem completely unrealistic to some readers, but skeptics X can be assured that these methods work. In the real world, X there are both incompetent managers and unreasonable users, X but a competent system manager can still create a well X administrate and well functioning site in spite of such X people. X X In addition to technical skills, the key to successful UNIX X system management is providing lots of ``TLC'' to users and X managers, and to remember that sometimes ``CYA'' can be X necessary. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X END_OF_FILE echo shar: 61 control characters may be missing from \"'misc/art.rt'\" if test 29944 -ne `wc -c <'misc/art.rt'`; then echo shar: \"'misc/art.rt'\" unpacked with wrong size! fi # end of 'misc/art.rt' fi if test -f 'misc/art.ur2' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'misc/art.ur2'\" else echo shar: Extracting \"'misc/art.ur2'\" \(15924 characters\) sed "s/^X//" >'misc/art.ur2' <<'END_OF_FILE' X X X X X X X X $Id: art.ur2.N,v 5.3.2.5 91/09/03 09:55:38 policy USENET $ X X Revised from "Famous Last Words", UNIX REVIEW, X July 1991 (Vol. 9, No. 7) X X X AAAA GGGGLLLLIIIIMMMMPPPPSSSSEEEE OOOOFFFF TTTTHHHHEEEE GGGGAAAALLLLLLLLOOOOWWWWSSSS X X by Bud Hovell X X X ``_A _g_l_i_m_p_s_e _o_f _t_h_e _g_a_l_l_o_w_s _h_a_s _a _m_a_r_v_e_l_o_u_s _w_a_y _o_f _f_o_c_u_s_s_i_n_g X _t_h_e _m_i_n_d.'' - Dr. Ben Johnson X X X IIIInnnnttttrrrroooodddduuuuccccttttiiiioooonnnn X X There is evidence of growing concern by administrators in X the UNIX community and elsewhere about how to achieve an X appropriate level of control over the local computing X environment through policy guidance. X X Indeed, policy is now becoming a hot topic. More adminis- X trators recognize increasing need to assure that users X (including themselves) will not subvert the organizational X mission or system integrity, violate basic minimum standards X of courtesy, privacy, and ethics, or inadvertently incur X criminal or civil liabilities. X X It is not true that ``people are no damn good'', and that X one must, therefore, check their tendency to intentional X diabolic mischief. There is no need to imprison users. X X But with a numerical expansion of ordinary login users and X an obscene abundance of eager lawyers, the preparation and X maintenance of carefully crafted policy eventually may X become a precondition for networking survival. (It may even X come to pass that some body of fundamental policy "stan- X dards" may be adopted in order to avoid the chaos of having X each organization gin up its own home-spun protocol, result- X ing in a crazy-quilt of policy definitions which mainly X differ only in choice of language.) X X The current trend seems certain to head us all into higher X levels of risk. Administrators who now express concern X about these growing risks may turn out to have been the X ``futurists''. X X X X X X X X X X X X X X X X - 2 - X X X X SSSSoooo WWWWhhhhaaaatttt''''ssss tttthhhheeee NNNNeeeewwwwssss???? X X A recent voluntary survey we conducted among system adminis- X trators and system managers on the uuuusssseeeennnneeeetttt drew returns from X nearly 300 respondents located at educational, commercial, X and other organizations. These locations serve some 100,000 X users, and most have more than a hundred users each. These X points emerge for immediate comment. X X Half of administrators and system managers say they have X held primary authority to define policies, and two-thirds X that they have been the primary enforcement authority -- and X will be so in the future. X X Allowing policy to be primarily defined by individual user X practices has been the historical case at one-third of X sites, but this will dramatically decline to only one-fifth X in the future. X X Verbal transmission of policy has been the dominant pattern X at half of all sites, historically, but will fall to only X one-quarter of sites. X X Fewer than ten percent of administrators identify upper X management decisions as the source of primary authority, X either for policy definition or for policy enforcement. And X they forecast only a faint upward trend. X X So there is some good news -- and some bad. X X TTTThhhheeee GGGGoooooooodddd NNNNeeeewwwwssss X X Evidently, allowing each user to ``do his own thing'' is X going to be a fading practice as time goes on, and the X majority of administrators will assert their own authority X to influence adoption of more formal definition and enforce- X ment of local policy. X X Administrators hold positions of trust by demonstrating both X technical knowledge and personal integrity. They must sup- X port the needs of users, while also fending off unwarranted X threats to the system itself. X X Also, administrators have the most intimate knowledge of X system (and user) behavior, and are thus able to offer X unique insight for the framing of effective written policy. X X They are also, therefore, the logical first persons for X users to turn to for expert guidance on policy interpreta- X tion and computer usage procedures. X X X X X X X X X X X X X - 3 - X X X X TTTThhhheeee BBBBaaaadddd NNNNeeeewwwwssss X X What should throw up a red flag to even the most casual X observer is the almost total lack of mention of top manage- X ment as the primary authority for either definition or X enforcement of how computer resources will be used. X X Top management members have no more valuable function than X to underwrite key policy decisions upon which everyone will X depend for effective, coordinated action. And this simply X doesn't appear to be happening for computer resource policy. X This creates a yawning chasm of uncertainty for everyone -- X and not least for the system administrator. X X The administrator may be the main agent for working with X users and supervisors to define and present the policy pro- X posal. But without top management as the approving and X enforcing authority, the adminstrator may be sailing in X treacherous waters, indeed: he or she should help forge and X operate the levers of policy, but should _n_e_v_e_r be pressed X into service as the ultimate fulcrum of authority. X X PPPPoooolllliiiiccccyyyy aaaannnndddd AAAAuuuutttthhhhoooorrrriiiittttyyyy X X It is often appropriate to delegate responsibility and X authority as far down into the organization as possible. But X top management is not then free to simply disappear; it must X still stand firmly and visibly behind those policies upon X which the organization relies to limit exposure to poten- X tially grievous mistakes that could be costly in a networked X environment. X X In a recent article, ``Policies for Appropriate Use of Net- X work and Computing Resources'', CERFnet News, May 1991 (Vol. X 3, No. 4), Brent Auernheimer points out: X X In addition to defining acceptable user behavior, poli- X cies provide a locus of action in which administrators X can operate confidently and that supervisors can justify. X X It is important that when incidents of inappropriate X behavior arise, system administrators have options avail- X able other than to immediately cut off accused users, or X to do nothing, allowing the possible misuse to continue. X X A well written policy is essential in making fair, defen- X sible decisions. X X When required to act, the administrator must have clearly X defined authority which only top management can legitimately X give. X X X X X X X X X X X X - 4 - X X X X It should be the administrator's first priority to gain this X authority by any ethical means. This may require dragging X the dark hearse of potential lawsuit through the legal X department and right up to the front door of the executive X offices -- or simply re-flavoring the dish to match the con- X temporary tastes of upper management (_s_e_e _N_o_t_e). X X Every reasonable measure should be taken by the administra- X tor to ensure his or her decisions will never be undercut by X someone higher up. One never knows for sure that top manage- X ment backing is solid until controversy actually presents X the acid test. ``Real'' policy is only what top management X will back to the hilt. X X The only thing more dreadful than no policy at all is having X one that deceives by offering a false promise of full sup- X port which falters in the breech. Policies which receive X public, written endorsement from top management rarely X suffer this fate. X X FFFFooooccccuuuussssssssiiiinnnngggg tttthhhheeee MMMMiiiinnnndddd X X When developing policy, one should keep a sharp eye on the X gallows. From a front-row seat, if possible. X X Writing effective policy is nothing less than the dead- X serious business of formulating strategies to successfully X cheat the hangman at every turn. Right now, it appears that X most of what exists for a guide is legal and lay speculation X -- but few tangible court rulings. X X Now, I'm no lawyer (and will never play one on TV), so when X I hear that there is a significant new area of law about X which even the courts haven't really spoken, I become only X mildly tuned in to the discussion. But when I realize that X my company could conceivably be invited to help define that X new law in the form of an unappetizing lawsuit where no one X has even a vague notion of what the outcome will be, then my X thoughts become more sober. X X Such concern should not be lightly dismissed: juries come in X with some pretty weird findings these days. And lawyers get X their reputations not only by winning, but by being credited X with defining "new law", invariably at someone else's X expense. X X It may be reasonable to assume that any organization operat- X ing today in a networked environment probably is exposed to X some sort of workable claim which might be troublesome to X resolve under threat of suit. Someone will eventually be X nominated to be "it" in this game of legal blindmans-bluff. X X X X X X X X X X X X - 5 - X X X X One would wish to ward off an invitation to the platform to X share in this dubious honor. X X DDDDooooddddggggiiiinnnngggg tttthhhheeee NNNNoooooooosssseeee X X Since the courts offer little valuable guidance about how to X safely proceed in an internetworked environment, the best X available substitute may well be the experience of the X administrator, expressed within written policies which top X management is willing to endorse. (Competent legal review X wouldn't hurt either, but don't make the mistake of turning X over the main task to your lawyer: he'll want to write it X for court, and you must be sure it's written, instead, for X people.) X X Indeed, the very best available defense under fire may prove X to be formal, well-advertised policy which preexists any X claim by a user that his rights were grievously violated as X the consequence of transactions and behaviors between per- X sons in a multi-user environment (for which management might X be held liable). X X Management, according to its particular mission, has the X duty of asserting adequate policy control over how owned X resources shall be used. Failure to publically articulate X such policy before a claim arises may be tantamount to X pleading ``no contest''. X X PPPPllllaaaaiiiinnnn JJJJuuuussssttttiiiicccceeee X X Ultimately, the motivation and rational for publishing X comprehensive and appropriate policy has less to do with X fear of brutish court proceedings and much more to do with X fundamental human courtesy and plain, simple justice. X X Providing sound, thoughtful policies for the users in an X organization is not just a nice thing to do. It's the X responsible thing to do. X X No real substitute exists for letting people know, right up X front, what is really expected of them. Putting it in a con- X cise form that is forthright and unambiguous helps defeat X private interpretation, which invariably rushes to fill a X vacuum. It is then absolutely reasonable to expect users to X fully live up to it. The vast majority will do so with a X willing sense of responsibility and no complaints. X X X X X X X X X X X X X X X X X - 6 - X X X X [ NOTE ] X X PPPPoooolllliiiiccccyyyy IIIIssss QQQQuuuuaaaalllliiiittttyyyy X X The administrative staff at the Midget-Widget Manufacturing X Company recently received the following missive from the MIS X Manager: ``_I_n_c_r_e_m_e_n_t_a_l _b_a_c_k_u_p_s _o_f _a_l_l _u_s_e_r _f_i_l_e_s _w_i_l_l _b_e X _p_e_r_f_o_r_m_e_d _b_y _t_h_e _o_n-_d_u_t_y _a_d_m_i_n_i_s_t_r_a_t_o_r _b_e_g_i_n_n_i_n_g _a_t _1_1 _p_m X _e_a_c_h _d_a_y, _e_x_c_e_p_t _t_h_a_t _o_n _F_r_i_d_a_y _i_t _w_i_l_l _b_e _a _f_u_l_l _b_a_c_k_u_p.'' X X System administrators now have a very specific procedure X about what actions must be taken, when, and by whom. But X what the administrator staff never saw was this previously- X written policy directive to the MIS Manager from the General X Manager at Midget-Widget: ``_A_l_l _l_o_c_a_l _c_o_m_p_u_t_e_r_s _m_u_s_t _b_e X _b_a_c_k_e_d _u_p _a_t _a _f_r_e_q_u_e_n_c_y _t_o _e_n_s_u_r_e _t_h_a_t _a_n_y _s_y_s_t_e_m _f_a_i_l_u_r_e, X _n_a_t_u_r_a_l _d_i_s_a_s_t_e_r, _o_r _o_t_h_e_r _c_a_l_a_m_i_t_y _w_i_l_l _n_e_v_e_r _r_e_s_u_l_t _i_n X _m_o_r_e _t_h_a_n _e_i_g_h_t _h_o_u_r_s _l_o_s_t _w_o_r_k-_p_r_o_d_u_c_t _f_o_r _a_n_y _l_o_g_i_n X _u_s_e_r.'' Notice that the General Manager has defined his X policy in terms of a specific, measurable outcome -- that X lost work-product for any user may never exceed eight hours. X Now we can fully understand the standard the MIS Manager is X trying to meet in the procedure that he has written for his X own staff. X X Regrettably, the procedure must be rejected. The Human X Resources Manager tells us that there is a new programmer X just hired who will begin working four 10-hour days each X week so that he can have more time to visit his sick mother X in San Pedro. Also, Midget-Widget has extraordinarily dedi- X cated users who routinely stay an hour or so late to finish X up their work. X X So the the MIS Manager must now redesign his procedure to X handle all known exceptions. Or negotiate with the General X Manager to change the stated standard. X X With an outcome-oriented policy in place, weighing the suf- X ficiency and appropriateness of procedure becomes a much X simpler task, and helps make solid quality-enhancement of X the user environment an achievable goal. Though top X managers may not always support strong ``policy'', they may X stand in line to sign up for what you present as ``qual- X ity''! X X [ Author Bio ] X X Bud Hovell is a productivity and project management special- X ist with MMMMTTTTEEEEKKKK IIIInnnntttteeeerrrrnnnnaaaattttiiiioooonnnnaaaallll,,,, IIIInnnncccc.... X X X X X X X X X X END_OF_FILE echo shar: 881 control characters may be missing from \"'misc/art.ur2'\" if test 15924 -ne `wc -c <'misc/art.ur2'`; then echo shar: \"'misc/art.ur2'\" unpacked with wrong size! fi # end of 'misc/art.ur2' fi echo shar: End of archive 3 \(of 3\). cp /dev/null ark3isdone MISSING="" for I in 1 2 3 ; do if test ! -f ark${I}isdone ; then MISSING="${MISSING} ${I}" fi done if test "${MISSING}" = "" ; then echo You have unpacked all 3 archives. echo "'This is usenet version 5.3.2.5 of 91/09/03.'" rm -f ark[1-9]isdone else echo You still need to unpack the following archives: echo " " ${MISSING} fi ## End of shell archive. exit 0 -- Bud Hovell _______________ policy@mtek.com