x3 发表于 2003-8-25 19:46:09

RFC2196

<br><br><br><br><br>Network Working Group                                    B. Fraser<br>Request for Comments: 2196                                    Editor<br>FYI: 8                                                       SEI/CMU<br>Obsoletes: 1244                                       September 1997<br>Category: Informational<br><br><br>                         Site Security Handbook<br><br><br>Status of this Memo<br><br>   This memo provides information for the Internet community.It does<br>   not specify an Internet standard of any kind.Distribution of this<br>   memo is unlimited.<br><br>Abstract<br><br>   This handbook is a guide to developing computer security policies and<br>   procedures for sites that have systems on the Internet.The purpose<br>   of this handbook is to provide practical guidance to administrators<br>   trying to secure their information and services.The subjects<br>   covered include policy content and formation, a broad range of<br>   technical system and network security topics, and security incident<br>   response.<br><br><br>Table of Contents<br><br>1.   Introduction....................................................2<br>1.1Purpose of this Work............................................3<br>1.2Audience........................................................3<br>1.3Definitions.....................................................3<br>1.4Related Work....................................................4<br>1.5Basic Approach..................................................4<br>1.6Risk Assessment.................................................5<br>2.   Security Policies...............................................6<br>2.1What is a Security Policy and Why Have One?.....................6<br>2.2What Makes a Good Security Policy?..............................9<br>

x3 发表于 2003-8-25 19:47:00

2.3Keeping the Policy Flexible..................................... 11<br>3.   Architecture.................................................... 11<br>3.1Objectives...................................................... 11<br>3.2Network and Service Configuration............................... 14<br>3.3Firewalls....................................................... 20<br>4.   Security Services and Procedures................................ 24<br>4.1Authentication.................................................. 24<br>4.2Confidentiality................................................. 28<br>4.3Integrity....................................................... 28<br><br><br><br>Fraser, Ed.                Informational                        <br> <br>

x3 发表于 2003-8-25 19:47:30

