Handbook of Local Area Networks, 1998 Edition:LAN Security Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next SITE SECURITY POLICIES Before implementing any security tools, software, or hardware, you must have some sort of site security plan. The plan may be short and sweet or long and involved, but having such a plan is essential. When setting out to develop your site security plan, you must consider a number of different factors. First, what is it you are trying to protect? Second, what you are protecting it from? Finally, how much of a threat is there? After you have determined your risks and exposures, you can then create a site security plan. Once your plan is in place you must make sure that it does not become static; it should be reviewed frequently and modified where appropriate. Determining what you are protecting should be a fairly straight-forward process; public-domain information mirrored on your Web server is not as much of an exposure as your corporate and client records on the LAN server. You must then examine your environment to determine what you are protecting your network from. In days past the norm was to have a large centralized computer locked away in a computer center. Dumb terminals were connected to that large computer, so you just had to be concerned with the security of a single system, usually in a single room. In addition, there were few connections to sites outside of your own. In today’s world of distributed computing, things are quite different. In most cases there is no longer just one machine to protect (although servers are often co-located in a just a few areas) and with the success of the Internet, many sites now have access to the world outside of their network. When examining your site to determine the level of threat and possible exposure, one place to start is with the physical risks. Is your building secure? Are the rooms where you store your most vital equipment secure? Do you have locks on the doors or can anyone walk into those rooms? Are the systems themselves protected? Are the keyboards locked? Do you need a password before you can extract or change any information? Intertwined with your examination of your network is the idea of risk analysis. You must determine the risks of a security breach and a cost-effective way to address those risks. You must make sure that what you are protecting is worth the amount of money that you will be spending to protect it. If, for example, a security breach would mean a possible loss of life (such as hospital life support systems or a 911 service) then that site should invest more into their security than an office that can tolerate some possible down time while the situation is addressed. Once you have determined what you need to protect and the level of protection that you need, you can create a site security policy. One important aspect in this process is to have the backing of upper management. If you establish a thorough, well thought out policy that no one follows and that you cannot enforce, you are no better off than having no policy at all. By having a buy-in from management, you will have more support in exercising the policies. In addition, there must be a consequence for users that do not follow the policies; otherwise, the policy document becomes an option which users will choose to follow or not — mostly not. It may be prudent to include a member of management in the policy making team. Request for Comments (RFC) 1244 is a site security handbook, an excellent place to start when developing a site security policy. This RFC provides guidance to site administrators on how to deal with security issues on the Internet. The guidelines for a plan, however, can be used even in the absence of a connection to any public network. One of the many reasons to create a site security policy is so that when you are in the middle of a security emergency, you have one source to go to which spells out what actions you should take; the middle of a crisis is hardly the ideal time to be making policy decisions. Having policies set forth ahead of time will ensure that the proper actions are taken in a timely fashion, and is particularly useful if the site manager is not around when the problem occurs. Additional reasons for having a policy on hand is that users know the acceptable use policies for network resources, users know what role they can play in protecting everyone’s information assets, and customers can see that you are serious about protecting their information. Issues ranging from allowing users to share accounts to whether they can attempt to break into other accounts or other networks should be addressed in the plan. You may want to include information about the appropriate use of copyrighted or licensed material. Without written policies, it will be more difficult to take action against a user who has performed an act that you deem contrary to the acceptable use of the resources. The consequence of a user’s violation of the security policies should be clearly spelled out in your document. If a security breach does occur, your document should spell out who must be contacted. Depending on the severity of the incident, law enforcement officials and the press may become involved. The interaction with these organizations and others should be addressed in your plan. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.