雏鹰部落

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 4051|回复: 17

[讨论/求助] RFC2196

[复制链接]
发表于 2003-8-25 19:46:09 | 显示全部楼层 |阅读模式
<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.1  Purpose of this Work............................................  3<br>1.2  Audience........................................................  3<br>1.3  Definitions.....................................................  3<br>1.4  Related Work....................................................  4<br>1.5  Basic Approach..................................................  4<br>1.6  Risk Assessment.................................................  5<br>2.   Security Policies...............................................  6<br>2.1  What is a Security Policy and Why Have One?.....................  6<br>2.2  What Makes a Good Security Policy?..............................  9<br>
 楼主| 发表于 2003-8-25 19:47:00 | 显示全部楼层
2.3  Keeping the Policy Flexible..................................... 11<br>3.   Architecture.................................................... 11<br>3.1  Objectives...................................................... 11<br>3.2  Network and Service Configuration............................... 14<br>3.3  Firewalls....................................................... 20<br>4.   Security Services and Procedures................................ 24<br>4.1  Authentication.................................................. 24<br>4.2  Confidentiality................................................. 28<br>4.3  Integrity....................................................... 28<br><br><br><br>Fraser, Ed.                Informational                        [Page 1]<br> <br>
 楼主| 发表于 2003-8-25 19:47:30 | 显示全部楼层
RFC 2196              Site Security Handbook              September 1997<br><br><br>4.4  Authorization................................................... 29<br>4.5  Access.......................................................... 30<br>4.6  Auditing........................................................ 34<br>4.7  Securing Backups................................................ 37<br>5.   Security Incident Handling...................................... 37<br>5.1  Preparing and Planning for Incident Handling.................... 39<br>5.2  Notification and Points of Contact.............................. 42<br>5.3  Identifying an Incident......................................... 50<br>5.4  Handling an Incident............................................ 52<br>5.5  Aftermath of an Incident........................................ 58<br>5.6  Responsibilities................................................ 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>
 楼主| 发表于 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                        [Page 2]<br> <br><br>RFC 2196              Site Security Handbook              September 1997<br><br><br>1.1  Purpose 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.2  Audience<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.3  Definitions<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                        [Page 3]<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.4  Related 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.5  Basic 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. [Fites 1989] 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>
 楼主| 发表于 2003-8-25 19:49:55 | 显示全部楼层
1.6  Risk Assessment<br><br>1.6.1  General 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.  [Fites 1989] and [Pfleeger 1989] 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.2  Identifying 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 [Pfleeger 1989]; 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                        [Page 5]<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.3  Identifying 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.1  What 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                        [Page 6]<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.1  Definition 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                        [Page 7]<br> <br><br>RFC 2196              Site Security Handbook              September 1997<br><br><br>2.1.2  Purposes 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.3  Who 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                        [Page 8]<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.2  What 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                        [Page 9]<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>
 楼主| 发表于 2003-8-25 19:51:50 | 显示全部楼层
以上是局部章节<br>我个人觉得很经典<br>大家自己下下看看
 楼主| 发表于 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 | 显示全部楼层
给个连接~~
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|熊猫同学技术论坛|小黑屋| 网络工程师论坛 ( 沪ICP备09076391 )

GMT+8, 2024-3-29 20:07 , Processed in 0.076775 second(s), 18 queries , Gzip On.

快速回复 返回顶部 返回列表