| < draft-ietf-ssh-handbook-03.txt | draft-ietf-ssh-handbook-04.txt > | |||
|---|---|---|---|---|
| Internet Draft Barbara Fraser | Internet Draft Barbara Fraser | |||
| Network Working Group SEI/CMU | Network Working Group SEI/CMU | |||
| Expires in six months Editor | Expires in six months Editor | |||
| June 1996 | March 1997 | |||
| Site Security Handbook | Site Security Handbook | |||
| <draft-ietf-ssh-handbook-03.txt> | <draft-ietf-ssh-handbook-04.txt> | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft. Internet-Drafts are working | |||
| documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
| and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
| working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet- Drafts as reference | time. It is inappropriate to use Internet- Drafts as reference | |||
| material or to cite them other than as ``work in progress.'' | material or to cite them other than as ``work in progress.'' | |||
| To learn the current status of any Internet-Draft, please check the | To learn the current status of any Internet-Draft, please check the | |||
| ``1id-abstracts.txt'' listing contained in the Internet- Drafts | ``1id-abstracts.txt'' listing contained in the Internet- Drafts | |||
| Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), | Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), | |||
| munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or | munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or | |||
| ftp.isi.edu (US West Coast). | ftp.isi.edu (US West Coast). | |||
| Abstract | ||||
| This handbook is a guide to developing computer security policies and | ||||
| procedures for sites that have systems on the Internet. The purpose | ||||
| of this handbook is to provide practical guidance to administrators | ||||
| trying to secure their information and services. The subjects | ||||
| covered include policy content and formation, a broad range of | ||||
| technical system and network security topics, and security incident | ||||
| response. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction.................................................... 2 | 1. Introduction.................................................... 2 | |||
| 1.1 Purpose of this Work............................................ 2 | 1.1 Purpose of this Work............................................ 2 | |||
| 1.2 Audience........................................................ 2 | 1.2 Audience........................................................ 2 | |||
| 1.3 Definitions..................................................... 3 | 1.3 Definitions..................................................... 3 | |||
| 1.4 Related Work.................................................... 3 | 1.4 Related Work.................................................... 3 | |||
| 1.5 Basic Approach.................................................. 3 | 1.5 Basic Approach.................................................. 3 | |||
| 1.6 Risk Assessment................................................. 4 | 1.6 Risk Assessment................................................. 4 | |||
| 2. Security Policies............................................... 5 | 2. Security Policies............................................... 5 | |||
| 2.1 What is a Computer Security Policy and Why Have One?............ 5 | 2.1 What is a Security Policy and Why Have One?..................... 5 | |||
| 2.2 What Makes a Good Computer Security Policy?..................... 7 | 2.2 What Makes a Good Security Policy?.............................. 7 | |||
| 2.3 Keeping the Policy Flexible..................................... 8 | 2.3 Keeping the Policy Flexible..................................... 9 | |||
| 3. Architecture.................................................... 9 | 3. Architecture.................................................... 9 | |||
| 3.1 Objectives...................................................... 9 | 3.1 Objectives...................................................... 10 | |||
| 3.2 Network and Service Configuration............................... 11 | 3.2 Network and Service Configuration............................... 12 | |||
| 3.3 Firewalls....................................................... 16 | 3.3 Firewalls....................................................... 17 | |||
| 4. Security Services and Procedures................................ 19 | 4. Security Services and Procedures................................ 21 | |||
| 4.1 Authentication.................................................. 19 | 4.1 Authentication.................................................. 21 | |||
| 4.2 Confidentiality................................................. 22 | 4.2 Confidentiality................................................. 24 | |||
| 4.3 Integrity....................................................... 23 | 4.3 Integrity....................................................... 24 | |||
| 4.4 Authorization................................................... 23 | 4.4 Authorization................................................... 25 | |||
| 4.5 Access.......................................................... 24 | 4.5 Access.......................................................... 25 | |||
| 4.6 Auditing........................................................ 27 | 4.6 Auditing........................................................ 29 | |||
| 4.7 Securing Backups................................................ 30 | 4.7 Securing Backups................................................ 31 | |||
| 5. Security Incident Handling...................................... 30 | 5. Security Incident Handling...................................... 32 | |||
| 5.1 Preparing and Planning for Incident Handling.................... 32 | 5.1 Preparing and Planning for Incident Handling.................... 33 | |||
| 5.2 Notification and Points of Contact.............................. 34 | 5.2 Notification and Points of Contact.............................. 35 | |||
| 5.3 Identifying an Incident......................................... 40 | 5.3 Identifying an Incident......................................... 42 | |||
| 5.4 Handling an Incident............................................ 42 | 5.4 Handling an Incident............................................ 44 | |||
| 5.5 Aftermath of an Incident........................................ 47 | 5.5 Aftermath of an Incident........................................ 49 | |||
| 5.6 Responsibilities................................................ 48 | 5.6 Responsibilities................................................ 50 | |||
| 6. Ongoing Activities.............................................. 49 | 6. Ongoing Activities.............................................. 51 | |||
| 7. Tools and Locations............................................. 49 | 7. Tools and Locations............................................. 52 | |||
| 8. Mailing Lists and Other Resources............................... 51 | 8. Mailing Lists and Other Resources............................... 53 | |||
| 9. References...................................................... 53 | 9. References...................................................... 55 | |||
| 10. Annotated Bibliography.......................................... 62 | 10. Annotated Bibliography.......................................... 65 | |||
| 1. INTRODUCTION | 1. Introduction | |||
| This document provides guidance to system and network administrators | This document provides guidance to system and network administrators | |||
| on how to address security issues within the Internet community. It | on how to address security issues within the Internet community. It | |||
| builds on the foundation provided in RFC 1244 and is the collective | builds on the foundation provided in RFC 1244 and is the collective | |||
| work of a number of contributing authors. Those authors include: | work of a number of contributing authors. Those authors include: | |||
| Jules P. Aronson, Nevil Brownlee, Frank Byrum, Joao Nuno Ferreira, | Jules P. Aronson, Nevil Brownlee, Frank Byrum, Joao Nuno Ferreira, | |||
| Erik Guttman, Klaus-Peter Kossakowski, Edward.P.Lewis, Gary Malkin, | Barbara Fraser, Steve Glass, Erik Guttman, Tom Killalea, Klaus-Peter | |||
| Russ Mundy, Philip J. Nesser, and Michael S. Ramsey. | Kossakowski, Lorna Leone, Edward.P.Lewis, Gary Malkin, Russ Mundy, | |||
| Philip J. Nesser, and Michael S. Ramsey. | ||||
| In addition to the principle writers, a number of reviewers provided | ||||
| valuable comments. Those reviewers include: Eric Luiijf, Marijke | ||||
| Kaat, and Han Pronk. | ||||
| A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, | A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, | |||
| CICnet, for their vision, leadership, and effort in the creation of | CICnet, for their vision, leadership, and effort in the creation of | |||
| the first version of this handbook. It is the working group's sincere | the first version of this handbook. It is the working group's sincere | |||
| hope that this version will be as helpful to the community as the | hope that this version will be as helpful to the community as the | |||
| earlier one was. | earlier one was. | |||
| 1.1 Purpose of this Work | 1.1 Purpose of This Work | |||
| This handbook is a guide to setting computer security policies and | This handbook is a guide to setting computer security policies and | |||
| procedures for sites that have systems on the Internet. This guide | procedures for sites that have systems on the Internet (however, the | |||
| lists issues and factors that a site must consider when setting their | information provided should also be useful to sites not yet connected | |||
| own policies. It makes some recommendations and provides discussions | to the Internet). This guide lists issues and factors that a site | |||
| of relevant areas. | must consider when setting their own policies. It makes a number of | |||
| recommendations and provides discussions of relevant areas. | ||||
| This guide is only a framework for setting security policies and | This guide is only a framework for setting security policies and | |||
| procedures. In order to have an effective set of policies and | procedures. In order to have an effective set of policies and | |||
| procedures, a site will have to make many decisions, gain agreement, | procedures, a site will have to make many decisions, gain agreement, | |||
| and then communicate and implement the policies. | and then communicate and implement these policies. | |||
| 1.2 Audience | 1.2 Audience | |||
| The audience for this document are system and network administrators, | The audience for this document are system and network administrators, | |||
| and decision makers (typically "middle management") at sites. For | and decision makers (typically "middle management") at sites. For | |||
| brevity, we will use the term "administrator" throughout this | brevity, we will use the term "administrator" throughout this | |||
| document to refer to system and network administrators. | document to refer to system and network administrators. | |||
| This document is not directed at programmers or those trying to | This document is not directed at programmers or those trying to | |||
| create secure programs or systems. The focus of this document is on | create secure programs or systems. The focus of this document is on | |||
| the policies and procedures that need to be in place to support any | the policies and procedures that need to be in place to support the | |||
| technical security features that a site may be implementing. | technical security features that a site may be implementing. | |||
| The primary audience for this work are sites that are members of the | The primary audience for this work are sites that are members of the | |||
| Internet community. However, this document should be useful to any | Internet community. However, this document should be useful to any | |||
| site that allows communication with other sites. As a general guide | site that allows communication with other sites. As a general guide | |||
| to security policies, this document may also be useful to sites with | to security policies, this document may also be useful to sites with | |||
| isolated systems. | isolated systems. | |||
| 1.3 Definitions | 1.3 Definitions | |||
| For the purposes of this guide, a "site" is any organization that | For the purposes of this guide, a "site" is any organization that | |||
| owns computers or network-related resources. These resources may | owns computers or network-related resources. These resources may | |||
| include host computers that users use, routers, terminal servers, | include host computers that users use, routers, terminal servers, | |||
| PC's or other devices that have access to the Internet. A site may | PC's or other devices that have access to the Internet. A site may | |||
| be an end user of Internet services or a service provider such as a | be an end user of Internet services or a service provider such as a | |||
| mid-level network. However, most of the focus of this guide is on | mid-level network. However, most of the focus of this guide is on | |||
| those end users of Internet services. We assume that the site has | those end users of Internet services. We assume that the site has | |||
| the ability to set policies and procedures for itself with the | the ability to set policies and procedures for itself with the | |||
| concurrence and support from those who actually own the resources. | concurrence and support from those who actually own the resources. It | |||
| will be assumed that sites that are parts of larger organizations | ||||
| will know when they need to consult, collaborate, or take | ||||
| recommendations from, the larger entity. | ||||
| The "Internet" is that set of networks and machines which use the | The "Internet" is that set of networks and machines which use the | |||
| TCP/IP protocol suite, connect through gateways, and share common | TCP/IP protocol suite, connect through gateways, and share common | |||
| name and address spaces [1]. | name and address spaces [1]. | |||
| The term "administrator" is used to cover all those people who are | The term "administrator" is used to cover all those people who are | |||
| responsible for the day-to-day operation of system and network | responsible for the day-to-day operation of system and network | |||
| resources. This may be a number of individuals or an organization. | resources. This may be a number of individuals or an organization. | |||
| The term "security administrator" is used to cover all those people | ||||
| who are responsible for the security of information and information | ||||
| technology. At some sites this function may be combined with | ||||
| administrator (above); at others, this will be a separate position. | ||||
| The term "decision maker" refers to those people at a site who set or | The term "decision maker" refers to those people at a site who set or | |||
| approve policy. These are often (but not always) the people who own | approve policy. These are often (but not always) the people who own | |||
| the resources. | the resources. | |||
| 1.4 Related Work | 1.4 Related Work | |||
| The IETF Guidelines for Security Incident Response Working Group | ||||
| (GRIP) is developing a document for security incident response teams. | ||||
| That document provides additional guidance to those organizations | ||||
| planning to develop their own computer security incident response | ||||
| team (CSIRT), including a template that is useful to CSIRTs when | ||||
| describing their policies and services. | ||||
| The Site Security Handbook Working Group is working on a User's Guide | The Site Security Handbook Working Group is working on a User's Guide | |||
| to Internet Security. It will provide practical guidance to end users | to Internet Security. It will provide practical guidance to end users | |||
| to help them protect their information and the resources they use. | to help them protect their information and the resources they use. | |||
| 1.5 Basic Approach | 1.5 Basic Approach | |||
| This guide is written to provide basic guidance in developing a | This guide is written to provide basic guidance in developing a | |||
| security plan for your site. One generally accepted approach to | security plan for your site. One generally accepted approach to | |||
| follow is suggested by Fites, et. al. [ref] and includes the | follow is suggested by Fites, et. al. [ref] and includes the | |||
| following steps: | following steps: | |||
| (1) Identify what you are trying to protect | (1) Identify what you are trying to protect. | |||
| (2) Determine what you are trying to protect it from | (2) Determine what you are trying to protect it from. | |||
| (3) Determine how likely the threats are | (3) Determine how likely the threats are. | |||
| (4) Implement measures which will protect your assets in a cost- | (4) Implement measures which will protect your assets in a cost- | |||
| effective manner. | effective manner. | |||
| (5) Review the process continuously and make improvements each time | (5) Review the process continuously and make improvements each time | |||
| a weakness is found. | a weakness is found. | |||
| Most of this document is focused on item 4 above, but the other steps | Most of this document is focused on item 4 above, but the other steps | |||
| cannot be avoided if an effective plan is to be established at your | cannot be avoided if an effective plan is to be established at your | |||
| site. One old truism in security is that the cost of protecting | site. One old truism in security is that the cost of protecting | |||
| yourself against a threat should be less than the cost of recovering | yourself against a threat should be less than the cost of recovering | |||
| if the threat were to strike you. Without reasonable knowledge of | if the threat were to strike you. Cost in this context should be | |||
| what you are protecting and what the likely threats are, following | remembered to include losses expressed in real currency, reputation, | |||
| this rule could be difficult. | trustworthiness, and other less obvious measures. Without reasonable | |||
| knowledge of what you are protecting and what the likely threats are, | ||||
| following this rule could be difficult. | ||||
| 1.6 Risk Assessment | 1.6 Risk Assessment | |||
| 1.6.1 General Discussion | 1.6.1 General Discussion | |||
| One of the most important reasons for creating a computer security | One of the most important reasons for creating a computer security | |||
| policy is to ensure that efforts spent on security yield cost | policy is to ensure that efforts spent on security yield cost | |||
| effective benefits. Although this may seem obvious, it is possible | effective benefits. Although this may seem obvious, it is possible | |||
| to be mislead about where the effort is needed. As an example, there | to be mislead about where the effort is needed. As an example, there | |||
| is a great deal of publicity about intruders on computers systems; | is a great deal of publicity about intruders on computers systems; | |||
| skipping to change at page 5, line 17 ¶ | skipping to change at page 5, line 37 ¶ | |||
| drives, communication lines, terminal servers, routers. | drives, communication lines, terminal servers, routers. | |||
| (2) Software: source programs, object programs, | (2) Software: source programs, object programs, | |||
| utilities, diagnostic programs, operating systems, | utilities, diagnostic programs, operating systems, | |||
| communication programs. | communication programs. | |||
| (3) Data: during execution, stored on-line, archived off-line, | (3) Data: during execution, stored on-line, archived off-line, | |||
| backups, audit logs, databases, in transit over | backups, audit logs, databases, in transit over | |||
| communication media. | communication media. | |||
| (4) People: users, administrators. | (4) People: users, administrators, hardware maintainers. | |||
| (5) Documentation: on programs, hardware, systems, local | (5) Documentation: on programs, hardware, systems, local | |||
| administrative procedures. | administrative procedures. | |||
| (6) Supplies: paper, forms, ribbons, magnetic media. | (6) Supplies: paper, forms, ribbons, magnetic media. | |||
| 1.6.3 Identifying the Threats | 1.6.3 Identifying the Threats | |||
| Once the assets requiring protection are identified, it is necessary | Once the assets requiring protection are identified, it is necessary | |||
| to identify threats to those assests. The threats can then be | to identify threats to those assets. The threats can then be | |||
| examined to determine what potential for loss exists. It helps to | examined to determine what potential for loss exists. It helps to | |||
| consider from what threats you are trying to protect your assets. | consider from what threats you are trying to protect your assets. | |||
| The following are classic threats that should be considered. | The following are classic threats that should be considered. | |||
| Depending on your site, there will be more specific threats that | Depending on your site, there will be more specific threats that | |||
| should be identified and addressed. | should be identified and addressed. | |||
| (1) Unauthorized access to resources and/or information | (1) Unauthorized access to resources and/or information | |||
| (2) Disclosure of information | (2) Unintented and/or unauthorized Disclosure of information | |||
| (3) Denial of service | (3) Denial of service | |||
| 2. Security Policies | 2. Security Policies | |||
| 2.1 What is a Computer Security Policy and Why Have One? | Throughout this document there will be many references to policies. | |||
| Often these references will include recommendations for specific | ||||
| policies. Rather than repeat guidance in how to create and | ||||
| communicate such a policy, the reader should apply the advice | ||||
| presented in this chapter when developing any policy recommended | ||||
| later in this book. | ||||
| The security-related decisions you make, or fail to make, as network | 2.1 What is a Security Policy and Why Have One? | |||
| The security-related decisions you make, or fail to make, as | ||||
| administrator largely determines how secure or insecure your network | administrator largely determines how secure or insecure your network | |||
| is, how much functionality your network offers, and how easy your | is, how much functionality your network offers, and how easy your | |||
| network is to use. However, you cannot make good decisions about | network is to use. However, you cannot make good decisions about | |||
| security without first determining what your security goals are. | security without first determining what your security goals are. | |||
| Until you determine what your security goals are, you cannot make | Until you determine what your security goals are, you cannot make | |||
| effective use of any collection of security tools because you simply | effective use of any collection of security tools because you simply | |||
| will not know what to check for and what restrictions to impose. | will not know what to check for and what restrictions to impose. | |||
| For example, your goals will probably be very different from the | For example, your goals will probably be very different from the | |||
| goals of a product vendor. Vendors are trying to make configuration | goals of a product vendor. Vendors are trying to make configuration | |||
| and operation of their products as simple as possible, which implies | and operation of their products as simple as possible, which implies | |||
| that the default configurations will often be as open (i.e., | that the default configurations will often be as open (i.e., | |||
| insecure) as possible. While this does make it easier to install new | insecure) as possible. While this does make it easier to install new | |||
| products, it also leaves access to those systems, and other systems | products, it also leaves access to those systems, and other systems | |||
| through them, open to any user who wanders by. | through them, open to any user who wanders by. | |||
| Your goals will be largely determined by the following key tradeoffs: | Your goals will be largely determined by the following key tradeoffs: | |||
| (1) services offered vs. security provided - | (1) services offered versus security provided - | |||
| Each service offered to users carries its own security risks. | Each service offered to users carries its own security risks. | |||
| For some services the risk outweighs the benefit of the service | For some services the risk outweighs the benefit of the service | |||
| and the administrator may choose to eliminate the service rather | and the administrator may choose to eliminate the service rather | |||
| than try to secure it. | than try to secure it. | |||
| (2) ease of use vs. security - | (2) ease of use versus security - | |||
| The easiest system to use would allow access to any user and requi= | The easiest system to use would allow access to any user and require | |||
| re | ||||
| no passwords; that is, there would be no security. Requiring | no passwords; that is, there would be no security. Requiring | |||
| passwords makes the system a little less convenient, but more secu= | passwords makes the system a little less convenient, but more secure. | |||
| re. | Requiring device-generated one-time passwords makes the system even | |||
| Requiring device-generated one-time passwords makes the system eve= | ||||
| n | ||||
| more difficult to use, but much more secure. | more difficult to use, but much more secure. | |||
| (3) cost of security vs. risk of loss - | (3) cost of security versus risk of loss - | |||
| There are many different costs to security: monetary (i.e., the | There are many different costs to security: monetary (i.e., the | |||
| cost of purchasing security hardware and software like firewalls | cost of purchasing security hardware and software like firewalls | |||
| and one-time password generators), performance (i.e., encryption | and one-time password generators), performance (i.e., encryption | |||
| and decryption take time), and ease of use (as mentioned above). | and decryption take time), and ease of use (as mentioned above). | |||
| There are also many levels of risk: loss of privacy (i.e., the | There are also many levels of risk: loss of privacy (i.e., the | |||
| reading of information by unauthorized individuals), loss of | reading of information by unauthorized individuals), loss of | |||
| data (i.e., the corruption or erasure of information), and the | data (i.e., the corruption or erasure of information), and the | |||
| loss of service (e.g., the filling of data storage space, usage | loss of service (e.g., the filling of data storage space, usage | |||
| of computational resources, and denial of network access). Each | of computational resources, and denial of network access). Each | |||
| type of cost must be weighed against each type of loss. | type of cost must be weighed against each type of loss. | |||
| Your goals should be communicated to all users, operations staff, and | Your goals should be communicated to all users, operations staff, and | |||
| managers through a set of security rules, called a "computer security | managers through a set of security rules, called a "security policy." | |||
| policy." | We are using this term, rather than the narrower "computer security | |||
| policy" since the scope includes all types of information technology | ||||
| and the information stored and manipulated by the technology. | ||||
| 2.1.1 Definition of a Computer Security Policy | 2.1.1 Definition of a Security Policy | |||
| A computer security policy is a formal statement of the rules by | A security policy is a formal statement of the rules by which people | |||
| which people who are given access to an organization's technology and | who are given access to an organization's technology and information | |||
| information assets must abide. | assets must abide. | |||
| 2.1.2 Purposes of a Computer Security Policy | 2.1.2 Purposes of a Security Policy | |||
| The main purpose of a computer security policy is to inform users, | The main purpose of a security policy is to inform users, staff and | |||
| staff and managers of their obligatory requirements for protecting | managers of their obligatory requirements for protecting technology | |||
| technology and information assets. The policy should specify the | and information assets. The policy should specify the mechanisms | |||
| mechanisms through which these requirements can be met. Another | through which these requirements can be met. Another purpose is to | |||
| purpose is to provide a baseline from which to acquire, configure and | provide a baseline from which to acquire, configure and audit | |||
| audit computer systems and networks for compliance with the policy. | computer systems and networks for compliance with the policy. | |||
| Therefore an attempt to use a set of security tools in the absence of | Therefore an attempt to use a set of security tools in the absence of | |||
| at least an implied security policy is meaningless. | at least an implied security policy is meaningless. | |||
| An Appropriate Use Policy (AUP) may also be part of a security | An Appropriate Use Policy (AUP) may also be part of a security | |||
| policy. It should spell out what users may and may not do on the | policy. It should spell out what users shall and shall not do on the | |||
| various components of the system, including the type of traffic | various components of the system, including the type of traffic | |||
| allowed on the networks. The AUP should be as explicit as possible | allowed on the networks. The AUP should be as explicit as possible | |||
| to avoid ambiguity or misunderstanding. For example, an AUP might | to avoid ambiguity or misunderstanding. For example, an AUP might | |||
| list any prohibited USENET newsgroups. | list any prohibited USENET newsgroups. (Note: Appropriate Use Policy | |||
| is referred to as Acceptable Use Policy by some sites.) | ||||
| 2.1.3 Who Should be Involved When Forming Policy? | 2.1.3 Who Should be Involved When Forming Policy? | |||
| In order for a security policy to be appropriate and effective, it | In order for a security policy to be appropriate and effective, it | |||
| needs to have the acceptance and support of all levels of employees | needs to have the acceptance and support of all levels of employees | |||
| within the organization. The following is a list of individuals who | within the organization. The following is a list of individuals who | |||
| should be involved in the creation and review of security policy | should be involved in the creation and review of security policy | |||
| documents: | documents: | |||
| (1) site security administrator | (1) site security administrator | |||
| (2) legal counsel | (2) information technology technical staff (e.g., staff from | |||
| (3) computing center personnel | computing center) | |||
| (4) administrators of large user groups within the organization | (3) administrators of large user groups within the organization | |||
| (e.g., business divisions, computer science department within a | (e.g., business divisions, computer science department within a | |||
| university, etc.) | university, etc.) | |||
| (5) security incident response team | (4) security incident response team | |||
| (6) representatives of the user groups affected by the security policy | (5) representatives of the user groups affected by the security policy | |||
| (6) responsible management | ||||
| (7) legal counsel (if appropriate) | ||||
| The list of above is representative of many organizations, but is not | The list above is representative of many organizations, but is not | |||
| necessarily comprehensive. The idea is to bring in representation | necessarily comprehensive. The idea is to bring in representation | |||
| from key stakeholders, management who have budget and policy | from key stakeholders, management who have budget and policy | |||
| authority, technical staff who know what can and cannot be supported, | authority, technical staff who know what can and cannot be supported, | |||
| and legal counsel who know the legal ramifications of various policy | and legal counsel who know the legal ramifications of various policy | |||
| choices. In some organizations, it may be appropriate to include | choices. In some organizations, it may be appropriate to include EDP | |||
| audit personnel. Involving this group is important if resulting | audit personnel. Involving this group is important if resulting | |||
| policy statements are to reach the broadest possible acceptance. | policy statements are to reach the broadest possible acceptance. It | |||
| is also relevant to mention that the role of legal counsel will also | ||||
| vary from country to country. | ||||
| 2.2 What Makes a Good Computer Security Policy? | 2.2 What Makes a Good Security Policy? | |||
| The characteristics of a good security policy are: | The characteristics of a good security policy are: | |||
| (1) It must be implementable through system administration | (1) It must be implementable through system administration | |||
| procedures, publishing of acceptable use guidelines, or other | procedures, publishing of acceptable use guidelines, or other | |||
| appropriate methods. | appropriate methods. | |||
| (2) It must be enforcible with security tools, where appropriate, | (2) It must be enforcible with security tools, where appropriate, | |||
| and with sanctions, where actual prevention is not technically | and with sanctions, where actual prevention is not technically | |||
| feasible. | feasible. | |||
| (3) It must clearly define the areas of responsibility for the | (3) It must clearly define the areas of responsibility for the | |||
| users, staff, and administrators. | users, administrators, and management. | |||
| The components of a good security policy include: | The components of a good security policy include: | |||
| (1) Computer Technology Purchasing Guidelines which specify required, | (1) Computer Technology Purchasing Guidelines which specify required, | |||
| or preferred, security features. These should supplement existing | or preferred, security features. These should supplement existing | |||
| purchasing policies and guidelines. | purchasing policies and guidelines. | |||
| (2) A Privacy Policy which defines reasonable expectations of privacy | (2) A Privacy Policy which defines reasonable expectations of privacy | |||
| regarding such issues as monitoring of electronic mail, logging of | regarding such issues as monitoring of electronic mail, logging of | |||
| keystrokes, and access to users' files. | keystrokes, and access to users' files. | |||
| (3) An Access Policy which defines access rights and privileges to | (3) An Access Policy which defines access rights and privileges to | |||
| protect assets from loss or disclosure by specifying acceptable us= | protect assets from loss or disclosure by specifying acceptable use | |||
| e | ||||
| guidelines for users, operations staff, and management. It should | guidelines for users, operations staff, and management. It should | |||
| provide guidelines for external connections, data communications, | provide guidelines for external connections, data communications, | |||
| connecting devices to a network, and adding new software to | connecting devices to a network, and adding new software to | |||
| systems. It should also specify any required notification message= | systems. It should also specify any required notification messages | |||
| s | ||||
| (e.g., connect messages should provide warnings about authorized | (e.g., connect messages should provide warnings about authorized | |||
| usage and line monitoring, and not simply say "Welcome"). | usage and line monitoring, and not simply say "Welcome"). | |||
| (4) An Accountability Policy which defines the responsibilities of use= | (4) An Accountability Policy which defines the responsibilities of users, | |||
| rs, | ||||
| operations staff, and management. It should specify an audit | operations staff, and management. It should specify an audit | |||
| capability, and provide incident handling guidelines (i.e., what t= | capability, and provide incident handling guidelines (i.e., what to | |||
| o | ||||
| do and who to contact if a possible intrusion is detected). | do and who to contact if a possible intrusion is detected). | |||
| (5) An Authentication Policy which establishes trust through an effect= | (5) An Authentication Policy which establishes trust through an effective | |||
| ive | ||||
| password policy, and by setting guidelines for remote location | password policy, and by setting guidelines for remote location | |||
| authentication and the use of authentication devices (e.g., one-ti= | authentication and the use of authentication devices (e.g., one-time | |||
| me | ||||
| passwords and the devices that generate them). | passwords and the devices that generate them). | |||
| (6) An Availability statement which sets users' expectations for the | (6) An Availability statement which sets users' expectations for the | |||
| availability of resources. It should address redundancy and recov= | availability of resources. It should address redundancy and recovery | |||
| ery | issues, as well as specify operating hours and maintenance down-time | |||
| issues, as well as specify operating hours and maintenance down-ti= | ||||
| me | ||||
| periods. It should also include contact information for reporting | periods. It should also include contact information for reporting | |||
| system and network failures. | system and network failures. | |||
| (7) A Violations Reporting Policy that indicates which types of | (7) An Information Technology System & Network Maintenance Policy | |||
| which describes how both internal and external maintenance people | ||||
| are allowed to handle and access technology. One important | ||||
| topic to be addressed here is whether remote maintenance is | ||||
| allowed and how such access is controlled. Another area for | ||||
| consideration here is outsourcing and how it is managed. | ||||
| (8) A Violations Reporting Policy that indicates which types of | ||||
| violations (e.g., privacy and security, internal and external) | violations (e.g., privacy and security, internal and external) | |||
| must be reported and to whom the reports are made. A | must be reported and to whom the reports are made. A | |||
| non-threatening atmosphere and the possibility of anonymous report= | non-threatening atmosphere and the possibility of anonymous reporting | |||
| ing | ||||
| will result in a greater probability that a violation will be | will result in a greater probability that a violation will be | |||
| reported if it is detected. | reported if it is detected. | |||
| (8) Supporting Information which provides users, staff, and management | (9) Supporting Information which provides users, staff, and management | |||
| with contact information for each type of policy violation; | with contact information for each type of policy violation; | |||
| guidelines on how to handle outside queries about a security incid= | guidelines on how to handle outside queries about a security incident, | |||
| ent, | or information which may be considered confidential or proprietary; | |||
| or information which may be considered confidential or proprietary= | and cross-references to security procedures and related information, | |||
| ; | such as company policies and governmental laws and regulations. | |||
| and cross-references to security procedures and related informatio= | ||||
| n, | ||||
| such as company policies and regulatory requirements (federal, sta= | ||||
| te, | ||||
| and local). | ||||
| There may be regulatory requirements that affect some aspects of your | There may be regulatory requirements that affect some aspects of your | |||
| security policy (e.g., line monitoring). The creators of the | security policy (e.g., line monitoring). The creators of the | |||
| security policy should consider seeking legal assistance in the | security policy should consider seeking legal assistance in the | |||
| creation of the policy. At a minimum, the policy should be reviewed | creation of the policy. At a minimum, the policy should be reviewed | |||
| by legal counsel. | by legal counsel. | |||
| Once your computer security policy has been established it should be | Once your security policy has been established it should be clearly | |||
| clearly communicated to users, staff, and management. Having all | communicated to users, staff, and management. Having all personnel | |||
| personnel sign a statement indicating that they have read, | sign a statement indicating that they have read, understood, and | |||
| understood, and agreed to abide by the policy is an important part of | agreed to abide by the policy is an important part of the process. | |||
| the process. Finally, your policy should be reviewed on a regular | Finally, your policy should be reviewed on a regular basis to see if | |||
| basis to see if it is successfully supporting your security needs. | it is successfully supporting your security needs. | |||
| 2.3 Keeping the Policy Flexible | 2.3 Keeping the Policy Flexible | |||
| In order for a security policy to be viable for the long term, it | In order for a security policy to be viable for the long term, it | |||
| requires a lot of flexibility. The mechanisms for updating the | requires a lot of flexibility based upon an architectural security | |||
| concept. A security policy should be (largely) independent from | ||||
| specific hardware and software situations (as specific systems tend | ||||
| to be replaced or moved overnight). The mechanisms for updating the | ||||
| policy should be clearly spelled out. This includes the process, the | policy should be clearly spelled out. This includes the process, the | |||
| people involved, and the people who must sign-off on the changes. | people involved, and the people who must sign-off on the changes. | |||
| It is also important to recognize that there are exceptions to every | It is also important to recognize that there are exceptions to every | |||
| rule. Whenever possible, the policy should spell out what exceptions | rule. Whenever possible, the policy should spell out what exceptions | |||
| to the general policy exist. For example, under what conditions is a | to the general policy exist. For example, under what conditions is a | |||
| system administrator allowed to go through a user's files. Also, | system administrator allowed to go through a user's files. Also, | |||
| there may be some cases when multiple users will have access to the | there may be some cases when multiple users will have access to the | |||
| same userid. For example, on systems with a "root" user, multiple | same userid. For example, on systems with a "root" user, multiple | |||
| system administrators may know the password and use the root account. | system administrators may know the password and use the root account. | |||
| Another consideration is called the "Garbage Truck Syndrome." This | Another consideration is called the "Garbage Truck Syndrome." This | |||
| refers to what would happen to a site if a key person was suddenly | refers to what would happen to a site if a key person was suddenly | |||
| unavailable for his/her job function (e.g., was suddenly ill or left | unavailable for his/her job function (e.g., was suddenly ill or left | |||
| the company unexpectedly). While the greatest security resides in | the company unexpectedly). While the greatest security resides in | |||
| the minimum dissemination of information, the risk of losing critical | the minimum dissemination of information, the risk of losing critical | |||
| information increases when that information is not shared. It is | information increases when that information is not shared. It is | |||
| necessary to determine what the proper balance is for your site. | important to determine what the proper balance is for your site. | |||
| 3. Architecture | 3. Architecture | |||
| 3.1 Objectives | 3.1 Objectives | |||
| 3.1.1 Completely defined security plans | 3.1.1 Completely Defined Security Plans | |||
| Defining a comprehensive security plan should be done by all sites. | All sites should define a comprehensive security plan. This plan | |||
| This plan should be at a higher level than the specific policies | should be at a higher level than the specific policies discussed in | |||
| discussed in section 2. It should be crafted as a framework of broad | chapter 2, and it should be crafted as a framework of broad | |||
| guidelines into which specific policies will fit. | guidelines into which specific policies will fit. | |||
| It is important to have this framework in place so that individual | It is important to have this framework in place so that individual | |||
| policies can be consistant with the overall site security | policies can be consistent with the overall site security | |||
| architecture. For example, having a strong policy with regard to | architecture. For example, having a strong policy with regard to | |||
| Internet access and having weak restrictions on modem usage is | Internet access and having weak restrictions on modem usage is | |||
| inconsistent with an overall philosophy of strong security | inconsistent with an overall philosophy of strong security | |||
| restrictions on external access. | restrictions on external access. | |||
| A security policy should contain, at a minimum: a list of services | A security plan should define: the list of network services that will | |||
| which are currently, or will be, provided; who will have access to | be provided; which areas of the organization will provide the | |||
| those services; how access will be provided; who will administer | services; who will have access to those services; how access will be | |||
| those services; etc. It is also important to define any limitations | provided; who will administer those services; etc. | |||
| on which portions of an organization can provide certain services. | ||||
| Another aspect of the plan should concern incident handling. Chapter | The plan should also address how incident will be handled. Chapter 5 | |||
| 5 provides an in-depth discussion of responses to incidents, but it | provides an in-depth discussion of this topic, but it is important | |||
| is important to define classes of incidents and define responses to | for each site to define classes of incidents and corresponding | |||
| each class of incident. For sites with firewalls, how many attempts | responses. For example, sites with firewalls should set a threshold | |||
| to foil the firewall will trigger a response? Are there levels of | on the number of attempts made to foil the firewall before triggering | |||
| escallation in both attacks and responses? For sites without | a response? Escallation levels should be defined for both attacks | |||
| firewalls, does a single attempt to connect constitute an incident? | and responses. Sites without firewalls will have to determine if a | |||
| How about a systematic scan of machines? | single attempt to connect to a host constitutes an incident? What | |||
| For sites connected to the Internet, the rampant media glorification | about a systematic scan of systems? | |||
| For sites connected to the Internet, the rampant media magnification | ||||
| of Internet related security incidents can overshadow a (potentially) | of Internet related security incidents can overshadow a (potentially) | |||
| more serious internal security problem. Likewise, companies who have | more serious internal security problem. Likewise, companies who have | |||
| never been on the Internet before, may have strong, well defined, | never been connected to the Internet may have strong, well defined, | |||
| internal policies but fail to adequately address an external | internal policies but fail to adequately address an external | |||
| connection policy. | connection policy. | |||
| 3.1.2 Separation of Services | 3.1.2 Separation of Services | |||
| There are many services which a site may wish to provide for its | There are many services which a site may wish to provide for its | |||
| users, some of which may be external. There are a variety of | users, some of which may be external. There are a variety of | |||
| security reasons to attempt to isolate services onto dedicated | security reasons to attempt to isolate services onto dedicated host | |||
| machines. There are also performance reasons in most cases, but a | computers. There are also performance reasons in most cases, but a | |||
| detailed discussion is beyond to scope of this document. | detailed discussion is beyond to scope of this document. | |||
| The services which a site may provide will, in most cases, have | The services which a site may provide will, in most cases, have | |||
| different levels of access needs and models of trust. Services which | different levels of access needs and models of trust. Services which | |||
| are essential to the security or smooth operation of a site would be | are essential to the security or smooth operation of a site would be | |||
| better off being placed on a dedicated machine with very limited | better off being placed on a dedicated machine with very limited | |||
| access (see Section 3.1.3 "deny all" model), rather than on a machine | access (see Section 3.1.3 "deny all" model), rather than on a machine | |||
| which provides a service (or services) which has traditionally been | that provides a service (or services) which has traditionally been | |||
| less secure, or requires greater accessability by users who may | less secure, or requires greater accessability by users who may | |||
| accidentally suborn security. | accidentally suborn security. | |||
| It is also important to distinguish between machines which operate | It is also important to distinguish between hosts which operate | |||
| within different models of trust, i.e., all the machines inside of a | within different models of trust (e.g., all the hosts inside of a | |||
| firewall and any machines on an exposed network. | firewall and any host on an exposed network). | |||
| Some of the services which should be examined for potential | Some of the services which should be examined for potential | |||
| separation are outlined in section 3.2.3. It is important to try to | separation are outlined in section 3.2.3. It is important to remember | |||
| understand that security is only as strong as the weakest link in the | that security is only as strong as the weakest link in the chain. | |||
| chain. Several of the most publicized penetrations in recent years | Several of the most publicized penetrations in recent years have been | |||
| has been through the electronic mail systems of machines. The | through the exploitation of vulnerabilities in electronic mail | |||
| intruders were not trying to steal electronic mail, but they used the | systems. The intruders were not trying to steal electronic mail, but | |||
| vulnerability in that system to gain access to other systems. | they used the vulnerability in that service to gain access to other | |||
| systems. | ||||
| If possible, each service should be running on a different machine | If possible, each service should be running on a different machine | |||
| whose only duty is to provide a specific service. This helps to | whose only duty is to provide a specific service. This helps to | |||
| isolate intruders and limit potential harm. | isolate intruders and limit potential harm. | |||
| 3.1.3 Deny all/ Allow all | 3.1.3 Deny all/ Allow all | |||
| There are two diametrically opposed underlying philosophies which can | There are two diametrically opposed underlying philosophies which can | |||
| be adopted in defining a security plan. Both alternatives are | be adopted when defining a security plan. Both alternatives are | |||
| legitimate models to adopt, depending on the site and its needs for | legitimate models to adopt, and the choice between them will depend | |||
| security. | on the site and its needs for security. | |||
| The first option is to turn off all services and then selectively | The first option is to turn off all services and then selectively | |||
| enable services on a case by case basis, be it at the machine or | enable services on a case by case basis as they are needed. This can | |||
| network level, as they are needed. This model, which will here after | be done at the host or network level as appropriate. This model, | |||
| be referred to as the "deny all" model, is generally more secure. | which will here after be referred to as the "deny all" model, is | |||
| More work is required to successfully implement a "deny all" | generally more secure than the other model described in the next | |||
| configuration and usually a better understanding of services. Only | paragraph. More work is required to successfully implement a "deny | |||
| allowing known services allows a better analysis of a particular | all" configuration as well as a better understanding of services. | |||
| service/protocol and the design of a security mechanism suited to the | Allowing only known services provides for a better analysis of a | |||
| security level of the site. | particular service/protocol and the design of a security mechanism | |||
| suited to the security level of the site. | ||||
| The other model, which will here after be referred to as the "allow | The other model, which will here after be referred to as the "allow | |||
| all" model, is much easier to implement, but is generally less secure | all" model, is much easier to implement, but is generally less secure | |||
| than the "deny all" model. Simply turn on all services, usually the | than the "deny all" model. Simply turn on all services, usually the | |||
| default at the host level, and allow all protocols to travel across | default at the host level, and allow all protocols to travel across | |||
| network boundaries, usually the default at the router level. As | network boundaries, usually the default at the router level. As | |||
| security holes become apparent, they are patched at either the host | security holes become apparent, they are restricted or patched at | |||
| or network level. | either the host or network level. | |||
| Each of these models can be applied to different portions of the | Each of these models can be applied to different portions of the | |||
| site, depending on functionality requirements, administrative | site, depending on functionality requirements, administrative | |||
| control, site policy, etc. For example, the policy may be to use the | control, site policy, etc. For example, the policy may be to use the | |||
| "allow all" model when setting up workstations for general use, but | "allow all" model when setting up workstations for general use, but | |||
| adopt a "deny all" model when setting up information servers, like an | adopt a "deny all" model when setting up information servers, like an | |||
| email hub. Likewise, an "allow all" policy may be adopted for | email hub. Likewise, an "allow all" policy may be adopted for | |||
| traffic between LAN's internal to the site, but a "deny all" policy | traffic between LAN's internal to the site, but a "deny all" policy | |||
| can be adopted between the site and the Internet. | can be adopted between the site and the Internet. | |||
| Be careful when mixing philosophies as in the examples above. Many | Be careful when mixing philosophies as in the examples above. Many | |||
| sites adopt the M & M theory of a hard "crunchy" shell and a soft | sites adopt the theory of a hard "crunchy" shell and a soft "squishy" | |||
| "squishy" middle. They are willing to pay the cost of security for | middle. They are willing to pay the cost of security for their | |||
| their external traffic and require strong security measures, but are | external traffic and require strong security measures, but are | |||
| unwilling or unable to provide similar protections internally. This | unwilling or unable to provide similar protections internally. This | |||
| works fine as long as the outer defenses are never breached and the | works fine as long as the outer defenses are never breached and the | |||
| internal users can be trusted. Once the outer shell (firewall) is | internal users can be trusted. Once the outer shell (firewall) is | |||
| breached, subverting the internal network is trivial. | breached, subverting the internal network is trivial. | |||
| 3.1.4 Identify real needs for services | 3.1.4 Identify Real Needs for Services | |||
| There is a large variety of services which may be provided, both | There is a large variety of services which may be provided, both | |||
| internally and on the Internet at large. Managing security is, in | internally and on the Internet at large. Managing security is, in | |||
| many ways, managing access to services internal to the site and | many ways, managing access to services internal to the site and | |||
| managing how internal users access information at remote sites. | managing how internal users access information at remote sites. | |||
| Services tend to rush like waves over the Internet. Over the years | Services tend to rush like waves over the Internet. Over the years | |||
| many sites have established anonymous FTP servers, gopher servers, | many sites have established anonymous FTP servers, gopher servers, | |||
| wais servers, WWW servers, etc. as they became popular, but not | wais servers, WWW servers, etc. as they became popular, but not | |||
| particularly needed, at all sites. Evaluate all new services that | particularly needed, at all sites. Evaluate all new services that | |||
| skipping to change at page 12, line 31 ¶ | skipping to change at page 13, line 21 ¶ | |||
| an administrator misconfigures a host, that host may offer degraded | an administrator misconfigures a host, that host may offer degraded | |||
| service. This only affects users who require that host and, unless | service. This only affects users who require that host and, unless | |||
| that host is a primary server, the number of affected users will | that host is a primary server, the number of affected users will | |||
| therefore be limited. However, if a router is misconfigured, all | therefore be limited. However, if a router is misconfigured, all | |||
| users who require the network will be affected. Obviously, this is a | users who require the network will be affected. Obviously, this is a | |||
| far larger number of users than those depending on any one host. | far larger number of users than those depending on any one host. | |||
| 3.2.2 Protecting the Network | 3.2.2 Protecting the Network | |||
| There are several problems to which networks are vulnerable. The | There are several problems to which networks are vulnerable. The | |||
| classic is a "denial of service" attack. In this case, the network | classic problem is a "denial of service" attack. In this case, the | |||
| is brought to a state in which it can no longer carry legitimate | network is brought to a state in which it can no longer carry | |||
| users' data. There are two common ways this can be done: by | legitimate users' data. There are two common ways this can be done: | |||
| attacking the routers and by flooding the network with extraneous | by attacking the routers and by flooding the network with extraneous | |||
| traffic. An attack on the router is designed to cause it to stop | traffic. Please note that the term "router" in this section is used | |||
| forwarding packets, or to forward them improperly. The former case | as an example of a larger class of active network interconnection | |||
| may be due to a misconfiguration, the injection of a spurious routing | components that also includes components like firewalls, proxy- | |||
| update, or a "flood attack" (i.e., the router is bombarded with | servers, etc. | |||
| unroutable packets, causing its performance to degrade). A flood | ||||
| attack on a network is similar to a flood attack on a router, except | An attack on the router is designed to cause it to stop forwarding | |||
| that the flood packets are usually broadcast. An ideal flood attack | packets, or to forward them improperly. The former case may be due | |||
| would be the injection of a single packet which exploits some known | to a misconfiguration, the injection of a spurious routing update, or | |||
| flaw in the network nodes and causes them to retransmit the packet, | a "flood attack" (i.e., the router is bombarded with unroutable | |||
| or generate error packets, each of which is picked up and repeated by | packets, causing its performance to degrade). A flood attack on a | |||
| network is similar to a flood attack on a router, except that the | ||||
| flood packets are usually broadcast. An ideal flood attack would be | ||||
| the injection of a single packet which exploits some known flaw in | ||||
| the network nodes and causes them to retransmit the packet, or | ||||
| generate error packets, each of which is picked up and repeated by | ||||
| another host. A well chosen attack packet can even generate an | another host. A well chosen attack packet can even generate an | |||
| exponential explosion of transmissions. | exponential explosion of transmissions. | |||
| Another classic problem is "spoofing." In this case, spurious | Another classic problem is "spoofing." In this case, spurious | |||
| routing updates are sent to one or more routers causing them to | routing updates are sent to one or more routers causing them to | |||
| misroute packets. This differs from a denial of service attack only | misroute packets. This differs from a denial of service attack only | |||
| in the purpose behind the spurious route. In denial of service, the | in the purpose behind the spurious route. In denial of service, the | |||
| object is to make the router unusable; a state which will be quickly | object is to make the router unusable; a state which will be quickly | |||
| detected by network users. In spoofing, the spurious route will | detected by network users. In spoofing, the spurious route will | |||
| cause packets to be routed to a host from which an intruder may | cause packets to be routed to a host from which an intruder may | |||
| skipping to change at page 13, line 53 ¶ | skipping to change at page 14, line 48 ¶ | |||
| anywhere on the Internet, requires built-in protection. That is, the | anywhere on the Internet, requires built-in protection. That is, the | |||
| service/protocol/server must provide whatever security may be | service/protocol/server must provide whatever security may be | |||
| required to prevent unauthorized access and modification of the Web | required to prevent unauthorized access and modification of the Web | |||
| database. | database. | |||
| Internal services (i.e., services meant to be used only by users | Internal services (i.e., services meant to be used only by users | |||
| within a site) and external services (i.e., services deliberately | within a site) and external services (i.e., services deliberately | |||
| made available to users outside a site) will, in general, have | made available to users outside a site) will, in general, have | |||
| protection requirements which differ as previously described. It is | protection requirements which differ as previously described. It is | |||
| therefore wise to isolate the internal services to one set of server | therefore wise to isolate the internal services to one set of server | |||
| machines and the external services to another set of server machines. | host computers and the external services to another set of server | |||
| That is, internal and external servers should not be co-located. In | host computers. That is, internal and external servers should not be | |||
| fact, many sites go so far as to have one set of subnets (or even | co-located on the same host computer. In fact, many sites go so far | |||
| different networks) which are accessible from the outside and another | as to have one set of subnets (or even different networks) which are | |||
| set which may be accessed only within the site. Of course, there is | accessible from the outside and another set which may be accessed | |||
| usually a firewall which connects these partitions. Great care must | only within the site. Of course, there is usually a firewall which | |||
| be taken to ensure that such a firewall is operating properly. | connects these partitions. Great care must be taken to ensure that | |||
| such a firewall is operating properly. | ||||
| There is increasing interest in using intranets to connect different | ||||
| parts of a organization (e.g., divisions of a company). While this | ||||
| document generally differentiates between external and internal | ||||
| (public and private), sites using intranets should be aware that they | ||||
| will need to consider three separations and take appropriate actions | ||||
| when designing and offering services. A service offered to an | ||||
| intranet would be neither public, nor as completely private as a | ||||
| service to a single organizational subunit. Therefore, the service | ||||
| would need its own supporting system, separated from both external | ||||
| and internal services and networks. | ||||
| One form of external service deserves some special consideration, and | One form of external service deserves some special consideration, and | |||
| that is anonymous, or guest, access. This may be either anonymous | that is anonymous, or guest, access. This may be either anonymous | |||
| FTP or guest (unauthenticated) login. It is extremely important to | FTP or guest (unauthenticated) login. It is extremely important to | |||
| ensure that anonymous FTP servers and guest login userids are | ensure that anonymous FTP servers and guest login userids are | |||
| carefully isolated from any hosts and file systems from which outside | carefully isolated from any hosts and file systems from which outside | |||
| users should be kept. Another area to which special attention must | users should be kept. Another area to which special attention must | |||
| be paid concerns anonymous, writable access. A site may be legally | be paid concerns anonymous, writable access. A site may be legally | |||
| responsible for the content of publicly available information, so | responsible for the content of publicly available information, so | |||
| careful monitoring of the information deposited by anonymous users is | careful monitoring of the information deposited by anonymous users is | |||
| advised. | advised. | |||
| Now we shall consider some of the most popular services: name | Now we shall consider some of the most popular services: name | |||
| service, password/key service, authentication/proxy service, | service, password/key service, authentication/proxy service, | |||
| electronic mail, WWW, file transfer, and NFS. Since these are the | electronic mail, WWW, file transfer, and NFS. Since these are the | |||
| most frequently used services, they are the most obvious points of | most frequently used services, they are the most obvious points of | |||
| attack. Also, a successful attack on one of these services can | attack. Also, a successful attack on one of these services can | |||
| produce disaster all out of proportion to the innocence of the basic | produce disaster all out of proportion to the innocence of the basic | |||
| service. | service. | |||
| 3.2.3.1 Name Servers (DNS and NIS(+)) | 3.2.3.1 Name Servers (DNS and NIS(+)) | |||
| The Internet uses the Domain Name System (DNS) to perform address | The Internet uses the Domain Name System (DNS) to perform address | |||
| resolution for host and network names. The Network Information | resolution for host and network names. The Network Information | |||
| Service (NIS) and NIS+ are not used on the global Internet, but are | Service (NIS) and NIS+ are not used on the global Internet, but are | |||
| subject to the same risks as a DNS server. Name-to-address | subject to the same risks as a DNS server. Name-to-address | |||
| resolution is critical to the secure operation of any network. An | resolution is critical to the secure operation of any network. An | |||
| attacker who can successfully control or impersonate a DNS server can | attacker who can successfully control or impersonate a DNS server can | |||
| re-route traffic to subvert security protections. For example, | re-route traffic to subvert security protections. For example, | |||
| routine traffic can be diverted to a compromised system to be | routine traffic can be diverted to a compromised system to be | |||
| monitored; or, users can be tricked into providing authentication | monitored; or, users can be tricked into providing authentication | |||
| secrets. An organization should create well known, protected sites | secrets. An organization should create well known, protected sites | |||
| to act as secondary name servers and protect their DNS masters from | to act as secondary name servers and protect their DNS masters from | |||
| denial of service attacks using filtering routers. | denial of service attacks using filtering routers. | |||
| 3.2.3.2 Password/Key Servers (NIS(+) and KDC) | Traditionally, DNS has had no security capabilities. In particular, | |||
| the information returned from a query could not be checked for | ||||
| modification or verified that it had come from the name server in | ||||
| question. Work has been done to incorporate digital signatures into | ||||
| the protocol which, when deployed, will allow the integrity of the | ||||
| information to be cryptographically verified (see RFC 2065). | ||||
| 3.2.3.2 Password/Key Servers (NIS(+) and KDC) | ||||
| Password and key servers generally protect their vital information | Password and key servers generally protect their vital information | |||
| (i.e., the passwords and keys) with encryption algorithms. However, | (i.e., the passwords and keys) with encryption algorithms. However, | |||
| even a one-way encrypted password can be determined by a dictionary | even a one-way encrypted password can be determined by a dictionary | |||
| attack (wherein common words are encrypted to see if they match the | attack (wherein common words are encrypted to see if they match the | |||
| stored encryption). It is therefore necessary to ensure that these | stored encryption). It is therefore necessary to ensure that these | |||
| servers are not accessable by hosts which do not plan to use them for | servers are not accessable by hosts which do not plan to use them for | |||
| the service, and even those hosts should only be able to access the | the service, and even those hosts should only be able to access the | |||
| service (i.e., general services, such as Telnet and FTP, should not | service (i.e., general services, such as Telnet and FTP, should not | |||
| be allowed by anyone other than administrators). | be allowed by anyone other than administrators). | |||
| 3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK) | 3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK) | |||
| A proxy server provides a number of security enhancements. It allows | A proxy server provides a number of security enhancements. It allows | |||
| sites to concentrate services through a specific host to allow | sites to concentrate services through a specific host to allow | |||
| monitoring, hiding of internal structure, etc. This funnelling of | monitoring, hiding of internal structure, etc. This funnelling of | |||
| services creates an attractive target for a potential intruder. The | services creates an attractive target for a potential intruder. The | |||
| type of protection required for a proxy server depends greatly on the | type of protection required for a proxy server depends greatly on the | |||
| proxy protocol in use and the services being proxied. The general | proxy protocol in use and the services being proxied. The general | |||
| rule of limiting access only to those hosts which need the services, | rule of limiting access only to those hosts which need the services, | |||
| and limiting access by those hosts to only those services, is a good | and limiting access by those hosts to only those services, is a good | |||
| starting point. | starting point. | |||
| 3.2.3.4 Electronic Mail | 3.2.3.4 Electronic Mail | |||
| Electronic mail (email) systems have long been a source for intruder | Electronic mail (email) systems have long been a source for intruder | |||
| break-ins because email protocols are among the oldest and most | break-ins because email protocols are among the oldest and most | |||
| widely deployed services. Also, by it's very nature, an email server | widely deployed services. Also, by it's very nature, an email server | |||
| requires access to the outside world; most email servers accept input | requires access to the outside world; most email servers accept input | |||
| from any source. An email server generally consists of two parts: a | from any source. An email server generally consists of two parts: a | |||
| receiving/sending agent and a processing agent. Since email is | receiving/sending agent and a processing agent. Since email is | |||
| delivered to all users, and is usually private, the processing agent | delivered to all users, and is usually private, the processing agent | |||
| typically requires system (root) privileges to deliver the mail. | typically requires system (root) privileges to deliver the mail. | |||
| Most email implementations perform both portions of the service, | Most email implementations perform both portions of the service, | |||
| which means the receiving agent also has system privileges. This | which means the receiving agent also has system privileges. This | |||
| opens several security holes which this document will not describe. | opens several security holes which this document will not describe. | |||
| There are some implementations available which allow a separation of | There are some implementations available which allow a separation of | |||
| the two agents. Such implementations are generally considered more | the two agents. Such implementations are generally considered more | |||
| secure, but still require careful installation to avoid creating a | secure, but still require careful installation to avoid creating a | |||
| security problem. | security problem. | |||
| 3.2.3.5 World Wide Web (WWW) | 3.2.3.5 World Wide Web (WWW) | |||
| The Web is growing in popularity exponentially because of its ease of | The Web is growing in popularity exponentially because of its ease of | |||
| use and the powerful abilities to concentrate information services. | use and the powerful ability to concentrate information services. | |||
| Most WWW servers take some directions and actions from the persons | Most WWW servers accept some type of direction and action from the | |||
| accessing their services. The most common example is taking a | persons accessing their services. The most common example is taking | |||
| request from a remote user and passing the provided information to a | a request from a remote user and passing the provided information to | |||
| program running on the server to process the request. Some of these | a program running on the server to process the request. Some of | |||
| programs are not written with security in mind and can create | these programs are not written with security in mind and can create | |||
| security holes. If a Web server is available to the Internet | security holes. If a Web server is available to the Internet | |||
| community, it is especially important that confidential information | community, it is especially important that confidential information | |||
| not be co-located on the same host as the server. In fact, it is | not be co-located on the same host as that server. In fact, it is | |||
| recommended that the server have a dedicated host which is not | recommended that the server have a dedicated host which is not | |||
| "trusted" by other internal hosts. It may be co-located with an | "trusted" by other internal hosts. | |||
| anonymous FTP server, since both protocols share common security | ||||
| considerations. | ||||
| 3.2.3.6 File Transfer (FTP, TFTP) | Many sites may want to co-locate FTP service with their WWW service. | |||
| But this should only occur for anon-ftp servers that only provide | ||||
| information (ftp-get). Anon-ftp puts, in combination with WWW, might | ||||
| be dangerous (e.g., they could result in modifications to the | ||||
| information your site is publishing to the web) and in themselves | ||||
| make the security considerations for each service different. | ||||
| 3.2.3.6 File Transfer (FTP, TFTP) | ||||
| FTP and TFTP both allow users to receive and send electronic files in | FTP and TFTP both allow users to receive and send electronic files in | |||
| a point-to-point manner. However, FTP requires authentication while | a point-to-point manner. However, FTP requires authentication while | |||
| TFTP requires none. For this reason, TFTP should be avoided as much | TFTP requires none. For this reason, TFTP should be avoided as much | |||
| as possible. | as possible. | |||
| Improperly configured FTP servers can allow intruders to copy, | Improperly configured FTP servers can allow intruders to copy, | |||
| replace and delete files at will, anywhere on a host, so it is very | replace and delete files at will, anywhere on a host, so it is very | |||
| important to configure this service correctly. Access to encrypted | important to configure this service correctly. Access to encrypted | |||
| passwords and proprietary data, and the introduction of trojan horses | passwords and proprietary data, and the introduction of trojan horses | |||
| are just a few of the potential security holes that can occur when | are just a few of the potential security holes that can occur when | |||
| the service is configured incorrectly. FTP servers should reside on | the service is configured incorrectly. FTP servers should reside on | |||
| their own host, or perhaps be co-located with a Web server, since the | their own host. Some sites choose to co-locate FTP with a Web | |||
| two protocols share common security considerations. As mentioned in | server, since the two protocols share common security considerations | |||
| the opening paragraphs of section 3.2.3, services offered internally | However, the the practice isn't recommended, especially when the FTP | |||
| to your site should not be co-located with services offered | service allows the deposit of files (see section on WWW above). As | |||
| externally. Each should have its own host. | mentioned in the opening paragraphs of section 3.2.3, services | |||
| offered internally to your site should not be co-located with | ||||
| services offered externally. Each should have its own host. | ||||
| TFTP does not support the same range of functions and has no security | TFTP does not support the same range of functions as FTP, and has no | |||
| whatsoever. This service should only be considered for internal use, | security whatsoever. This service should only be considered for | |||
| and then it should be configured in a restricted way so that the | internal use, and then it should be configured in a restricted way so | |||
| server only has access to a set of predetermined files (instead of | that the server only has access to a set of predetermined files | |||
| every world-readable file on the system). Probably the most common | (instead of every world-readable file on the system). Probably the | |||
| usage of TFTP is for downloading router configuration files to a | most common usage of TFTP is for downloading router configuration | |||
| router. TFTP should reside on its own host, and should not be | files to a router. TFTP should reside on its own host, and should | |||
| installed on hosts supporting external FTP or Web access. | not be installed on hosts supporting external FTP or Web access. | |||
| 3.2.3.7 NFS | 3.2.3.7 NFS | |||
| The Network File Service allows hosts to share common disks. NFS is | The Network File Service allows hosts to share common disks. NFS is | |||
| most frequently used by diskless hosts who depend on a disk server | frequently used by diskless hosts who depend on a disk server for all | |||
| for all of their storage needs. Unfortunately, NFS has no built-in | of their storage needs. Unfortunately, NFS has no built-in security. | |||
| security. It is therefore necessary that the NFS server be | It is therefore necessary that the NFS server be accessable only by | |||
| accessable only by those hosts which are using it for service. It is | those hosts which are using it for service. This is achieved by | |||
| especially important that external hosts be unable to reach the NFS | specifying which hosts the file system is being exported to and in | |||
| host by any means. Ideally, such access attempts would be stopped by | what manner (e.g., read-only, read-write, etc.). Filesystems should | |||
| a firewall. | not be exported to any hosts outside the local network since this | |||
| will require that the NFS service be accessible externally. Ideally, | ||||
| external access to NFS service should be stopped by a firewall. | ||||
| 3.2.4 Protecting the Protection | 3.2.4 Protecting the Protection | |||
| It is amazing how often a site will overlook the most obvious | It is amazing how often a site will overlook the most obvious | |||
| weakness in its security by leaving the security server itself open | weakness in its security by leaving the security server itself open | |||
| to attack. Based on considerations previously discussed, it should | to attack. Based on considerations previously discussed, it should | |||
| be clear that: the security server should not be accessible from | be clear that: the security server should not be accessible from | |||
| off-site; should offer minimum access, except for the authentication | off-site; should offer minimum access, except for the authentication | |||
| function, to users on-site; and should not be co-located with any | function, to users on-site; and should not be co-located with any | |||
| other servers. Further, all access to the node, including access to | other servers. Further, all access to the node, including access to | |||
| skipping to change at page 17, line 4 ¶ | skipping to change at page 18, line 29 ¶ | |||
| the quest for system security. They provide a certain level of | the quest for system security. They provide a certain level of | |||
| protection and are, in general, a way of implementing security policy | protection and are, in general, a way of implementing security policy | |||
| at the network level. The level of security that a firewall provides | at the network level. The level of security that a firewall provides | |||
| can vary as much as the level of security on a particular machine. | can vary as much as the level of security on a particular machine. | |||
| There are the traditional trade-offs between security, ease of use, | There are the traditional trade-offs between security, ease of use, | |||
| cost, complexity, etc. | cost, complexity, etc. | |||
| A firewall is any one of several mechanisms used to control and watch | A firewall is any one of several mechanisms used to control and watch | |||
| access to and from a network for the purpose of protecting it. A | access to and from a network for the purpose of protecting it. A | |||
| firewall acts as a gateway through which all traffic to and from the | firewall acts as a gateway through which all traffic to and from the | |||
| protected network or machines passes. Firewalls help to place | protected network and/or systems passes. Firewalls help to place | |||
| limitations on the amount and type of communication that takes place | limitations on the amount and type of communication that takes place | |||
| between the protected network and the another network (e.g., the | between the protected network and the another network (e.g., the | |||
| Internet, or another piece of the site's network). | Internet, or another piece of the site's network). | |||
| A firewall is generally a way to build a wall between one part of a | A firewall is generally a way to build a wall between one part of a | |||
| network, a company=D5s internal network, for example, and another part, | network, a company's internal network, for example, and another part, | |||
| the global Internet, for example. The unique feature about this wall | the global Internet, for example. The unique feature about this wall | |||
| is that there needs to be ways for some traffic with particular | is that there needs to be ways for some traffic with particular | |||
| characteristics to pass through carefully monitored doors | characteristics to pass through carefully monitored doors | |||
| ("gateways"). The difficult part is to establish the criteria by | ("gateways"). The difficult part is establishing the criteria by | |||
| which the packets are allowed or denied access through the doors. | which the packets are allowed or denied access through the doors. | |||
| Different books written on firewalls use different terminology to | Books written on firewalls use different terminology to describe the | |||
| describe the various forms of firewalls. This can be confusing to | various forms of firewalls. This can be confusing to system | |||
| system administrators who are not familiar with firewalls. The thing | administrators who are not familiar with firewalls. The thing to note | |||
| to note here is that there is no fixed terminology for the | here is that there is no fixed terminology for the description of | |||
| description of firewalls. | firewalls. | |||
| Firewalls are not always, or even typically, a single machine, but in | Firewalls are not always, or even typically, a single machine. | |||
| general are a combination of routers, networks, and host machines, so | Rather, firewalls are often a combination of routers, network | |||
| for the purposes of this discussion, the term "firewall" can consist | segments, and host computers. Therefore, for the purposes of this | |||
| of more than one physical device. Firewalls are typically built | discussion, the term "firewall" can consist of more than one physical | |||
| using two different components, filtering routers and proxy servers. | device. Firewalls are typically built using two different | |||
| components, filtering routers and proxy servers. | ||||
| Filtering routers are the easiest component to conceptualize in a | Filtering routers are the easiest component to conceptualize in a | |||
| firewall. A router moves data back and forth between two (or more) | firewall. A router moves data back and forth between two (or more) | |||
| different networks. A "normal" router takes a packet from network A | different networks. A "normal" router takes a packet from network A | |||
| and "routes" it to its destination on network B. A filtering router | and "routes" it to its destination on network B. A filtering router | |||
| does the same thing but decides not only how to route the packet, but | does the same thing but decides not only how to route the packet, but | |||
| should it route the packet. This is done by installing a series of | whether it should route the packet. This is done by installing a | |||
| filters by which the router decides what to do with any given packet | series of filters by which the router decides what to do with any | |||
| of data. | given packet of data. | |||
| A discussion concerning capabilities of a particular brand of router, | A discussion concerning capabilities of a particular brand of router, | |||
| running a particular software version is outside the scope of this | running a particular software version is outside the scope of this | |||
| document. However, when evaluating a router to be used for filtering | document. However, when evaluating a router to be used for filtering | |||
| packets, the following criteria can be important when implementing a | packets, the following criteria can be important when implementing a | |||
| filtering policy: source and destination IP address, source and | filtering policy: source and destination IP address, source and | |||
| destination TCP port numbers, state of the TCP "ack" bit, UDP source | destination TCP port numbers, state of the TCP "ack" bit, UDP source | |||
| and destination port numbers, and direction of packet flow (i.e.. A- | and destination port numbers, and direction of packet flow (i.e.. A- | |||
| >B or B->A). Other information necessary to construct a secure | >B or B->A). Other information necessary to construct a secure | |||
| filtering scheme are whether the router reorders filter instructions | filtering scheme are whether the router reorders filter instructions | |||
| skipping to change at page 18, line 20 ¶ | skipping to change at page 19, line 46 ¶ | |||
| has to be protected very carefully. To make resources available to | has to be protected very carefully. To make resources available to | |||
| legitimate users across this firewall, services have to be forwarded | legitimate users across this firewall, services have to be forwarded | |||
| by the bastion host. Some servers have forwarding built in (like | by the bastion host. Some servers have forwarding built in (like | |||
| DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP, | DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP, | |||
| etc.), proxy servers can be used to allow access to the resources | etc.), proxy servers can be used to allow access to the resources | |||
| across the firewall in a secure way. | across the firewall in a secure way. | |||
| A proxy server is way to concentrate application services through a | A proxy server is way to concentrate application services through a | |||
| single machine. There is typically a single machine (the bastion | single machine. There is typically a single machine (the bastion | |||
| host) that acts as a proxy server for a variety of protocols (Telnet, | host) that acts as a proxy server for a variety of protocols (Telnet, | |||
| SMTP, FTP, HTTP, etc.) but there can be individual machines for each | SMTP, FTP, HTTP, etc.) but there can be individual host computers for | |||
| service. Instead of connecting directly to an external server, the | each service. Instead of connecting directly to an external server, | |||
| client connects to the proxy server which in turn initiates a | the client connects to the proxy server which in turn initiates a | |||
| connection to the requested external server. Depending on the type | connection to the requested external server. Depending on the type | |||
| of proxy server used, it is possible to configure internal clients to | of proxy server used, it is possible to configure internal clients to | |||
| perform this redirection automatically, without knowledge to the | perform this redirection automatically, without knowledge to the | |||
| user, others might require that the user connect directly to the | user, others might require that the user connect directly to the | |||
| proxy server and then initiate the connection through a specified | proxy server and then initiate the connection through a specified | |||
| format. | format. | |||
| There are significant security benefits which can be derived from | There are significant security benefits which can be derived from | |||
| using proxy servers. It is possible to add access control lists to | using proxy servers. It is possible to add access control lists to | |||
| protocols, requiring users or machines to provide some level of | protocols, requiring users or systems to provide some level of | |||
| authentication before access is granted. Smarter proxy servers, | authentication before access is granted. Smarter proxy servers, | |||
| sometimes called Application Layer Gateways (ALGs), can be written | sometimes called Application Layer Gateways (ALGs), can be written | |||
| which understand specific protocols and can be configured to block | which understand specific protocols and can be configured to block | |||
| only subsections of the protocol. For example, an ALG for FTP can | only subsections of the protocol. For example, an ALG for FTP can | |||
| tell the difference between the "put" command and the "get" command; | tell the difference between the "put" command and the "get" command; | |||
| an organization may wish to allow users to "get" files from the | an organization may wish to allow users to "get" files from the | |||
| Internet, but not be able to "put" internal files on a remote server. | Internet, but not be able to "put" internal files on a remote server. | |||
| By contrast, a filtering router could either block all FTP access, or | By contrast, a filtering router could either block all FTP access, or | |||
| none, but not a subset. | none, but not a subset. | |||
| skipping to change at page 19, line 54 ¶ | skipping to change at page 21, line 27 ¶ | |||
| implementing security for a site and they protect against a large | implementing security for a site and they protect against a large | |||
| variety of attacks. But it is important to keep in mind that they | variety of attacks. But it is important to keep in mind that they | |||
| are only one part of the solution. They cannot protect your site | are only one part of the solution. They cannot protect your site | |||
| against all types of attack. | against all types of attack. | |||
| 4. Security Services and Procedures | 4. Security Services and Procedures | |||
| This chapter guides the reader through a number of topics that should | This chapter guides the reader through a number of topics that should | |||
| be addressed when securing a site. Each section touches on a | be addressed when securing a site. Each section touches on a | |||
| security service or capability that may be required to protect the | security service or capability that may be required to protect the | |||
| information and systems at a site. These are presented at a fairly | information and systems at a site. The topics are presented at a | |||
| high-level to introduce the reader to the concepts. | fairly high-level to introduce the reader to the concepts. | |||
| Throughout the chapter, you will find considerable mention of | Throughout the chapter, you will find significant mention of | |||
| cryptography. It is outside the scope of this document to delve into | cryptography. It is outside the scope of this document to delve into | |||
| details concerning cryptography, but the interested reader can obtain | details concerning cryptography, but the interested reader can obtain | |||
| more information from books and articles listed in the reference | more information from books and articles listed in the reference | |||
| section of this document. | section of this document. | |||
| 4.1 Authentication | 4.1 Authentication | |||
| For many years, the prescribed method for authenticating users has | For many years, the prescribed method for authenticating users has | |||
| been through the use of standard, reusable passwords. Originally, | been through the use of standard, reusable passwords. Originally, | |||
| these passwords were used by users at terminals to authenticate | these passwords were used by users at terminals to authenticate | |||
| themselves to a central computer. At the time, there were no | themselves to a central computer. At the time, there were no | |||
| networks (internally or externally), so the risk of disclosure of the | networks (internally or externally), so the risk of disclosure of the | |||
| clear text password was minimal. Today, systems are connected | clear text password was minimal. Today, systems are connected | |||
| together through local networks, and these local networks are further | together through local networks, and these local networks are further | |||
| connected together and to the Internet. Users are logging in from | connected together and to the Internet. Users are logging in from | |||
| all over the globe; their reusable passwords are often transmitted | all over the globe; their reusable passwords are often transmitted | |||
| across those same networks in clear text, ripe for anyone in-between | across those same networks in clear text, ripe for anyone in-between | |||
| to capture. And indeed, the CERT Coordination Center and other | to capture. And indeed, the CERT Coordination Center and other | |||
| response teams are seeing a tremendous number of incidents involving | response teams are seeing a tremendous number of incidents involving | |||
| packet sniffers which are capturing the clear text passwords. To | packet sniffers which are capturing the clear text passwords. | |||
| address this threat, we are including sections on better | ||||
| technologies, like one-time passwords and Kerberos. | ||||
| With the advent of newer technologies like one-time passwords (e.g., | With the advent of newer technologies like one-time passwords (e.g., | |||
| S/Key), PGP, and token-based authentication devices, people are using | S/Key), PGP, and token-based authentication devices, people are using | |||
| password-like strings as secret tokens and pins. We are including a | password-like strings as secret tokens and pins. If these secret | |||
| discussion on these since they are the foundation upon which stronger | tokens and pins are not properly selected and protected, the | |||
| authentication techniques are based. If these secret tokens and pins | authentication will be easily subverted. | |||
| are not properly selected and protected, the authentication will be | ||||
| easily subverted. | ||||
| 4.1.1 One-Time passwords | 4.1.1 One-Time passwords | |||
| As mentioned above, given today's networked environments, it is | As mentioned above, given today's networked environments, it is | |||
| recommended that sites concerned about the security and integrity of | recommended that sites concerned about the security and integrity of | |||
| their systems and networks consider moving away from standard, | their systems and networks consider moving away from standard, | |||
| reusable passwords. There have been many incidents involving Trojan | reusable passwords. There have been many incidents involving Trojan | |||
| network programs (e.g., telnet and rlogin) and network packet | network programs (e.g., telnet and rlogin) and network packet | |||
| sniffing programs. These programs capture clear text | sniffing programs. These programs capture clear text | |||
| hostname/account name/password triplets. Intruders can use the | hostname/account name/password triplets. Intruders can use the | |||
| captured information for subsequent access to those hosts and | captured information for subsequent access to those hosts and | |||
| accounts. This is possible because 1) the password is used over and | accounts. This is possible because 1) the password is used over and | |||
| over (hence the term "reusable"), and 2) the password passes across | over (hence the term "reusable"), and 2) the password passes across | |||
| the network in clear text. | the network in clear text. | |||
| Several authentication techniques have been developed that address | Several authentication techniques have been developed that address | |||
| this problem. Among these techniques are challenge-response | this problem. Among these techniques are challenge-response | |||
| technologies that provide passwords that are only used once (commonly | technologies that provide passwords that are only used once (commonly | |||
| called one-time passwords). This document provides a list of sources | called one-time passwords). There are a number of products available | |||
| for products that provide this capability. The decision to use a | that sites should consider using. The decision to use a product is | |||
| product is the responsibility of each organization, and each | the responsibility of each organization, and each organization should | |||
| organization should perform its own evaluation and selection. | perform its own evaluation and selection. | |||
| 4.1.2 Kerberos | 4.1.2 Kerberos | |||
| Kerberos is a distributed network security system which provides for | Kerberos is a distributed network security system which provides for | |||
| authentication across unsecured networks. If requested by the | authentication across unsecured networks. If requested by the | |||
| application, integrity and encryption can also be provided. Kerberos | application, integrity and encryption can also be provided. Kerberos | |||
| was originally developed at the Massachusetts Institute of Technology | was originally developed at the Massachusetts Institute of Technology | |||
| (MIT) in the late 1980's. There are two major releases of Kerberos, | (MIT) in the mid 1980's. There are two major releases of Kerberos, | |||
| version 4 and 5, which are for practical purposes, incompatible. | version 4 and 5, which are for practical purposes, incompatible. | |||
| Kerberos relies on a symmetric key database using a key distribution | Kerberos relies on a symmetric key database using a key distribution | |||
| center (KDC) which is known as the Kerberos server. A user or | center (KDC) which is known as the Kerberos server. A user or | |||
| service (known as "principals") are granted electronic "tickets" | service (known as "principals") are granted electronic "tickets" | |||
| after properly communicating with the KDC. These tickets are used | after properly communicating with the KDC. These tickets are used | |||
| for authentication between principals. All tickets include a time | for authentication between principals. All tickets include a time | |||
| stamp which limits the time period for which the ticket is valid. | stamp which limits the time period for which the ticket is valid. | |||
| Therefore, Kerberos clients and server must have a secure time | Therefore, Kerberos clients and server must have a secure time | |||
| source, and be able to keep time accurately. | source, and be able to keep time accurately. | |||
| skipping to change at page 21, line 39 ¶ | skipping to change at page 23, line 9 ¶ | |||
| When selecting secret tokens, take care to choose them carefully. | When selecting secret tokens, take care to choose them carefully. | |||
| Like the selection of passwords, they should be robust against brute | Like the selection of passwords, they should be robust against brute | |||
| force efforts to guess them. That is, they should not be single | force efforts to guess them. That is, they should not be single | |||
| words in any language, any common, industry, or cultural acronyms, | words in any language, any common, industry, or cultural acronyms, | |||
| etc. Ideally, they will be longer rather than shorter and consist of | etc. Ideally, they will be longer rather than shorter and consist of | |||
| pass phrases that combine upper and lower case character, digits, and | pass phrases that combine upper and lower case character, digits, and | |||
| other characters. | other characters. | |||
| Once chosen, the protection of these secret tokens is very important. | Once chosen, the protection of these secret tokens is very important. | |||
| Some are used as pins to hardware devices (like token cards) and | Some are used as pins to hardware devices (like token cards) and | |||
| these should not be written down and placed in the same location as | these should not be written down or placed in the same location as | |||
| the device with which they are associated. Others, such as a secret | the device with which they are associated. Others, such as a secret | |||
| PGP key, should be protected from unauthorized access. | Pretty Good Privacy (PGP) key, should be protected from unauthorized | |||
| access. | ||||
| One final word on this subject. When using cryptography products, | One final word on this subject. When using cryptography products, | |||
| like PGP, take care to determine the proper key length and ensure | like PGP, take care to determine the proper key length and ensure | |||
| that your users are trained to do likewise. As technology advances, | that your users are trained to do likewise. As technology advances, | |||
| the minimum safe key length continues to grow. Make sure your site | the minimum safe key length continues to grow. Make sure your site | |||
| keeps up with the current state of knowledge on the subject so that | keeps up with the latest knowledge on the technology so that you can | |||
| you can ensure any cryptography used will be providing you the | ensure that any cryptography in use is providing the protection you | |||
| protection you are assuming it is. | believe it is. | |||
| 4.1.4 Password Assurance | 4.1.4 Password Assurance | |||
| While the need to eliminate the use of standard, reusable passwords | While the need to eliminate the use of standard, reusable passwords | |||
| cannot be overstated, it is recognized that some organizations may | cannot be overstated, it is recognized that some organizations may | |||
| have to transition to the use of better technology. Given that | still be using them. While it's recommended that these organizations | |||
| situation, we have included the following advice to help with the | transition to the use of better technology, in the mean time, we have | |||
| selection and maintenance of traditional passwords. But remember, | the following advice to help with the selection and maintenance of | |||
| none of these measures provides protection against disclosure due to | traditional passwords. But remember, none of these measures provides | |||
| sniffer programs. | protection against disclosure due to sniffer programs. | |||
| (1) The importance of robust passwords - In many (if not most) cases o= | (1) The importance of robust passwords - In many (if not most) cases of | |||
| f | system penetration, the intruder needs to gain access to an account | |||
| system penetration, the intruder needs to gain access to an accoun= | ||||
| t | ||||
| on the system. One way that goal is typically accomplished is | on the system. One way that goal is typically accomplished is | |||
| through guessing the password of a legitimate user. This is often | through guessing the password of a legitimate user. This is often | |||
| accomplished by running an automated password cracking program, | accomplished by running an automated password cracking program, | |||
| which utilizes a very large dictionary, against the system's passw= | which utilizes a very large dictionary, against the system's password | |||
| ord | file. The only way to guard against passwords being disclosed in this | |||
| file. The only way to guard against passwords being disclosed in = | manner is through the careful selection of passwords which cannot be | |||
| this | easily guessed (i.e., combinations of numbers, letters, and punctuation | |||
| manner is through the careful selection of passwords which cannot = | characters). Passwords should also be as long as the system supports | |||
| be | and users can tolerate. | |||
| easily guessed (i.e., combinations of numbers, letters, and punctu= | ||||
| ation | ||||
| characters). | ||||
| (2) Changing default passwords - Many operating systems and applicatio= | (2) Changing default passwords - Many operating systems and application | |||
| n | ||||
| programs are installed with default accounts and passwords. These | programs are installed with default accounts and passwords. These | |||
| must be changed immediately to something that cannot be guessed or | must be changed immediately to something that cannot be guessed or | |||
| cracked. | cracked. | |||
| (3) Restricting access to the password file - In particular, a site | (3) Restricting access to the password file - In particular, a site | |||
| wants to protect the encrypted password portion of the file so tha= | wants to protect the encrypted password portion of the file so that | |||
| t | ||||
| would-be intruders don't have them available for cracking. One | would-be intruders don't have them available for cracking. One | |||
| effective technique is to use shadow passwords where the password | effective technique is to use shadow passwords where the password | |||
| field of the standard file contains a dummy or false password. Th= | field of the standard file contains a dummy or false password. The | |||
| e | file containing the legitimate passwords are protected elsewhere on | |||
| file containing the legitimate passwords are protected elsewhere o= | ||||
| n | ||||
| the system. | the system. | |||
| (4) Password aging - When and how to expire passwords is still a subje= | (4) Password aging - When and how to expire passwords is still a subject | |||
| ct | of controversy among the security community. It is generally accepted | |||
| of controversy among the security community. It is generally acce= | that a password should not be maintained once an account is no longer in | |||
| pted | use, but it is hotly debated whether a user should be forced to change a | |||
| that a password should not be maintained once an account is no lon= | ||||
| ger in | ||||
| use, but it is hotly debated whether a user should be forced to ch= | ||||
| ange a | ||||
| good password that's in active use. The arguments for changing | good password that's in active use. The arguments for changing | |||
| passwords relate to the prevention of the continued use of penetra= | passwords relate to the prevention of the continued use of penetrated | |||
| ted | ||||
| accounts. However, the opposition claims that frequent password | accounts. However, the opposition claims that frequent password | |||
| changes lead to users writing down their passwords in visible area= | changes lead to users writing down their passwords in visible areas | |||
| s | (such as pasting them to a terminal), or to users selecting very simple | |||
| (such as pasting them to a terminal), or to users selecting very s= | passwords that are easy to guess. It should also be stated that an | |||
| imple | intruder will probably use a captured or guessed password sooner rather | |||
| passwords that are easy to guess. It should also be stated that a= | ||||
| n | ||||
| intruder will probably use a captured or guessed password sooner r= | ||||
| ather | ||||
| than later, in which case password aging provides little if any | than later, in which case password aging provides little if any | |||
| protection. | protection. | |||
| While there is no definitive answer to this dilemma, a password po= | While there is no definitive answer to this dilemma, a password policy | |||
| licy | should directly address the issue and provide guidelines for how often | |||
| should directly address the issue and provide guidelines for how o= | a user should change the password. Certainly, an annual change in | |||
| ften | their password is usually not difficult for most users, and you | |||
| a user should change the password. It is recommended that passwor= | should consider requiring it. It is recommended that passwords | |||
| ds | be changed at least whenever a privileged account is compromised, | |||
| be changed whenever root is penetrated, there is a critical change= | there is a critical change in personnel (especially if it is an | |||
| in | administrator!), or when an account has been compromised. In | |||
| personnel (especially if it is the system administrator!), or when= | addition, if a privileged account password is compromised, | |||
| an | all passwords on the system should be changed. | |||
| account has been compromised. In particular, if the root password= | ||||
| is | ||||
| compromised, all passwords on the system should be changed. In | ||||
| addition, an annual change in their password is usually not diffic= | ||||
| ult | ||||
| for most users, and you should consider requiring it. | ||||
| 4.2 Confidentiality | 4.2 Confidentiality | |||
| There will be information assets that your site will want to protect | There will be information assets that your site will want to protect | |||
| from disclosure to unauthorized entities. Operating systems often | from disclosure to unauthorized entities. Operating systems often | |||
| have built-in file protection mechanisms that allow an administrator | have built-in file protection mechanisms that allow an administrator | |||
| to control who on the system can access, or "see," the contents of a | to control who on the system can access, or "see," the contents of a | |||
| given file. A stronger way to provide confidentiality is through | given file. A stronger way to provide confidentiality is through | |||
| encryption. Encryption is accomplished by scrambling data so that it | encryption. Encryption is accomplished by scrambling data so that it | |||
| is very difficult and time consuming for anyone other than the | is very difficult and time consuming for anyone other than the | |||
| skipping to change at page 23, line 23 ¶ | skipping to change at page 24, line 50 ¶ | |||
| the text to a readable (clear text) form. We recommend that sites | the text to a readable (clear text) form. We recommend that sites | |||
| use encryption to provide confidentiality and protect valuable | use encryption to provide confidentiality and protect valuable | |||
| information. | information. | |||
| The use of encryption is sometimes controlled by governmental and | The use of encryption is sometimes controlled by governmental and | |||
| site regulations, so we encourage administrators to become informed | site regulations, so we encourage administrators to become informed | |||
| of laws or policies that regulate its use before employing it. It is | of laws or policies that regulate its use before employing it. It is | |||
| outside the scope of this document to discuss the various algorithms | outside the scope of this document to discuss the various algorithms | |||
| and programs available for this purpose, but we do caution against | and programs available for this purpose, but we do caution against | |||
| the casual use of the UNIX crypt program as it has been found to be | the casual use of the UNIX crypt program as it has been found to be | |||
| easily broken. We also encourage you to take time to understand the | easily broken. We also encourage everyone to take time to understand | |||
| strength of the encryption in any given algorithm/product before | the strength of the encryption in any given algorithm/product before | |||
| using it. Most well-known products are well-documented in the | using it. Most well-known products are well-documented in the | |||
| literature, so this should be a fairly easy task. | literature, so this should be a fairly easy task. | |||
| 4.3 Integrity | 4.3 Integrity | |||
| As an administrator, you will want to make sure that information | As an administrator, you will want to make sure that information | |||
| (e.g., operating system files, company data, etc.) has not been | (e.g., operating system files, company data, etc.) has not been | |||
| altered in an unauthorized fashion. This means you will want to | altered in an unauthorized fashion. This means you will want to | |||
| provide some assurance as to the integrity of the information on your | provide some assurance as to the integrity of the information on your | |||
| systems. One way to provide this is to produce a checksum of the | systems. One way to provide this is to produce a checksum of the | |||
| skipping to change at page 23, line 47 ¶ | skipping to change at page 25, line 20 ¶ | |||
| hasn't changed (which would indicate the data has been modified). | hasn't changed (which would indicate the data has been modified). | |||
| Some operating systems come with checksumming programs, such as the | Some operating systems come with checksumming programs, such as the | |||
| UNIX sum program. However, these may not provide the protection you | UNIX sum program. However, these may not provide the protection you | |||
| actually need. Files can be modified in such a way as to preserve | actually need. Files can be modified in such a way as to preserve | |||
| the result of the UNIX sum program! Therefore, we suggest that you | the result of the UNIX sum program! Therefore, we suggest that you | |||
| use a cryptographically strong program, such as the message digesting | use a cryptographically strong program, such as the message digesting | |||
| program MD5 [ref], to produce the checksums you will be using to | program MD5 [ref], to produce the checksums you will be using to | |||
| assure integrity. | assure integrity. | |||
| There are other applications when integrity will want to be assured, | There are other applications where integrity will need to be assured, | |||
| such as when transmitting an email message between two parties. There | such as when transmitting an email message between two parties. There | |||
| are products available that can provide this capability. The purpose | are products available that can provide this capability. Once you | |||
| of this section is to acquaint you with this concept so that you can | identify that this is a capability you need, you can go about | |||
| apply it where needed. Once you identify that this is a capability | identifying technologies that will provide it. | |||
| you need, you can go about identifying technologies that will provide | ||||
| it. | ||||
| 4.4 Authorization | 4.4 Authorization | |||
| Authorization refers to the process of granting privileges to | Authorization refers to the process of granting privileges to | |||
| processes and, ultimately, users. This differs from authentication | processes and, ultimately, users. This differs from authentication | |||
| in that authentication is what occurs to identify a user. Once | in that authentication is the process used to identify a user. Once | |||
| identified (reliably), the privileges, rights, property, and | identified (reliably), the privileges, rights, property, and | |||
| permissible actions of the user are determined by authorization. | permissible actions of the user are determined by authorization. | |||
| Explicitly listing the authorized activities of each user (and user | Explicitly listing the authorized activities of each user (and user | |||
| process) with respect to all resources (objects) is impossible in a | process) with respect to all resources (objects) is impossible in a | |||
| reasonable system. In a real system certain techniques are used to | reasonable system. In a real system certain techniques are used to | |||
| simplify the process of granting and checking authorization(s). | simplify the process of granting and checking authorization(s). | |||
| One approach, popularized in UNIX systems, is to assign to each | One approach, popularized in UNIX systems, is to assign to each | |||
| object three classes of user: owner, group and world. The owner is | object three classes of user: owner, group and world. The owner is | |||
| skipping to change at page 24, line 27 ¶ | skipping to change at page 25, line 52 ¶ | |||
| super-user. The owner permissions (read, write and execute) apply | super-user. The owner permissions (read, write and execute) apply | |||
| only to the owner. A group is a collection of users which share | only to the owner. A group is a collection of users which share | |||
| access rights to an object. The group permissions (read, write and | access rights to an object. The group permissions (read, write and | |||
| execute) apply to all users in the group (except the owner). The | execute) apply to all users in the group (except the owner). The | |||
| world refers to everybody else with access to the system. The world | world refers to everybody else with access to the system. The world | |||
| permissions (read, write and execute) apply to all users (except the | permissions (read, write and execute) apply to all users (except the | |||
| owner and members of the group). | owner and members of the group). | |||
| Another approach is to attach to an object a list which explicitly | Another approach is to attach to an object a list which explicitly | |||
| contains the identity of all permitted users (or groups). This is an | contains the identity of all permitted users (or groups). This is an | |||
| Access Control List. The advantage of these are that they are easily | Access Control List (ACL). The advantage of ACLs are that they are | |||
| maintained (one central list per object). | easily maintained (one central list per object) and it's very easy to | |||
| visually check who has access to what. The disadvantages are the | ||||
| extra resources required to store such lists, as well as the vast | ||||
| number of such lists required for large systems. | ||||
| 4.5 Access | 4.5 Access | |||
| 4.5.1 Physical Access | 4.5.1 Physical Access | |||
| Restrict physical access to areas containing hosts to people who are | Restrict physical access to hosts, allowing access only to those | |||
| supposed to use the hosts. Hosts include "trusted" terminals (such | people who are supposed to use the hosts. Hosts include "trusted" | |||
| as system consoles, operator terminals and terminals dedicated to | terminals (i.e., terminals which allow unauthenticated use such as | |||
| system consoles, operator terminals and terminals dedicated to | ||||
| special tasks), and individual microcomputers and workstations, | special tasks), and individual microcomputers and workstations, | |||
| especially those connected to your network. Make sure access | especially those connected to your network. Make sure people's work | |||
| restrictions mesh well with people's work patterns; otherwise they | areas mesh well with access restrictions; otherwise they will find | |||
| will find ways to circumvent your physical security (e.g., jamming | ways to circumvent your physical security (e.g., jamming doors open). | |||
| doors open). | ||||
| Keep original and backup copies of data and programs safe. Apart | Keep original and backup copies of data and programs safe. Apart | |||
| from keeping them in good condition for backup purposes, they must be | from keeping them in good condition for backup purposes, they must be | |||
| protected from theft. | protected from theft. It is important to keep backups in a separate | |||
| location from the originals, not only for damage considerations, but | ||||
| also to guard against thefts. | ||||
| Portable hosts are a particular risk. Make sure it won't cause | Portable hosts are a particular risk. Make sure it won't cause | |||
| problems if one of your staff's portable computer is stolen. | problems if one of your staff's portable computer is stolen. | |||
| Consider developing guidelines for the kinds of data that should be | Consider developing guidelines for the kinds of data that should be | |||
| allowed to reside on the disks of portable computers as well as how | allowed to reside on the disks of portable computers as well as how | |||
| the data should be protected (e.g., encryption) when it is on a | the data should be protected (e.g., encryption) when it is on a | |||
| portable computer. | portable computer. | |||
| Other areas where physical access should be restricted is the wiring | Other areas where physical access should be restricted is the wiring | |||
| closets and important network elements like file servers, name server | closets and important network elements like file servers, name server | |||
| hosts, and routers. | hosts, and routers. | |||
| 4.5.2 Walk-up Network Connections | 4.5.2 Walk-up Network Connections | |||
| By "walk-up" connections, we mean sockets located so as to provide a | By "walk-up" connections, we mean network connection points located | |||
| convenient way for users to connect a portable host to your network. | to provide a convenient way for users to connect a portable host to | |||
| your network. | ||||
| Consider whether you need to provide this service, bearing in mind | Consider whether you need to provide this service, bearing in mind | |||
| that it allows any user to attach an unauthorized host to your | that it allows any user to attach an unauthorized host to your | |||
| network. This increases the risk of attacks via techniques such as | network. This increases the risk of attacks via techniques such as | |||
| IP address spoofing, packet sniffing, etc. Users and site management | IP address spoofing, packet sniffing, etc. Users and site management | |||
| must appreciate the risks involved. If you decide to provide walk-up | must appreciate the risks involved. If you decide to provide walk-up | |||
| connections, plan the service carefully and define precisely where | connections, plan the service carefully and define precisely where | |||
| you will provide it so that you can provide the necessary physical | you will provide it so that you can ensure the necessary physical | |||
| access security. | access security. | |||
| A walk-up host should be authenticated before its user is permitted | A walk-up host should be authenticated before its user is permitted | |||
| to access resources on your network. As an alternative, it may be | to access resources on your network. As an alternative, it may be | |||
| possible to control physical access. For example, if the service is | possible to control physical access. For example, if the service is | |||
| to be used by students, you might only provide walk-up connection | to be used by students, you might only provide walk-up connection | |||
| sockets in student laboratories. | sockets in student laboratories. | |||
| Keep an eye on empty offices. It may be sensible to disconnect | If you are providing walk-up access for visitors to connect back to | |||
| connections to unused offices at the wiring closet. Consider using | their home networks (e.g., to read e-mail, etc.) in your facility, | |||
| secure hubs and monitoring attempts to connect unauthorized hosts. | consider using a separate subnet that has no connectivity to the | |||
| internal network. | ||||
| Keep an eye on any area that contains unmonitored access to the | ||||
| network, such as vacant offices. It may be sensible to disconnect | ||||
| such areas at the wiring closet, and consider using secure hubs and | ||||
| monitoring attempts to connect unauthorized hosts. | ||||
| 4.5.3 Other Network Technologies | 4.5.3 Other Network Technologies | |||
| Technologies considered here include X.25, ISDN, SMDS, DDS and Frame | Technologies considered here include X.25, ISDN, SMDS, DDS and Frame | |||
| Relay. All are provided via physical links which go through | Relay. All are provided via physical links which go through | |||
| telephone exchanges, providing the potential for them to be diverted. | telephone exchanges, providing the potential for them to be diverted. | |||
| Crackers are certainly interested in telephone switches as well as in | Crackers are certainly interested in telephone switches as well as in | |||
| data networks! | data networks! | |||
| With switched technologies, use Permanent Virtual Circuits or Closed | With switched technologies, use Permanent Virtual Circuits or Closed | |||
| User Groups whenever this is possible. Technologies which provide | User Groups whenever this is possible. Technologies which provide | |||
| authentication and/or encryption (such as IPv6) are evolving rapidly; | authentication and/or encryption (such as IPv6) are evolving rapidly; | |||
| consider using them on links where security is important. | consider using them on links where security is important. | |||
| 4.5.4 Modems | 4.5.4 Modems | |||
| 4.5.4.1 Modem lines must be managed | 4.5.4.1 Modem Lines Must Be Managed | |||
| Although they provide convenient access to a site for its users, they | Although they provide convenient access to a site for its users, they | |||
| can also provide an effective detour around the site's firewalls. | can also provide an effective detour around the site's firewalls. | |||
| For this reason it is essential to maintain proper control of modems. | For this reason it is essential to maintain proper control of modems. | |||
| Don't allow users to install a modem line without proper | Don't allow users to install a modem line without proper | |||
| authorization. This includes temporary installations (e.g., plugging | authorization. This includes temporary installations (e.g., plugging | |||
| a modem into a facsimile or telephone line overnight). | a modem into a facsimile or telephone line overnight). | |||
| Maintain a register of all your modem lines and keep your register up | Maintain a register of all your modem lines and keep your register up | |||
| to date. Conduct regular site checks for unauthorized modems. | to date. Conduct regular (ideally automated) site checks for | |||
| unauthorized modems. | ||||
| 4.5.4.2 Dial-in Users Must Be Authenticated | ||||
| 4.5.4.2 Dial-in users must be authenticated | ||||
| A username and password check should be completed before a user can | A username and password check should be completed before a user can | |||
| access anything on your network. Normal password security | access anything on your network. Normal password security | |||
| considerations are particularly important (see section 4.1.1). | considerations are particularly important (see section 4.1.1). | |||
| Remember that telephone lines can be tapped, and that it is quite | Remember that telephone lines can be tapped, and that it is quite | |||
| easy to intercept messages to cellular phones. Modern high-speed | easy to intercept messages to cellular phones. Modern high-speed | |||
| modems use more sophisticated modulation techniques, which makes them | modems use more sophisticated modulation techniques, which makes them | |||
| somewhat more difficult to monitor, but it is prudent to assume that | somewhat more difficult to monitor, but it is prudent to assume that | |||
| hackers know how to eavesdrop on your lines. For this reason, you | hackers know how to eavesdrop on your lines. For this reason, you | |||
| should use one-shot passwords if at all possible. | should use one-time passwords if at all possible. | |||
| It is helpful to have a single dial-in point (e.g., a single large | It is helpful to have a single dial-in point (e.g., a single large | |||
| modem pool) so that all users are authenticated in the same way. | modem pool) so that all users are authenticated in the same way. | |||
| Users will occasionally mis-type a password. Set a short delay - say | Users will occasionally mis-type a password. Set a short delay - say | |||
| two seconds - after the first and second failed logins, and force a | two seconds - after the first and second failed logins, and force a | |||
| disconnect after the third. This will slow down automated password | disconnect after the third. This will slow down automated password | |||
| attacks. Don't tell the user whether the username, the password, or | attacks. Don't tell the user whether the username, the password, or | |||
| both, were incorrect. | both, were incorrect. | |||
| 4.5.4.3 All logins (successful and unsuccessful) should be logged | 4.5.4.3 Call-back Capability | |||
| Don't keep correct passwords in the log, but consider keeping | Some dial-in servers offer call-back facilities (i.e., the user dials | |||
| incorrect passwords to aid in detecting password attacks. However, | in and is authenticated, then the system disconnects the call and | |||
| most incorrect passwords are correct passwords with one character | calls back on a specified number). Call-back is useful since if | |||
| mistyped and may suggest the real password. If you can't keep this | someone were to guess a username and password, they are disconnected, | |||
| information secure, don't log it at all. | and the system then calls back the actual user whose password was | |||
| cracked; random calls from a server are suspicious, at best. This | ||||
| does mean users may only log in from one location (where the server | ||||
| is configured to dial them back), and of course there may be phone | ||||
| charges associated with there call-back location. | ||||
| This feature should be used with caution; it can easily be bypassed. | ||||
| At a minimum, make sure that the return call is never made from the | ||||
| same modem as the incoming one. Overall, although call-back can | ||||
| improve modem security, you should not depend on it alone. | ||||
| 4.5.4.4 All Logins Should Be Logged | ||||
| All logins, whether successful or unsuccessful should be logged. | ||||
| However, do not keep correct passwords in the log. Rather, log them | ||||
| simply as a successful login attempt. Since most bad passwords are | ||||
| mistyped by authorized users, they only vary by a single character | ||||
| from the actual password. Therefore if you can't keep such a log | ||||
| secure, don't log it at all. | ||||
| If Calling Line Identification is available, take advantage of it by | If Calling Line Identification is available, take advantage of it by | |||
| recording the calling number for each login attempt. Be sensitive to | recording the calling number for each login attempt. Be sensitive to | |||
| the privacy issues raised by Calling Line Identification. Also be | the privacy issues raised by Calling Line Identification. Also be | |||
| aware that Calling Line Identification is not to be trusted; use the | aware that Calling Line Identification is not to be trusted (since | |||
| data for informational purposes only, not for authentication. | intruders have been known to break into phone switches and forward | |||
| phone numbers or make other changes); use the data for informational | ||||
| purposes only, not for authentication. | ||||
| 4.5.4.4 Minimize the amount of information given in your opening banner | 4.5.4.5 Choose Your Opening Banner Carefully | |||
| In particular, don't announce the type of host hardware or operating | Many sites use a system default contained in a message of the day | |||
| system - this encourages specialist hackers. | file for their opening banner. Unfortunately, this often includes the | |||
| type of host hardware or operating system present on the host. This | ||||
| can provide valuable information to a would-be intruder. Instead, | ||||
| each site should create its own specific login banner, taking care to | ||||
| only include necessary information. | ||||
| Display a short banner, but don't offer an "inviting" name (e.g., | Display a short banner, but don't offer an "inviting" name (e.g., | |||
| University of XYZ, Student Records System). Instead, give your site | University of XYZ, Student Records System). Instead, give your site | |||
| name, a short warning that sessions may be monitored, and a | name, a short warning that sessions may be monitored, and a | |||
| username/password prompt. Get your site's lawyers to check your | username/password prompt. Verify possible legal issues related to | |||
| banner to make sure it states your legal position correctly. | the text you put into the banner. | |||
| For high-security applications, consider using a "blind" password | For high-security applications, consider using a "blind" password | |||
| (i.e., give no response to an incoming call until the user has typed | (i.e., give no response to an incoming call until the user has typed | |||
| in a password). This effectively simulates a dead modem. | in a password). This effectively simulates a dead modem. | |||
| 4.5.4.5 Call-back Capability | 4.5.4.6 Dial-out Authentication | |||
| Some dial-in servers offer call-back facilities (i.e., the user dials | ||||
| in and is authenticated, then the system disconnects the call and | ||||
| calls back on a specified number). You will probably have to pay the | ||||
| charges for such calls. | ||||
| This feature should be used with caution; it can easily be bypassed. | ||||
| At a minimum, make sure that the return call is never made from the | ||||
| same modem as the incoming one. Overall, although call-back can | ||||
| improve modem security, you should not depend on it alone. | ||||
| 4.5.4.6 Dial-out authentication | ||||
| Dial-out users should also be authenticated, particularly since your | Dial-out users should also be authenticated, particularly since your | |||
| site will have to pay their telephone charges. | site will have to pay their telephone charges. | |||
| Never allow dial-out from an unauthenticated dial-in call, and | Never allow dial-out from an unauthenticated dial-in call, and | |||
| consider whether you will allow it from an authenticated one. The | consider whether you will allow it from an authenticated one. The | |||
| goal here is to prevent callers using your modem pool as part of a | goal here is to prevent callers using your modem pool as part of a | |||
| chain of logins. This can be hard to detect, particularly if a | chain of logins. This can be hard to detect, particularly if a | |||
| hacker sets up a path through several hosts on your site. | hacker sets up a path through several hosts on your site. | |||
| At a minimum, don't allow the same modems and phone lines to be used | At a minimum, don't allow the same modems and phone lines to be used | |||
| for both dial-in and dial-out. This can be implemented easily if you | for both dial-in and dial-out. This can be implemented easily if you | |||
| run separate dial-in and dial-out modem pools. | run separate dial-in and dial-out modem pools. | |||
| 4.5.4.7 Make your modem programming as "bullet-proof" as possible | 4.5.4.7 Make Your Modem Programming as "Bullet-proof" as Possible | |||
| Be sure modems can't be reprogrammed while they're in service. At a | Be sure modems can't be reprogrammed while they're in service. At a | |||
| minimum, make sure that three plus signs won't put your dial-in | minimum, make sure that three plus signs won't put your dial-in | |||
| modems into command mode! | modems into command mode! | |||
| Program your modems to reset to your standard configuration at the | Program your modems to reset to your standard configuration at the | |||
| start of each new call. Failing this, make them reset at the end of | start of each new call. Failing this, make them reset at the end of | |||
| each call. This precaution will protect you against accidental | each call. This precaution will protect you against accidental | |||
| reprogramming of your modems. | reprogramming of your modems. Resetting at both the end and the | |||
| beginning of each call will assure an even higher level of confidence | ||||
| that a new caller will not inherit a previous caller's session. | ||||
| Check that your modems terminate calls cleanly. When a user logs out | Check that your modems terminate calls cleanly. When a user logs out | |||
| from an access server, verify that the server hangs up the phone line | from an access server, verify that the server hangs up the phone line | |||
| properly. It is equally important that the server forces logouts | properly. It is equally important that the server forces logouts | |||
| from whatever sessions were active if the user hangs up unexpectedly. | from whatever sessions were active if the user hangs up unexpectedly. | |||
| 4.6 Auditing | 4.6 Auditing | |||
| This section covers the procedures for collecting data generated by | This section covers the procedures for collecting data generated by | |||
| network activity, which may be useful in analyzing the security of a | network activity, which may be useful in analyzing the security of a | |||
| network and responding to security incidents. | network and responding to security incidents. | |||
| 4.6.1 What to collect | 4.6.1 What to Collect | |||
| Audit data should include any attempt to achieve a different security | Audit data should include any attempt to achieve a different security | |||
| level by any person, process, or other entity in the network. This | level by any person, process, or other entity in the network. This | |||
| includes login and logout, su (or the non-UNIX equivalent), ticket | includes login and logout, super user access (or the non-UNIX | |||
| generation (for Kerberos, for example), and any other change of | equivalent), ticket generation (for Kerberos, for example), and any | |||
| access or status. It is especially important to note "anonymous" or | other change of access or status. It is especially important to note | |||
| "guest" access to public servers. | "anonymous" or "guest" access to public servers. | |||
| The actual data to collect will differ for different sites and for | The actual data to collect will differ for different sites and for | |||
| different types of access changes within a site. In general, the | different types of access changes within a site. In general, the | |||
| information you want to collect includes: username and hostname, for | information you want to collect includes: username and hostname, for | |||
| login and logout; previous and new access rights, for a change of | login and logout; previous and new access rights, for a change of | |||
| access rights; and a timestamp. Of course, there is much more | access rights; and a timestamp. Of course, there is much more | |||
| information which might be gathered, depending on what the system | information which might be gathered, depending on what the system | |||
| makes available and how much space is available to store that | makes available and how much space is available to store that | |||
| information. | information. | |||
| skipping to change at page 29, line 51 ¶ | skipping to change at page 31, line 50 ¶ | |||
| occurs. | occurs. | |||
| If a data handling plan is not adequately defined prior to an | If a data handling plan is not adequately defined prior to an | |||
| incident, it may mean that there is no recourse in the aftermath of | incident, it may mean that there is no recourse in the aftermath of | |||
| an event, and it may create liability resulting from improper | an event, and it may create liability resulting from improper | |||
| treatment of the data. | treatment of the data. | |||
| 4.6.5 Legal Considerations | 4.6.5 Legal Considerations | |||
| Due to the content of audit data, there are a number of legal | Due to the content of audit data, there are a number of legal | |||
| questions that arise which need to be addressed by your legal | questions that arise which might need to be addressed by your legal | |||
| counsel. If you collect and save audit data, you need to be prepared | counsel. If you collect and save audit data, you need to be prepared | |||
| for consequences resulting both from its existence and its content. | for consequences resulting both from its existence and its content. | |||
| One area concerns the privacy of individuals. In certain instances, | One area concerns the privacy of individuals. In certain instances, | |||
| audit data may contain personal information. Searching through the | audit data may contain personal information. Searching through the | |||
| data, even for a routine check of the system's security, could | data, even for a routine check of the system's security, could | |||
| represent an invasion of privacy. | represent an invasion of privacy. | |||
| A second area of concern involves knowledge of intrusive behavior | A second area of concern involves knowledge of intrusive behavior | |||
| originating from your site. If an organization keeps audit data, is | originating from your site. If an organization keeps audit data, is | |||
| skipping to change at page 30, line 27 ¶ | skipping to change at page 32, line 26 ¶ | |||
| 4.7 Securing Backups | 4.7 Securing Backups | |||
| The procedure of creating backups is a classic part of operating a | The procedure of creating backups is a classic part of operating a | |||
| computer system. Within the context of this document, backups are | computer system. Within the context of this document, backups are | |||
| addressed as part of the overall security plan of a site. There are | addressed as part of the overall security plan of a site. There are | |||
| several aspects to backups that are important within this context: | several aspects to backups that are important within this context: | |||
| (1) Make sure your site is creating backups | (1) Make sure your site is creating backups | |||
| (2) Make sure your site is using offsite storage for backups. The | (2) Make sure your site is using offsite storage for backups. The | |||
| storage site should be carefully selected for both its security an= | storage site should be carefully selected for both its security and | |||
| d | ||||
| its availability. | its availability. | |||
| (3) Consider encrypting your backups to provide additional protection = | (3) Consider encrypting your backups to provide additional protection of | |||
| of | the information once it is off-site. However, be aware that you will | |||
| the information once it is off-site. However, be aware that you w= | need a good key management scheme so that you'll be able to recover | |||
| ill | ||||
| need a good key management scheme so that you'll be able to recove= | ||||
| r | ||||
| data at any point in the future. Also, make sure you will have | data at any point in the future. Also, make sure you will have | |||
| access to the necessary decryption programs at such time in the | access to the necessary decryption programs at such time in the | |||
| future as you need to perform the decryption. | future as you need to perform the decryption. | |||
| (4) Don't always assume that your backups are good. There have been | (4) Don't always assume that your backups are good. There have been | |||
| many instances of computer security incidents that have gone on fo= | many instances of computer security incidents that have gone on for | |||
| r | long periods of time before a site has noticed the incident. In such | |||
| long periods of time before a site has noticed the incident. In s= | ||||
| uch | ||||
| cases, backups of the affected systems are also tainted. | cases, backups of the affected systems are also tainted. | |||
| (5) Periodically check your backups. | (5) Periodically verify the correctness and completeness of your | |||
| backups. | ||||
| 5. Security Incident Handling | 5. Security Incident Handling | |||
| This section of the document will supply guidance to be applied | This chapter of the document will supply guidance to be used before, | |||
| before, during, and after a computer security incident occurs on a | during, and after a computer security incident occurs on a host, | |||
| machine, network, site, or multi-site environment. The operative | network, site, or multi-site environment. The operative philosophy | |||
| philosophy in the event of a breach of computer security is to react | in the event of a breach of computer security is to react according | |||
| according to a plan. This is true whether the breach is the result | to a plan. This is true whether the breach is the result of an | |||
| of an external intruder attack, unintentional damage, a student | external intruder attack, unintentional damage, a student testing | |||
| testing some new program to exploit a software vulnerability, or a | some new program to exploit a software vulnerability, or a | |||
| disgruntled employee. Each of the possible types of events, such as | disgruntled employee. Each of the possible types of events, such as | |||
| those just listed, should be addressed in advance by adequate | those just listed, should be addressed in advance by adequate | |||
| contingency plans. | contingency plans. | |||
| Traditional computer security, while quite important in the overall | Traditional computer security, while quite important in the overall | |||
| site security plan, usually pays little attention to how to actually | site security plan, usually pays little attention to how to actually | |||
| handle the attack once it occurs. The result is that when an attack | handle an attack once one occurs. The result is that when an attack | |||
| is in progress, many decisions are made in haste and can be damaging | is in progress, many decisions are made in haste and can be damaging | |||
| to tracking down the source of the incident, collecting evidence to | to tracking down the source of the incident, collecting evidence to | |||
| be used in prosecution efforts, preparing for the recovery of the | be used in prosecution efforts, preparing for the recovery of the | |||
| system, and protecting the valuable data contained on the system. | system, and protecting the valuable data contained on the system. | |||
| One of the most important, but often overlooked, benefits for | One of the most important, but often overlooked, benefits for | |||
| efficient incident handling is an economic one. Having both | efficient incident handling is an economic one. Having both | |||
| technical and managerial personnel respond to an incident requires | technical and managerial personnel respond to an incident requires | |||
| considerable resources. If trained to handle incidents efficiently, | considerable resources. If trained to handle incidents efficiently, | |||
| less staff time is required when one occurs. | less staff time is required when one occurs. | |||
| Due to the world-wide network most incidents are not restricted to a | Due to the world-wide network most incidents are not restricted to a | |||
| single site. Operating systems vulnerabilities apply (in some cases) | single site. Operating systems vulnerabilities apply (in some cases) | |||
| to several millions of systems, and many vulnerabilities are | to several millions of systems, and many vulnerabilities are | |||
| exploited within the network itself. Therefore, it is vital for all | exploited within the network itself. Therefore, it is vital that all | |||
| sites with involved parties are informed as soon as possible. | sites with involved parties be informed as soon as possible. | |||
| Another benefit is related to public relations. News about computer | Another benefit is related to public relations. News about computer | |||
| security incidents tends to be damaging to an organization's stature | security incidents tends to be damaging to an organization's stature | |||
| among current or potential clients. Efficient incident handling | among current or potential clients. Efficient incident handling | |||
| minimizes the potential for negative exposure. | minimizes the potential for negative exposure. | |||
| A final benefit of efficient incident handling is related to legal | A final benefit of efficient incident handling is related to legal | |||
| issues. It is possible that in the near future organizations may be | issues. It is possible that in the near future organizations may be | |||
| sued because one of their nodes was used to launch a network attack. | held responsible because one of their nodes was used to launch a | |||
| In a similar vein, people who develop patches or workarounds may be | network attack. In a similar vein, people who develop patches or | |||
| sued if the patches or workarounds are ineffective, resulting in | workarounds may be sued if the patches or workarounds are | |||
| compromise of the systems, or, if the patches or workarounds | ineffective, resulting in compromise of the systems, or, if the | |||
| themselves damage systems. Knowing about operating system | patches or workarounds themselves damage systems. Knowing about | |||
| vulnerabilities and patterns of attacks, and then taking appropriate | operating system vulnerabilities and patterns of attacks, and then | |||
| measures to counter these potential threats, is critical to | taking appropriate measures to counter these potential threats, is | |||
| circumventing possible legal problems. | critical to circumventing possible legal problems. | |||
| The sections in this chapter provide an outline and starting point | The sections in this chapter provide an outline and starting point | |||
| for creating your site's policy for handling security incidents. The | for creating your site's policy for handling security incidents. The | |||
| sections are: | sections are: | |||
| (1) Preparing and planning (what are the goals and objectives in | (1) Preparing and planning (what are the goals and objectives in | |||
| handling an incident). | handling an incident). | |||
| (2) Notification (who should be contacted in the case of an incident). | (2) Notification (who should be contacted in the case of an incident). | |||
| (3) Evaluation (how serious is the incident). | - Local managers and personnel | |||
| - Law enforcement and investigative agencies | ||||
| - Computer security incidents handling teams | ||||
| - Affected and involved sites | ||||
| - Internal communications | ||||
| - Public relations and press releases | ||||
| (3) Identifying an incident (is it an incident and how serious is it). | ||||
| (4) Handling (what should be done when an incident occurs). | (4) Handling (what should be done when an incident occurs). | |||
| - Notification (who should be notified about the incident). | - Notification (who should be notified about the incident) | |||
| - Containment (how can the damage be limited). | - Protecting evidence and activity logs (what records should be | |||
| - Eradication (how to eliminate the reasons for the incident). | kept from before, during, and after the incident) | |||
| - Recovery (how to reestablish service and systems). | - Containment (how can the damage be limited) | |||
| - Follow Up (what actions should be taken after the incident). | - Eradication (how to eliminate the reasons for the incident) | |||
| - Legal/Investigative implications (what are the legal and | - Recovery (how to reestablish service and systems) | |||
| prosecutorial implications of the incident). | - Follow Up (what actions should be taken after the incident) | |||
| - Documentation Logs (what records should be kept from | ||||
| before, during, and after the incident). | ||||
| (5) Aftermath (what are the implications of past incidents). | (5) Aftermath (what are the implications of past incidents). | |||
| (6) Responsibilities (how to handle an incident responsibly). | ||||
| (6) Administrative response to incidents. | ||||
| The remainder of this chapter will detail the issues involved in each | The remainder of this chapter will detail the issues involved in each | |||
| of the important topics listed above, and provide some guidance as to | of the important topics listed above, and provide some guidance as to | |||
| what should be included in a site policy for handling incidents. | what should be included in a site policy for handling incidents. | |||
| 5.1 Preparing and Planning for Incident Handling | 5.1 Preparing and Planning for Incident Handling | |||
| Part of handling an incident is being prepared to respond to an | Part of handling an incident is being prepared to respond to an | |||
| incident before the incident occurs in the first place. This | incident before the incident occurs in the first place. This | |||
| includes establishing a suitable level of protections as explained in | includes establishing a suitable level of protections as explained in | |||
| the preceding chapters. Doing this should help your site prevent | the preceding chapters. Doing this should help your site prevent | |||
| incidents as well as limit potential damage resulting from them when | incidents as well as limit potential damage resulting from them when | |||
| they do occur. Protection also includes preparing incident handling | they do occur. Protection also includes preparing incident handling | |||
| guidelines as part of a contingency plan for your organization or | guidelines as part of a contingency plan for your organization or | |||
| site. Having written plans eliminates much of the ambiguity which | site. Having written plans eliminates much of the ambiguity which | |||
| occurs during an incident, and will lead to a more appropriate and | occurs during an incident, and will lead to a more appropriate and | |||
| thorough set of responses. It is vitally important to test the | thorough set of responses. It is vitally important to test the | |||
| proposed plan before an incident occurs through "dry runs". A team | proposed plan before an incident occurs through "dry runs". A team | |||
| might even consider hiring a tiger team to act in parallel with the | might even consider hiring a tiger team to act in parallel with the | |||
| dry run. | dry run. (Note: a tiger team is a team of specialists that try to | |||
| penetrate the security of a system.) | ||||
| Learning to respond efficiently to an incident is important for a | Learning to respond efficiently to an incident is important for a | |||
| number of reasons: | number of reasons: | |||
| (1) protecting the assets which could be compromised | (1) Protecting the assets which could be compromised | |||
| (2) protecting resources which could be utilized more | (2) Protecting resources which could be utilized more | |||
| profitably if an incident did not require their services | profitably if an incident did not require their services | |||
| (3) complying with (government or other) regulations | (3) Complying with (government or other) regulations | |||
| (4) preventing the use of your systems in attacks against other | (4) Preventing the use of your systems in attacks against other | |||
| systems (which could cause you to incur legal liability) | systems (which could cause you to incur legal liability) | |||
| (5) minimizing the potential for negative exposure | (5) Minimizing the potential for negative exposure | |||
| As in any set of pre-planned procedures, attention must be paid to a | As in any set of pre-planned procedures, attention must be paid to a | |||
| set of goals for handling an incident. These goals will be | set of goals for handling an incident. These goals will be | |||
| prioritized differently depending on the site. A specific set of | prioritized differently depending on the site. A specific set of | |||
| objectives can be identified for dealing with incidents: | objectives can be identified for dealing with incidents: | |||
| (1) Figure out how it happened. | (1) Figure out how it happened. | |||
| (2) Find out how to avoid further exploitation of the same | (2) Find out how to avoid further exploitation of the same | |||
| vulnerability. | vulnerability. | |||
| (3) Avoid escalation and further incidents. | (3) Avoid escalation and further incidents. | |||
| (4) Recover from the incident. | (4) Assess the impact and damage of the incident. | |||
| (5) Find out who did it. | (5) Recover from the incident. | |||
| (6) Update policies and procedures as needed. | ||||
| (5) Find out who did it (if appropriate and possible). | ||||
| Due to the nature of the incident, there might be a conflict between | Due to the nature of the incident, there might be a conflict between | |||
| analyzing the original source of a problem and restoring systems and | analyzing the original source of a problem and restoring systems and | |||
| services. Overall goals (like assuring the integrity of critical | services. Overall goals (like assuring the integrity of critical | |||
| systems) might be the reason for not analyzing an incident. Of | systems) might be the reason for not analyzing an incident. Of | |||
| course, this is an important management decision; but all involved | course, this is an important management decision; but all involved | |||
| parties must be aware that without analysis the same incident may | parties must be aware that without analysis the same incident may | |||
| happen again. | happen again. | |||
| It is also important to prioritize the actions to be taken during an | It is also important to prioritize the actions to be taken during an | |||
| skipping to change at page 33, line 32 ¶ | skipping to change at page 35, line 38 ¶ | |||
| Prevent exploitations of other systems, networks or | Prevent exploitations of other systems, networks or | |||
| sites and inform already affected systems, networks or | sites and inform already affected systems, networks or | |||
| sites about successful penetrations. | sites about successful penetrations. | |||
| (4) Priority four -- prevent damage to systems (e.g., loss | (4) Priority four -- prevent damage to systems (e.g., loss | |||
| or alteration of system files, damage to disk drives, | or alteration of system files, damage to disk drives, | |||
| etc.). Damage to systems can result in costly down | etc.). Damage to systems can result in costly down | |||
| time and recovery. | time and recovery. | |||
| (5) Priority five -- minimize disruption of computing | (5) Priority five -- minimize disruption of computing | |||
| resources. It is better in many cases to shut a system | resources (including processes). It is better in many | |||
| down or disconnect from a network than to risk damage | cases to shut a system down or disconnect from a network | |||
| to data or systems. | than to risk damage to data or systems. Sites will have | |||
| to evaluate the trade-offs between shutting down and | ||||
| disconnecting, and staying up. There may be service | ||||
| agreements in place that may require keeping systems | ||||
| up even in light of further damage occurring. However, | ||||
| the damage and scope of an incident may be so extensive | ||||
| that service agreements may have to be over-ridden. | ||||
| An important implication for defining priorities is that once human | An important implication for defining priorities is that once human | |||
| life and national security considerations have been addressed, it is | life and national security considerations have been addressed, it is | |||
| generally more important to save data than system software and | generally more important to save data than system software and | |||
| hardware. Although it is undesirable to have any damage or loss | hardware. Although it is undesirable to have any damage or loss | |||
| during an incident, systems can be replaced. However, the loss or | during an incident, systems can be replaced. However, the loss or | |||
| compromise of data (especially classified or proprietary data) is | compromise of data (especially classified or proprietary data) is | |||
| usually not an acceptable outcome under any circumstances. | usually not an acceptable outcome under any circumstances. | |||
| Another important concern is the effect on others, beyond the systems | Another important concern is the effect on others, beyond the systems | |||
| skipping to change at page 34, line 10 ¶ | skipping to change at page 36, line 22 ¶ | |||
| follow. | follow. | |||
| The policies chosen by your site on how it reacts to incidents will | The policies chosen by your site on how it reacts to incidents will | |||
| shape your response. For example, it may make little sense to create | shape your response. For example, it may make little sense to create | |||
| mechanisms to monitor and trace intruders if your site does not plan | mechanisms to monitor and trace intruders if your site does not plan | |||
| to take action against the intruders if they are caught. Other | to take action against the intruders if they are caught. Other | |||
| organizations may have policies that affect your plans. Telephone | organizations may have policies that affect your plans. Telephone | |||
| companies often release information about telephone traces only to | companies often release information about telephone traces only to | |||
| law enforcement agencies. | law enforcement agencies. | |||
| Handling incidents can be tedious and require any number of routine | ||||
| tasks that could be handled by support personnel. To free the | ||||
| technical staff it may be helpful to identify support staff who will | ||||
| help with tasks like: photocopying, fax'ing, etc. | ||||
| 5.2 Notification and Points of Contact | 5.2 Notification and Points of Contact | |||
| It is important to establish contacts with various personnel before a | It is important to establish contacts with various personnel before a | |||
| real incident occurs. These contacts are either local, other system | real incident occurs. Many times, incidents are not real | |||
| responsible or administrative contacts administrators elsewhere on | emergencies. Indeed, often you will be able to handle the activities | |||
| the Internet or are investigative agencies. Working with these | internally. However, there will also be many times when others | |||
| contacts appropriately will help to make your incident handling | outside your immediate department will need to be included in the | |||
| process more efficient. | incident handling. These additional contacts include local managers | |||
| and system administrators, administrative contacts for other sites on | ||||
| the Internet, and various investigative organizations. Getting to | ||||
| know these contacts before incidents occurs will help to make your | ||||
| incident handling process more efficient. | ||||
| Communication may need to be established with various "Points of | For each type of communication contact, specific "Points of Contact" | |||
| Contact" (POC). These may be technical or administrative in nature | (POC) should be defined. These may be technical or administrative in | |||
| and may include legal or investigative agencies as well as Service | nature and may include legal or investigative agencies as well as | |||
| Providers and vendors. It is important to decide how much | service providers and vendors. When establishing these contact, it | |||
| information will be shared, especially with the wider community of | is important to decide how much information will be shared with each | |||
| users at a site, with the public (the press) and with other sites. | class of contact. It is especially important to define, ahead of | |||
| time, what information will be shared with the users at a site, with | ||||
| the public (including the press), and with other sites. | ||||
| Settling these issues are especially important for the local person | Settling these issues are especially important for the local person | |||
| responsible for handling the incident, since that is the person | responsible for handling the incident, since that is the person | |||
| responsible for the actual notification of others. A list of | responsible for the actual notification of others. A list of | |||
| contacts in each of these categories is an important time saver for | contacts in each of these categories is an important time saver for | |||
| this person during an incident. It can be quite difficult to find an | this person during an incident. It can be quite difficult to find an | |||
| appropriate person during an incident when many urgent events are | appropriate person during an incident when many urgent events are | |||
| ongoing. Including relevant telephone numbers (also electronic mail | ongoing. It is strongly recommended that all relevant telephone | |||
| addresses and fax numbers) in the site security policy is strongly | numbers (also electronic mail addresses and fax numbers) be included | |||
| recommended. It is especially important to know how to contact | in the site security policy. The names and contact information of | |||
| individuals who will be directly involved in handling a security | all individuals who will be directly involved in the handling of an | |||
| incident. | incident should be placed at the top of this list. | |||
| 5.2.1 Local Managers and Personnel | 5.2.1 Local Managers and Personnel | |||
| When an incident is under way, a major issue is deciding who is in | When an incident is under way, a major issue is deciding who is in | |||
| charge of coordinating the activity of the multitude of players. A | charge of coordinating the activity of the multitude of players. A | |||
| major mistake that can be made is to have a number of POCs who are | major mistake that can be made is to have a number of people who are | |||
| not pulling their efforts together. This will only add to the | each working independently, but are not working together. This will | |||
| confusion of the event and will probably lead to wasted or | only add to the confusion of the event and will probably lead to | |||
| ineffective effort. | wasted or ineffective effort. | |||
| The single POC may or may not be the person responsible for handling | The single POC may or may not be the person responsible for handling | |||
| the incident. There are two distinct roles to fill when deciding who | the incident. There are two distinct roles to fill when deciding who | |||
| shall be the POC and who will be the person in charge of the | shall be the POC and who will be the person in charge of the | |||
| incident. The person in charge of the incident will make decisions | incident. The person in charge of the incident will make decisions | |||
| as to the interpretation of policy applied to the event. In | as to the interpretation of policy applied to the event. In | |||
| contrast, the POC must coordinate the effort of all the parties | contrast, the POC must coordinate the effort of all the parties | |||
| involved with handling the event. | involved with handling the event. | |||
| The POC must be a person with the technical expertise to successfully | The POC must be a person with the technical expertise to successfully | |||
| coordinate the effort of the system managers and users involved in | coordinate the efforts of the system managers and users involved in | |||
| monitoring and reacting to the attack. Often the management | monitoring and reacting to the attack. Care should be taken when | |||
| structure of a site is such that the administrator of a set of | identifying who this person will be. It should not necessarily be | |||
| resources is not a technically competent person with regard to | the same person who has administrative responsibility for the | |||
| handling the details of the operations of the computers, but is | compromised systems since often such administrators have knowledge | |||
| ultimately responsible for the use of these resources. | only sufficient for the day to day use of the computers, and lack in | |||
| depth technical expertise. | ||||
| Another important function of the POC is to maintain contact with law | Another important function of the POC is to maintain contact with law | |||
| enforcement and other external agencies to assure that multi-agency | enforcement and other external agencies to assure that multi-agency | |||
| involvement occurs. The level of involvement will be determined by | involvement occurs. The level of involvement will be determined by | |||
| management decisions as well as legal constraints. | management decisions as well as legal constraints. | |||
| Finally, if legal action in the form of prosecution is involved, the | A single POC should also be the single person in charge of collecting | |||
| POC may be asked to speak for the site in court. The alternative is | evidence, since as a rule of thumb, the more people that touch a | |||
| to have multiple witnesses whose input may be hard to coordinate in a | potential piece of evidence, the greater the possibility that it will | |||
| legal sense. This may lead to a weakening of any case against the | be inadmissible in court. To ensure that evidence will be acceptable | |||
| attackers. A single POC may also be the single person in charge of | to the legal community, collecting evidence should be done following | |||
| collecting evidence, which will keep the number of people accounting | predefined procedures in accordance with local laws and legal | |||
| for evidence to a minimum. As a rule of thumb, the more people that | regulations. | |||
| touch a potential piece of evidence, the greater the possibility that | ||||
| it will be inadmissible in court. | ||||
| One of the most critical tasks for the POC is the coordination of all | One of the most critical tasks for the POC is the coordination of all | |||
| relevant processes. As responsibilities might be distributed over | relevant processes. Responsibilities may be distributed over the | |||
| the whole site, which may well consist of multiple independent | whole site, involving multiple independent departments or groups. | |||
| departments or groups, a well coordinate effort is crucial for | This will require a well coordinated effort in order to achieve | |||
| overall success. The situation get even worse if multiple sites are | overall success. The situation becomes even more complex if multiple | |||
| involved. In many cases, no single POC in one site can coordinate | sites are involved. When this happens, rarely will a single POC at | |||
| the handling of an entire incident. The appropriate incident | one site be able to adequately coordinate the handling of the entire | |||
| response teams are more suitable, if multiple sites are involved. | incident. Instead, appropriate incident response teams should be | |||
| involved. | ||||
| The incident handling process should provide some escalation | The incident handling process should provide some escalation | |||
| mechanisms. The POC might change; the impact of the incident force | mechanisms. In order to define such a mechanism, sites will need to | |||
| the management to take the lead instead of giving the technical | create an internal classification scheme for incidents. Associated | |||
| administrator the responsibility. Other reasons for changing the POC | with each level of incident will be the appropriate POC and | |||
| are the emergence of conflicts of interest, or changing priorities or | procedures. As an incident is escalated, there may be a change in | |||
| responsibilities. Regardless of why the POC is changed, all involved | the POC which will need to be communicated to all others involved in | |||
| parties must be informed. Arrangements should be made to allow the | handling the incident. When a change in the POC occurs, old POC | |||
| new POC to contact the old one, to ensure an adequate briefing of | should brief the new POC in all background information. | |||
| background information. | ||||
| Lastly, users must know how to report suspected incidents. Sites | ||||
| should establish reporting procedures that will work both during and | ||||
| outside normal working hours. Help desks are often used to receive | ||||
| these reports during normal working hours, while beepers and | ||||
| telephones can be used for out of hours reporting. | ||||
| 5.2.2 Law Enforcement and Investigative Agencies | 5.2.2 Law Enforcement and Investigative Agencies | |||
| In the event of an incident that has legal consequences, it is | In the event of an incident that has legal consequences, it is | |||
| important to establish contact with investigative agencies (e.g, the | important to establish contact with investigative agencies (e.g, the | |||
| FBI and Secret Service in the U.S.) as soon as possible. Local law | FBI and Secret Service in the U.S.) as soon as possible. Local law | |||
| enforcement, local security offices, and campus police departments | enforcement, local security offices, and campus police departments | |||
| should also be informed as appropriate. | should also be informed as appropriate. This section describes many | |||
| of the issues that will be confronted, but it is acknowledged that | ||||
| each organization will have its own local and governmental laws and | ||||
| regulations that will impact how they interact with law enforcement | ||||
| and investigative agencies. The most important point to make is that | ||||
| each site needs to work through these issues. | ||||
| A primary reason is that once a major attack is in progress, there is | A primary reason for determining these point of contact well in | |||
| little time to call these agencies to determine exactly who the | advance of an incident is that once a major attack is in progress, | |||
| correct point of contact is. Another reason is that it is important | there is little time to call these agencies to determine exactly who | |||
| to cooperate with these agencies in a manner that will foster a good | the correct point of contact is. Another reason is that it is | |||
| working relationship, and that will be in accordance with the working | important to cooperate with these agencies in a manner that will | |||
| procedures of these agencies. Knowing the working procedures in | foster a good working relationship, and that will be in accordance | |||
| advance and the expectations of your point of contact is a big step | with the working procedures of these agencies. Knowing the working | |||
| in this direction. For example, it is important to gather evidence | procedures in advance, and the expectations of your point of contact | |||
| that will be admissible in a court of law, requiring prior knowledge | is a big step in this direction. For example, it is important to | |||
| of how to gather such evidence. A final reason for establishing | gather evidence that will be admissible in any subsequent legal | |||
| contacts as soon as possible is that it is impossible to know the | proceedings, and this will require prior knowledge of how to gather | |||
| particular agency that will assume jurisdiction in any given | such evidence. A final reason for establishing contacts as soon as | |||
| incident. Making contacts and finding the proper channels early will | possible is that it is impossible to know the particular agency that | |||
| make responding to an incident go considerably more smoothly. | will assume jurisdiction in any given incident. Making contacts and | |||
| finding the proper channels early on will make responding to an | ||||
| incident go considerably more smoothly. | ||||
| If your organization or site has a legal counsel, you need to notify | If your organization or site has a legal counsel, you need to notify | |||
| this office soon after you learn that an incident is in progress. At | this office soon after you learn that an incident is in progress. At | |||
| a minimum, your legal counsel needs to be involved to protect the | a minimum, your legal counsel needs to be involved to protect the | |||
| legal and financial interests of your site or organization. There | legal and financial interests of your site or organization. There | |||
| are many legal and practical issues, a few of which are: | are many legal and practical issues, a few of which are: | |||
| (1) Whether your site or organization is willing to risk negative | (1) Whether your site or organization is willing to risk negative | |||
| publicity or exposure to cooperate with legal prosecution efforts. | publicity or exposure to cooperate with legal prosecution efforts. | |||
| (2) Downstream liability--if you leave a compromised system as is so | (2) Downstream liability--if you leave a compromised system as is so | |||
| it can be monitored and another computer is damaged because the | it can be monitored and another computer is damaged because the | |||
| attack originated from your system, your site or organization | attack originated from your system, your site or organization | |||
| may be liable for damages incurred. | may be liable for damages incurred. | |||
| (3) Distribution of information--if your site or organization distribu= | (3) Distribution of information--if your site or organization distributes | |||
| tes | information about an attack in which another site or organization may | |||
| information about an attack in which another site or organization = | be involved or the vulnerability in a product that may affect ability | |||
| may | to market that product, your site or organization may again be liable | |||
| be involved or the vulnerability in a product that may affect abil= | ||||
| ity | ||||
| to market that product, your site or organization may again be lia= | ||||
| ble | ||||
| for any damages (including damage of reputation). | for any damages (including damage of reputation). | |||
| (4) Liabilities due to monitoring--your site or organization may be su= | (4) Liabilities due to monitoring--your site or organization may be sued | |||
| ed | ||||
| if users at your site or elsewhere discover that your site is | if users at your site or elsewhere discover that your site is | |||
| monitoring account activity without informing users. | monitoring account activity without informing users. | |||
| Unfortunately, there are no clear precedents yet on the liabilities | Unfortunately, there are no clear precedents yet on the liabilities | |||
| or responsibilities of organizations involved in a security incident | or responsibilities of organizations involved in a security incident | |||
| or who might be involved in supporting an investigative effort. | or who might be involved in supporting an investigative effort. | |||
| Investigators will often encourage organizations to help trace and | Investigators will often encourage organizations to help trace and | |||
| monitor intruders. Indeed, most investigators cannot pursue computer | monitor intruders. Indeed, most investigators cannot pursue computer | |||
| intrusions without extensive support from the organizations involved. | intrusions without extensive support from the organizations involved. | |||
| However, investigators cannot provide protection from liability | However, investigators cannot provide protection from liability | |||
| skipping to change at page 37, line 24 ¶ | skipping to change at page 40, line 5 ¶ | |||
| procedures for responding to incidents. It is essential to obtain a | procedures for responding to incidents. It is essential to obtain a | |||
| "clean bill of health" from a legal perspective before you actually | "clean bill of health" from a legal perspective before you actually | |||
| carry out these procedures. | carry out these procedures. | |||
| It is vital, when dealing with investigative agencies, to verify that | It is vital, when dealing with investigative agencies, to verify that | |||
| the person who calls asking for information is a legitimate | the person who calls asking for information is a legitimate | |||
| representative from the agency in question. Unfortunately, many well | representative from the agency in question. Unfortunately, many well | |||
| intentioned people have unknowingly leaked sensitive details about | intentioned people have unknowingly leaked sensitive details about | |||
| incidents, allowed unauthorized people into their systems, etc., | incidents, allowed unauthorized people into their systems, etc., | |||
| because a caller has masqueraded as a representative of a government | because a caller has masqueraded as a representative of a government | |||
| agency. | agency. (Note: this word of caution actually applies to all external | |||
| contacts.) | ||||
| A similar consideration is using a secure means of communication. | A similar consideration is using a secure means of communication. | |||
| Because many network attackers can easily re-route electronic mail, | Because many network attackers can easily re-route electronic mail, | |||
| avoid using electronic mail to communicate with other agencies (as | avoid using electronic mail to communicate with other agencies (as | |||
| well as others dealing with the incident at hand). Non-secured phone | well as others dealing with the incident at hand). Non-secured phone | |||
| lines (the phones normally used in the business world) are also | lines (the phones normally used in the business world) are also | |||
| frequent targets for tapping by network intruders, so be careful! | frequent targets for tapping by network intruders, so be careful! | |||
| There is no established set of rules for responding to an incident | There is no one established set of rules for responding to an | |||
| when the local government becomes involved. Normally, except by | incident when the local government becomes involved. Normally (in | |||
| court order, no agency can force you to monitor, to disconnect from | the U.S.), except by legal order, no agency can force you to monitor, | |||
| the network, to avoid telephone contact with the suspected attackers, | to disconnect from the network, to avoid telephone contact with the | |||
| etc. As discussed before, you should consult the matter with your | suspected attackers, etc. Each organization will have a set of local | |||
| legal counsel, especially before taking an action that your | and national laws and regulations that must be adhered to when | |||
| organization has never taken. | handling incidents. It is recommended that each site be familiar with | |||
| those laws and regulations, and identify and get know the contacts | ||||
| The particular agency involved may ask you to leave an attacked | for agencies with jurisdiction well in advance of handling an | |||
| machine on and to monitor activity. Complying with this request will | incident. | |||
| ensure continued cooperation of the agency. This is usually the best | ||||
| route towards finding the source of the network attacks and, | ||||
| ultimately, terminating the attacks. Additionally, you may need | ||||
| information or a favor from the agency involved. You are likely to | ||||
| get what you need only if you have been cooperative. It is | ||||
| particularly important to avoid unnecessary or unauthorized | ||||
| disclosure of information about the incident, including any | ||||
| information furnished by the agency involved. In other words, don't | ||||
| compromise the case the agency is trying to build. And remember, if | ||||
| you do not cooperate with an agency, you will be less likely to | ||||
| receive help from that agency in the future. | ||||
| Sometimes your needs and the needs of an investigative agency will | ||||
| differ. Your site may want to get back to normal business by closing | ||||
| an attack route, but the investigative agency may want you to keep | ||||
| this route open. Similarly, your site may want to close a | ||||
| compromised system down to avoid the possibility of negative | ||||
| publicity, but again the investigative agency may want you to | ||||
| continue monitoring. When there is such a conflict, there may be a | ||||
| complex set of tradeoffs (e.g., interests of your site's management, | ||||
| amount of resources you can devote to the problem, jurisdictional | ||||
| boundaries, etc.). An important guiding principle is related to what | ||||
| might be called "Internet citizenship" and its responsibilities. See | ||||
| section 5.6. | ||||
| 5.2.3 Computer Security Incident Handling Teams | 5.2.3 Computer Security Incident Handling Teams | |||
| There now exists a number of Computer Security Incident Response | There are currently a number of of Computer Security Incident | |||
| teams (CSIRTs) such as the CERT Coordination Center and the CIAC or | Response teams (CSIRTs) such as the CERT Coordination Center, the | |||
| other teams around the globe. Teams exist for many major government | German DFN-CERT, and other teams around the globe. Teams exist for | |||
| agencies and large corporations. If such a team is available, | many major government agencies and large corporations. If such a | |||
| notifying it should be of primary importance during the early stages | team is available, notifying it should be of primary consideration | |||
| of an incident. These teams are responsible for coordinating | during the early stages of an incident. These teams are responsible | |||
| computer security incidents over a range of sites and larger | for coordinating computer security incidents over a range of sites | |||
| entities. Even if the incident is believed to be contained within a | and larger entities. Even if the incident is believed to be | |||
| single site, it is possible that the information available through a | contained within a single site, it is possible that the information | |||
| response team could help in closing out the incident. | available through a response team could help in fully resolving the | |||
| incident. | ||||
| If it is determined that the breach occurred due to a flaw in the | If it is determined that the breach occurred due to a flaw in the | |||
| system's hardware or software, the vendor (or supplier) and a | system's hardware or software, the vendor (or supplier) and a | |||
| Computer Security Incident Handling team should be notified as soon | Computer Security Incident Handling team should be notified as soon | |||
| as possible. This is especially important because many other systems | as possible. This is especially important because many other systems | |||
| are vulnerable, too. | are vulnerable, and these vendor and response team organizations can | |||
| help disseminate help to other affected sites. | ||||
| In setting up a site policy for incident handling, it may be | In setting up a site policy for incident handling, it may be | |||
| desirable to create a subgroup, much like those teams that already | desirable to create a subgroup, much like those teams that already | |||
| exist, that will be responsible for handling computer security | exist, that will be responsible for handling computer security | |||
| incidents for the site (or organization). If such a team is created, | incidents for the site (or organization). If such a team is created, | |||
| it is essential that communication lines be opened between this team | it is essential that communication lines be opened between this team | |||
| and other teams. Once an incident is under way, it is difficult to | and other teams. Once an incident is under way, it is difficult to | |||
| open a trusted dialogue between other teams if none has existed | open a trusted dialogue between other teams if none has existed | |||
| before. | before. | |||
| skipping to change at page 38, line 43 ¶ | skipping to change at page 41, line 4 ¶ | |||
| In setting up a site policy for incident handling, it may be | In setting up a site policy for incident handling, it may be | |||
| desirable to create a subgroup, much like those teams that already | desirable to create a subgroup, much like those teams that already | |||
| exist, that will be responsible for handling computer security | exist, that will be responsible for handling computer security | |||
| incidents for the site (or organization). If such a team is created, | incidents for the site (or organization). If such a team is created, | |||
| it is essential that communication lines be opened between this team | it is essential that communication lines be opened between this team | |||
| and other teams. Once an incident is under way, it is difficult to | and other teams. Once an incident is under way, it is difficult to | |||
| open a trusted dialogue between other teams if none has existed | open a trusted dialogue between other teams if none has existed | |||
| before. | before. | |||
| 5.2.4 Affected and Involved Sites | 5.2.4 Affected and Involved Sites | |||
| If an incident has an impact on other sites, it is good practice to | If an incident has an impact on other sites, it is good practice to | |||
| inform them. It may be obvious from the beginning that the incident | inform them. It may be obvious from the beginning that the incident | |||
| is not limited to the local site, or it may emerge only after further | is not limited to the local site, or it may emerge only after further | |||
| analysis. | analysis. | |||
| Each site might choose to contact other sites directly or they can | Each site may choose to contact other sites directly or they can pass | |||
| pass the information to an appropriate incident response team, to | the information to an appropriate incident response team. It is often | |||
| which the involved site belongs. As it is often very difficult to | very difficult to find the responsible POC at remote sites and the | |||
| find the responsible POC at remote sites, the involvement of an | incident response team will be able to facilitate contact by making | |||
| incident response team will facilitate contact by making use of | use of already established channels. | |||
| already established channels. | ||||
| The legal and liability issues arising from a security incident may | The legal and liability issues arising from a security incident will | |||
| differ from site to site. It is important to define a policy for the | differ from site to site. It is important to define a policy for the | |||
| sharing and logging of information about other sites before an | sharing and logging of information about other sites before an | |||
| incident occurs. This policy should be crafted in consultation with | incident occurs. | |||
| legal counsel. | ||||
| Information about specific people is especially sensitive, and may be | Information about specific people is especially sensitive, and may be | |||
| subject to privacy laws. To avoid problems in this area, irrelevant | subject to privacy laws. To avoid problems in this area, irrelevant | |||
| information should be deleted and a statement of how to handle the | information should be deleted and a statement of how to handle the | |||
| remaining information should be included. A clear statement of how | remaining information should be included. A clear statement of how | |||
| this information is to be used is essential. No one who informs a | this information is to be used is essential. No one who informs a | |||
| site of a security incident wants to read about it in the public | site of a security incident wants to read about it in the public | |||
| press. Incident response teams are valuable in this respect. When | press. Incident response teams are valuable in this respect. When | |||
| they pass information to responsible POCs, they are able to protect | they pass information to responsible POCs, they are able to protect | |||
| the anonymity of the original source. But, be aware that, in many | the anonymity of the original source. But, be aware that, in many | |||
| cases, the analysis of logs and information at other sites will | cases, the analysis of logs and information at other sites will | |||
| reveal addresses of your site. | reveal addresses of your site. | |||
| All the problems discussed above should be not taken as reasons not | All the problems discussed above should be not taken as reasons not | |||
| to involve other sites. In fact, the experiences of existing teams | to involve other sites. In fact, the experiences of existing teams | |||
| reveal that most sites informed about security problems are not even | reveal that most sites informed about security problems are not even | |||
| aware that their site had been compromised. Without timely | aware that their site had been compromised. Without timely | |||
| information, other sites are often unable to take action against | information, other sites are often unable to take action against | |||
| intruders. | intruders. | |||
| 5.2.5 Public Relations - Press Releases | 5.2.5 Internal Communications | |||
| It is crucial during a major incident to communicate why certain | ||||
| actions are being taken, and how the users (or departments) are | ||||
| expected to behave. In particular, it should be made very clear to | ||||
| users what they are allowed to say (and not say) to the outside world | ||||
| (including other departments). For example, it wouldn't be good for | ||||
| an organization if users replied to customers with something like, | ||||
| "I'm sorry the systems are down, we've had an intruder and we are | ||||
| trying to clean things up." It would be much better if they were | ||||
| instructed to respond with a prepared statement like, "I'm sorry our | ||||
| systems are unavailable, they are being maintained for better service | ||||
| in the future." | ||||
| Communications with customers and contract partners should be handled | ||||
| in a sensible, but sensitive way. One can prepare for the main issues | ||||
| by preparing a checklist. When an incident occurs, the checklist can | ||||
| be used with the addition of a sentence or two for the specific | ||||
| circumstances of the incident. | ||||
| Public relations departments can be very helpful during incidents. | ||||
| They should be involved in all planning and can provide well | ||||
| constructed responses for use when contact with outside departments | ||||
| and organizations is necessary. | ||||
| 5.2.6 Public Relations - Press Releases | ||||
| There has been a tremendous growth in the amount of media coverage | ||||
| dedicated to computer security incidents in the United States. Such | ||||
| press coverage is bound to extend to other countries as the Internet | ||||
| continues to grow and expand internationally. Readers from countries | ||||
| where such media attention has not yet occurred, can learn from the | ||||
| experiences in the U.S. and should be forwarned and prepared. | ||||
| One of the most important issues to consider is when, who, and how | One of the most important issues to consider is when, who, and how | |||
| much to release to the general public through the press. There are | much to release to the general public through the press. There are | |||
| many issues to consider when deciding this particular issue. First | many issues to consider when deciding this particular issue. First | |||
| and foremost, if a public relations office exists for the site, it is | and foremost, if a public relations office exists for the site, it is | |||
| important to use this office as liaison to the press. The public | important to use this office as liaison to the press. The public | |||
| relations office is trained in the type and wording of information | relations office is trained in the type and wording of information | |||
| released, and will help to assure that the image of the site is | released, and will help to assure that the image of the site is | |||
| protected during and after the incident (if possible). A public | protected during and after the incident (if possible). A public | |||
| relations office has the advantage that you can communicate candidly | relations office has the advantage that you can communicate candidly | |||
| skipping to change at page 39, line 55 ¶ | skipping to change at page 42, line 45 ¶ | |||
| that any information provided to the press will be quickly reviewed | that any information provided to the press will be quickly reviewed | |||
| by the perpetrator of the incident. Also note that misleading the | by the perpetrator of the incident. Also note that misleading the | |||
| press can often backfire and cause more damage than releasing | press can often backfire and cause more damage than releasing | |||
| sensitive information. | sensitive information. | |||
| While it is difficult to determine in advance what level of detail to | While it is difficult to determine in advance what level of detail to | |||
| provide to the press, some guidelines to keep in mind are: | provide to the press, some guidelines to keep in mind are: | |||
| (1) Keep the technical level of detail low. Detailed | (1) Keep the technical level of detail low. Detailed | |||
| information about the incident may provide enough | information about the incident may provide enough | |||
| information for copy-cat events or even damage the | information for others to launch similar attacks on | |||
| site's ability to prosecute once the event is over. | other sites, or even damage the site's ability to | |||
| prosecute the guilty party once the event is over. | ||||
| (2) Keep the speculation out of press statements. | (2) Keep the speculation out of press statements. | |||
| Speculation of who is causing the incident or the | Speculation of who is causing the incident or the | |||
| motives are very likely to be in error and may cause | motives are very likely to be in error and may cause | |||
| an inflamed view of the incident. | an inflamed view of the incident. | |||
| (3) Work with law enforcement professionals to assure that | (3) Work with law enforcement professionals to assure that | |||
| evidence is protected. If prosecution is involved, | evidence is protected. If prosecution is involved, | |||
| assure that the evidence collected is not divulged to | assure that the evidence collected is not divulged to | |||
| the press. | the press. | |||
| skipping to change at page 40, line 26 ¶ | skipping to change at page 43, line 16 ¶ | |||
| prepared. The popular press is famous for the "2 am" | prepared. The popular press is famous for the "2 am" | |||
| interview, where the hope is to catch the interviewee off | interview, where the hope is to catch the interviewee off | |||
| guard and obtain information otherwise not available. | guard and obtain information otherwise not available. | |||
| (5) Do not allow the press attention to detract from the | (5) Do not allow the press attention to detract from the | |||
| handling of the event. Always remember that the successful | handling of the event. Always remember that the successful | |||
| closure of an incident is of primary importance. | closure of an incident is of primary importance. | |||
| 5.3 Identifying an Incident | 5.3 Identifying an Incident | |||
| 5.3.1 Is it real? | 5.3.1 Is It Real? | |||
| This stage involves determining if a problem really exists. Of | This stage involves determining if a problem really exists. Of | |||
| course many if not most signs often associated with virus infection, | course many if not most signs often associated with virus infection, | |||
| system intrusions, malicious users, etc., are simply anomalies such | system intrusions, malicious users, etc., are simply anomalies such | |||
| as hardware failures or suspicious system/user behavior. To assist | as hardware failures or suspicious system/user behavior. To assist | |||
| in identifying whether there really is an incident, it is usually | in identifying whether there really is an incident, it is usually | |||
| helpful to obtain and use any detection software which may be | helpful to obtain and use any detection software which may be | |||
| available. Audit information is also extremely useful, especially in | available. Audit information is also extremely useful, especially in | |||
| determining whether there is a network attack. It is extremely | determining whether there is a network attack. It is extremely | |||
| important to obtain a system snapshot as soon as one suspects that | important to obtain a system snapshot as soon as one suspects that | |||
| something is wrong. Many incidents cause a dynamic chain of events | something is wrong. Many incidents cause a dynamic chain of events | |||
| to occur, and an initial system snapshot may be the most valuable | to occur, and an initial system snapshot may be the most valuable | |||
| tool for identifying the problem and any source of attack. Finally, | tool for identifying the problem and any source of attack. Finally, | |||
| it is important to start a log book. Recording system events, | it is important to start a log book. Recording system events, | |||
| telephone conversations, time stamps, etc., can lead to a more rapid | telephone conversations, time stamps, etc., can lead to a more rapid | |||
| and systematic identification of the problem, and is the basis for | and systematic identification of the problem, and is the basis for | |||
| subsequent stages of incident handling. | subsequent stages of incident handling. | |||
| There are certain indications or "symptoms" of an incident which | There are certain indications or "symptoms" of an incident that | |||
| deserve special attention: | deserve special attention: | |||
| (1) System crashes. | (1) System crashes. | |||
| (2) New user accounts (the account RUMPLESTILTSKIN has been | (2) New user accounts (the account RUMPLESTILTSKIN has been | |||
| unexpectedly created), or high activity on a previously | unexpectedly created), or high activity on a previously | |||
| low usage account. | low usage account. | |||
| (3) New files (usually with novel or strange file names, | (3) New files (usually with novel or strange file names, | |||
| such as data.xx or k or .xx ). | such as data.xx or k or .xx ). | |||
| (4) Accounting discrepancies (in a UNIX system you might | (4) Accounting discrepancies (in a UNIX system you might | |||
| notice the shrinking of an accounting file called | notice the shrinking of an accounting file called | |||
| skipping to change at page 41, line 55 ¶ | skipping to change at page 44, line 45 ¶ | |||
| (9) Is law enforcement involved? | (9) Is law enforcement involved? | |||
| 5.3.3 Assessing the Damage and Extent | 5.3.3 Assessing the Damage and Extent | |||
| The analysis of the damage and extent of the incident can be quite | The analysis of the damage and extent of the incident can be quite | |||
| time consuming, but should lead to some insight into the nature of | time consuming, but should lead to some insight into the nature of | |||
| the incident, and aid investigation and prosecution. As soon as the | the incident, and aid investigation and prosecution. As soon as the | |||
| breach has occurred, the entire system and all of its components | breach has occurred, the entire system and all of its components | |||
| should be considered suspect. System software is the most probable | should be considered suspect. System software is the most probable | |||
| target. Preparation is key to be able to detect all changes for a | target. Preparation is key to be able to detect all changes for a | |||
| possibly tainted system. This includes checksumming all tapes from | possibly tainted system. This includes checksumming all media from | |||
| the vendor using a algorithm which is resistant to tampering. (See | the vendor using a algorithm which is resistant to tampering. (See | |||
| sections 4.3) | sections 4.3) | |||
| Assuming original vendor distribution tapes are available, an | ||||
| Assuming original vendor distribution media are available, an | ||||
| analysis of all system files should commence, and any irregularities | analysis of all system files should commence, and any irregularities | |||
| should be noted and referred to all parties involved in handling the | should be noted and referred to all parties involved in handling the | |||
| incident. It can be very difficult, in some cases, to decide which | incident. It can be very difficult, in some cases, to decide which | |||
| backup tapes are showing a correct system status. Consider, for | backup media are showing a correct system status. Consider, for | |||
| example, that the incident may have continued for months or years | example, that the incident may have continued for months or years | |||
| before discovery, and the suspect may be an employee of the site, or | before discovery, and the suspect may be an employee of the site, or | |||
| otherwise have intimate knowledge or access to the systems. In all | otherwise have intimate knowledge or access to the systems. In all | |||
| cases, the pre-incident preparation will determine what recovery is | cases, the pre-incident preparation will determine what recovery is | |||
| possible. | possible. | |||
| If the system supports centralized logging (most do), go back over | If the system supports centralized logging (most do), go back over | |||
| the logs and look for abnormalities. If process accounting and | the logs and look for abnormalities. If process accounting and | |||
| connect time accounting is enabled, look for patterns of system | connect time accounting is enabled, look for patterns of system | |||
| usage. To a lesser extent, disk usage may shed light on the | usage. To a lesser extent, disk usage may shed light on the | |||
| incident. Accounting can provide much helpful information in an | incident. Accounting can provide much helpful information in an | |||
| analysis of an incident and subsequent prosecution. Your ability to | analysis of an incident and subsequent prosecution. Your ability to | |||
| address all aspects of a specific incident strongly depends on the | address all aspects of a specific incident strongly depends on the | |||
| success of this analysis. | success of this analysis. | |||
| 5.4 Handling an Incident | 5.4 Handling an Incident | |||
| Certain steps are necessary to take during the handling of an | Certain steps are necessary to take during the handling of an | |||
| incident. In all security related activities, the most important | incident. In all security related activities, the most important | |||
| point to be made is: One should have policies in place. Without | point to be made is that all sites should have policies in place. | |||
| defined goals, activities undertaken will remain without focus. The | Without defined policies and goals, activities undertaken will remain | |||
| goals should be defined by management and legal counsel in advance. | without focus. The goals should be defined by management and legal | |||
| counsel in advance. | ||||
| One of the most fundamental objectives is to restore control of the | One of the most fundamental objectives is to restore control of the | |||
| affected systems and to limit the impact and damage. In the worst | affected systems and to limit the impact and damage. In the worst | |||
| case scenario, shutting down the system, or disconnecting the system | case scenario, shutting down the system, or disconnecting the system | |||
| from the network, may the only practical solution. | from the network, may the only practical solution. | |||
| As the activities involved are complex, try to get as much help as | As the activities involved are complex, try to get as much help as | |||
| necessary. While trying to solve the problem alone, real damage | necessary. While trying to solve the problem alone, real damage | |||
| might occur due to delays or missing information. Most system | might occur due to delays or missing information. Most | |||
| administrators take the discovery of an intruder as personal | administrators take the discovery of an intruder as a personal | |||
| challenge. By proceeding this way, other objectives as outlined in | challenge. By proceeding this way, other objectives as outlined in | |||
| the local policies may not always be considered. Trying to catch | the local policies may not always be considered. Trying to catch | |||
| intruders may be a very low priority, compared to system integrity, | intruders may be a very low priority, compared to system integrity, | |||
| for example. Monitoring a hacker's activity is useful, but it might | for example. Monitoring a hacker's activity is useful, but it might | |||
| not be considered worth the risk to allow continued access. | not be considered worth the risk to allow the continued access. | |||
| 5.4.1 Types of notification, Exchange of information | 5.4.1 Types of Notification and Exchange of Information | |||
| When you have confirmed that an incident is occurring, the | When you have confirmed that an incident is occurring, the | |||
| appropriate personnel must be notified. How this notification is | appropriate personnel must be notified. How this notification is | |||
| achieved is very important to keeping the event under control both | achieved is very important to keeping the event under control both | |||
| from a technical and emotional standpoint. The circumstances should | from a technical and emotional standpoint. The circumstances should | |||
| be described in as much detail as possible, in order to aid prompt | be described in as much detail as possible, in order to aid prompt | |||
| acknowledgment and understanding of the problem. Great care should | acknowledgment and understanding of the problem. Great care should | |||
| be taken when determining to which groups detailed technical | be taken when determining to which groups detailed technical | |||
| information is given during the notification. For example, it is | information is given during the notification. For example, it is | |||
| helpful to pass this kind of information to an incident handling team | helpful to pass this kind of information to an incident handling team | |||
| skipping to change at page 43, line 15 ¶ | skipping to change at page 46, line 7 ¶ | |||
| vulnerabilities involved in an incident. On the other hand, putting | vulnerabilities involved in an incident. On the other hand, putting | |||
| the critical knowledge into the public domain (e.g., via USENET | the critical knowledge into the public domain (e.g., via USENET | |||
| newsgroups or mailing lists) may potentially put a large number of | newsgroups or mailing lists) may potentially put a large number of | |||
| systems at risk of intrusion. It is invalid to assume that all | systems at risk of intrusion. It is invalid to assume that all | |||
| administrators reading a particular newsgroup have access to | administrators reading a particular newsgroup have access to | |||
| operating system source code, or can even understand an advisory well | operating system source code, or can even understand an advisory well | |||
| enough to take adequate steps. | enough to take adequate steps. | |||
| First of all, any notification to either local or off-site personnel | First of all, any notification to either local or off-site personnel | |||
| must be explicit. This requires that any statement (be it an | must be explicit. This requires that any statement (be it an | |||
| electronic mail message, phone call, or fax) providing information | electronic mail message, phone call, fax, beeper, or semaphone) | |||
| about the incident be clear, concise, and fully qualified. When you | providing information about the incident be clear, concise, and fully | |||
| are notifying others that will help you handle an event, a "smoke | qualified. When you are notifying others that will help you handle | |||
| screen" will only divide the effort and create confusion. If a | an event, a "smoke screen" will only divide the effort and create | |||
| division of labor is suggested, it is helpful to provide information | confusion. If a division of labor is suggested, it is helpful to | |||
| to each participant about what is being accomplished in other | provide information to each participant about what is being | |||
| efforts. This will not only reduce duplication of effort, but allow | accomplished in other efforts. This will not only reduce duplication | |||
| people working on parts of the problem to know where to obtain | of effort, but allow people working on parts of the problem to know | |||
| information relevant to their part of the incident. | where to obtain information relevant to their part of the incident. | |||
| Another important consideration when communicating about the incident | Another important consideration when communicating about the incident | |||
| is to be factual. Attempting to hide aspects of the incident by | is to be factual. Attempting to hide aspects of the incident by | |||
| providing false or incomplete information may not only prevent a | providing false or incomplete information may not only prevent a | |||
| successful resolution to the incident, but may even worsen the | successful resolution to the incident, but may even worsen the | |||
| situation. | situation. | |||
| The choice of language used when notifying people about the incident | The choice of language used when notifying people about the incident | |||
| can have a profound effect on the way that information is received. | can have a profound effect on the way that information is received. | |||
| When you use emotional or inflammatory terms, you raise the potential | When you use emotional or inflammatory terms, you raise the potential | |||
| skipping to change at page 44, line 21 ¶ | skipping to change at page 47, line 12 ¶ | |||
| to someone else, the following minimum information should be | to someone else, the following minimum information should be | |||
| provided: | provided: | |||
| (1) timezone of logs, ... in GMT or local time | (1) timezone of logs, ... in GMT or local time | |||
| (2) information about the remote system, including host names, | (2) information about the remote system, including host names, | |||
| IP addresses and (perhaps) user IDs | IP addresses and (perhaps) user IDs | |||
| (3) all log entries relevant for the remote site | (3) all log entries relevant for the remote site | |||
| (4) type of incident (what happened, why should you care) | (4) type of incident (what happened, why should you care) | |||
| If local information (i.e., local user IDs) is included in the log | If local information (i.e., local user IDs) is included in the log | |||
| entries, it might be necessary to sanitize the entries beforehand to | entries, it will be necessary to sanitize the entries beforehand to | |||
| avoid privacy issues. In general, all information which might assist | avoid privacy issues. In general, all information which might assist | |||
| a remote site in resolving an incident should be given out, unless | a remote site in resolving an incident should be given out, unless | |||
| local policies prohibit this. | local policies prohibit this. | |||
| 5.4.2 Protecting Evidence and Activity Logs | 5.4.2 Protecting Evidence and Activity Logs | |||
| When you respond to an incident, document all details related to the | When you respond to an incident, document all details related to the | |||
| incident. This will provide valuable information to yourself and | incident. This will provide valuable information to yourself and | |||
| others as you try to unravel the course of events. Documenting all | others as you try to unravel the course of events. Documenting all | |||
| details will ultimately save you time. If you don't document every | details will ultimately save you time. If you don't document every | |||
| skipping to change at page 44, line 49 ¶ | skipping to change at page 47, line 40 ¶ | |||
| provide the basis for later phases of the handling process: | provide the basis for later phases of the handling process: | |||
| eradication, recovery, and follow-up "lessons learned." | eradication, recovery, and follow-up "lessons learned." | |||
| During the initial stages of an incident, it is often infeasible to | During the initial stages of an incident, it is often infeasible to | |||
| determine whether prosecution is viable, so you should document as if | determine whether prosecution is viable, so you should document as if | |||
| you are gathering evidence for a court case. At a minimum, you | you are gathering evidence for a court case. At a minimum, you | |||
| should record: | should record: | |||
| (1) all system events (audit records) | (1) all system events (audit records) | |||
| (2) all actions you take (time tagged) | (2) all actions you take (time tagged) | |||
| (3) all phone conversations (including the person with whom | (3) all external conversations (including the person with whom | |||
| you talked, the date and time, and the content of the | you talked, the date and time, and the content of the | |||
| conversation) | conversation) | |||
| The most straightforward way to maintain documentation is keeping a | The most straightforward way to maintain documentation is keeping a | |||
| log book. This allows you to go to a centralized, chronological | log book. This allows you to go to a centralized, chronological | |||
| source of information when you need it, instead of requiring you to | source of information when you need it, instead of requiring you to | |||
| page through individual sheets of paper. Much of this information is | page through individual sheets of paper. Much of this information is | |||
| potential evidence in a court of law. Thus, when you initially | potential evidence in a court of law. Thus, when a legal follow-up | |||
| suspect that an incident will result in prosecution or when an | is a possibility, one should follow the prepared procedures and avoid | |||
| investigative agency becomes involved, you need to: | jeopardizing the legal follow-up by improper handling of possible | |||
| evidence. If appropriate, the following steps may be taken. | ||||
| (1) Regularly (e.g., every day) turn in photocopied, signed | (1) Regularly (e.g., every day) turn in photocopied, signed | |||
| copies of your logbook (as well as media you use to record | copies of your logbook (as well as media you use to record | |||
| system events) to a document custodian. | system events) to a document custodian. | |||
| (2) The custodian should store these copied pages in a secure | (2) The custodian should store these copied pages in a secure | |||
| place (e.g., a safe). | place (e.g., a safe). | |||
| (3) When you submit information for storage, you should | (3) When you submit information for storage, you should | |||
| receive a signed, dated receipt from the document | receive a signed, dated receipt from the document | |||
| custodian. | custodian. | |||
| skipping to change at page 46, line 4 ¶ | skipping to change at page 48, line 50 ¶ | |||
| 5.4.4 Eradication | 5.4.4 Eradication | |||
| Once the incident has been contained, it is time to eradicate the | Once the incident has been contained, it is time to eradicate the | |||
| cause. But before eradicating the cause, great care should be taken | cause. But before eradicating the cause, great care should be taken | |||
| to collect all necessary information about the compromised system(s) | to collect all necessary information about the compromised system(s) | |||
| and the cause of the incident as they will likely be lost when | and the cause of the incident as they will likely be lost when | |||
| cleaning up the system. | cleaning up the system. | |||
| Software may be available to help you in the eradication process, | Software may be available to help you in the eradication process, | |||
| such as anti-virus software for small systems. If any bogus files | such as anti-virus software. If any bogus files have been created, | |||
| have been created archive them before deleting them. In the case of | archive them before deleting them. In the case of virus infections, | |||
| virus infections, it is important to clean and reformat any disks | it is important to clean and reformat any media containing infected | |||
| containing infected files. Finally, ensure that all backups are | files. Finally, ensure that all backups are clean. Many systems | |||
| clean. Many systems infected with viruses become periodically re- | infected with viruses become periodically re-infected simply because | |||
| infected simply because people do not systematically eradicate the | people do not systematically eradicate the virus from backups. After | |||
| virus from backups. After eradication, a new backup should be taken. | eradication, a new backup should be taken. | |||
| Removing all vulnerabilities once an incident has occurred is | Removing all vulnerabilities once an incident has occurred is | |||
| difficult. The key to removing vulnerabilities is knowledge and | difficult. The key to removing vulnerabilities is knowledge and | |||
| understanding of the breach. | understanding of the breach. | |||
| It may be necessary to go back to the original distribution tapes and | It may be necessary to go back to the original distribution media and | |||
| re-customize the system. To facilitate this worst case scenario, a | re-customize the system. To facilitate this worst case scenario, a | |||
| record of the original system setup and each customization change | record of the original system setup and each customization change | |||
| should be maintained. In the case of a network-based attack, it is | should be maintained. In the case of a network-based attack, it is | |||
| important to install patches for each operating system vulnerability | important to install patches for each operating system vulnerability | |||
| which was exploited. | which was exploited. | |||
| As discussed in section 5.4.2, a security log can be most valuable | As discussed in section 5.4.2, a security log can be most valuable | |||
| during this phase of removing vulnerabilities. The logs showing how | during this phase of removing vulnerabilities. The logs showing how | |||
| the incident was discovered and contained can be used later to help | the incident was discovered and contained can be used later to help | |||
| determine how extensive the damage was from a given incident. The | determine how extensive the damage was from a given incident. The | |||
| skipping to change at page 46, line 54 ¶ | skipping to change at page 49, line 47 ¶ | |||
| system are extremely important and should be specific to the site. | system are extremely important and should be specific to the site. | |||
| 5.4.6 Follow-Up | 5.4.6 Follow-Up | |||
| Once you believe that a system has been restored to a "safe" state, | Once you believe that a system has been restored to a "safe" state, | |||
| it is still possible that holes, and even traps, could be lurking in | it is still possible that holes, and even traps, could be lurking in | |||
| the system. One of the most important stages of responding to | the system. One of the most important stages of responding to | |||
| incidents is also the most often omitted, the follow-up stage. In | incidents is also the most often omitted, the follow-up stage. In | |||
| the follow-up stage, the system should be monitored for items that | the follow-up stage, the system should be monitored for items that | |||
| may have been missed during the cleanup stage. It would be prudent | may have been missed during the cleanup stage. It would be prudent | |||
| to utilize some of the tools mentioned in section xxx (e.g., xxx) as | to utilize some of the tools mentioned in chapter 7 as a start. | |||
| a start. Remember, these tools don't replace continual system | Remember, these tools don't replace continual system monitoring and | |||
| monitoring and good systems administration practices. | good systems administration practices. | |||
| The most important element of the follow-up stage is performing a | The most important element of the follow-up stage is performing a | |||
| postmortem analysis. Exactly what happened, and at what times? How | postmortem analysis. Exactly what happened, and at what times? How | |||
| well did the staff involved with the incident perform? What kind of | well did the staff involved with the incident perform? What kind of | |||
| information did the staff need quickly, and how could they have | information did the staff need quickly, and how could they have | |||
| gotten that information as soon as possible? What would the staff do | gotten that information as soon as possible? What would the staff do | |||
| differently next time? | differently next time? | |||
| After an incident, it is prudent to write a report describing the | After an incident, it is prudent to write a report describing the | |||
| exact sequence of events: the method of discovery, correction | exact sequence of events: the method of discovery, correction | |||
| skipping to change at page 48, line 15 ¶ | skipping to change at page 51, line 7 ¶ | |||
| The whole purpose of this post mortem process is to improve all | The whole purpose of this post mortem process is to improve all | |||
| security measures to protect the site against future attacks. As a | security measures to protect the site against future attacks. As a | |||
| result of an incident, a site or organization should gain practical | result of an incident, a site or organization should gain practical | |||
| knowledge from the experience. A concrete goal of the post mortem is | knowledge from the experience. A concrete goal of the post mortem is | |||
| to develop new proactive methods. Another important facet of the | to develop new proactive methods. Another important facet of the | |||
| aftermath may be end user and administrator education to prevent a | aftermath may be end user and administrator education to prevent a | |||
| reoccurrence of the security problem. | reoccurrence of the security problem. | |||
| 5.6 Responsibilities | 5.6 Responsibilities | |||
| 5.6.1 Not crossing the line | 5.6.1 Not Crossing the Line | |||
| It is one thing to protect one's own network, but quite another to | It is one thing to protect one's own network, but quite another to | |||
| assume that one should protect other networks. During the handling | assume that one should protect other networks. During the handling | |||
| of an incident, certain system vulnerabilities of one's own systems | of an incident, certain system vulnerabilities of one's own systems | |||
| and the systems of others become apparent. It is quite easy and may | and the systems of others become apparent. It is quite easy and may | |||
| even be tempting to pursue the intruders in order to track them. | even be tempting to pursue the intruders in order to track them. | |||
| Keep in mind that at a certain point it is possible to "cross the | Keep in mind that at a certain point it is possible to "cross the | |||
| line," and, with the best of intentions, become no better than the | line," and, with the best of intentions, become no better than the | |||
| intruder. | intruder. | |||
| skipping to change at page 49, line 11 ¶ | skipping to change at page 51, line 58 ¶ | |||
| action that assumes the user intentionally caused the incident may | action that assumes the user intentionally caused the incident may | |||
| not be appropriate for a user who simply made a mistake. It may be | not be appropriate for a user who simply made a mistake. It may be | |||
| appropriate to include sanctions more suitable for such a situation | appropriate to include sanctions more suitable for such a situation | |||
| in your policies (e.g., education or reprimand of a user) in addition | in your policies (e.g., education or reprimand of a user) in addition | |||
| to more stern measures for intentional acts of intrusion and system | to more stern measures for intentional acts of intrusion and system | |||
| misuse. | misuse. | |||
| 6. Ongoing Activities | 6. Ongoing Activities | |||
| At this point in time, your site has hopefully developed a complete | At this point in time, your site has hopefully developed a complete | |||
| security policy and developed procedures to assist in the | security policy and has developed procedures to assist in the | |||
| configuration and management of your technology in support of those | configuration and management of your technology in support of those | |||
| policies. How nice it would be if you could sit back and relax at | policies. How nice it would be if you could sit back and relax at | |||
| this point and know that you were finished with the job of security. | this point and know that you were finished with the job of security. | |||
| Unfortunately, that isn't the case. Your systems and networks are | Unfortunately, that isn't possible. Your systems and networks are | |||
| not a static environment, so you will need to review policies and | not a static environment, so you will need to review policies and | |||
| procedures on a regular basis. There are a number of steps you can | procedures on a regular basis. There are a number of steps you can | |||
| take to help you keep up with the changes around you so that you can | take to help you keep up with the changes around you so that you can | |||
| initiate corresponding actions to address those changes. The | initiate corresponding actions to address those changes. The | |||
| following is a starter set and you may add others as appropriate for | following is a starter set and you may add others as appropriate for | |||
| your site. | your site. | |||
| (1) Subscribe to advisories that are issued by various security incide= | (1) Subscribe to advisories that are issued by various security incident | |||
| nt | response teams, like those of the CERT Coordination Center, and | |||
| response teams, like those of the CERT Coordination Center [ref], = | update your systems against those threats that apply to your site's | |||
| and | ||||
| update your systems against those threats that apply to your site'= | ||||
| s | ||||
| technology. | technology. | |||
| (2) Monitor security patches that are produced by the vendors of your | (2) Monitor security patches that are produced by the vendors of your | |||
| equipment, and obtain and install all that apply. | equipment, and obtain and install all that apply. | |||
| (3) Actively watch the configurations of your systems to identify any | (3) Actively watch the configurations of your systems to identify any | |||
| changes that may have occurred, then investigate all anomalies. | changes that may have occurred, and investigate all anomalies. | |||
| (4) Review all security policies and procedures annually (at a minimum= | (4) Review all security policies and procedures annually (at a minimum). | |||
| ) | ||||
| (5) Read appropriate mailing lists and USENET newsgroups to keep up to | (5) Read relevant mailing lists and USENET newsgroups to keep up to | |||
| date with the latest information being shared by fellow | date with the latest information being shared by fellow | |||
| administrators. | administrators. | |||
| (6) Regularly check for compliance to policies and procedures. This | (6) Regularly check for compliance with policies and procedures. This | |||
| audit should be performed by someone other than the people who | audit should be performed by someone other than the people who | |||
| define or implement the policies and procedures. | define or implement the policies and procedures. | |||
| 7. Tools and Locations | 7. Tools and Locations | |||
| This section provides a brief overview of publicly available security | This chapter provides a brief list of publicly available security | |||
| technology which can be downloaded from the Internet. Many of the | technology which can be downloaded from the Internet. Many of the | |||
| items described below will undoubtedly be surpassed or made obsolete | items described below will undoubtedly be surpassed or made obsolete | |||
| before this document is published. This section is divided into two | before this document is published. | |||
| major subsections, applications and tools. The applications heading | ||||
| will include all end user programs (clients) and their supporting | ||||
| system infrastructure (servers). The tools heading will deal with | ||||
| the tools that a general user will never see or need to use, but | ||||
| which may be part of or used by applications, used to troubleshoot | ||||
| security problems or guard against intruders by system and network | ||||
| administrators. | ||||
| The emphasis will be on UNIX applications and tools, but other | Some of the tools listed are applications such as end user programs | |||
| platforms, particularly PC's and Macintoshes, will be mentioned where | (clients) and their supporting system infrastructure (servers). | |||
| information is available. | Others are tools that a general user will never see or need to use, | |||
| but may be used by applications, or by administrators to troubleshoot | ||||
| security problems or to guard against intruders. | ||||
| A sad fact is that there are very few security conscious applications | ||||
| currently available. Primarily, this is caused by the need for a | ||||
| security infrastructure which must first be put into place for most | ||||
| applications to operate securely. There is considerable effort | ||||
| currently taking place to build this infrastructure so that | ||||
| applications can take advantage of secure communications. | ||||
| Most of the tools and applications described below can be found in | Most of the tools and applications described below can be found in | |||
| one of the following two archive sites: | one of the following archive sites: | |||
| (1) CERT Coordination Center | (1) CERT Coordination Center | |||
| ftp://info.cert.org:/pub/tools | ftp://info.cert.org:/pub/tools | |||
| (2) DFN-CERT | (2) DFN-CERT | |||
| ftp://ftp.cert.dfn.de/pub/tools/ | ftp://ftp.cert.dfn.de/pub/tools/ | |||
| (3) Computer Operations, Audit, and Security Tools (COAST) | (3) Computer Operations, Audit, and Security Tools (COAST) | |||
| coast.cs.purdue.edu:/pub/tools | coast.cs.purdue.edu:/pub/tools | |||
| Any references to CERT or COAST will refer to these two locations. | It is important to note that many sites, including CERT and COAST are | |||
| These two sites act as repositories for most tools, exceptions will | mirrored throughout the Internet. Be careful to use a "well known" | |||
| be noted in the text. *** It is important to note that many sites, | mirror site to retrieve software, and to use verification tools (md5 | |||
| including CERT and COAST are mirrored throughout the Internet. Be | checksums, etc.) to validate that software. A clever cracker might | |||
| careful to use a "well known" mirror site to retrieve software and to | advertise security software that has intentionally been designed to | |||
| use whatever verification tools possible, checksums, md5 checksums, | provide access to data or systems. | |||
| etc... to validate that software. A clever cracker might advertise | ||||
| security software with designed flaws in order to gain access to data | ||||
| or machines. *** | ||||
| Applications | ||||
| The sad truth is that there are very few security conscious | ||||
| applications currently available. The real reason is the need for a | ||||
| security infrastructure which must be first put into place for most | ||||
| applications to operate securely. There is considerable effort | ||||
| currently taking place to place this infrastructure so that | ||||
| applications can take advantage of secure communications. | ||||
| Unix based applications | Tools | |||
| COPS | COPS | |||
| DES | DES | |||
| Drawbridge | Drawbridge | |||
| identd (not really a security tool) | identd (not really a security tool) | |||
| ISS | ISS | |||
| Kerberos | Kerberos | |||
| logdaemon | logdaemon | |||
| lsof | lsof | |||
| MD5 | MD5 | |||
| skipping to change at page 51, line 37 ¶ | skipping to change at page 54, line 18 ¶ | |||
| available. A CERT advisory may also be a warning to our | available. A CERT advisory may also be a warning to our | |||
| constituency about ongoing attacks (e.g., | constituency about ongoing attacks (e.g., | |||
| "CA-91:18.Active.Internet.tftp.Attacks"). | "CA-91:18.Active.Internet.tftp.Attacks"). | |||
| CERT advisories are also published on the USENET newsgroup: | CERT advisories are also published on the USENET newsgroup: | |||
| comp.security.announce | comp.security.announce | |||
| CERT advisory archives are available via anonymous FTP from | CERT advisory archives are available via anonymous FTP from | |||
| info.cert.org in the /pub/cert_advisories directory. | info.cert.org in the /pub/cert_advisories directory. | |||
| (2) CERT Tools Mailing List | (2) VIRUS-L List | |||
| Send mail to: cert-tools-request@cert.sei.cmu.edu | ||||
| Message Body: subscribe cert-tools FIRSTNAME LASTNAME | ||||
| The purpose of this moderated mailing list is to | ||||
| encourage the exchange of information on security | ||||
| tools and techniques. The list should not be used | ||||
| for security problem reports. | ||||
| (3) VIRUS-L List | ||||
| Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu | Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu | |||
| Message Body: subscribe virus-L FIRSTNAME LASTNAME | Message Body: subscribe virus-L FIRSTNAME LASTNAME | |||
| VIRUS-L is a moderated mailing list with a focus | VIRUS-L is a moderated mailing list with a focus | |||
| on computer virus issues. For more information, | on computer virus issues. For more information, | |||
| including a copy of the posting guidelines, see | including a copy of the posting guidelines, see | |||
| the file "virus-l.README", available by anonymous | the file "virus-l.README", available by anonymous | |||
| FTP from cs.ucr.edu. | FTP from cs.ucr.edu. | |||
| (4) Academic Firewalls | (3) Internet Firewalls | |||
| Send mail to: majordomo@greatcircle.com | Send mail to: majordomo@greatcircle.com | |||
| Message Body: subscribe firewalls user@host | Message Body: subscribe firewalls user@host | |||
| The Firewalls mailing list is a discussion forum for | The Firewalls mailing list is a discussion forum for | |||
| firewall administrators and implementors. | firewall administrators and implementors. | |||
| USENET newsgroups | USENET newsgroups | |||
| (1) comp.security.announce | (1) comp.security.announce | |||
| The comp.security.announce newsgroup is moderated | The comp.security.announce newsgroup is moderated | |||
| skipping to change at page 52, line 56 ¶ | skipping to change at page 55, line 28 ¶ | |||
| security-related threats, vulnerabilities, and solutions. At the | security-related threats, vulnerabilities, and solutions. At the | |||
| same time, the Clearinghouse strives to be a general index to | same time, the Clearinghouse strives to be a general index to | |||
| computer security information on a broad variety of subjects, | computer security information on a broad variety of subjects, | |||
| including general risks, privacy, legal issues, viruses, | including general risks, privacy, legal issues, viruses, | |||
| assurance, policy, and training. | assurance, policy, and training. | |||
| (2) http://www.telstra.com.au/info/security.html | (2) http://www.telstra.com.au/info/security.html | |||
| This Reference Index contains a list of links to information | This Reference Index contains a list of links to information | |||
| sources on Network and Computer Security. There is no implied | sources on Network and Computer Security. There is no implied | |||
| fitness to the Tools, Techniques and Documents contained within th= | fitness to the Tools, Techniques and Documents contained within this | |||
| is | ||||
| archive. Many if not all of these items work well, but we do | archive. Many if not all of these items work well, but we do | |||
| not guarantee that this will be so. This information is for the | not guarantee that this will be so. This information is for the | |||
| education and legitimate use of computer security techniques only. | education and legitimate use of computer security techniques only. | |||
| (3) http://www.alw.nih.gov/Security/security.html | (3) http://www.alw.nih.gov/Security/security.html | |||
| This page features general information about computer security. | This page features general information about computer security. | |||
| Information is organized by source and each section is organized | Information is organized by source and each section is organized | |||
| by topic. Recent modifications are noted in What's New page. | by topic. Recent modifications are noted in What's New page. | |||
| 9. References | 9. References | |||
| The following references may not be available in all countries. | ||||
| [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and | [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and | |||
| McAuliffe, "The Law and The Internet", USENIX 1995 Technical | McAuliffe, "The Law and The Internet", USENIX 1995 Technical | |||
| Conference on UNIX and Advanced Computing, New Orleans, LA, January | Conference on UNIX and Advanced Computing, New Orleans, LA, January | |||
| 16-20, 1995. | 16-20, 1995. | |||
| [ABA, 1989] American Bar Association, Section of Science and | [ABA, 1989] American Bar Association, Section of Science and | |||
| Technology, "Guide to the Prosecution of Telecommunication Fraud by | Technology, "Guide to the Prosecution of Telecommunication Fraud by | |||
| the Use of Computer Crime Statutes", American Bar Association, 1989. | the Use of Computer Crime Statutes", American Bar Association, 1989. | |||
| [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", | [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", | |||
| skipping to change at page 54, line 25 ¶ | skipping to change at page 56, line 53 ¶ | |||
| [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, | [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, | |||
| Butterworth Publishers, Stoneham, MA, 1987. | Butterworth Publishers, Stoneham, MA, 1987. | |||
| [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and | [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and | |||
| The Law", MIT Press, Cambridge, MA, 1995. | The Law", MIT Press, Cambridge, MA, 1995. | |||
| [CCH, 1989] Commerce Clearing House, "Guide to Computer Law", | [CCH, 1989] Commerce Clearing House, "Guide to Computer Law", | |||
| (Topical Law Reports), Chicago, IL., 1989. | (Topical Law Reports), Chicago, IL., 1989. | |||
| [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet | [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet | |||
| Filtering", USSENIX: Proceedings of the Thrid UNIX Security | Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, | |||
| Symposium, Baltimore, MD, September 1992. | Baltimore, MD, September 1992. | |||
| [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building | [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building | |||
| Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. | Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. | |||
| [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet | [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet | |||
| Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, | Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, | |||
| June 1990. | June 1990. | |||
| [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker | [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker | |||
| is Lured, Endured, and Studied", AT&T Bell Laboratories. | is Lured, Endured, and Studied", AT&T Bell Laboratories. | |||
| skipping to change at page 56, line 55 ¶ | skipping to change at page 59, line 27 ¶ | |||
| [Howard, 1995] G. Howard, "Introduction to Internet Security: From | [Howard, 1995] G. Howard, "Introduction to Internet Security: From | |||
| Basics to Beyond", Prima Publishing, Rocklin, CA, 1995. | Basics to Beyond", Prima Publishing, Rocklin, CA, 1995. | |||
| [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, | [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, | |||
| "Protection of Computer Systems and Software: New Approaches for | "Protection of Computer Systems and Software: New Approaches for | |||
| Combating Theft of Software and Unauthorized Intrusion", Papers | Combating Theft of Software and Unauthorized Intrusion", Papers | |||
| presented at a workshop sponsored by the National Science Foundation, | presented at a workshop sponsored by the National Science Foundation, | |||
| 1986. | 1986. | |||
| [Hughes, 1995] L. Hughes Jr., "Actually Useful: Internet Security | [Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security | |||
| Techniques", New Riders Publishing, Indianapolis, IN, 1995. | Techniques", New Riders Publishing, Indianapolis, IN, 1995. | |||
| [IAB-RFC1087, 89] Internet Activities Board, "Ethics and the | [IAB-RFC1087, 89] Internet Activities Board, "Ethics and the | |||
| Internet", RFC 1087, IAB, January 1989. Also appears in the | Internet", RFC 1087, IAB, January 1989. Also appears in the | |||
| Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. | Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. | |||
| [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. | [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. | |||
| VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & | VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & | |||
| Associates, Sebastopol, CA, 1995. | Associates, Sebastopol, CA, 1995. | |||
| skipping to change at page 59, line 51 ¶ | skipping to change at page 62, line 24 ¶ | |||
| Products and Services Catalog", NSA, Quarterly Publication. | Products and Services Catalog", NSA, Quarterly Publication. | |||
| [NSF, 1988] National Science Foundation, "NSF Poses Code of | [NSF, 1988] National Science Foundation, "NSF Poses Code of | |||
| Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. | Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. | |||
| 688, June 1989. Also appears in the minutes of the regular meeting | 688, June 1989. Also appears in the minutes of the regular meeting | |||
| of the Division Advisory Panel for Networking and Communications | of the Division Advisory Panel for Networking and Communications | |||
| Research and Infrastructure, Dave Farber, Chair, November 29-30, | Research and Infrastructure, Dave Farber, Chair, November 29-30, | |||
| 1988. | 1988. | |||
| [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation | [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation | |||
| Security Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987, 58 | Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 | |||
| pages. | pages. | |||
| [OTA-CIT-310, 1987] United States Congress, Office of Technology | [OTA-CIT-310, 1987] United States Congress, Office of Technology | |||
| Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for | Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for | |||
| Electronic Information", OTA-CIT-310, October 1987. | Electronic Information", OTA-CIT-310, October 1987. | |||
| [OTA-TCT-606] Congress of the United States, Office of Technology | [OTA-TCT-606] Congress of the United States, Office of Technology | |||
| Assessment, "Information Security and Privacy in Network | Assessment, "Information Security and Privacy in Network | |||
| Environments", OTA-TCT-606, September 1994. | Environments", OTA-TCT-606, September 1994. | |||
| skipping to change at page 60, line 29 ¶ | skipping to change at page 62, line 55 ¶ | |||
| Business", QED Information Sciences, Inc., Wellesley, MA. (245 | Business", QED Information Sciences, Inc., Wellesley, MA. (245 | |||
| pages). | pages). | |||
| [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, | [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, | |||
| Englewood Cliffs, NJ, 1989. | Englewood Cliffs, NJ, 1989. | |||
| [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks | [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks | |||
| and Conferencing Systems Worldwide", Digital Press, Bedford, MA, | and Conferencing Systems Worldwide", Digital Press, Bedford, MA, | |||
| 1990. | 1990. | |||
| [Ranum1, 1992] M. Ranum, "An Internet Firwall", Proceedings of World | [Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World | |||
| Conference on Systems Management and Security, 1992. | Conference on Systems Management and Security, 1992. | |||
| [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment | [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment | |||
| Corporation Washington Open Systems Resource Center, June 12, 1992. | Corporation Washington Open Systems Resource Center, June 12, 1992. | |||
| [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. | [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. | |||
| [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and | [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and | |||
| Methods for Internet Firewalls", Trustest Information Systems, 1994. | Methods for Internet Firewalls", Trustest Information Systems, 1994. | |||
| skipping to change at page 61, line 10 ¶ | skipping to change at page 63, line 36 ¶ | |||
| second edition, 1996. | second edition, 1996. | |||
| [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 | [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 | |||
| Winter USENIX Conference, Usenix Association, San Diego, CA, February | Winter USENIX Conference, Usenix Association, San Diego, CA, February | |||
| 1989. | 1989. | |||
| [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", | [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", | |||
| Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. | Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. | |||
| [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit | [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit | |||
| and Capture of Kevin Mitnick, America's Most Wanted Comptuer Outlaw- | and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw- | |||
| by the Man Who Did It", Hyperion, 324p, 1996. | by the Man Who Did It", Hyperion, 324p, 1996. | |||
| [Shirey, 1990] R. Shirey, "Defense Data Network Security | [Shirey, 1990] R. Shirey, "Defense Data Network Security | |||
| Architecture", Computer Communication Review, Vol. 20, No. 2, Page | Architecture", Computer Communication Review, Vol. 20, No. 2, Page | |||
| 66, 1 April 1990. | 66, 1 April 1990. | |||
| [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters | [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters | |||
| of Deception: The Gang that Ruled Cyberspace", Harper Collins | of Deception: The Gang that Ruled Cyberspace", Harper Collins | |||
| Publishers, 1995. | Publishers, 1995. | |||
| skipping to change at page 69, line 32 ¶ | skipping to change at page 72, line 4 ¶ | |||
| communications security, physical security, risk analysis and | communications security, physical security, risk analysis and | |||
| security planning, and legal and ethical issues. 538 pages including | security planning, and legal and ethical issues. 538 pages including | |||
| index and bibliography. | index and bibliography. | |||
| [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks | [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks | |||
| and Conferencing Systems Worldwide", Digital Press, Bedford, MA, | and Conferencing Systems Worldwide", Digital Press, Bedford, MA, | |||
| 1990. | 1990. | |||
| [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX | [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX | |||
| Network Security" | Network Security" | |||
| More details in USENIX Third UNIX Security Symposium, September 14-16 | ||||
| More details in USENIX Thrid UNIX Security Symposium, September 14-16 | ||||
| 1992. | 1992. | |||
| [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX | [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX | |||
| Network Security", ARINC Research Corporation, February 18, 1993. | Network Security", ARINC Research Corporation, February 18, 1993. | |||
| [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer | [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer | |||
| Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991. | Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991. | |||
| [Shirey, 1990] R. Shirey, "Defense Data Network Security | [Shirey, 1990] R. Shirey, "Defense Data Network Security | |||
| Architecture", Computer Communication Review, Vol. 20, No. 2, Page | Architecture", Computer Communication Review, Vol. 20, No. 2, Page | |||
| skipping to change at page 73, line 15 ¶ | skipping to change at page 75, line 38 ¶ | |||
| Access is via FTP, IP address ariel.umn.edu. Look in the | Access is via FTP, IP address ariel.umn.edu. Look in the | |||
| directory /ethics. | directory /ethics. | |||
| 10.4 Firewalls | 10.4 Firewalls | |||
| [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings | [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings | |||
| of the Third Usenix Security Symposium, Baltimore, MD. September, | of the Third Usenix Security Symposium, Baltimore, MD. September, | |||
| 1992. | 1992. | |||
| [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet | [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet | |||
| Filtering", USSENIX: Proceedings of the Thrid UNIX Security | Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, | |||
| Symposium, Balimore, MD, September 1992. | Baltimore, MD, September 1992. | |||
| [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building | [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building | |||
| Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. | Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. | |||
| [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker | [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker | |||
| is Lured, Endured, and Studied", AT&T Bell Laboratories. | is Lured, Endured, and Studied", AT&T Bell Laboratories. | |||
| [Cheswick2] W. Cheswick, "The Design of a Secure Internet Gateway", | [Cheswick2] W. Cheswick, "The Design of a Secure Internet Gateway", | |||
| Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990. | Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990. | |||
| skipping to change at page 73, line 42 ¶ | skipping to change at page 76, line 11 ¶ | |||
| managing firewalls. | managing firewalls. | |||
| [NCSA, 1995] NCSA, "NCSA Firewall Policy Guide", 1995. | [NCSA, 1995] NCSA, "NCSA Firewall Policy Guide", 1995. | |||
| [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 | [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 | |||
| Proceedings", 1996. | Proceedings", 1996. | |||
| [Ranum, 1992] M. Ranum, "A Network Firewall", Digital Equipment | [Ranum, 1992] M. Ranum, "A Network Firewall", Digital Equipment | |||
| Corporation Washington Open Systems Resource Center, June 12, 1992. | Corporation Washington Open Systems Resource Center, June 12, 1992. | |||
| [Ranum, 1992] M. Ranum, "An Internet Firwall", Proceedings of World | [Ranum, 1992] M. Ranum, "An Internet Firewall", Proceedings of World | |||
| Conference on Systems Management and Security, 1992. | Conference on Systems Management and Security, 1992. | |||
| Available ftp://decuac.dec.com/pub/docs/firewall/firewall.ps | Available ftp://decuac.dec.com/pub/docs/firewall/firewall.ps | |||
| [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. | [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. | |||
| A good start for those implementing or installing firewalls. | A good start for those implementing or installing firewalls. | |||
| Available ftp://ftp.tis.com | Available ftp://ftp.tis.com | |||
| [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and | [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and | |||
| skipping to change at page 76, line 34 ¶ | skipping to change at page 78, line 57 ¶ | |||
| Proceedings of the European Software Engineering Conference 1989, | Proceedings of the European Software Engineering Conference 1989, | |||
| Warwick England, September 1989. Proceedings published by Springer- | Warwick England, September 1989. Proceedings published by Springer- | |||
| Verlag as: Lecture Notes in Computer Science #387. Also issued as | Verlag as: Lecture Notes in Computer Science #387. Also issued as | |||
| Purdue Technical Report #CSD-TR-933. | Purdue Technical Report #CSD-TR-933. | |||
| 10.6 National Computer Security Center (NCSC) | 10.6 National Computer Security Center (NCSC) | |||
| All NCSC publications, approved for public release, are available | All NCSC publications, approved for public release, are available | |||
| from the NCSC Superintendent of Documents. | from the NCSC Superintendent of Documents. | |||
| NCSC =3D National Computer Security Center 9800 Savage Road Ft Meade, | NCSC = National Computer Security Center 9800 Savage Road Ft Meade, | |||
| MD 20755-6000 | MD 20755-6000 | |||
| CSC =3D Computer Security Center: an older name for the NCSC | CSC = Computer Security Center: an older name for the NCSC | |||
| NTISS =3D National Telecommunications and Information Systems Security | NTISS = National Telecommunications and Information Systems Security | |||
| NTISS Committee, National Security Agency Ft Meade, MD 20755-6000 | NTISS Committee, National Security Agency Ft Meade, MD 20755-6000 | |||
| [CSC-STD-002-85, 1985] Department of Defense, "Password Management | [CSC-STD-002-85, 1985] Department of Defense, "Password Management | |||
| Guideline", CSC-STD-002-85, 12 April 1985, 31 pages. | Guideline", CSC-STD-002-85, 12 April 1985, 31 pages. | |||
| The security provided by a password system depends on the passwords | The security provided by a password system depends on the passwords | |||
| being kept secret at all times. Thus, a password is vulnerable to | being kept secret at all times. Thus, a password is vulnerable to | |||
| compromise whenever it is used, stored, or even known. In a | compromise whenever it is used, stored, or even known. In a | |||
| password-based authentication mechanism implemented on an ADP system, | password-based authentication mechanism implemented on an ADP system, | |||
| passwords are vulnerable to compromise due to five essential aspects | passwords are vulnerable to compromise due to five essential aspects | |||
| skipping to change at page 77, line 52 ¶ | skipping to change at page 80, line 20 ¶ | |||
| be identified. The control task of configuration management is | be identified. The control task of configuration management is | |||
| performed by subjecting every change to documentation, hardware, and | performed by subjecting every change to documentation, hardware, and | |||
| software/firmware to review and approval by an authorized authority. | software/firmware to review and approval by an authorized authority. | |||
| Configuration status accounting is responsible for recording and | Configuration status accounting is responsible for recording and | |||
| reporting on the configuration of the product throughout the change. | reporting on the configuration of the product throughout the change. | |||
| Finally, though the process of a configuration audit, the completed | Finally, though the process of a configuration audit, the completed | |||
| change can be verified to be functionally correct, and for trusted | change can be verified to be functionally correct, and for trusted | |||
| systems, consistent with the security policy of the system. | systems, consistent with the security policy of the system. | |||
| [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation | [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation | |||
| Security Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987, 58 | Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 | |||
| pages. | pages. | |||
| This document provides guidance to users, managers, security | This document provides guidance to users, managers, security | |||
| officers, and procurement officers of Office Automation Systems. | officers, and procurement officers of Office Automation Systems. | |||
| Areas addressed include: physical security, personnel security, | Areas addressed include: physical security, personnel security, | |||
| procedural security, hardware/software security, emanations security | procedural security, hardware/software security, emanations security | |||
| (TEMPEST), and communications security for stand-alone OA Systems, OA | (TEMPEST), and communications security for stand-alone OA Systems, OA | |||
| Systems used as terminals connected to mainframe computer systems, | Systems used as terminals connected to mainframe computer systems, | |||
| and OA Systems used as hosts in a Local Area Network (LAN). | and OA Systems used as hosts in a Local Area Network (LAN). | |||
| Differentiation is made between those Office Automation Systems | Differentiation is made between those Office Automation Systems | |||
| End of changes. 228 change blocks. | ||||
| 701 lines changed or deleted | 781 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||