marchany@vtserf.cc.vt.edu (Randy Marchany) (05/28/91)
The Internet Engineering Task Force (IETF) has a security policy working group that is devising a handbook that contains guidelines for aiding sysadmins is creating a usage policy for their individual sites. It is available via anonymous FTP from cert.sei.cmu.edu under the /pub/ssphwg directory. It is a DRAFT copy but still is quite useful as a guide. Another resource for DEC users is the Security SIG of DECUS. They have offered a series of talks in the past 2 DECUSs and they serve to increase a sysadmins awareness of protection from unauthorized use in today's networked environment. There are a few things to keep in mind. A workable policy requires 3 major steps. First, someone HAS to write the policy. This is usually left up to the sysadmin. In an environment where there are a number of networked machines (university, branches/divisions of a company, etc), then ALL of the sysadmins should get together and agree on a policy statement. This is not as difficult as it sounds because nobody wants their system to be misused. The sysadmins should devise the policy because while mgt may be aware of the problem, chances are they tend to operate in a reactive mode rather than a preventive mode. The policy statement need not be complicated. A simple statement to the effect of "our computers must not be used in violation of international, national, state, local laws". The important thing is that this policy statement be WRITTEN down somewhere. The draft policy should be reviewed by the site's legal counsel. It is NOT our job to be "wanna-be lawyers". After legal review, it should then be presented to mgt for approval. The most effective argument to ensure consideration of the policy is that of liability. Is a site liable for misuse of its computing resources if there is not policy statement regarding their use? Second, the user community needs to be educated on the policy as well as ethical and responsible use. This involves creating a series of "Statement" papers on subjects such as responsible userid access, etc. These statements should be more specific than the general policy statement. For instance, they should refer to the state laws on computer abuse AND the penalties mentioned in those statutes. Again, the local sysadmin group should draft the document(s). How do we implement this "education"? Some suggestions are 1) orientation sessions for users 2) training your local user consulting groups 3) training your upper mgt. Remember, the whole purpose of this is NOT to create a Big Brother atmosphere, rather, it is to EDUCATE your user community on RESPONSIBLE behavior. This really isn't that hard to do since most of us already have an inherent sense of what is responsible use. The users should sign a form (approved by your site legal counsel) acknowledging that they understand and agree to abide by the policy. You, as a sysadmin need to go the extra mile to ensure user NOTIFICATION of the policy and the signed form is proof that the user was notified. Third, I mentioned in an earlier post that setting up the policy structure is like insurance. You never think about it until you have to. If a "violation" occurs at your site, you should have a plan in place on how to deal with it. Everybody has fire drill plans, etc., this is no different. I summarize this section from the IETF Draft policy handbook. 1. Define what your goals/objectives are in handling the incident -Examples: protect human life, protect sensitive data, prevent damage to systems/equipment, prevent disruption of service. 2. Evaluation. - Is the violation real? This requires the sysadmin to have a "feel" for what is "normal" system use. - What is the scope of the "violation"? Is it multi-site? Is sensitive information involved? What is the entry point of the incident (phone lines, network, etc.) 3. Notification. - Who do you notify of an incident? How do you notify them (email, phone, fax, etc.)? Who do you notify DURING the incident and AFTER the incident? People such as sysadmins, administration, law enforcement, CERT should be on your list. - Public Relations? Keeping your site public relations office informed may need to be considered. 4. Response. - Contain the incident. - Eradicate the cause. - Recover from the incident - Follow-up. Do a post-mortem analysis. What happened and when? How well did we deal with the incident. Were the appropriate staff elements (sysadmins, user consulting groups, mgt) informed? - KEEP A DETAILED LOG OF THE INCIDENT HANDLING!!!! - Keep the evidence in a SECURE place. 5. Legal/Investigative. - Establish contacts with investigative agencies. The reason for this is that things happen quickly during an incident and is little time to determine who to call. If the incident is serious enough to go to court, you need to know HOW TO GATHER ADMISSIBLE EVIDENCE!!!! Otherwise, your efforts are useless. - Your site legal counsel should be involved in any decision to contact outside law enforcement agencies. Hopefully, your legal counsel was involved in the drafting of your site policy statement, so you've already esatblished a contact there. It is IMPERATIVE that your legal counsel review your steps for Incident Handling BEFORE you actually carry out these procs. It does seem like a lot of work but it really is a "one-shot". You'll spend a lot of time to do this once but then it's in place for a long period of time. Periodic reviews of the procedures will not take a lot of time to do. Again, I stress that we shouldn't drift off course in our discussions. -Randy Marchany Internet: marchany@vtserf.cc.vt.edu