RFC 2196            Site Security Handbook            September 1997<br><br><br>4.4Authorization................................................... 29<br>4.5Access.......................................................... 30<br>4.6Auditing........................................................ 34<br>4.7Securing Backups................................................ 37<br>5.   Security Incident Handling...................................... 37<br>5.1Preparing and Planning for Incident Handling.................... 39<br>5.2Notification and Points of Contact.............................. 42<br>5.3Identifying an Incident......................................... 50<br>5.4Handling an Incident............................................ 52<br>5.5Aftermath of an Incident........................................ 58<br>5.6Responsibilities................................................ 59<br>6.   Ongoing Activities.............................................. 60<br>7.   Tools and Locations............................................. 60<br>8.   Mailing Lists and Other Resources............................... 62<br>9.   References...................................................... 64<br><br>1.Introduction<br><br>   This document provides guidance to system and network administrators<br>   on how to address security issues within the Internet community.It<br>   builds on the foundation provided in RFC 1244 and is the collective<br>   work of a number of contributing authors. Those authors include:<br>   Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee<br>   (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net),<br>   Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser<br>   (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman<br>   (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus-<br>   Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone<br>   (lorna@staff.singnet.com.sg), Edward.P.Lewis<br>   (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com),<br>   Russ Mundy (mundy@tis.com), Philip J. Nesser<br>   (pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey<br>   (msr@interpath.net).<br><br>   In addition to the principle writers, a number of reviewers provided<br>   valuable comments. Those reviewers include: Eric Luiijf<br>   (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak<br>   (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl).<br><br>   A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook,<br>

x3 发表于 2003-8-25 19:48:34

CICnet, for their vision, leadership, and effort in the creation of<br>   the first version of this handbook. It is the working group's sincere<br>   hope that this version will be as helpful to the community as the<br>   earlier one was.<br><br><br><br><br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>1.1Purpose of This Work<br><br>   This handbook is a guide to setting computer security policies and<br>   procedures for sites that have systems on the Internet (however, the<br>   information provided should also be useful to sites not yet connected<br>   to the Internet).This guide lists issues and factors that a site<br>   must consider when setting their own policies.It makes a number of<br>   recommendations and provides discussions of relevant areas.<br><br>   This guide is only a framework for setting security policies and<br>   procedures.In order to have an effective set of policies and<br>   procedures, a site will have to make many decisions, gain agreement,<br>   and then communicate and implement these policies.<br><br>1.2Audience<br><br>   The audience for this document are system and network administrators,<br>   and decision makers (typically &quot;middle management&quot;) at sites.For<br>   brevity, we will use the term &quot;administrator&quot; throughout this<br>   document to refer to system and network administrators.<br><br>   This document is not directed at programmers or those trying to<br>   create secure programs or systems.The focus of this document is on<br>   the policies and procedures that need to be in place to support the<br>   technical security features that a site may be implementing.<br><br>   The primary audience for this work are sites that are members of the<br>   Internet community.However, this document should be useful to any<br>   site that allows communication with other sites.As a general guide<br>   to security policies, this document may also be useful to sites with<br>   isolated systems.<br><br>1.3Definitions<br><br>   For the purposes of this guide, a &quot;site&quot; is any organization that<br>   owns computers or network-related resources. These resources may<br>   include host computers that users use, routers, terminal servers, PCs<br>   or other devices that have access to the Internet.A site may be an<br>   end user of Internet services or a service provider such as a mid-<br>   level network.However, most of the focus of this guide is on those<br>   end users of Internet services.We assume that the site has the<br>   ability to set policies and procedures for itself with the<br>   concurrence and support from those who actually own the resources. It<br>   will be assumed that sites that are parts of larger organizations<br>   will know when they need to consult, collaborate, or take<br>   recommendations from, the larger entity.<br><br><br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>   The &quot;Internet&quot; is a collection of thousands of networks linked by a<br>   common set of technical protocols which make it possible for users of<br>   any one of the networks to communicate with, or use the services<br>   located on, any of the other networks (FYI4, RFC 1594).<br><br>   The term &quot;administrator&quot; is used to cover all those people who are<br>   responsible for the day-to-day operation of system and network<br>   resources.This may be a number of individuals or an organization.<br><br>   The term &quot;security administrator&quot; is used to cover all those people<br>   who are responsible for the security of information and information<br>   technology.At some sites this function may be combined with<br>   administrator (above); at others, this will be a separate position.<br><br>   The term &quot;decision maker&quot; refers to those people at a site who set or<br>   approve policy.These are often (but not always) the people who own<br>   the resources.<br><br>1.4Related Work<br><br>   The Site Security Handbook Working Group is working on a User's Guide<br>   to Internet Security. It will provide practical guidance to end users<br>   to help them protect their information and the resources they use.<br><br>1.5Basic Approach<br><br>   This guide is written to provide basic guidance in developing a<br>   security plan for your site.One generally accepted approach to<br>   follow is suggested by Fites, et. al. and includes the<br>   following steps:<br><br>   (1)Identify what you are trying to protect.<br>   (2)Determine what you are trying to protect it from.<br>   (3)Determine how likely the threats are.<br>   (4)Implement measures which will protect your assets in a cost-<br>      effective manner.<br>   (5)Review the process continuously and make improvements each time<br>      a weakness is found.<br><br>   Most of this document is focused on item 4 above, but the other steps<br>   cannot be avoided if an effective plan is to be established at your<br>   site.One old truism in security is that the cost of protecting<br>   yourself against a threat should be less than the cost of recovering<br>   if the threat were to strike you.Cost in this context should be<br>   remembered to include losses expressed in real currency, reputation,<br>   trustworthiness, and other less obvious measures.Without reasonable<br>   knowledge of what you are protecting and what the likely threats are,<br>   following this rule could be difficult.<br><br>

x3 发表于 2003-8-25 19:49:55

1.6Risk Assessment<br><br>1.6.1General Discussion<br><br>   One of the most important reasons for creating a computer security<br>   policy is to ensure that efforts spent on security yield cost<br>   effective benefits.Although this may seem obvious, it is possible<br>   to be mislead about where the effort is needed.As an example, there<br>   is a great deal of publicity about intruders on computers systems;<br>   yet most surveys of computer security show that, for most<br>   organizations, the actual loss from &quot;insiders&quot; is much greater.<br><br>   Risk analysis involves determining what you need to protect, what you<br>   need to protect it from, and how to protect it.It is the process of<br>   examining all of your risks, then ranking those risks by level of<br>   severity.This process involves making cost-effective decisions on<br>   what you want to protect.As mentioned above, you should probably<br>   not spend more to protect something than it is actually worth.<br><br>   A full treatment of risk analysis is outside the scope of this<br>   document. and provide introductions to<br>   this topic.However, there are two elements of a risk analysis that<br>   will be briefly covered in the next two sections:<br><br>   (1) Identifying the assets<br>   (2) Identifying the threats<br><br>   For each asset, the basic goals of security are availability,<br>   confidentiality, and integrity.Each threat should be examined with<br>   an eye to how the threat could affect these areas.<br><br>1.6.2Identifying the Assets<br><br>   One step in a risk analysis is to identify all the things that need<br>   to be protected.Some things are obvious, like valuable proprietary<br>   information, intellectual property, and all the various pieces of<br>   hardware; but, some are overlooked, such as the people who actually<br>   use the systems. The essential point is to list all things that could<br>   be affected by a security problem.<br><br>   One list of categories is suggested by Pfleeger ; this<br>   list is adapted from that source:<br><br>   (1)Hardware: CPUs, boards, keyboards, terminals,<br>      workstations, personal computers, printers, disk<br>      drives, communication lines, terminal servers, routers.<br><br><br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>   (2)Software: source programs, object programs,<br>      utilities, diagnostic programs, operating systems,<br>      communication programs.<br><br>   (3)Data: during execution, stored on-line, archived off-line,<br>      backups, audit logs, databases, in transit over<br>      communication media.<br><br>   (4)People: users, administrators, hardware maintainers.<br><br>   (5)Documentation: on programs, hardware, systems, local<br>      administrative procedures.<br><br>   (6)Supplies: paper, forms, ribbons, magnetic media.<br><br>1.6.3Identifying the Threats<br><br>   Once the assets requiring protection are identified, it is necessary<br>   to identify threats to those assets.The threats can then be<br>   examined to determine what potential for loss exists.It helps to<br>   consider from what threats you are trying to protect your assets.<br>   The following are classic threats that should be considered.<br>   Depending on your site, there will be more specific threats that<br>   should be identified and addressed.<br><br>   (1)Unauthorized access to resources and/or information<br>   (2)Unintented and/or unauthorized Disclosure of information<br>   (3)Denial of service<br><br>2.Security Policies<br><br>   Throughout this document there will be many references to policies.<br>   Often these references will include recommendations for specific<br>   policies. Rather than repeat guidance in how to create and<br>   communicate such a policy, the reader should apply the advice<br>   presented in this chapter when developing any policy recommended<br>   later in this book.<br><br>2.1What is a Security Policy and Why Have One?<br><br>   The security-related decisions you make, or fail to make, as<br>   administrator largely determines how secure or insecure your network<br>   is, how much functionality your network offers, and how easy your<br>   network is to use.However, you cannot make good decisions about<br>   security without first determining what your security goals are.<br>   Until you determine what your security goals are, you cannot make<br>   effective use of any collection of security tools because you simply<br>   will not know what to check for and what restrictions to impose.<br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>   For example, your goals will probably be very different from the<br>   goals of a product vendor.Vendors are trying to make configuration<br>   and operation of their products as simple as possible, which implies<br>   that the default configurations will often be as open (i.e.,<br>   insecure) as possible.While this does make it easier to install new<br>   products, it also leaves access to those systems, and other systems<br>   through them, open to any user who wanders by.<br><br>   Your goals will be largely determined by the following key tradeoffs:<br><br>   (1)services offered versus security provided -<br>      Each service offered to users carries its own security risks.<br>      For some services the risk outweighs the benefit of the service<br>      and the administrator may choose to eliminate the service rather<br>      than try to secure it.<br><br>   (2)ease of use versus security -<br>      The easiest system to use would allow access to any user and<br>      require no passwords; that is, there would be no security.<br>      Requiring passwords makes the system a little less convenient,<br>      but more secure.Requiring device-generated one-time passwords<br>      makes the system even more difficult to use, but much more<br>      secure.<br><br>   (3)cost of security versus risk of loss -<br>      There are many different costs to security: monetary (i.e., the<br>      cost of purchasing security hardware and software like firewalls<br>      and one-time password generators), performance (i.e., encryption<br>      and decryption take time), and ease of use (as mentioned above).<br>      There are also many levels of risk: loss of privacy (i.e., the<br>      reading of information by unauthorized individuals), loss of<br>      data (i.e., the corruption or erasure of information), and the<br>      loss of service (e.g., the filling of data storage space, usage<br>      of computational resources, and denial of network access).Each<br>      type of cost must be weighed against each type of loss.<br><br><br>   Your goals should be communicated to all users, operations staff, and<br>   managers through a set of security rules, called a &quot;security policy.&quot;<br>   We are using this term, rather than the narrower &quot;computer security<br>   policy&quot; since the scope includes all types of information technology<br>   and the information stored and manipulated by the technology.<br><br>2.1.1Definition of a Security Policy<br><br>   A security policy is a formal statement of the rules by which people<br>   who are given access to an organization's technology and information<br>   assets must abide.<br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>2.1.2Purposes of a Security Policy<br><br>   The main purpose of a security policy is to inform users, staff and<br>   managers of their obligatory requirements for protecting technology<br>   and information assets.The policy should specify the mechanisms<br>   through which these requirements can be met.Another purpose is to<br>   provide a baseline from which to acquire, configure and audit<br>   computer systems and networks for compliance with the policy.<br>   Therefore an attempt to use a set of security tools in the absence of<br>   at least an implied security policy is meaningless.<br><br>   An Appropriate Use Policy (AUP) may also be part of a security<br>   policy.It should spell out what users shall and shall not do on the<br>   various components of the system, including the type of traffic<br>   allowed on the networks.The AUP should be as explicit as possible<br>   to avoid ambiguity or misunderstanding.For example, an AUP might<br>   list any prohibited USENET newsgroups. (Note: Appropriate Use Policy<br>   is referred to as Acceptable Use Policy by some sites.)<br><br>2.1.3Who Should be Involved When Forming Policy?<br><br>   In order for a security policy to be appropriate and effective, it<br>   needs to have the acceptance and support of all levels of employees<br>   within the organization.It is especially important that corporate<br>   management fully support the security policy process otherwise there<br>   is little chance that they will have the intended impact.The<br>   following is a list of individuals who should be involved in the<br>   creation and review of security policy documents:<br><br>   (1)site security administrator<br>   (2)information technology technical staff (e.g., staff from<br>      computing center)<br>   (3)administrators of large user groups within the organization<br>      (e.g., business divisions, computer science department within a<br>      university, etc.)<br>   (4)security incident response team<br>   (5)representatives of the user groups affected by the security<br>      policy<br>   (6)responsible management<br>   (7)legal counsel (if appropriate)<br><br>   The list above is representative of many organizations, but is not<br>   necessarily comprehensive.The idea is to bring in representation<br>   from key stakeholders, management who have budget and policy<br>   authority, technical staff who know what can and cannot be supported,<br>   and legal counsel who know the legal ramifications of various policy<br><br><br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>   choices.In some organizations, it may be appropriate to include EDP<br>   audit personnel.Involving this group is important if resulting<br>   policy statements are to reach the broadest possible acceptance.It<br>   is also relevant to mention that the role of legal counsel will also<br>   vary from country to country.<br><br>2.2What Makes a Good Security Policy?<br><br>   The characteristics of a good security policy are:<br><br>   (1)It must be implementable through system administration<br>      procedures, publishing of acceptable use guidelines, or other<br>      appropriate methods.<br><br>   (2)It must be enforcible with security tools, where appropriate,<br>      and with sanctions, where actual prevention is not technically<br>      feasible.<br><br>   (3)It must clearly define the areas of responsibility for the<br>      users, administrators, and management.<br><br>   The components of a good security policy include:<br><br>   (1)Computer Technology Purchasing Guidelines which specify<br>      required, or preferred, security features.These should<br>      supplement existing purchasing policies and guidelines.<br><br>   (2)A Privacy Policy which defines reasonable expectations of<br>      privacy regarding such issues as monitoring of electronic mail,<br>      logging of keystrokes, and access to users' files.<br><br>   (3)An Access Policy which defines access rights and privileges to<br>      protect assets from loss or disclosure by specifying acceptable<br>      use guidelines for users, operations staff, and management.It<br>      should provide guidelines for external connections, data<br>      communications, connecting devices to a network, and adding new<br>      software to systems.It should also specify any required<br>      notification messages (e.g., connect messages should provide<br>      warnings about authorized usage and line monitoring, and not<br>      simply say &quot;Welcome&quot;).<br><br>   (4)An Accountability Policy which defines the responsibilities of<br>      users, operations staff, and management.It should specify an<br>      audit capability, and provide incident handling guidelines<br>      (i.e., what to do and who to contact if a possible intrusion is<br>      detected).<br><br><br><br><br><br>Fraser, Ed.                Informational                        <br> <br><br>RFC 2196            Site Security Handbook            September 1997<br><br><br>   (5)An Authentication Policy which establishes trust through an<br>      effective password policy, and by setting guidelines for remote<br>      location authentication and the use of authentication devices<br>      (e.g., one-time passwords and the devices that generate them).<br><br>   (6)An Availability statement which sets users' expectations for the<br>      availability of resources.It should address redundancy and<br>      recovery issues, as well as specify operating hours and<br>      maintenance down-time periods.It should also include contact<br>      information for reporting system and network failures.<br><br>   (7)An Information Technology System & Network Maintenance Policy<br>      which describes how both internal and external maintenance<br>      people are allowed to handle and access technology. One<br>      important topic to be addressed here is whether remote<br>      maintenance is allowed and how such access is controlled.<br>      Another area for consideration here is outsourcing and how it is<br>      managed.<br><br>   (8)A Violations Reporting Policy that indicates which types of<br>      violations (e.g., privacy and security, internal and external)<br>      must be reported and to whom the reports are made.A non-<br>      threatening atmosphere and the possibility of anonymous<br>      reporting will result in a greater probability that a violation<br>      will be reported if it is detected.<br><br>   (9)Supporting Information which provides users, staff, and<br>      management with contact information for each type of policy<br>      violation; guidelines on how to handle outside queries about a<br>      security incident, or information which may be considered<br>      confidential or proprietary; and cross-references to security<br>      procedures and related information, such as company policies and<br>      governmental laws and regulations.<br><br>   There may be regulatory requirements that affect some aspects of your<br>   security policy (e.g., line monitoring).The creators of the<br>   security policy should consider seeking legal assistance in the<br>   creation of the policy.At a minimum, the policy should be reviewed<br>   by legal counsel.<br><br>

x3 发表于 2003-8-25 19:51:50

以上是局部章节<br>我个人觉得很经典<br>大家自己下下看看

x3 发表于 2003-8-25 20:00:32

看贴的要回<br>

小熊 发表于 2003-8-25 20:21:07

好长啊啊   <br><br>天啊~~<br><br>让我今晚12点后,慢慢看好了

丢丢 发表于 2003-8-25 20:41:08

我是要大家下整个文看

小熊 发表于 2003-8-25 20:52:56

给个连接~~
页: [1] 2
查看完整版本: RFC2196