RFC2196 日本語訳
2196 Site Security Handbook. B. Fraser. September 1997. (Format: TXT=191772 bytes) (Obsoletes RFC1244) (Also FYI0008) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Fraser Request for Comments: 2196 Editor FYI: 8 SEI/CMU Obsoletes: 1244 September 1997 Category: Informational
コメントを求めるワーキンググループB.フレーザの要求をネットワークでつないでください: 2196エディタFYI: 8 SEI/米カーネギーメロン大学は以下を時代遅れにします。 1244 1997年9月のカテゴリ: 情報
Site Security Handbook
サイトセキュリティハンドブック
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
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
目次
1. Introduction.................................................... 2 1.1 Purpose of this Work............................................ 3 1.2 Audience........................................................ 3 1.3 Definitions..................................................... 3 1.4 Related Work.................................................... 4 1.5 Basic Approach.................................................. 4 1.6 Risk Assessment................................................. 5 2. Security Policies............................................... 6 2.1 What is a Security Policy and Why Have One?..................... 6 2.2 What Makes a Good Security Policy?.............................. 9 2.3 Keeping the Policy Flexible..................................... 11 3. Architecture.................................................... 11 3.1 Objectives...................................................... 11 3.2 Network and Service Configuration............................... 14 3.3 Firewalls....................................................... 20 4. Security Services and Procedures................................ 24 4.1 Authentication.................................................. 24 4.2 Confidentiality................................................. 28 4.3 Integrity....................................................... 28
1. 序論… 2 1.1 このWorkの目的… 3 1.2聴衆… 3 1.3の定義… 1.4が関係づけた3は働いています… 4 1.5 基本的なアプローチ… 4 1.6 査定を危険にさらしてください… 5 2. 安全保障政策… 6 2.1 Security PolicyとWhy Have Oneは何ですか? 6 2.2 何が優れた警備体制方針を作りますか? 9 2.3 方針をフレキシブルに保ちます… 11 3. アーキテクチャ… 11 3.1の目的… 11 3.2 構成をネットワークでつないで、修理してください… 14 3.3個のファイアウォール… 20 4. セキュリティー・サービスと手順… 24 4.1認証… 24 4.2秘密性… 28 4.3保全… 28
Fraser, Ed. Informational [Page 1] RFC 2196 Site Security Handbook September 1997
フレーザ、[1ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
4.4 Authorization................................................... 29 4.5 Access.......................................................... 30 4.6 Auditing........................................................ 34 4.7 Securing Backups................................................ 37 5. Security Incident Handling...................................... 37 5.1 Preparing and Planning for Incident Handling.................... 39 5.2 Notification and Points of Contact.............................. 42 5.3 Identifying an Incident......................................... 50 5.4 Handling an Incident............................................ 52 5.5 Aftermath of an Incident........................................ 58 5.6 Responsibilities................................................ 59 6. Ongoing Activities.............................................. 60 7. Tools and Locations............................................. 60 8. Mailing Lists and Other Resources............................... 62 9. References...................................................... 64
4.4承認… 29 4.5アクセサリー… 30 4.6 監査します。 34 4.7 バックアップを固定します… 37 5. セキュリティインシデント取り扱い… 37 5.1 付随している取り扱いを準備して、計画を立てます… 39 5.2の通知と連絡先… 42 5.3 インシデントを特定します… 50 5.4 インシデントを扱います… 52 インシデントの5.5余波… 58 5.6の責任… 59 6. 進行中の活動… 60 7. ツールと位置… 60 8. メーリングリストと他のリソース… 62 9. 参照… 64
1. Introduction
1. 序論
This document provides guidance to system and network administrators on how to address security issues within the Internet community. It builds on the foundation provided in RFC 1244 and is the collective work of a number of contributing authors. Those authors include: Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus- Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone (lorna@staff.singnet.com.sg), Edward.P.Lewis (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com), Russ Mundy (mundy@tis.com), Philip J. Nesser (pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey (msr@interpath.net).
このドキュメントはシステムとネットワーク管理者へのインターネットコミュニティの中でセキュリティが問題であるとどう扱うかにおける指導を提供します。 それは、RFC1244に提供された基礎に建てて、多くの貢献している作者の集合著作物です。 それらの作者は: ジュールズ・P.アロンソン( aronson@nlm.nih.gov )、ネヴィル・ブラウンリー( n.brownlee@auckland.ac.nz )、フランク・バイラム( byrum@norfolk.infi.net )、ジョアン・ヌーノ・フェレイラ( ferreira@rccn.net )、バーバラ・フレーザ( byf@cert.org )、スティーブは( glass@ftp.com )をガラスで覆います、エリックGuttman( erik.guttman@eng.sun.com )、クラウスピーターKossakowski( kossakowski@cert.dfn.de )、トムKillalea( tomk@nwnet.net )、ローナ・レオーネ( lorna@staff.singnet.com.sg )、エドワード; P.ルイス( Edward.P.Lewis.1@gsfc.nasa.gov )、ゲーリー・マルキン( gmalkin@xylogics.com )、ラス・マンディ( mundy@tis.com )、フィリップJ.Nesser( pjnesser@martigny.ai.mit.edu )、およびマイケル・S.ラムゼイ( msr@interpath.net )。
In addition to the principle writers, a number of reviewers provided valuable comments. Those reviewers include: Eric Luiijf (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl).
原則作家に加えて、多くの評論家が貴重なコメントを提供しました。 それらの評論家は: エリックLuiijf( luiijf@fel.tno.nl )、Marijke Kaat( marijke.kaat@sec.nl )、レイPlzak( plzak@nic.mil )、およびハン・プロンク( h.m.pronk@vka.nl )。
A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, CICnet, for their vision, leadership, and effort in the creation of 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 earlier one was.
特別番組はありがとうございます。このハンドブックの最初のバージョンの作成におけるそれらのビジョン、リーダーシップ、および取り組みにジョイス・レイノルズ、ISIとポールHolbrook、CICnetに行きます。 このバージョンが共同体に1つが、より初期であったのと同じくらい役立っているのは、ワーキンググループの心からの望みです。
Fraser, Ed. Informational [Page 2] RFC 2196 Site Security Handbook September 1997
フレーザ、[2ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
1.1 Purpose of This Work
1.1 この仕事の目的
This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet (however, the information provided should also be useful to sites not yet connected to the Internet). This guide lists issues and factors that a site 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 procedures. In order to have an effective set of policies and procedures, a site will have to make many decisions, gain agreement, and then communicate and implement these policies.
このガイドは、安全保障政策を設定するためのフレームワークと手順にすぎません。 有効なセットの方針と手順を持つために、そして、サイトは、これらの政策を多くの決定をして、協定を獲得して、伝えて、実施しなければならないでしょう。
1.2 Audience
1.2 聴衆
The audience for this document are system and network administrators, and decision makers (typically "middle management") at sites. For brevity, we will use the term "administrator" throughout this document to refer to system and network administrators.
このドキュメントのための聴衆は、システムと、ネットワーク管理者と、サイトの意思決定者(通常「中央管理」)です。 簡潔さに、私たちは参照するこのドキュメント中で「管理者」という用語を使用するつもりです。システムとネットワーク管理者。
This document is not directed at programmers or those trying to create secure programs or systems. The focus of this document is on the policies and procedures that need to be in place to support the technical security features that a site may be implementing.
プログラマか安全なプログラムかシステムを作成しようとするものがこのドキュメントに向けられません。このドキュメントの焦点が技術的なセキュリティがサイトが実装しているかもしれない特徴であるとサポートするために適所にある必要がある方針と手順にあります。
The primary audience for this work are sites that are members of the Internet community. However, this document should be useful to any site that allows communication with other sites. As a general guide to security policies, this document may also be useful to sites with isolated systems.
この仕事のためのプライマリーオーディエンスはインターネットコミュニティのメンバーであるサイトです。 しかしながら、このドキュメントは他のサイトとのコミュニケーションを許容するどんなサイトも役に立つべきです。 安全保障政策への一般的なガイドとして、また、このドキュメントも孤立系によってサイトの役に立つかもしれません。
1.3 Definitions
1.3 定義
For the purposes of this guide, a "site" is any organization that owns computers or network-related resources. These resources may include host computers that users use, routers, terminal servers, PCs 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 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 the ability to set policies and procedures for itself with the 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.
このガイドの目的のために、「サイト」は、コンピュータを所有しているどんな組織かネットワーク関連のリソースです。 これらのリソースはインターネットに近づく手段を持っているユーザが使用するホストコンピュータ、ルータ、ターミナルサーバ、PCまたは対向機器を含むかもしれません。 サイトは、中間の平らなネットワークなどのインターネットのサービスのエンドユーザかサービスプロバイダーであるかもしれません。 しかしながら、インターネットのサービスのそれらのエンドユーザの上にこのガイドの焦点の大部分があります。 私たちは、サイトには合意とサポートで実際にリソースを所有している人からそれ自体に方針と手順を設定する能力があると思います。 より大きい組織の部分であるサイトが、それらが、いつから推薦を相談するか、共同するか、または取る必要であるかを知ると思われるでしょう、より大きい実体。
Fraser, Ed. Informational [Page 3] RFC 2196 Site Security Handbook September 1997
フレーザ、[3ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
The "Internet" is a collection of thousands of networks linked by a common set of technical protocols which make it possible for users of any one of the networks to communicate with, or use the services located on, any of the other networks (FYI4, RFC 1594).
「インターネット」はネットワークが他のネットワーク(FYI4、RFC1594)のどれかで交信するか、または見つけられたサービスを利用するのをいくらか1つのユーザにとって可能にする一般的なセットの技術的なプロトコルによってリンクされた何千ものネットワークの収集です。
The term "administrator" is used to cover all those people who are responsible for the day-to-day operation of system and network 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.
「セキュリティ管理者」という用語は、情報と情報技術のセキュリティに責任があるそれらのすべての人々をカバーするのに使用されます。 いくつかのサイトでは、この機能は管理者(above)に結合されるかもしれません。 他のものでは、これは別々の位置になるでしょう。
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 the resources.
「意思決定者」という用語はサイトの方針を設定するか、または承認する人々について言及します。 (いつもでない)しばしばこれらはリソースを所有している人々です。
1.4 Related Work
1.4 関連仕事
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 help them protect their information and the resources they use.
Site Security Handbook作業部会はインターネットSecurityへのUserのガイドに取り組んでいます。 それは、自分達が彼らの情報とそれらが使用するリソースを保護するのを助けるために実際的な指針をエンドユーザに提供するでしょう。
1.5 Basic Approach
1.5 基本的なアプローチ
This guide is written to provide basic guidance in developing a security plan for your site. One generally accepted approach to follow is suggested by Fites, et. al. [Fites 1989] and includes the following steps:
このガイドは、あなたのサイトに警備計画を開発するのに基本的な指導を提供するために書かれています。 続く1つの一般に、受け入れられたアプローチがetファイツ、アルによって提案されます。 [ファイツ1989]と以下が踏むインクルード:
(1) Identify what you are trying to protect.
(2) Determine what you are trying to protect it from.
(3) Determine how likely the threats are.
(4) Implement measures which will protect your assets in a cost-
effective manner.
(5) Review the process continuously and make improvements each time
a weakness is found.
(1) 何を保護しようとしているか特定してください。 (2) 何からそれを保護しようとしているか決定してください。 (3) 脅威がどれくらいありそうであるか決定してください。 (4) 費用の効果的な方法であなたの資産を保護する政策を実施してください。 (5) 絶え間なくプロセスを見直してください、そして、弱点が見つけられるたびに改良をしてください。
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 site. One old truism in security is that the cost of protecting yourself against a threat should be less than the cost of recovering if the threat were to strike you. Cost in this context should be remembered to include losses expressed in real currency, reputation, 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.
このドキュメントの大部分は上の項目4に焦点を合わせられますが、有効な方法があなたのサイトに設立されることであるなら他のステップを避けることができません。 1つの古い公理は安全に脅威に対して我が身をかばう費用が脅威があなたを打つことであったなら回復する費用以下であるべきであるということです。 費用は、実際の通貨、評判、信頼できること、および他のそれほど明白でない程度で言い表された損失を含むようにこのような関係においては覚えていられるべきです。 あなたが何を保護しているか、そして、ありそうな脅威が何であるかに関する妥当な知識がなければ、この規則に従うのは難しいかもしれません。
Fraser, Ed. Informational [Page 4] RFC 2196 Site Security Handbook September 1997
フレーザ、[4ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
1.6 Risk Assessment
1.6 リスクアセスメント
1.6.1 General Discussion
1.6.1 一般議論
One of the most important reasons for creating a computer security policy is to ensure that efforts spent on security yield cost effective benefits. Although this may seem obvious, it is possible to be mislead about where the effort is needed. As an example, there is a great deal of publicity about intruders on computers systems; yet most surveys of computer security show that, for most organizations, the actual loss from "insiders" is much greater.
コンピュータセキュリティ方針を作成するのが、セキュリティに費やされた取り組みが費用効率がよい状態でもたらされるのを保証することになっているので、最も重要な理由の1つは利益を得ます。 これは明白に見えるかもしれませんが、それは可能です。必要であることで、取り組みがあるおよそところでミスリードします。 例として、コンピュータシステムの上の侵入者に関して大きな宣伝があります。 しかし、コンピュータセキュリティのほとんどの調査が、ほとんどの組織には、「インサイダー」からの実際の損失がはるかに大きいのを示します。
Risk analysis involves determining what you need to protect, what you need to protect it from, and how to protect it. It is the process of examining all of your risks, then ranking those risks by level of severity. This process involves making cost-effective decisions on what you want to protect. As mentioned above, you should probably not spend more to protect something than it is actually worth.
危険分析は、何を保護するか、そして、あなたが、必要があるあなたが、何からそれを保護する必要があるか、そして、どのようにそれを保護するかを決定することを伴います。 それはあなたのリスクのすべてを調べて、次に、厳しさのレベルでそれらの危険を格付けするプロセスです。 このプロセスは、あなたが保護したいことに関する費用対効果に優れた決定をすることを伴います。 以上のように、あなたは、何かを保護するためにたぶん実際に価値があった状態でそれ以上を費やすべきではありません。
A full treatment of risk analysis is outside the scope of this document. [Fites 1989] and [Pfleeger 1989] provide introductions to this topic. However, there are two elements of a risk analysis that will be briefly covered in the next two sections:
このドキュメントの範囲の外に危険分析の完全な処理があります。 [ファイツ1989]と[Pfleeger1989]はこの話題に序論を提供します。 しかしながら、次の2つのセクションで簡潔にカバーされている危険分析の2つの原理があります:
(1) Identifying the assets (2) Identifying the threats
(1) 脅威を特定しながら、資産(2)を特定すること。
For each asset, the basic goals of security are availability, confidentiality, and integrity. Each threat should be examined with an eye to how the threat could affect these areas.
各資産のために、セキュリティの基本的な目標は、有用性と、秘密性と、保全です。 各脅威は目で脅威がどうこれらの領域に影響するかもしれないかに調べられるべきです。
1.6.2 Identifying the Assets
1.6.2 資産を特定すること。
One step in a risk analysis is to identify all the things that need to be protected. Some things are obvious, like valuable proprietary information, intellectual property, and all the various pieces of hardware; but, some are overlooked, such as the people who actually use the systems. The essential point is to list all things that could be affected by a security problem.
危険分析におけるワンステップは保護される必要があるすべてのものを特定することです。 いくつかのものが貴重な知的財産情報、知的所有権、およびすべての様々なハードウェアのように明白です。 しかし、或るものは見落とされます、実際にシステムを使用する人々などのように。不可欠のポイントは警備上の問題で影響を受けることができた万物を記載することです。
One list of categories is suggested by Pfleeger [Pfleeger 1989]; this list is adapted from that source:
カテゴリの1つのリストがPfleeger[Pfleeger1989]によって勧められます。 このリストはそのソースから適合させられます:
(1) Hardware: CPUs, boards, keyboards, terminals,
workstations, personal computers, printers, disk
drives, communication lines, terminal servers, routers.
(1)ハードウェア: CPU、ボード、キーボード、端末、ワークステーション、パーソナルコンピュータ、プリンタ、ディスクドライブ、通信回線、ターミナルサーバ、ルータ。
Fraser, Ed. Informational [Page 5] RFC 2196 Site Security Handbook September 1997
フレーザ、[5ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
(2) Software: source programs, object programs,
utilities, diagnostic programs, operating systems,
communication programs.
(2)ソフトウェア: 原始プログラム、オブジェクトプログラム、ユーティリティ、診断プログラム、コミュニケーションがプログラムするオペレーティングシステム。
(3) Data: during execution, stored on-line, archived off-line,
backups, audit logs, databases, in transit over
communication media.
(3)データ: オンラインで、格納されていた状態でオフラインで保存された実行の間、バックアップはコミュニケーションメディアの上のトランジットでログ、データベースを監査してください。
(4) People: users, administrators, hardware maintainers.
(4)の人々: ユーザ、管理者、ハードウェア維持装置。
(5) Documentation: on programs, hardware, systems, local
administrative procedures.
(5)ドキュメンテーション: プログラム、ハードウェア、システム、ローカルの行政手続に関して。
(6) Supplies: paper, forms, ribbons, magnetic media.
(6) 供給: 紙、フォーム、リボン、磁気媒体。
1.6.3 Identifying the Threats
1.6.3 脅威を特定すること。
Once the assets requiring protection are identified, it is necessary to identify threats to those assets. The threats can then be examined to determine what potential for loss exists. It helps to consider from what threats you are trying to protect your assets. The following are classic threats that should be considered. Depending on your site, there will be more specific threats that should be identified and addressed.
保護を必要とする資産がいったん特定されると、それらの資産への脅威を特定するのが必要です。 そして、損失のどんな可能性が存在するかを決定するために脅威を調べることができます。 それは、あなたがどんな脅威から資産を保護しようとしているかを考えるのを助けます。 ↓これは考えられるべきである古典的な脅威です。 あなたのサイトによって、特定されて、扱われるべきであるより特定の脅威があるでしょう。
(1) Unauthorized access to resources and/or information (2) Unintented and/or unauthorized Disclosure of information (3) Denial of service
(1) サービスの情報(3)否定のリソース、そして/または、情報(2)のUnintented、そして/または、権限のないDisclosureへの不正アクセス
2. Security Policies
2. 安全保障政策
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.
このドキュメント中に、方針の多くの参照があるでしょう。 しばしば、これらの参照は特定保険証券のための推薦を含むでしょう。 むしろ、読者はそのような方針を作成して、どう伝えるかの指導を繰り返すより後でこの本のお勧めのどんな方針も開発するとき本章に提示されたアドバイスを適用するべきです。
2.1 What is a Security Policy and Why Have One?
2.1 Security PolicyとWhy Have Oneは何ですか?
The security-related decisions you make, or fail to make, as administrator largely determines how secure or insecure your network is, how much functionality your network offers, and how easy your network is to use. However, you cannot make good decisions about security without first determining what your security goals are. Until you determine what your security goals are, you cannot make effective use of any collection of security tools because you simply will not know what to check for and what restrictions to impose.
あなたが作るか、または管理者があなたのネットワークがどれくらい安全であるか、そして、または不安定であり、あなたのネットワークがどのくらいの機能性を提供するか、そして、あなたのネットワークが使用にどれくらい簡単であるかを主に決心しているときしないセキュリティ関連の決定。 しかしながら、最初にあなたのセキュリティ目標が何であるかを決定しない、あなたはセキュリティに関する良い決定をすることができません。 何がないかどうかチェックするか、そして、どんな制限を課したらよいかを絶対に知らないので、あなたのセキュリティ目標が何であるかを決心するまで、あなたはセキュリティツールの少しの収集もうまく利用することができません。
Fraser, Ed. Informational [Page 6] RFC 2196 Site Security Handbook September 1997
フレーザ、[6ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
For example, your goals will probably be very different from the goals of a product vendor. Vendors are trying to make configuration and operation of their products as simple as possible, which implies that the default configurations will often be as open (i.e., insecure) as possible. While this does make it easier to install new products, it also leaves access to those systems, and other systems through them, open to any user who wanders by.
例えば、あなたの目標はたぶん製品ベンダーの目標から非常に異なるようになるでしょう。 ベンダーはそれらの製品の構成と操作をできるだけ簡単にしようとしています(デフォルト設定ができるだけしばしば開くのを(すなわち、不安定な)含意します)。 新製品をインストールするのはこれで、より簡単になりますが、また、それらのシステム、および他のシステムへのアクセスはそれらを通して残っています、歩き回るどんなユーザにとっても、開きます。
Your goals will be largely determined by the following key tradeoffs:
あなたの目標は以下の主要な見返りで主に決定するようになるでしょう:
(1) services offered versus security provided -
Each service offered to users carries its own security risks.
For some services the risk outweighs the benefit of the service
and the administrator may choose to eliminate the service rather
than try to secure it.
(1) セキュリティに対して提供されたサービスは提供されました--ユーザに提供された各サービスはそれ自身のセキュリティ危険を運びます。 リスクが十二分に補ういくつかのサービスのために、サービスと管理者の利益は、それを機密保護しようとするよりむしろサービスを排除するのを選ぶかもしれません。
(2) ease of use versus security -
The easiest system to use would allow access to any user and
require no passwords; that is, there would be no security.
Requiring passwords makes the system a little less convenient,
but more secure. Requiring device-generated one-time passwords
makes the system even more difficult to use, but much more
secure.
(2)使いやすさ対セキュリティ--使用する中で最も簡単なシステムは、どんなユーザへのアクセスも許して、パスワードを全く必要としないでしょう。 すなわち、セキュリティが全くないでしょう。 パスワードを必要とするのに、システムはもう少し便利ではありませんが、より安全になります。 デバイスで発生しているワンタイムパスワードを必要とするのに、システムはさらに使用する難しいのですが、はるかに安全になります。
(3) cost of security versus risk of loss -
There are many different costs to security: monetary (i.e., the
cost of purchasing security hardware and software like firewalls
and one-time password generators), performance (i.e., encryption
and decryption take time), and ease of use (as mentioned above).
There are also many levels of risk: loss of privacy (i.e., the
reading of information by unauthorized individuals), loss of
data (i.e., the corruption or erasure of information), and the
loss of service (e.g., the filling of data storage space, usage
of computational resources, and denial of network access). Each
type of cost must be weighed against each type of loss.
セキュリティ対危険負担の(3)費用--セキュリティへの多くの異なったコストがあります: 通貨、(すなわち、ファイアウォールとワンタイムパスワードジェネレータのようにセキュリティハードウェアとソフトウェアを購入する費用)、性能(すなわち、暗号化と復号化は時間がかかる)、および使いやすさ(以上のように)。 また、多くのレベルのリスクがあります: プライバシーの損失(すなわち、権限のない個人による情報の読書)、データの喪失(すなわち、情報の不正か消去)、およびサービスの損失(例えば、データ集積スペースの充填、コンピュータのリソースの用法、およびネットワークアクセスの否定)。 それぞれのタイプの費用についてそれぞれのタイプの損失に比較考量しなければなりません。
Your goals should be communicated to all users, operations staff, and managers through a set of security rules, called a "security 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.
あなたの目標は「安全保障政策」と呼ばれる1セットのセキュリティ規則ですべてのユーザ、操作スタッフ、およびマネージャに伝えられるべきです。 範囲がすべてのタイプの情報技術と技術で保存されて、操られた情報を含んでいるので、私たちは、より狭い「コンピュータセキュリティ方針」よりむしろ今期を使用しています。
2.1.1 Definition of a Security Policy
2.1.1 安全保障政策の定義
A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide.
安全保障政策は組織の技術と情報資産へのアクセスが与えられている人々がとどまらなければならない規則の正式な声明です。
Fraser, Ed. Informational [Page 7] RFC 2196 Site Security Handbook September 1997
フレーザ、[7ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
2.1.2 Purposes of a Security Policy
2.1.2 安全保障政策の目的
The main purpose of a security policy is to inform users, staff and managers of their obligatory requirements for protecting technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Another purpose is to provide a baseline from which to acquire, configure and audit computer systems and networks for compliance with the policy. Therefore an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.
安全保障政策の主な目的は技術と情報資産を保護するための彼らの義務的な要件についてユーザ、スタッフ、およびマネージャに知らせることです。 方針はこれらの必要条件を満たすことができるメカニズムを指定するべきです。 別の目的は方針への承諾ためにコンピュータ・システムとネットワークを取得して、構成して、監査する基線を提供することです。 したがって、少なくとも暗示している安全保障政策がないとき1セットのセキュリティツールを使用する試みは無意味です。
An Appropriate Use Policy (AUP) may also be part of a security policy. It should spell out what users shall and shall not do on the various components of the system, including the type of traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. For example, an AUP might list any prohibited USENET newsgroups. (Note: Appropriate Use Policy is referred to as Acceptable Use Policy by some sites.)
また、Appropriate Use Policy(AUP)は安全保障政策の一部であるかもしれません。 それはユーザがして、システムの様々な部品でしないものとすることは詳しく説明するべきです、ネットワークに許容されたトラフィックのタイプを含んでいて。 AUPは、あいまいさか誤解を避けるためにできるだけ明白であるべきです。 例えば、AUPはどんな禁止されたユーズネットも記載するかもしれません。 (注意: 適切なUse PolicyはいくつかのサイトによってAcceptable Use Policyと呼ばれます。)
2.1.3 Who Should be Involved When Forming Policy?
2.1.3 Shouldが人である、Involved When Forming Policy?
In order for a security policy to be appropriate and effective, it needs to have the acceptance and support of all levels of employees within the organization. It is especially important that corporate management fully support the security policy process otherwise there is little chance that they will have the intended impact. The following is a list of individuals who should be involved in the creation and review of security policy documents:
安全保障政策が適切であって、効果的であるように、それは組織の中ですべてのレベルの従業員の承認とサポートを必要とします。 企業経営が安全保障政策プロセスを完全にサポートするのは、特に重要です。そうでなければ、彼らには意図している影響力があるという見込みがほとんどありません。 ↓これは、作成にかかわるべきである個人のリストと安全保障政策ドキュメントのレビューです:
(1) site security administrator
(2) information technology technical staff (e.g., staff from
computing center)
(3) administrators of large user groups within the organization
(e.g., business divisions, computer science department within a
university, etc.)
(4) security incident response team
(5) representatives of the user groups affected by the security
policy
(6) responsible management
(7) legal counsel (if appropriate)
(1) 組織(例えば、ビジネス部門、大学の中のコンピュータサイエンス部など)の中の大きいユーザ・グループのサイトセキュリティ管理者(2)情報技術技術スタッフ(例えば、計算機センタからのスタッフ)(3)管理者 (4) 安全保障政策の(6)責任がある管理(7)弁護士で影響を受けたユーザ・グループのセキュリティインシデント応答チーム(5)代表(適切であるなら)
The list above is representative of many organizations, but is not necessarily comprehensive. The idea is to bring in representation from key stakeholders, management who have budget and policy authority, technical staff who know what can and cannot be supported, and legal counsel who know the legal ramifications of various policy
上記のリストは、多くの組織を代表しますが、必ず包括的であるというわけではありません。 考えは主要な利害関係者から表現を持って入ることです、予算と方針権威を持っている管理、何が顧問弁護士であることができ、様々な方針の法的な分岐を知っているサポートしていて、法的な顧問弁護士であるはずがないかを知っている技術スタッフ
Fraser, Ed. Informational [Page 8] RFC 2196 Site Security Handbook September 1997
フレーザ、[8ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
choices. In some organizations, it may be appropriate to include EDP audit personnel. Involving this group is important if resulting 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 Security Policy?
2.2 何が優れた警備体制方針を作りますか?
The characteristics of a good security policy are:
優れた警備体制方針の特性は以下の通りです。
(1) It must be implementable through system administration
procedures, publishing of acceptable use guidelines, or other
appropriate methods.
(1) それはシステム管理手順、許容できる使用の出版を通してガイドライン、または他の適切なメソッドを実装可能することであるに違いありません。
(2) It must be enforcible with security tools, where appropriate,
and with sanctions, where actual prevention is not technically
feasible.
(2) それはセキュリティツール、適切であるところ、および制裁があるenforcibleであるに違いありません。(そこでは、実際の防止が技術的に可能ではありません)。
(3) It must clearly define the areas of responsibility for the
users, administrators, and management.
(3) それは明確にユーザ、管理者、および管理への責任の領域を定義しなければなりません。
The components of a good security policy include:
優れた警備体制方針の成分は:
(1) Computer Technology Purchasing Guidelines which specify
required, or preferred, security features. These should
supplement existing purchasing policies and guidelines.
(1) 指定するコンピュータ・テクノロジーPurchasing Guidelinesがセキュリティ機能を必要であった、または好みました。 これらは、方針とガイドラインを購入しながら存在しながら、補われるべきです。
(2) A Privacy Policy which defines reasonable expectations of
privacy regarding such issues as monitoring of electronic mail,
logging of keystrokes, and access to users' files.
(2) モニターするような問題に関してプライバシーへの合理的な期待を定義する電子メールのプライバシーに関する方針、キーストロークの伐採、およびユーザのファイルへのアクセス。
(3) An Access Policy which defines access rights and privileges to
protect assets from loss or disclosure by specifying acceptable
use guidelines for users, operations staff, and management. It
should provide guidelines for external connections, data
communications, connecting devices to a network, and adding new
software to systems. It should also specify any required
notification messages (e.g., connect messages should provide
warnings about authorized usage and line monitoring, and not
simply say "Welcome").
(3) アクセス権を定義するAccess Policyと資産を保護する特権はユーザ、操作スタッフ、および管理に指定許容できることで損失か公開からガイドラインを使用します。 それは外部の接続にガイドラインを提供するべきです、データ通信、デバイスをネットワークに接続して、新しいソフトウェアをシステムに追加して。また、どんな必要な通知メッセージも指定するべきである、(例えば、接続してください、メッセージが認可された用法と系列モニターに関する警告を提供して、「歓迎」を絶対に言うべきでない、)
(4) An Accountability Policy which defines the responsibilities of
users, operations staff, and management. It should specify an
audit capability, and provide incident handling guidelines
(i.e., what to do and who to contact if a possible intrusion is
detected).
(4) ユーザ、操作スタッフ、および管理の責任を定義するAccountability Policy。 それは、監査能力を指定して、付随している取り扱いガイドラインを提供するべきです(すなわち、何をするか、そして、可能な侵入が検出されるなら、だれに連絡しますか)。
Fraser, Ed. Informational [Page 9] RFC 2196 Site Security Handbook September 1997
フレーザ、[9ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
(5) An Authentication Policy which establishes trust through an
effective password policy, and by setting guidelines for remote
location authentication and the use of authentication devices
(e.g., one-time passwords and the devices that generate them).
(5) 効果的なパスワード方針を通して認証デバイス(それらを生成する例えば、ワンタイムパスワードとデバイス)の離れた場所認証と使用のためのガイドラインを設定することで信頼を確立するAuthentication Policy。
(6) An Availability statement which sets users' expectations for the
availability of resources. It should address redundancy and
recovery issues, as well as specify operating hours and
maintenance down-time periods. It should also include contact
information for reporting system and network failures.
(6) リソースの有用性へのユーザの期待を設定するAvailability声明。 それは、冗長と回復が問題であると扱って、営業時間とメインテナンス休止時間の期間を指定するべきです。 また、それはリポーティングシステムとネットワーク失敗のための問い合わせ先を含むべきです。
(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.
(7) 技術を扱って、内部の、そして、外部の両方のメインテナンスの人々がどうアクセスできるかを説明する情報Technology System&Network Maintenance Policy。 ここで扱われる1つの重要な話題はリモート・メンテナンスが許容されているかどうかと、そのようなアクセスがどのように制御されているかということです。 ここでの考慮のための別の領域は、アウトソーシングとそれがどう管理されるかということです。
(8) A Violations Reporting Policy that indicates which types of
violations (e.g., privacy and security, internal and external)
must be reported and to whom the reports are made. A non-
threatening atmosphere and the possibility of anonymous
reporting will result in a greater probability that a violation
will be reported if it is detected.
(8) どのタイプの違反(内部の、そして、外部の例えば、プライバシーとセキュリティ)を報告しなければならないかを示して、レポートがされるViolations Reporting Policy。 非険悪な大気と匿名の報告の可能性はそれが検出されると違反が報告されるというより大きい確率をもたらすでしょう。
(9) Supporting Information which provides users, staff, and
management with contact information for each type of policy
violation; guidelines on how to handle outside queries about a
security incident, 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.
(9) それぞれのタイプの方針違反のための問い合わせ先にユーザ、スタッフ、および管理を提供する情報をサポートします。 セキュリティインシデントに関してどう外の質問を扱うかに関するガイドライン、または秘密であるか、または独占であると考えられるかもしれない情報。 そして、会社の方針や、政府の法や規則のセキュリティ手順と関連する情報への相互参照。
There may be regulatory requirements that affect some aspects of your security policy (e.g., line monitoring). The creators of the security policy should consider seeking legal assistance in the creation of the policy. At a minimum, the policy should be reviewed by legal counsel.
あなたの安全保障政策(例えば、系列モニター)のいくつかの局面に影響する法的な要求事項があるかもしれません。 安全保障政策のクリエイターは、方針の作成における法的な支援を求めると考えるべきです。 最小限では、方針は弁護士によって視察されるべきです。
Once your security policy has been established it should be clearly communicated to users, staff, and management. Having all personnel sign a statement indicating that they have read, understood, and agreed to abide by the policy is an important part of the process. Finally, your policy should be reviewed on a regular basis to see if it is successfully supporting your security needs.
あなたの安全保障政策がいったん確立されると、それは明確にユーザ、スタッフ、および管理に伝えられるべきです。 すべての人員に彼らが、読んで、分かって、方針を守るのに同意したのを示す声明を調印させるのは、プロセスの重要な部分です。 最終的に、あなたの方針は、それが首尾よくあなたの安全要求をサポートしているかどうかを見るために定期的に見直されるべきです。
Fraser, Ed. Informational [Page 10] RFC 2196 Site Security Handbook September 1997
フレーザ、[10ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
2.3 Keeping the Policy Flexible
2.3 方針をフレキシブルに保つこと。
In order for a security policy to be viable for the long term, it 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 people involved, and the people who must sign-off on the changes.
安全保障政策が長期の間、実行可能であるように、それは建築セキュリティ概念に基づく多くの柔軟性を必要とします。 安全保障政策は特定のハードウェアとソフトウェア状況から(主に)独立しているべきです(特定のシステムが、夜通し取り替えるか、または動く傾向があるとき)。 方針をアップデートするためのメカニズムは明確に詳しく説明されるべきです。 これはプロセス、かかわった人々、および変化の上でサインオフしなければならない人々を含んでいます。
It is also important to recognize that there are exceptions to every rule. Whenever possible, the policy should spell out what exceptions to the general policy exist. For example, under what conditions is a system administrator allowed to go through a user's files. Also, there may be some cases when multiple users will have access to the same userid. For example, on systems with a "root" user, multiple system administrators may know the password and use the root account.
また、あらゆる規則への例外があると認めるのも重要です。 可能であることで、方針が詳しく説明するべきであるときはいつも、全般的執行方針へのどんな例外が存在していますか? 例えば、システム管理者はどんな条件のもとでユーザのファイルに直面できますか? また、複数のユーザが同じユーザIDに近づく手段を持つとき、いくつかのケースがあるかもしれません。 例えば、複数のシステム管理者が、「根」ユーザとのシステムの上では、パスワードを知って、根のアカウントを使用するかもしれません。
Another consideration is called the "Garbage Truck Syndrome." This 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 the company unexpectedly). While the greatest security resides in the minimum dissemination of information, the risk of losing critical information increases when that information is not shared. It is important to determine what the proper balance is for your site.
別の考慮は「パッカー車シンドローム」と呼ばれます。 これはキーパーソンが突然その人の職務権限(例えば、突然、病気であった、または不意に退職する)を入手できないならサイトに起こることを示します。 最もすばらしいセキュリティは情報の最小の普及にありますが、その情報が共有されないとき、損をしている重要情報の危険は増加します。 適性バランスがあなたのサイトへの何であるかを決定するのは重要です。
3. Architecture
3. アーキテクチャ
3.1 Objectives
3.1 目的
3.1.1 Completely Defined Security Plans
3.1.1 完全に定義された警備計画
All sites should define a comprehensive security plan. This plan should be at a higher level than the specific policies discussed in chapter 2, and it should be crafted as a framework of broad guidelines into which specific policies will fit.
すべてのサイトが包括的安全保障プランを定義するべきです。 このプランがそう第2章で論じられた特定保険証券より高いレベルにあるべきです、そして、それは特定保険証券が合う幅広い指針のフレームワークとして作られるべきです。
It is important to have this framework in place so that individual policies can be consistent with the overall site security architecture. For example, having a strong policy with regard to Internet access and having weak restrictions on modem usage is inconsistent with an overall philosophy of strong security restrictions on external access.
適所にこのフレームワークを持っているのは、独特の方針が総合的なサイトセキュリティー体系と一致するくらい重要です。 例えば、インターネット・アクセスに関して強硬な政策を持っていて、モデム用法に弱い制限を持っているのは外部のアクセサリーで強い安全保障制限の総合的な哲学に矛盾しています。
A security plan should define: the list of network services that will be provided; which areas of the organization will provide the services; who will have access to those services; how access will be provided; who will administer those services; etc.
警備計画は以下を定義するべきです。 提供されるネットワーク・サービスのリスト。 組織のどの領域がサービスを提供するだろうか。 だれがそれらのサービスに近づく手段を持つだろうか。 どうアクセスを提供するだろうか。 だれがそれらのサービスを管理するだろうか。 など
Fraser, Ed. Informational [Page 11] RFC 2196 Site Security Handbook September 1997
フレーザ、[11ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
The plan should also address how incident will be handled. Chapter 5 provides an in-depth discussion of this topic, but it is important for each site to define classes of incidents and corresponding responses. For example, sites with firewalls should set a threshold on the number of attempts made to foil the firewall before triggering a response? Escallation levels should be defined for both attacks and responses. Sites without firewalls will have to determine if a single attempt to connect to a host constitutes an incident? What about a systematic scan of systems?
また、プランはインシデントがどう扱われるかを扱うべきです。 第5章はこの話題の徹底的な議論を提供しますが、各サイトがインシデントと対応する応答のクラスを定義するのは、重要です。 例えば、ファイアウォールがあるサイトは応答の引き金となる前にファイアウォールをくじくのがされた試みの数の敷居を設定するべきですか? Escallationレベルは攻撃と応答の両方のために定義されるべきです。 ファイアウォールのないサイトは、ホストに接するただ一つの試みがインシデントを構成するかどうか決定しなければならないでしょうか? システムの系統的なスキャンはどうですか?
For sites connected to the Internet, the rampant media magnification of Internet related security incidents can overshadow a (potentially) more serious internal security problem. Likewise, companies who have never been connected to the Internet may have strong, well defined, internal policies but fail to adequately address an external connection policy.
インターネットにつなげられたサイト、インターネットの倍率が関係づけた猛烈なメディアのために、セキュリティインシデントは(潜在的に)より重大な国内保安問題を曇らせることができます。 同様に、インターネットに一度も接続されたことがない会社は、強くて、よく定義されて、内部の方針を持っていますが、適切に外部の接続方針を扱わないかもしれません。
3.1.2 Separation of Services
3.1.2 サービスの分離
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 security reasons to attempt to isolate services onto dedicated host computers. There are also performance reasons in most cases, but a detailed discussion is beyond to scope of this document.
サイトがそれの或るものが外部であるかもしれないユーザに備えたがっているかもしれない多くのサービスがあります。 専用ホストコンピュータにサービスを隔離するのを試みるさまざまなセキュリティ理由があります。 また、性能理由が多くの場合ありますが、このドキュメントの範囲には詳細な論議が向こうにあります。
The services which a site may provide will, in most cases, have different levels of access needs and models of trust. Services which are essential to the security or smooth operation of a site would be 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 that provides a service (or services) which has traditionally been less secure, or requires greater accessability by users who may accidentally suborn security.
多くの場合、サイトが提供するかもしれないサービスが異なったレベルのアクセスの必要性と信頼のモデルがあるでしょう。 サイトのセキュリティか円滑な運用に不可欠のサービスは、伝統的に安全でないサービス(または、サービス)を提供するか、または偶然セキュリティに偽証させるかもしれないユーザで、よりすばらしいaccessabilityを必要とするマシンの上でというよりむしろ非常に限られたアクセス(「すべてを否定してください」というセクション3.1.3モデルを見る)で専用マシンに置かれながら、より暮らし向きが良いでしょう。
It is also important to distinguish between hosts which operate within different models of trust (e.g., all the hosts inside of a firewall and any host on an exposed network).
また、ホストを見分けるのも重要です(信頼(例えば、暴露しているネットワークのファイアウォールとどんなホストのすべてのホスト内部も)の異なったモデルの中で作動します)。
Some of the services which should be examined for potential separation are outlined in section 3.2.3. It is important to remember that security is only as strong as the weakest link in the chain. Several of the most publicized penetrations in recent years have been through the exploitation of vulnerabilities in electronic mail systems. The intruders were not trying to steal electronic mail, but they used the vulnerability in that service to gain access to other systems.
潜在的分離がないかどうか調べられるべきであるサービスのいくつかがセクション3.2.3に概説されています。 セキュリティが単にチェーンで最も弱いリンクと同じくらい強いのを覚えているのは重要です。 電子メール・システムの脆弱性の攻略を通していくつかの最もピーアールされたペネトレーションが近年ありました。侵入者は電子メールを横取りしようとしていませんでしたが、彼らは、他のシステムへのアクセスを得るのにそのサービスに脆弱性を使用しました。
Fraser, Ed. Informational [Page 12] RFC 2196 Site Security Handbook September 1997
フレーザ、[12ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
If possible, each service should be running on a different machine whose only duty is to provide a specific service. This helps to isolate intruders and limit potential harm.
できれば、各サービスは特定のサービスを提供する唯一の義務がことである異なったマシンで動くべきです。 これは、侵入者を隔離して、潜在的害を制限するのを助けます。
3.1.3 Deny all/ Allow all
3.1.3 すべての/がすべてを許容することを否定してください。
There are two diametrically opposed underlying philosophies which can be adopted when defining a security plan. Both alternatives are legitimate models to adopt, and the choice between them will depend on the site and its needs for security.
警備計画を定義するとき採用できる2つの正反対の基本的な哲学があります。 両方の代替手段は採用する正統のモデルです、そして、彼らのこの選択はサイトとそのセキュリティの必要性次第でしょう。
The first option is to turn off all services and then selectively enable services on a case by case basis as they are needed. This can be done at the host or network level as appropriate. This model, which will here after be referred to as the "deny all" model, is generally more secure than the other model described in the next paragraph. More work is required to successfully implement a "deny all" configuration as well as a better understanding of services. Allowing only known services provides for a better analysis of a particular service/protocol and the design of a security mechanism suited to the security level of the site.
第1の選択がすべてのサービスからターンして、次に、選択的にサービスを可能にすることになっている、ケースバイケース、基礎、それらが必要であるように。 ホストかネットワークレベルでこれが適宜できます。 一般に、このモデル(「すべてを否定してください」というモデルと呼ばれた後にここでそうする)は次のパラグラフで説明されたもう片方のモデルより安全です。 より多くの仕事が、首尾よくより良いサービスの理解と同様に「すべてを否定してください」という構成を実装するのに必要です。 知られているサービスだけを許すと、特定のサービス/プロトコルの、より良い分析とサイトのセキュリティー・レベルに合ったセキュリティー対策のデザインは備えられます。
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 than the "deny all" model. Simply turn on all services, usually the default at the host level, and allow all protocols to travel across network boundaries, usually the default at the router level. As security holes become apparent, they are restricted or patched at either the host or network level.
もう片方のモデル(「すべてを許容してください」というモデルと呼ばれた後にここでそうする)は、実装するのがはるかに簡単ですが、一般に、「すべてを否定してください」というモデルより安全ではありません。 ホストレベルで単にサービス、通常すべてのデフォルトをつけてください、そして、ルータレベルでネットワーク限界の向こう側に旅行するプロトコル、通常すべてのデフォルトを許容してください。 セキュリティーホールが明らかになるとき、ホストかネットワークレベルでそれらに、制限されるか、またはパッチします。
Each of these models can be applied to different portions of the site, depending on functionality requirements, administrative control, site policy, etc. For example, the policy may be to use the "allow all" model when setting up workstations for general use, but adopt a "deny all" model when setting up information servers, like an email hub. Likewise, an "allow all" policy may be adopted for traffic between LAN's internal to the site, but a "deny all" policy can be adopted between the site and the Internet.
これらのモデル各人をサイトの異なった部分に適用できます、機能性要件、運営管理コントロール、サイト方針などによって 例えば、方針が一般的使用のためのワークステーションをセットアップするとき、「すべてを許容してください」というモデルを使用することであるかもしれませんが、情報サーバをセットアップするときには「すべてを否定してください」というモデルを採用してください、メールハブのように。 同様に、「すべてを許容してください」という方針はLANのところの間のトラフィックのためにサイトに内部で採られるかもしれませんが、サイトとインターネットの間で「すべてを否定してください」という方針を採ることができます。
Be careful when mixing philosophies as in the examples above. Many sites adopt the theory of a hard "crunchy" shell and a soft "squishy" middle. They are willing to pay the cost of security for their external traffic and require strong security measures, but are unwilling or unable to provide similar protections internally. This works fine as long as the outer defenses are never breached and the internal users can be trusted. Once the outer shell (firewall) is breached, subverting the internal network is trivial.
上記の例のように哲学を混ぜるときには、注意してください。 多くのサイトが固い「ボリボリ音を立てている」シェルと柔らかい「ぐにゃぐにゃ」の中央の理論を採用します。 彼らは、セキュリティの費用をそれらの域外交通に支払って、強い安全策を必要とすることを望んでいますが、不本意であるか、または内部的に同様の保護を提供できません。 外側のディフェンスを決して破らないで、内部利用者を信じることができる限り、これはきめ細かに働いています。 外側のシェル(ファイアウォール)がいったん破られると、内部のネットワークを打倒するのは些細です。
Fraser, Ed. Informational [Page 13] RFC 2196 Site Security Handbook September 1997
フレーザ、[13ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
3.1.4 Identify Real Needs for Services
3.1.4 サービスの真の必要性を特定してください。
There is a large variety of services which may be provided, both internally and on the Internet at large. Managing security is, in many ways, managing access to services internal to the site and managing how internal users access information at remote sites.
内部的で全体のインターネットの上で提供されるかもしれないさまざまなサービスがあります。 セキュリティを管理するのが、サイトへの内部のサービスへのアクセスを管理して、内部利用者がリモートサイトでどう情報にアクセスするかを管理しながら、多くの方法であります。
Services tend to rush like waves over the Internet. Over the years many sites have established anonymous FTP servers, gopher servers, wais servers, WWW servers, etc. as they became popular, but not particularly needed, at all sites. Evaluate all new services that are established with a skeptical attitude to determine if they are actually needed or just the current fad sweeping the Internet.
サービスは、インターネットの上の波のように突進する傾向があります。 数年間、ポピュラーですが、特に必要でなくなったとき、多くのサイトが公開FTPサーバ、リスサーバ、waisサーバ、WWWサーバなどを確立しています、すべてのサイトで。 疑い深い態度で確立される、それらが実際に必要であるかどうか決定するすべての新種業務かまさしくインターネットに広まる現在の流行を評価してください。
Bear in mind that security complexity can grow exponentially with the number of services provided. Filtering routers need to be modified to support the new protocols. Some protocols are inherently difficult to filter safely (e.g., RPC and UDP services), thus providing more openings to the internal network. Services provided on the same machine can interact in catastrophic ways. For example, allowing anonymous FTP on the same machine as the WWW server may allow an intruder to place a file in the anonymous FTP area and cause the HTTP server to execute it.
セキュリティの複雑さがサービスの数を提供している状態で指数関数的に成長できるのを覚えておいてください。 フィルタリングルータは、新しいプロトコルをサポートするように変更される必要があります。 いくつかのプロトコルは安全に(例えば、RPCとUDPサービス)をフィルターにかけるのは本来難しいです、その結果、より多くの始まりを内部のネットワークに提供します。 同じマシンの上で提供されたサービスは壊滅的な方法で相互作用できます。 例えば、WWWサーバと同じマシンの上に公開FTPを許容するのに、侵入者を公開FTP領域にファイルを置いて、HTTPサーバがそれを実行することを引き起こすかもしれません。
3.2 Network and Service Configuration
3.2 ネットワークとサービス構成
3.2.1 Protecting the Infrastructure
3.2.1 インフラストラクチャを保護すること。
Many network administrators go to great lengths to protect the hosts on their networks. Few administrators make any effort to protect the networks themselves. There is some rationale to this. For example, it is far easier to protect a host than a network. Also, intruders are likely to be after data on the hosts; damaging the network would not serve their purposes. That said, there are still reasons to protect the networks. For example, an intruder might divert network traffic through an outside host in order to examine the data (i.e., to search for passwords). Also, infrastructure includes more than the networks and the routers which interconnect them. Infrastructure also includes network management (e.g., SNMP), services (e.g., DNS, NFS, NTP, WWW), and security (i.e., user authentication and access restrictions).
多くのネットワーク管理者が、彼らのネットワークにホストを保護するために力を尽くします。 わずかな管理者しか、ネットワーク自体を保護するためにどんな取り組みも作りません。 これへの何らかの原理があります。 例えば、ホストを保護するのはネットワークよりはるかに簡単です。 また、ホストに関するデータの後に、侵入者もいそうです。 ネットワークを破損するのは目的に適わないでしょう。 それは言って、ネットワークを保護する理由がまだあります。 例えば、侵入者は、データ(すなわち、パスワードの検索への)を調べるために外部のホストを通してネットワークトラフィックを紛らすかもしれません。 また、インフラストラクチャはそれらとインタコネクトするネットワークとルータ以上を含んでいます。 また、インフラストラクチャはネットワークマネージメント(例えば、SNMP)、サービス(例えば、DNS、NFS、NTP、WWW)、およびセキュリティ(すなわち、ユーザー認証とアクセス制限)を含んでいます。
The infrastructure also needs protection against human error. When an administrator misconfigures a host, that host may offer degraded service. This only affects users who require that host and, unless
また、インフラストラクチャは人為ミスに対する保護を必要とします。 管理者misconfiguresであるときに、ホスト、そのホストは降格しているサービスを提供するかもしれません。 そしてこれがそのホストを必要とするユーザに影響するだけである。
Fraser, Ed. Informational [Page 14] RFC 2196 Site Security Handbook September 1997
フレーザ、[14ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
that host is a primary server, the number of affected users will therefore be limited. However, if a router is misconfigured, all users who require the network will be affected. Obviously, this is a far larger number of users than those depending on any one host.
そのホストがプライマリサーバである、したがって、影響を受けるユーザの数は制限されるでしょう。 しかしながら、ルータがmisconfiguredされると、ネットワークを必要とするすべてのユーザが影響を受けるでしょう。 明らかに、これはどんなホストにも頼るものよりはるかに多くのユーザです。
3.2.2 Protecting the Network
3.2.2 ネットワークを保護すること。
There are several problems to which networks are vulnerable. The classic problem is a "denial of service" attack. In this case, the network is brought to a state in which it can no longer carry legitimate users' data. There are two common ways this can be done: by attacking the routers and by flooding the network with extraneous traffic. Please note that the term "router" in this section is used as an example of a larger class of active network interconnection components that also includes components like firewalls, proxy- servers, etc.
ネットワークが被害を受け易いいくつかの問題があります。 古典的な問題は「サービスの否定」攻撃です。 この場合、ネットワークはそれがもう正統のユーザのデータを運ぶことができない状態に持って来られます。 これができる2つの一般的な方法があります: ルータを攻撃して、異質なトラフィックでネットワークをあふれさせることによって。 このセクションの「ルータ」という用語はまた、ファイアウォールのようなコンポーネント、プロキシサーバなどを含んでいるより大きいクラスのアクティブなネットワーク相互接続コンポーネントに関する例として使用されます。
An attack on the router is designed to cause it to stop forwarding packets, or to forward them improperly. The former case may be due to a misconfiguration, the injection of a spurious routing update, or a "flood attack" (i.e., the router is bombarded with unroutable 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 exponential explosion of transmissions.
ルータに対する攻撃は、パケットを進めるのを止めるか、または不適切にそれらを進めることを引き起こすように設計されています。 前のケースはmisconfiguration、偽りのルーティングアップデートの注射、または「洪水攻撃」のためであるかもしれません(すなわち、ルータは非発送可能パケットで砲撃されます、退行する性能を引き起こして)。 ネットワークに対する洪水攻撃はルータに対する洪水攻撃と同様です、通常、洪水パケットが放送されるのを除いて。 理想的な洪水攻撃はネットワーク・ノードの何らかの知られている欠点を利用して、パケットを再送するか、または誤りパケットを生成することを引き起こす単一のパケットの注射でしょう。それのそれぞれが、別のホストによって拾われて、繰り返されます。 適切な攻撃パケットはトランスミッションの指数の爆発を生成することさえできます。
Another classic problem is "spoofing." In this case, spurious routing updates are sent to one or more routers causing them to misroute packets. This differs from a denial of service attack only 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 detected by network users. In spoofing, the spurious route will cause packets to be routed to a host from which an intruder may monitor the data in the packets. These packets are then re-routed to their correct destinations. However, the intruder may or may not have altered the contents of the packets.
別の古典的な問題は「だまされています」。 この場合、misrouteパケットにそれらを引き起こす1つ以上のルータに偽りのルーティングアップデートを送ります。 これは偽物のルートの後ろの目的だけにおけるサービス不能攻撃と異なっています。 サービスの否定では、オブジェクトで、ルータは使用不可能になることになっています。 ネットワーク利用者によってすぐに検出される状態。 スプーフィングでは、偽物のルートで、侵入者がパケットでデータをモニターするかもしれないホストにパケットを発送するでしょう。 そして、これらのパケットはそれらの正しい目的地に別ルートで送られます。 しかしながら、侵入者はパケットのコンテンツを変更したかもしれません。
The solution to most of these problems is to protect the routing update packets sent by the routing protocols in use (e.g., RIP-2, OSPF). There are three levels of protection: clear-text password, cryptographic checksum, and encryption. Passwords offer only minimal protection against intruders who do not have direct access to the physical networks. Passwords also offer some protection against misconfigured routers (i.e, routers which, out of the box, attempt to
これらの問題の大部分への解決は使用中のルーティング・プロトコル(例えば、リップ-2、OSPF)によって送られたルーティングアップデートパケットを保護することです。 保護の3つのレベルがあります: クリアテキストパスワード、暗号のチェックサム、および暗号化。 パスワードは物理ネットワークにダイレクトに近づく手段を持っていない侵入者に対する最小量の保護だけを提供します。 また、パスワードがmisconfiguredルータを何らかの保護に提供する、(i.e、ルータ、どれ、創造的に試みてくださいか。
Fraser, Ed. Informational [Page 15] RFC 2196 Site Security Handbook September 1997
フレーザ、[15ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
route packets). The advantage of passwords is that they have a very low overhead, in both bandwidth and CPU consumption. Checksums protect against the injection of spurious packets, even if the intruder has direct access to the physical network. Combined with a sequence number, or other unique identifier, a checksum can also protect again "replay" attacks, wherein an old (but valid at the time) routing update is retransmitted by either an intruder or a misbehaving router. The most security is provided by complete encryption of sequenced, or uniquely identified, routing updates. This prevents an intruder from determining the topology of the network. The disadvantage to encryption is the overhead involved in processing the updates.
ルートパケット) パスワードの利点は帯域幅とCPU消費の両方に非常に低いオーバーヘッドを持っているということです。 侵入者が物理ネットワークにダイレクトに近づく手段を持っても、チェックサムは偽りのパケットの注射から守ります。 しかし、一連番号、または他のユニークな識別子に結合されています、また、チェックサムは再び「再生」攻撃を保護できます、どの点で、老人、(時間) ルーティングアップデートで有効であるのは、侵入者によって再送されていてふらちな事するルータです。 配列されたか、または唯一特定されたルーティングアップデートの完全な暗号化で最も多くのセキュリティを提供します。 これによって、侵入者はネットワークのトポロジーを決定できません。 暗号化への不都合はアップデートを処理するのに伴われるオーバーヘッドです。
RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text passwords in their base design specifications. In addition, there are extensions to each base protocol to support MD5 encryption.
RIP-2(RFC1723)とOSPF(RFC1583)は、それらのベースデザイン仕様でクリアテキストがパスワードであるとともにサポートします。 さらに、MD5が暗号化であるとサポートするために、それぞれのベースプロトコルへの拡大があります。
Unfortunately, there is no adequate protection against a flooding attack, or a misbehaving host or router which is flooding the network. Fortunately, this type of attack is obvious when it occurs and can usually be terminated relatively simply.
残念ながら、ネットワークをあふれさせているフラッディング攻撃、ふらちな事をしているホストまたはルータに対するどんな適切な保護もありません。 幸い、このタイプの攻撃は、起こるとき、明白であり、通常、比較的単に終えることができます。
3.2.3 Protecting the Services
3.2.3 サービスを保護すること。
There are many types of services and each has its own security requirements. These requirements will vary based on the intended use of the service. For example, a service which should only be usable within a site (e.g., NFS) may require different protection mechanisms than a service provided for external use. It may be sufficient to protect the internal server from external access. However, a WWW server, which provides a home page intended for viewing by users anywhere on the Internet, requires built-in protection. That is, the service/protocol/server must provide whatever security may be required to prevent unauthorized access and modification of the Web database.
多くのタイプのサービスがあります、そして、それぞれには、それ自身のセキュリティ要件があります。 これらの要件はサービスの意図している使用に基づいて異なるでしょう。 例えば、サイト(例えば、NFS)の中で使用可能であるだけであるべきサービスは外部の使用に提供されたサービスと異なった保護メカニズムを必要とするかもしれません。 外部のアクセサリーから内部のサーバを保護するのは十分であるかもしれません。 しかしながら、WWWサーバ(ユーザによる見るようにインターネットでどこでも意図したホームページを提供する)は内蔵の保護を必要とします。 すなわち、サービス/プロトコル/サーバはウェブデータベースの不正アクセスと変更を防ぐのに必要であるどんなセキュリティも提供しなければなりません。
Internal services (i.e., services meant to be used only by users within a site) and external services (i.e., services deliberately made available to users outside a site) will, in general, have protection requirements which differ as previously described. It is therefore wise to isolate the internal services to one set of server host computers and the external services to another set of server host computers. That is, internal and external servers should not be co-located on the same host computer. In fact, many sites go so far
一般に、内部のサービス(すなわち、サービスは、サイトの中で単にユーザによって使用されることを意味した)と外部サービス(すなわち、故意にサイトの外でユーザにとって利用可能にされたサービス)には、以前に説明されているとして異なる保護要件があるでしょう。 したがって、1セットのサーバホストコンピュータに対する内部のサービスともう1セットのサーバホストコンピュータへの外部サービスを隔離するのは賢明です。 すなわち、内部の、そして、外部のサーバは同じホストコンピュータの上に共同位置するべきではありません。 事実上、多くのサイトが今までのところ、続きます。
Fraser, Ed. Informational [Page 16] RFC 2196 Site Security Handbook September 1997
フレーザ、[16ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
as to have one set of subnets (or even different networks) which are accessible from the outside and another set which may be accessed only within the site. Of course, there is usually a firewall which 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.
組織(例えば、会社の部門)の異なった部分を接続するのにイントラネットを使用することで関心を増やすのがあります。 一般に、このドキュメントが外部と内部(公共の、そして、個人的な)の間で差別化する間、イントラネットを使用するサイトはサービスを設計して、提供するとき、3つの分離を考えて、適切な行動を取るのが必要であることを意識しているべきです。 イントラネットに提供されたサービスは、公共でなくて、また単一の組織的な「副-ユニット」に対するサービスとして同じくらい完全に個人的でないでしょう。 したがって、サービスは外部の、そして、内部のサービスとネットワークの両方と切り離されたそれ自身のサポートシステムを必要とするでしょう。
One form of external service deserves some special consideration, and that is anonymous, or guest, access. This may be either anonymous FTP or guest (unauthenticated) login. It is extremely important to ensure that anonymous FTP servers and guest login userids are carefully isolated from any hosts and file systems from which outside users should be kept. Another area to which special attention must be paid concerns anonymous, writable access. A site may be legally responsible for the content of publicly available information, so careful monitoring of the information deposited by anonymous users is advised.
ある形式の外部サービスが何らかの特別の配慮に値して、それが匿名である、または客演してください、アクセサリー これはどちらかの公開FTPかゲスト(非認証した)ログインであるかもしれません。 公開FTPサーバとゲストログインユーザIDがどんなホストとファイルシステムからもどれがユーザの外に保たれるべきであるかから慎重に隔離されるのを保証するのは非常に重要です。 特別な注意を向けなければならない別の領域は匿名の、そして、書き込み可能なアクセサリーに関係があります。 サイトが公的に利用可能な情報の内容に法的に原因となるかもしれないので、匿名のユーザによって預けられた情報の注意深い監視は教えられます。
Now we shall consider some of the most popular services: name service, password/key service, authentication/proxy service, electronic mail, WWW, file transfer, and NFS. Since these are the most frequently used services, they are the most obvious points of attack. Also, a successful attack on one of these services can produce disaster all out of proportion to the innocence of the basic service.
今、私たちは最もポピュラーなサービスのいくつかを考えるつもりです: サービス、パスワード/主要なサービス、認証/代理業務、電子メール、WWW、ファイル転送、およびNFSを命名してください。 これらが最も頻繁に使用されたサービスであるので、それらは最も明白なポイントの攻撃です。 また、これらのサービスの1つに対するうまくいっている攻撃は基本サービスの無実に割合が全面的な災害を発生させることができます。
3.2.3.1 Name Servers (DNS and NIS(+))
3.2.3.1 ネームサーバ(DNSとNIS(+))
The Internet uses the Domain Name System (DNS) to perform address resolution for host and network names. The Network Information 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 resolution is critical to the secure operation of any network. An attacker who can successfully control or impersonate a DNS server can re-route traffic to subvert security protections. For example, routine traffic can be diverted to a compromised system to be monitored; or, users can be tricked into providing authentication secrets. An organization should create well known, protected sites
インターネットは、ホストのためのアドレス解決とネットワーク名を実行するのに、ドメインネームシステム(DNS)を使用します。 Network情報Service(NIS)とNIS+は世界的なインターネットで使用されませんが、DNSサーバと同じリスクを受けることがあります。名前からアドレスへの解決はどんなネットワークの安全な操作にも重要です。 首尾よくDNSサーバを制御するか、またはまねることができる攻撃者は、機密保持を打倒するために交通ルートを変更できます。 例えば、モニターされるために通常のトラフィックを感染されたシステムに紛らすことができます。 または、認証秘密を提供するようにユーザをだますことができます。 組織はよく知られていて、保護されたサイトを作成するべきです。
Fraser, Ed. Informational [Page 17] RFC 2196 Site Security Handbook September 1997
フレーザ、[17ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
to act as secondary name servers and protect their DNS masters from denial of service attacks using filtering routers.
セカンダリネームサーバとして機能して、サービスの否定から彼らのDNS主人を保護するのは、フィルタリングルータを使用することで攻撃されます。
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).
DNSには、伝統的に、セキュリティ能力が全くありません。 質問から返された情報は、特に、変更がないかどうかチェックできませんでしたし、それが問題のネームサーバから来たことを確かめもしました。 配布されると情報の保全が暗号で確かめられるのを許容するプロトコルにデジタル署名を組み入れるために、仕事をしました(RFC2065を見てください)。
3.2.3.2 Password/Key Servers (NIS(+) and KDC)
3.2.3.2 パスワード/主要なサーバ(NIS(+)とKDC)
Password and key servers generally protect their vital information (i.e., the passwords and keys) with encryption algorithms. However, even a one-way encrypted password can be determined by a dictionary attack (wherein common words are encrypted to see if they match the stored encryption). It is therefore necessary to ensure that these 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 service (i.e., general services, such as Telnet and FTP, should not be allowed by anyone other than administrators).
一般に、パスワードと主要なサーバは暗号化アルゴリズムでそれらの極めて重要な情報(すなわち、パスワードとキー)を保護します。しかしながら、辞書攻撃(一般的な語はそれらが保存された暗号化に合っているかどうか確認するためにそこで暗号化される)で一方向暗号化されたパスワードさえ決定できます。 したがって、これらのサーバが確実にホストでアクセス可能にならないようにするのが必要であり、(サービスに彼らを使用するのを計画していません)それらのホストさえサービスにアクセスできるだけであるべきです(管理者以外のだれもすなわち、TelnetやFTPなどの一般的なサービスを許すべきではありません)。
3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK)
3.2.3.3 認証/Proxyサーバ(ソックス、FWTK)
A proxy server provides a number of security enhancements. It allows sites to concentrate services through a specific host to allow monitoring, hiding of internal structure, etc. This funnelling of services creates an attractive target for a potential intruder. The type of protection required for a proxy server depends greatly on the proxy protocol in use and the services being proxied. The general 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 starting point.
プロキシサーバは多くのセキュリティ増進を提供します。 それで、サイトは、モニター、内部の構造の隠れることなどを許容するために特定のホストを通してサービスを集結できます。 サービスをこの注ぐのは潜在的侵入者のための魅力的な目標を作成します。 プロキシサーバに必要である保護のタイプは使用中であるプロキシプロトコルとproxiedされるサービスを大いに当てにします。 アクセスをサービスを必要とするそれらのホストに制限するだけであり、それらのホストによるアクセスをそれらのサービスだけに制限する一般的な規則は良い出発点です。
3.2.3.4 Electronic Mail
3.2.3.4 電子メール
Electronic mail (email) systems have long been a source for intruder break-ins because email protocols are among the oldest and most widely deployed services. Also, by it's very nature, an email server requires access to the outside world; most email servers accept input from any source. An email server generally consists of two parts: a receiving/sending agent and a processing agent. Since email is delivered to all users, and is usually private, the processing agent typically requires system (root) privileges to deliver the mail. Most email implementations perform both portions of the service, which means the receiving agent also has system privileges. This opens several security holes which this document will not describe. There are some implementations available which allow a separation of
最も古くて広く最も配布しているサービスの中にメールプロトコルがあるので、長い間、電子メール(メール)システムは侵入者不法侵入のためのソースです。 それがまさしくその自然である、Eメールサーバは外の世界へのアクセスを必要とします。 ほとんどのEメールサーバがどんなソースからも入力を受け入れます。 一般に、Eメールサーバは2つの部品から成ります: 受信/送付エージェントと処理エージェント。 メールがすべてのユーザに提供されて、通常個人的であるので、処理エージェントは郵便を配達するためにシステム(根)特権を通常必要とします。 ほとんどのメール実装が両方のまた、受信エージェントにはシステム特権があることを意味するサービスの部分を実行します。 これはこのドキュメントが説明しないいくつかのセキュリティーホールを開きます。 分離を許容する利用可能ないくつかの実装があります。
Fraser, Ed. Informational [Page 18] RFC 2196 Site Security Handbook September 1997
フレーザ、[18ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
the two agents. Such implementations are generally considered more secure, but still require careful installation to avoid creating a security problem.
2人のエージェント。 そのような実装は、より安全であると一般に考えられますが、それでも、慎重なインストールを必要として、警備上の問題を作成するのを避けてください。
3.2.3.5 World Wide Web (WWW)
3.2.3.5 WWW(WWW)
The Web is growing in popularity exponentially because of its ease of use and the powerful ability to concentrate information services. Most WWW servers accept some type of direction and action from the persons accessing their services. The most common example is taking a request from a remote user and passing the provided information to a program running on the server to process the request. Some of these programs are not written with security in mind and can create security holes. If a Web server is available to the Internet community, it is especially important that confidential information 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 "trusted" by other internal hosts.
ウェブは使いやすさと情報サービスを集結する強力な能力で人気で指数関数的に成長しています。 ほとんどのWWWサーバが彼らのサービスにアクセスする人々からタイプの方向と動作を受け入れます。 最も一般的な例は、要求を処理するためにサーバで動きながら、リモート・ユーザーと提供された情報を通過するのからプログラムまでの要求を取っています。 これらのいくつかのプログラムが、念頭にセキュリティで書かれていなくて、セキュリティー上の欠陥を生み出すことができます。 ウェブサーバがインターネットコミュニティに利用可能であるなら、秘密情報がそのサーバと同じホストの上に共同位置していないのは、特に重要です。事実上、サーバにはひたむきなホストがいるのは、お勧めです(他の内部のホストによって「信じられません」)。
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.
多くのサイトが彼らのWWWサービスによるFTPサービスの共同場所を見つけたがっているかもしれません。 しかし、これは情報(ftpに、得る)を提供するだけであるやがてftpなサーバのために起こるだけであるべきです。 やがてftpする、置く、WWWと組み合わせて、危険であり(例えば、彼らはあなたのサイトがウェブに発表している情報への変更をもたらすかもしれません)、自分たちで各サービスのためのセキュリティ問題を異なるようにするかもしれません。
3.2.3.6 File Transfer (FTP, TFTP)
3.2.3.6 ファイル転送(FTP、TFTP)
FTP and TFTP both allow users to receive and send electronic files in a point-to-point manner. However, FTP requires authentication while TFTP requires none. For this reason, TFTP should be avoided as much as possible.
FTPとTFTPはユーザに二地点間方法で電子ファイルを受けて、ともに送らせます。 しかしながら、TFTPはなにも必要としませんが、FTPは認証を必要とします。 この理由で、TFTPはできるだけ避けられるべきです。
Improperly configured FTP servers can allow intruders to copy, replace and delete files at will, anywhere on a host, so it is very important to configure this service correctly. Access to encrypted passwords and proprietary data, and the introduction of Trojan horses are just a few of the potential security holes that can occur when the service is configured incorrectly. FTP servers should reside on their own host. Some sites choose to co-locate FTP with a Web server, since the two protocols share common security considerations However, the the practice isn't recommended, especially when the FTP service allows the deposit of files (see section on WWW above). As 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.
侵入者がホストで自由自在と、どこでも不適切に構成されたFTPサーバでファイルをコピーして、置き換えて、削除できるので、正しくこのサービスを構成するのは非常に重要です。 暗号化されたパスワードで独占にデータにアクセスしてください。そうすれば、トロイの木馬の導入はただサービスが不当に構成されるとき現れることができる潜在的セキュリティーホールのいくつかです。 FTPサーバはそれら自身のホストの上にあるべきです。 いくつかのサイトが、ウェブサーバがあるFTPの共同場所を見つけるのを選びます、2つのプロトコルが共通の安全保障問題Howeverを共有するので習慣はお勧めではありません、特にFTPサービスがファイルの預金を許容するとき(WWWの上のセクションが上であることを見てください)。 セクション3.2.3の冒頭記事で言及されるように、内部的にあなたのサイトに提供されたサービスの外部的にサービスを提供している状態で共同見つけるべきではありません。 それぞれには、それ自身のホストがいるべきです。
Fraser, Ed. Informational [Page 19] RFC 2196 Site Security Handbook September 1997
フレーザ、[19ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
TFTP does not support the same range of functions as FTP, and has no security whatsoever. This service should only be considered for internal use, and then it should be configured in a restricted way so that the server only has access to a set of predetermined files (instead of every world-readable file on the system). Probably the most common usage of TFTP is for downloading router configuration files to a router. TFTP should reside on its own host, and should not be installed on hosts supporting external FTP or Web access.
TFTPは同じ範囲のFTPへの関数をサポートしないで、またセキュリティを全く持っていません。このサービスが内部の使用のために考えられるだけであるべきであり、次に、それが制限された方法で構成されるべきであるので、サーバは1セットの予定されたファイル(システムのあらゆる世界読み込み可能なファイルの代わりに)に近づく手段を持っているだけです。 たぶんTFTPの最も一般的な使用法は、ルータ構成ファイルをルータにダウンロードするものです。 TFTPはそれ自身のホストの上に住んでいるべきであり、外部のFTPかウェブアクセサリーをサポートするホストの上にインストールするべきではありません。
3.2.3.7 NFS
3.2.3.7 NFS
The Network File Service allows hosts to share common disks. NFS is frequently used by diskless hosts who depend on a disk server for all of their storage needs. Unfortunately, NFS has no built-in security. It is therefore necessary that the NFS server be accessable only by those hosts which are using it for service. This is achieved by specifying which hosts the file system is being exported to and in what manner (e.g., read-only, read-write, etc.). Filesystems should 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.
Network File Serviceはホストに一般的なディスクを共有させます。 NFSは頻繁に彼らのストレージの必要性のすべてのためにディスクサーバを当てにするディスクレス・ホストによって使用されます。 残念ながら、NFSには、内蔵のセキュリティーが全くありません。 したがって、NFSサーバがそれらのホストだけでアクセス可能であることが必要です(サービスにそれを使用しています)。 方法とどんな方法(例えば、読書唯一の、そして、読書して書いているなど)でファイルシステムがどのホストにエクスポートされているかを指定することによって、これは達成されます。 これが、NFSサービスが外部的にアクセスしやすいのを必要とするので、企業内情報通信網の外におけるどんなホストにもファイルシステムをエクスポートするべきではありません。 理想的に、NFSサービスへの外部のアクセスはファイアウォールによって止められるべきです。
3.2.4 Protecting the Protection
3.2.4 保護を保護すること。
It is amazing how often a site will overlook the most obvious weakness in its security by leaving the security server itself open to attack. Based on considerations previously discussed, it should be clear that: the security server should not be accessible from off-site; should offer minimum access, except for the authentication function, to users on-site; and should not be co-located with any other servers. Further, all access to the node, including access to the service itself, should be logged to provide a "paper trail" in the event of a security breach.
サイトがセキュリティサーバ自体を攻撃するために開いた状態でおくことによってセキュリティで最も明白な弱点のどれくらいの頻度で見晴らしがきくかは、驚くべきものです。 以前に議論した問題に基づいて、それはそれをクリアすることであるべきです: セキュリティサーバはオフサイトからアクセスしやすいはずがありません。 現場でユーザへの認証機能以外の最低輸入義務を提供するべきです。 そして、いかなる他のサーバでも共同見つけるべきではありません。 さらに、サービス自体へのアクセスを含むノードへのすべてのアクセスが、機密保護違反の場合、「ペーパートレール」を提供するために登録されるべきです。
3.3 Firewalls
3.3 ファイアウォール
One of the most widely deployed and publicized security measures in use on the Internet is a "firewall." Firewalls have been given the reputation of a general panacea for many, if not all, of the Internet security issues. They are not. Firewalls are just another tool in the quest for system security. They provide a certain level of protection and are, in general, a way of implementing security policy 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. There are the traditional trade-offs between security, ease of use, cost, complexity, etc.
インターネットで使用中の最も広く配布していてピーアールされた安全対策の1つは「ファイアウォール」です。 インターネット安全保障問題の多く(すべてでなくても)の一般的な万能薬の評判をファイアウォールに与えました。 それらはそうではありません。 ファイアウォールはシステムセキュリティを求めてただのツールです。 それらは、あるレベルの保護を提供して、一般に、ネットワークレベルで安全保障政策を実装する方法です。 ファイアウォールが提供するセキュリティのレベルは特定のマシンでセキュリティのレベルで異なることができます。 セキュリティ、使いやすさ、費用、複雑さなどの間には、伝統的なトレードオフがあります。
Fraser, Ed. Informational [Page 20] RFC 2196 Site Security Handbook September 1997
フレーザ、[20ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
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 firewall acts as a gateway through which all traffic to and from the protected network and/or systems passes. Firewalls help to place limitations on the amount and type of communication that takes place between the protected network and the another network (e.g., the Internet, or another piece of the site's network).
ファイアウォールはそれを保護する目的のためにネットワークとネットワークからアクセスを制御して、見るのに使用される数個のメカニズムのいずれでもあります。 ファイアウォールはシステムと保護されたネットワーク、そして/または、システムからのすべてのトラフィックが終わるゲートウェイとして作動します。 そして、ファイアウォールが、撮影が保護されたネットワークの間に置くコミュニケーションの量とタイプに制限を置くのを助ける、別のネットワーク(例えば、インターネット、またはもう1片のサイトのネットワーク)。
A firewall is generally a way to build a wall between one part of a
network, a company's internal network, for example, and another part,
the global Internet, for example. The unique feature about this wall
is that there needs to be ways for some traffic with particular
characteristics to pass through carefully monitored doors
("gateways"). The difficult part is establishing the criteria by
which the packets are allowed or denied access through the doors.
Books written on firewalls use different terminology to describe the
various forms of firewalls. This can be confusing to system
administrators who are not familiar with firewalls. The thing to note
here is that there is no fixed terminology for the description of
firewalls.
例えば、一般に、ファイアウォールはネットワークの一部と、例えば、会社の内部のネットワークと別の部分の間の壁、世界的なインターネットを造る方法です。 この壁に関するユニークな特徴はそこでは、特定の特性がある何らかのトラフィックが慎重に通り抜ける方法である必要性がドア(「ゲートウェイ」)をモニターしたということです。 難しい部分はパケットがドアを通るアクセスを許容されているか、または拒絶される評価基準を確立しています。 書かれた本は、様々な形式のファイアウォールについて説明するのにファイアウォールの上に異なった用語を使用します。 これはファイアウォールに詳しくないシステム管理者に混乱させられることができます。 ここで注意することはファイアウォールの記述のための固定用語が全くないということです。
Firewalls are not always, or even typically, a single machine. Rather, firewalls are often a combination of routers, network segments, and host computers. Therefore, for the purposes of this discussion, the term "firewall" can consist of more than one physical device. Firewalls are typically built using two different components, filtering routers and proxy servers.
通常、ファイアウォールは単一マシンでさえあります。 むしろ、しばしばファイアウォールはルータ、ネットワークセグメント、およびホストコンピュータの組み合わせです。 したがって、この議論の目的のために、「ファイアウォール」という用語は1個以上のフィジカル・デバイスから成ることができます。 ルータとプロキシサーバをフィルターにかけて、ファイアウォールは、2つの異なったコンポーネントを使用することで通常建設されます。
Filtering routers are the easiest component to conceptualize in a firewall. A router moves data back and forth between two (or more) different networks. A "normal" router takes a packet from network A 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 whether it should route the packet. This is done by installing a series of filters by which the router decides what to do with any given packet of data.
フィルタリングルータはファイアウォールで最も概念化しやすいコンポーネントです。 ルータは2つ(さらに)の異なったネットワークの間で前後方向でデータを動かします。 「正常な」ルータは、ネットワークAからパケットを取って、ルータをフィルターにかけると同じことがするネットワークB.Aでそれを目的地に「発送します」が、それがどのようにだけパケットを発送するかではなく、パケットを発送するべきであるかどうか決めます。 ルータが何かデータの与えられたパケットで何をしたらよいかを決める一連のフィルタをインストールすることによって、これをします。
A discussion concerning capabilities of a particular brand of router, running a particular software version is outside the scope of this document. However, when evaluating a router to be used for filtering packets, the following criteria can be important when implementing a filtering policy: source and destination IP address, source and destination TCP port numbers, state of the TCP "ack" bit, UDP source and destination port numbers, and direction of packet flow (i.e.. A- >B or B->A). Other information necessary to construct a secure filtering scheme are whether the router reorders filter instructions (designed to optimize filters, this can sometimes change the meaning and cause unintended access), and whether it is possible to apply
ルータの特定のブランドの能力に関する議論、このドキュメントの範囲の外に特定のソフトウェアバージョンを実行するのがあります。 しかしながら、パケットをフィルターにかけるのに使用されるためにルータを評価するとき、フィルタリング政策を実施するとき、以下の評価基準は重要である場合があります: ソースと送付先IPアドレスとソースと目的地TCPポートナンバー、TCP「ackな」ビット、UDPソース、および目的地の州は数、およびパケット流動(. すなわち、A>BかB>A)の方向を移植します。 安全なフィルタリング体系を構成するのに他の情報必要であるのは、ルータ追加注文が指示をフィルターにかけるかどうかと(フィルタを最適化するように設計されていて、これは、時々意味を変えて、故意でないアクセスを引き起こす場合があります)、適用するのが可能であるかどうかということです。
Fraser, Ed. Informational [Page 21] RFC 2196 Site Security Handbook September 1997
フレーザ、[21ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
filters for inbound and outbound packets on each interface (if the router filters only outbound packets then the router is "outside" of its filters and may be more vulnerable to attack). In addition to the router being vulnerable, this distinction between applying filters on inbound or outbound packets is especially relevant for routers with more than 2 interfaces. Other important issues are the ability to create filters based on IP header options and the fragment state of a packet. Building a good filter can be very difficult and requires a good understanding of the type of services (protocols) that will be filtered.
それぞれの本国行きの、そして、外国行きのパケットのためのフィルタは連結します(ルータが外国行きのパケットだけをフィルターにかけるなら、ルータは、「外にフィルタの」あって、攻撃するために、より被害を受け易いかもしれません)。 被害を受け易いルータに加えて、ルータにおいて、本国行きの、または、外国行きのパケットにフィルタを適用するところのこの区別は2つ以上のインタフェースで特に関連しています。 他の切迫した課題はIPヘッダーオプションとパケットの断片状態に基づくフィルタを作成する能力です。 良いフィルタを組立てるのは、非常に難しい場合があり、フィルターにかけられるサービス(プロトコル)のタイプの良い理解を必要とします。
For better security, the filters usually restrict access between the two connected nets to just one host, the bastion host. It is only possible to access the other network via this bastion host. As only this host, rather than a few hundred hosts, can get attacked, it is easier to maintain a certain level of security because only this host has to be protected very carefully. To make resources available to legitimate users across this firewall, services have to be forwarded by the bastion host. Some servers have forwarding built in (like DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP, etc.), proxy servers can be used to allow access to the resources across the firewall in a secure way.
より良いセキュリティのために、通常、フィルタは2つの接続ネットの間のアクセスをちょうど1人のホスト、要塞ホストに制限します。 この要塞ホストを通して単にもう片方のネットワークにアクセスするのは可能です。 数100人のホストよりむしろこのホストしか攻撃できないのに従って、このホストだけが非常に慎重に保護されなければならないので、あるレベルのセキュリティを維持するのは、より簡単です。 リソースをこのファイアウォールの向こう側に正統のユーザにとって利用可能にするように、要塞ホストはサービスを進めなければなりません。 いくつかのサーバで推進を組み込みます(DNS-サーバやSMTPサーバーのように)、他のサービス(例えば、Telnet、FTPなど)のためにファイアウォールの向こう側に安全な方法でリソースへのアクセスを許すのにプロキシサーバは使用できます。
A proxy server is way to concentrate application services through a single machine. There is typically a single machine (the bastion host) that acts as a proxy server for a variety of protocols (Telnet, SMTP, FTP, HTTP, etc.) but there can be individual host computers for each service. Instead of connecting directly to an external server, the client connects to the proxy server which in turn initiates a connection to the requested external server. Depending on the type of proxy server used, it is possible to configure internal clients to perform this redirection automatically, without knowledge to the user, others might require that the user connect directly to the proxy server and then initiate the connection through a specified format.
単一マシンを通してずっと濃縮アプリケーション・サービスにはプロキシサーバがあります。 通常さまざまなプロトコル(telnet、SMTP、FTP、HTTPなど)のためのプロキシサーバとして作動する単一マシン(要塞ホスト)ですが、各サービスのための個々のホストコンピュータがあることができます。 直接外部のサーバに接続することの代わりに、クライアントは順番に要求された外部のサーバに接続を開始するプロキシサーバに接続します。使用されるプロキシサーバのタイプに頼っていて、自動的にこのリダイレクションを実行するために内部のクライアントを構成するのは可能です、ユーザへの知識なしで他のものがユーザが直接プロキシサーバに接続して、次に、指定された形式を通して接続を開始するのを必要とするかもしれません。
There are significant security benefits which can be derived from using proxy servers. It is possible to add access control lists to protocols, requiring users or systems to provide some level of authentication before access is granted. Smarter proxy servers, sometimes called Application Layer Gateways (ALGs), can be written which understand specific protocols and can be configured to block only subsections of the protocol. For example, an ALG for FTP can tell the difference between the "put" command and the "get" command; 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. By contrast, a filtering router could either block all FTP access, or none, but not a subset.
プロキシサーバを使用するのから得ることができる重要なセキュリティ利益があります。 アクセスコントロールリストをプロトコルに追加するのは可能です、アクセスが承諾される前に何らかのレベルの認証を提供するためにユーザかシステムを必要として。 より賢い時々Application Layer Gateways(ALGs)と呼ばれたプロキシサーバは書くことができます、そして、(特定のプロトコルを理解しています)プロトコルの小区分だけを妨げるために構成できます。 例えば、FTPのためのALGは「置き」コマンドと「得」コマンドの違いを言うことができます。 組織は、ユーザがインターネットからファイルを「得ること」を許容することを願っていますが、リモートサーバの内部のファイルを「置くことができないかもしれません」。対照的に、フィルタリングルータは部分集合ではなく、すべてのFTPアクセス、またはなにも妨げることができませんでした。
Fraser, Ed. Informational [Page 22] RFC 2196 Site Security Handbook September 1997
フレーザ、[22ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
Proxy servers can also be configured to encrypt data streams based on a variety of parameters. An organization might use this feature to allow encrypted connections between two locations whose sole access points are on the Internet.
また、さまざまなパラメタに基づくデータ・ストリームを暗号化するためにProxyサーバを構成できます。 組織は唯一のアクセスポイントがインターネットにある2つの位置の間の暗号化された接続を許すこの特徴を使用するかもしれません。
Firewalls are typically thought of as a way to keep intruders out, but they are also often used as a way to let legitimate users into a site. There are many examples where a valid user might need to regularly access the "home" site while on travel to trade shows and conferences, etc. Access to the Internet is often available but may be through an untrusted machine or network. A correctly configured proxy server can allow the correct users into the site while still denying access to other users.
ファイアウォールは侵入者を避ける方法として通常考えられますが、また、彼らは正統のユーザをサイトに入れる方法としてしばしば使用されます。 正規ユーザーが取り引きするのが旅行のときに目立っていますが、定期的に「ホーム」サイトにアクセスする必要があるかもしれない多くの例と会議などがあります。 インターネットへのアクセスは、しばしば利用可能ですが、信頼されていないマシンかネットワークを通してあるかもしれません。 正しく構成されたプロキシサーバはまだ他のユーザへのアクセスを拒絶している間、正しいユーザのサイトに入ることを許すことができます。
The current best effort in firewall techniques is found using a combination of a pair of screening routers with one or more proxy servers on a network between the two routers. This setup allows the external router to block off any attempts to use the underlying IP layer to break security (IP spoofing, source routing, packet fragments), while allowing the proxy server to handle potential security holes in the higher layer protocols. The internal router's purpose is to block all traffic except to the proxy server. If this setup is rigidly implemented, a high level of security can be achieved.
ファイアウォールのテクニックによるベストエフォート型の電流は2つのルータの間のネットワークの1つ以上のプロキシサーバへの1組の選別ルータの組み合わせを使用しているのが見つけられます。 このセットアップで、プロキシサーバが、より高い層のプロトコルの潜在的セキュリティーホールを扱うのを許容している間、外部のルータはセキュリティ(IPスプーフィング、ソースルーティング、パケットは断片化する)を壊すのに基本的なIP層を使用するどんな試みもふさぐことができます。 内部のルータの目的はプロキシサーバ以外のすべてのトラフィックを妨げることです。このセットアップが厳格に実装されるなら、高いレベルのセキュリティは達成できます。
Most firewalls provide logging which can be tuned to make security administration of the network more convenient. Logging may be centralized and the system may be configured to send out alerts for abnormal conditions. It is important to regularly monitor these logs for any signs of intrusions or break-in attempts. Since some intruders will attempt to cover their tracks by editing logs, it is desirable to protect these logs. A variety of methods is available, including: write once, read many (WORM) drives; papers logs; and centralized logging via the "syslog" utility. Another technique is to use a "fake" serial printer, but have the serial port connected to an isolated machine or PC which keeps the logs.
ほとんどのファイアウォールがネットワークのセキュリティ管理をより便利にするように調整できる伐採を提供します。 伐採は集結されるかもしれません、そして、システムは、異常な状態のために警戒を出すために構成されるかもしれません。 定期的に侵入か不法侵入未遂のどんなサインのためのこれらのログもモニターするのは重要です。 何人かの侵入者が、ログを編集することによって証拠を隠すのを試みるので、これらのログを保護するのは望ましいです。 以下を含んでいて、さまざまなメソッドが利用可能です。 一度書いてください、そして、多くの(WORM)ドライブを読んでください。 書類ログ。 そして、"syslog"ユーティリティを通した集結された伐採。 別のテクニックが「にせ」のシリアルプリンタを使用することですが、ログを保つ孤立しているマシンかPCにシリアルポートを接続させてください。
Firewalls are available in a wide range of quality and strengths. Commercial packages start at approximately $10,000US and go up to over $250,000US. "Home grown" firewalls can be built for smaller amounts of capital. It should be remembered that the correct setup of a firewall (commercial or homegrown) requires a significant amount of skill and knowledge of TCP/IP. Both types require regular maintenance, installation of software patches and updates, and regular monitoring. When budgeting for a firewall, these additional costs should be considered in addition to the cost of the physical elements of the firewall.
ファイアウォールはさまざまな品質と強さで利用可能です。 コマーシャル・パッケージは、$およそ10,000USで始まって、$の上を250,000USに上がります。 よりわずかな量の首都で「育てられたホーム」ファイアウォールを建設できます。 ファイアウォール(商業の、または、国産の)の正しいセットアップがかなりの量の技能とTCP/IPに関する知識を必要とするのが覚えていられるべきです。 両方のタイプは定期補修、ソフトウェアパッチのインストール、アップデート、および定期的なモニターを必要とします。 ファイアウォールの予算を立てるとき、これらの別途費用はファイアウォールの物理的な原理の費用に加えて考えられるべきです。
Fraser, Ed. Informational [Page 23] RFC 2196 Site Security Handbook September 1997
フレーザ、[23ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
As an aside, building a "home grown" firewall requires a significant amount of skill and knowledge of TCP/IP. It should not be trivially attempted because a perceived sense of security is worse in the long run than knowing that there is no security. As with all security measures, it is important to decide on the threat, the value of the assets to be protected, and the costs to implement security.
余談として、「発展されたホーム」ファイアウォールを建設するのはかなりの量の技能とTCP/IPに関する知識を必要とします。 セキュリティが全くないのを知っているより知覚された安心感が結局悪いので、それを些細なことに試みるべきではありません。 すべての安全策のように、脅威、保護されるべき資産の価値、およびコストでセキュリティを実装すると決めるのは重要です。
A final note about firewalls. They can be a great aid when implementing security for a site and they protect against a large 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 against all types of attack.
ファイアウォールに関する最後通達。 サイトにセキュリティを実装するとき、それらはかなりの援助であるかもしれません、そして、彼らはさまざまな攻撃から守ります。 しかし、それらがソリューションの一部にすぎないことを覚えておくのは重要です。 彼らはすべてのタイプの攻撃に対してあなたのサイトを保護できません。
4. Security Services and Procedures
4. セキュリティー・サービスと手順
This chapter guides the reader through a number of topics that should be addressed when securing a site. Each section touches on a security service or capability that may be required to protect the information and systems at a site. The topics are presented at a fairly high-level to introduce the reader to the concepts.
本章はサイトを保証するとき扱われるべきである多くの話題を通して読者を案内します。 各セクションはサイトに情報とシステムを保護するのに必要であるかもしれないセキュリティー・サービスか能力に触れます。 話題は概念を読者に紹介するためにかなりハイレベルのaに提示されます。
Throughout the chapter, you will find significant mention of cryptography. It is outside the scope of this document to delve into details concerning cryptography, but the interested reader can obtain more information from books and articles listed in the reference section of this document.
章中では、あなたは暗号の重要な言及を見つけるでしょう。 暗号に関して詳細を調べるために、このドキュメントの範囲の外にそれはありますが、興味のある読者はこのドキュメントの参照部でリストアップされた本と記事から詳しい情報を得ることができます。
4.1 Authentication
4.1 認証
For many years, the prescribed method for authenticating users has been through the use of standard, reusable passwords. Originally, these passwords were used by users at terminals to authenticate themselves to a central computer. At the time, there were no networks (internally or externally), so the risk of disclosure of the clear text password was minimal. Today, systems are connected together through local networks, and these local networks are further connected together and to the Internet. Users are logging in from all over the globe; their reusable passwords are often transmitted across those same networks in clear text, ripe for anyone in-between to capture. And indeed, the CERT* Coordination Center and other response teams are seeing a tremendous number of incidents involving packet sniffers which are capturing the clear text passwords.
何年間も、ユーザを認証するための処方されたメソッドが標準の、そして、再利用できるパスワードの使用であります。 元々、これらのパスワードは、中央のコンピュータに自分たちを認証するのに端末のユーザによって使用されました。 当時、ネットワーク(内部的か外部的に)が全くなかったので、クリアテキストパスワードの公開のリスクは最小限でした。 今日、システムは企業内情報通信網を通して一緒に接続されます、そして、これらの企業内情報通信網はさらに一緒に、そして、インターネットに接続されます。 ユーザは世界中からログインしています。 それらの再使用可能パスワードは、クリアテキストのそれらの同じネットワークの向こう側にしばしば伝えられて、捕獲に中間である人はだれにとっても、熟しています。 本当に、そして、コーディネートセンターと他の応答が組にするCERT*は物凄い数のインシデントがクリアテキストパスワードを得ているパケットスニッファーにかかわっているのが見えています。
With the advent of newer technologies like one-time passwords (e.g., S/Key), PGP, and token-based authentication devices, people are using password-like strings as secret tokens and pins. If these secret tokens and pins are not properly selected and protected, the authentication will be easily subverted.
ワンタイムパスワード(例えば、S/キー)、PGP、およびトークンベースの認証デバイスのような、より新しい技術の到来で、人々は秘密のトークンとピンとしてパスワードのようなストリングを使用しています。 これらの秘密のトークンとピンが適切に選択されて、保護されないと、認証は容易に打倒されるでしょう。
Fraser, Ed. Informational [Page 24] RFC 2196 Site Security Handbook September 1997
フレーザ、[24ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
4.1.1 One-Time passwords
4.1.1 1回のパスワード
As mentioned above, given today's networked environments, it is recommended that sites concerned about the security and integrity of their systems and networks consider moving away from standard, reusable passwords. There have been many incidents involving Trojan network programs (e.g., telnet and rlogin) and network packet sniffing programs. These programs capture clear text hostname/account name/password triplets. Intruders can use the captured information for subsequent access to those hosts and accounts. This is possible because 1) the password is used over and over (hence the term "reusable"), and 2) the password passes across the network in clear text.
今日のネットワークでつながれた環境を考えて、以上のように、それらのシステムのセキュリティと保全に関して心配しているサイトとネットワークが、標準の、そして、再利用できるパスワードから遠くに移行すると考えるのは、お勧めです。 トロイの全国番組(例えば、telnetとrlogin)とネットワークパケットスニフィングプログラムにかかわる多くのインシデントがありました。これらのプログラムは、クリアテキストがホスト名/アカウント名/パスワード三つ子であるとキャプチャします。 侵入者はそれらのホストとアカウントへのその後のアクセスに捕らわれている情報を使用できます。 これが可能である、1) パスワードは再三(したがって、「再利用できる」という用語)使用されて、パスワードがネットワークの向こう側に通る2は)テキストをクリアします。
Several authentication techniques have been developed that address this problem. Among these techniques are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords). There are a number of products available that sites should consider using. The decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection.
このその問題を訴えるいくつかの認証技術が見いだされました。 このうち、テクニックは一度(一般的にワンタイムパスワードと呼ばれる)使用されるだけであるパスワードを提供するチャレンジレスポンス技術です。 サイトが使用すると考えるべきである利用可能な多くの製品があります。 製品を使用するという決定はそれぞれの組織の責任です、そして、各組織はそれ自身の評価と選択を実行するべきです。
4.1.2 Kerberos
4.1.2 ケルベロス
Kerberos is a distributed network security system which provides for authentication across unsecured networks. If requested by the application, integrity and encryption can also be provided. Kerberos was originally developed at the Massachusetts Institute of Technology (MIT) in the mid 1980s. There are two major releases of Kerberos, version 4 and 5, which are for practical purposes, incompatible.
ケルベロスは非機密保護しているネットワークの向こう側に認証に備える分配されたネットワークセキュリティシステムです。 また、アプリケーションで要求するなら、保全と暗号化を提供できます。 ケルベロスは1980年代の半ば元々、マサチューセッツ工科大学(MIT)で開発されました。 ケルベロスの2つの主要なリリース、両立しないバージョン4と5があります。(それは、実用的な目的のためのものです)。
Kerberos relies on a symmetric key database using a key distribution center (KDC) which is known as the Kerberos server. A user or service (known as "principals") are granted electronic "tickets" after properly communicating with the KDC. These tickets are used for authentication between principals. All tickets include a time stamp which limits the time period for which the ticket is valid. Therefore, Kerberos clients and server must have a secure time source, and be able to keep time accurately.
ケルベロスサーバとして知られている主要な配送センター(KDC)を使用することでケルベロスは対称鍵データベースに依存します。適切にKDCとコミュニケートした後に、ユーザかサービス(「主体」として、知られている)に電子「チケット」を与えます。 これらのチケットは主体の間の認証に使用されます。 すべてのチケットがチケットが有効である期間を制限するタイムスタンプを含んでいます。 したがって、ケルベロスクライアントとサーバは、安全な時間ソースがあって、正確に時間を保つことができなければなりません。
The practical side of Kerberos is its integration with the application level. Typical applications like FTP, telnet, POP, and NFS have been integrated with the Kerberos system. There are a variety of implementations which have varying levels of integration. Please see the Kerberos FAQ available at http://www.ov.com/misc/krb- faq.html for the latest information.
ケルベロスの実用的側面はアプリケーションレベルがあるその統合です。 FTP、telnet、POP、およびNFSのような主用途はケルベロスシステムについて統合しています。 異なったレベルの統合を持っているさまざまな実装があります。 ケルベロスFAQが http://www.ov.com/misc/krb- faq.htmlで最新情報に利用可能であることを見てください。
Fraser, Ed. Informational [Page 25] RFC 2196 Site Security Handbook September 1997
フレーザ、[25ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
4.1.3 Choosing and Protecting Secret Tokens and PINs
4.1.3 秘密のトークンと暗証番号を選んで、保護すること。
When selecting secret tokens, take care to choose them carefully. Like the selection of passwords, they should be robust against brute force efforts to guess them. That is, they should not be single words in any language, any common, industry, or cultural acronyms, etc. Ideally, they will be longer rather than shorter and consist of pass phrases that combine upper and lower case character, digits, and other characters.
秘密のトークンを選択するときには注意して、慎重にそれらを選んでください。 パスワードの品揃えのように、それらは、それらを推測するために力任せの取り組みに対して強健であるべきです。 すなわち、それらはどんな言語の一語、どんな一般的であるか、産業的、または、文化的な頭文字語であるべきではありませんなど。 理想的に、それらは、より短いというよりむしろより長く、大文字と小文字キャラクタを結合するパス句、ケタ、および他のキャラクタから成るでしょう。
Once chosen, the protection of these secret tokens is very important. Some are used as pins to hardware devices (like token cards) and 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 Pretty Good Privacy (PGP) key, should be protected from unauthorized access.
いったん選ばれていると、これらの秘密のトークンの保護は非常に重要です。 或るものは、ハードウェアデバイス(トークン・カードのような)へのピンとこれらを書き留めるべきでないように使用されるか、またはそれらが関連しているデバイスと同じ位置に置かれます。 秘密のプリティ・グッド・プライバシ(PGP)キーなどの他のものは不正アクセスから保護されるべきです。
One final word on this subject. When using cryptography products, like PGP, take care to determine the proper key length and ensure that your users are trained to do likewise. As technology advances, the minimum safe key length continues to grow. Make sure your site keeps up with the latest knowledge on the technology so that you can ensure that any cryptography in use is providing the protection you believe it is.
この問題に関する1つの最終的な単語。 暗号製品を使用するときにはPGPのように、注意して、適切なキー長を測定して、あなたのユーザが同様にそうするよう訓練されるのを保証してください。 最小の安全なキー長は、技術の進歩に伴って、成長し続けています。 サイトが使用中のどんな暗号もあなたがいるとそれに信じている保護を提供しているのを保証できるように技術に関する最新の知識について行くのを確実にしてください。
4.1.4 Password Assurance
4.1.4 パスワード保証
While the need to eliminate the use of standard, reusable passwords cannot be overstated, it is recognized that some organizations may still be using them. While it's recommended that these organizations transition to the use of better technology, in the mean time, we have the following advice to help with the selection and maintenance of traditional passwords. But remember, none of these measures provides protection against disclosure due to sniffer programs.
標準の、そして、再利用できるパスワードの使用を排除する必要性を誇張できませんが、いくつかの組織がまだそれらを使用しているかもしれないと認められます。 それが、より良い技術の使用へのこれらの組織変遷、その間に、私たちには伝統的なパスワードの選択とメインテナンスで助けるという以下のアドバイスがあることが勧められますが。 しかし、覚えていてください、そして、これらの測定のいずれもパケット盗聴プログラムプログラムによる公開に対する保護を提供しません。
(1) The importance of robust passwords - In many (if not most) cases
of system penetration, the intruder needs to gain access to an
account on the system. One way that goal is typically
accomplished is through guessing the password of a legitimate
user. This is often accomplished by running an automated
password cracking program, which utilizes a very large
dictionary, against the system's password file. The only way to
guard against passwords being disclosed in this manner is
through the careful selection of passwords which cannot be
easily guessed (i.e., combinations of numbers, letters, and
punctuation characters). Passwords should also be as long as
the system supports and users can tolerate.
(1) システム侵入の多くの最も)場合における、強健なパスワードの重要性、侵入者はシステムの上でアカウントへのアクセスを得る必要があります。 1つの方法で、目標が通常達成されるのが、正統のユーザのパスワードを推測することであります。 これは非常に大きい辞書を利用する自動化されたパスワード解析プログラムを動かすことによって、しばしば達成されます、システムのパスワードファイルに対して。 明らかにされるパスワードに用心する唯一の方法がこの様に容易に推測できないパスワード(すなわち、数、手紙、および句読文字の組み合わせ)の厳選であります。 また、パスワードもシステム支援とユーザが許容できるのと同じくらい長いはずです。
Fraser, Ed. Informational [Page 26] RFC 2196 Site Security Handbook September 1997
フレーザ、[26ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
(2) Changing default passwords - Many operating systems and
application programs are installed with default accounts and
passwords. These must be changed immediately to something that
cannot be guessed or cracked.
--(2) デフォルトパスワードを変えて、多くのオペレーティングシステムとアプリケーション・プログラムはデフォルトアカウントとパスワードでインストールされます。 これらはすぐ推測できないか、割ることができないことに変わらなければなりません。
(3) Restricting access to the password file - In particular, a site
wants to protect the encrypted password portion of the file so
that would-be intruders don't have them available for cracking.
One effective technique is to use shadow passwords where the
password field of the standard file contains a dummy or false
password. The file containing the legitimate passwords are
protected elsewhere on the system.
--(3) アクセスをパスワードファイルに制限して、特に、サイトがファイルの暗号化されたパスワード一部を保護したがっているので、不審な侵入者は彼らを分解に利用可能にしません。 1つの効果的なテクニックは標準ファイルのパスワード欄がダミーの、または、誤ったパスワードを含むシャドウパスワードを使用することです。 正統のパスワードを含むファイルはシステムの上のほかの場所に保護されます。
(4) Password aging - When and how to expire passwords is still a
subject of controversy among the security community. It is
generally accepted that a password should not be maintained once
an account is no longer in use, but it is hotly debated whether
a user should be forced to change a good password that's in
active use. The arguments for changing passwords relate to the
prevention of the continued use of penetrated accounts.
However, the opposition claims that frequent password changes
lead to users writing down their passwords in visible areas
(such as pasting them to a terminal), or to users selecting very
simple passwords that are easy to guess. It should also be
stated that an intruder will probably use a captured or guessed
password sooner rather than later, in which case password aging
provides little if any protection.
(4)パスワードの年をとること--いつ、それでも、パスワードを吐き出すのは、どう安全保障共同体の中の論争の対象であるか。 一般に、アカウントがいったんもう使用中にならないとパスワードを維持するべきではありませんが、熱心にユーザがやむを得ず能動的使用である良いパスワードを変えるべきであるかどうか討論すると受け入れます。 パスワードを変えるための議論は入り込まれたアカウントの継続的な使用の防止に関連します。 しかしながら、反対は、頻繁なパスワード変化が目に見える領域(それらを端末に貼ることなどの)、または、推測しやすい非常に簡単なパスワードを選択するユーザに彼らのパスワードを書き留めるユーザに通じると主張します。 また、侵入者が後でというよりむしろより早くたぶん捕らわれているか推測されたパスワードを使用すると述べられているべきであり、その場合、パスワードの年をとるのはまずの保護を前提とします。
While there is no definitive answer to this dilemma, a password
policy should directly address the issue and provide guidelines
for how often a user should change the password. Certainly, an
annual change in their password is usually not difficult for
most users, and you should consider requiring it. It is
recommended that passwords be changed at least whenever a
privileged account is compromised, there is a critical change in
personnel (especially if it is an administrator!), or when an
account has been compromised. In addition, if a privileged
account password is compromised, all passwords on the system
should be changed.
このジレンマのどんな決定的な答えもない間、パスワード方針は、ユーザがどれくらいの頻度でパスワードを変えるべきであるかに直接問題を扱って、ガイドラインを提供するべきです。 確かに、ほとんどのユーザには、通常、それらのパスワードにおける年変化は難しくはありません、そして、あなたはそれを必要とすると考えるべきです。 パスワードが変えて、特権があるアカウントが感染されるときはいつも、少なくとも、重要な変化が人員にあるという(特にそれが管理者であるなら!)ことであることが推薦されて、アカウントがいつ感染されたかをそうされます。 さらに、特権があるアカウントパスワードに感染するなら、システムに関するすべてのパスワードを変えるべきです。
(5) Password/account blocking - Some sites find it useful to disable
accounts after a predefined number of failed attempts to
authenticate. If your site decides to employ this mechanism, it
is recommended that the mechanism not "advertise" itself. After
(5)パスワード/アカウントブロッキング--いくつかのサイトによって、認証する事前に定義された数の未遂の後にアカウントを無効にするのが役に立つのがわかります。 あなたのサイトが、このメカニズムを使うと決めるなら、メカニズムがそれ自体の「広告を出さないこと」は、お勧めです。 後
Fraser, Ed. Informational [Page 27] RFC 2196 Site Security Handbook September 1997
フレーザ、[27ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
disabling, even if the correct password is presented, the
message displayed should remain that of a failed login attempt.
Implementing this mechanism will require that legitimate users
contact their system administrator to request that their account
be reactivated.
表示されたメッセージを正しいパスワードが提示されても無効にするのは失敗したログイン試みのもののままで残るべきです。 このメカニズムを実装するのは、正統のユーザが彼らのアカウントが現役に戻されるよう要求するために彼らのシステム管理者に連絡するのを必要とするでしょう。
(6) A word about the finger daemon - By default, the finger daemon
displays considerable system and user information. For example,
it can display a list of all users currently using a system, or
all the contents of a specific user's .plan file. This
information can be used by would-be intruders to identify
usernames and guess their passwords. It is recommended that
sites consider modifying finger to restrict the information
displayed.
(6)、指のデーモンに関する単語--デフォルトで、指のデーモンはかなりのシステムとユーザー情報を表示します。 例えば、それは、現在システム、または特定のユーザの.planファイルのすべてのコンテンツを使用することですべてのユーザのリストを表示できます。 不審な侵入者は、ユーザ名を特定して、それらのパスワードを推測するのにこの情報を使用できます。 サイトが、情報を制限するように指を変更するのが表示されていると考えるのは、お勧めです。
4.2 Confidentiality
4.2 秘密性
There will be information assets that your site will want to protect from disclosure to unauthorized entities. Operating systems often have built-in file protection mechanisms that allow an administrator to control who on the system can access, or "see," the contents of a given file. A stronger way to provide confidentiality is through encryption. Encryption is accomplished by scrambling data so that it is very difficult and time consuming for anyone other than the authorized recipients or owners to obtain the plain text. Authorized recipients and the owner of the information will possess the corresponding decryption keys that allow them to easily unscramble the text to a readable (clear text) form. We recommend that sites use encryption to provide confidentiality and protect valuable information.
あなたのサイトが公開から権限のない実体まで保護したくなる情報資産があるでしょう。 オペレーティングシステムには、管理者が、だれがシステムの上で与えられたファイルのコンテンツをアクセスするか、または「見ることができるか」を制御できる内蔵のファイル保護メカニズムがしばしばあります。 秘密性を提供するより強い方法が暗号化であります。 暗号化がデータにスクランブルをかけることによって実行されるので、認可された受取人か所有者以外のだれでもプレーンテキストを得るのは、非常に難しくて、時間がかかっています。 情報の認可された受取人と所有者はそれらが容易に読み込み可能な(クリアテキスト)フォームにテキストをもとに戻すことができる対応する復号化キーを所有するでしょう。 私たちは、サイトが秘密性を提供して、貴重な情報を保護するのに暗号化を使用することを勧めます。
The use of encryption is sometimes controlled by governmental and site regulations, so we encourage administrators to become informed of laws or policies that regulate its use before employing it. It is outside the scope of this document to discuss the various algorithms 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 easily broken. We also encourage everyone to take time to understand the strength of the encryption in any given algorithm/product before using it. Most well-known products are well-documented in the literature, so this should be a fairly easy task.
暗号化の使用が時々政府とサイト規則によって制御されるので、私たちは、管理者がそれを使う前に使用を規制する法か方針において知識があるようになるよう奨励します。 様々なアルゴリズムとこの目的に利用可能なプログラムについて議論するために、このドキュメントの範囲の外にそれはありますが、私たちは、UNIX地下室のカジュアルな使用に対して容易に壊されるのがわかったときプログラムを作るように警告します。 また、私たちは、皆がそれを使用する前にどんな与えられたアルゴリズム/製品の中の暗号化の強さを理解するために時間をかけるよう奨励します。 ほとんどのよく知られる製品が文学によく記録されているので、これはかなり簡単なタスクであるべきです。
4.3 Integrity
4.3 保全
As an administrator, you will want to make sure that information (e.g., operating system files, company data, etc.) has not been altered in an unauthorized fashion. This means you will want to provide some assurance as to the integrity of the information on your
管理者として、あなたは、情報(例えば、オペレーティングシステムファイル、社内資料など)が権限のないファッションで変更されていないのを確実にしたくなるでしょう。 これが、あなたが情報の保全に関して何らかの保証を提供したいために望んでいることを意味する、あなた
Fraser, Ed. Informational [Page 28] RFC 2196 Site Security Handbook September 1997
フレーザ、[28ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
systems. One way to provide this is to produce a checksum of the unaltered file, store that checksum offline, and periodically (or when desired) check to make sure the checksum of the online file hasn't changed (which would indicate the data has been modified).
システムこれを提供するOne方法は、非変更されたファイルのチェックサムを生産して、そのチェックサムをオフラインで保存して、オンライン・ファイルのチェックサムが変化していないのを(データが変更されたのを示すでしょう)確実にするために定期的にチェックする(望まれていると)ことです。
Some operating systems come with checksumming programs, such as the UNIX sum program. However, these may not provide the protection you 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 use a cryptographically strong program, such as the message digesting program MD5 [ref], to produce the checksums you will be using to assure integrity.
いくつかのオペレーティングシステムがUNIX合計プログラムなどのプログラムをchecksummingすると共に来ます。 しかしながら、これらはあなたが実際に必要とする保護を提供しないかもしれません。 ファイルをUNIX合計プログラムの結果を保存するほどそのような方法で変更できます! したがって、私たちは、あなたが暗号であなたが保全を保証するのに使用するチェックサムを生産するためにプログラムMD5[審判]を読みこなすメッセージとして強いプログラムで、あれほど状態でaを使用することを提案します。
There are other applications where integrity will need to be assured, such as when transmitting an email message between two parties. There are products available that can provide this capability. Once you identify that this is a capability you need, you can go about identifying technologies that will provide it.
他の利用が保全が保証される必要があるところにあります、メールメッセージを2の間に送るのがパーティーへ行く時のように。 この能力を提供できる利用可能な製品があります。 これがあなたが必要とする能力であることをいったん特定すると、あなたは、それを提供する技術を特定しながら、動き回ることができます。
4.4 Authorization
4.4 承認
Authorization refers to the process of granting privileges to processes and, ultimately, users. This differs from authentication in that authentication is the process used to identify a user. Once identified (reliably), the privileges, rights, property, and permissible actions of the user are determined by authorization.
承認はプロセスへの特権と結局ユーザを与えるプロセスについて言及します。 これは認証がユーザを特定するのに使用されるプロセスであるという点において認証と異なっています。 いったん特定されると(確かに)、ユーザの特権、権利、特性、および許されている動きは承認で決定します。
Explicitly listing the authorized activities of each user (and user process) with respect to all resources (objects) is impossible in a reasonable system. In a real system certain techniques are used to simplify the process of granting and checking authorization(s).
すべてのリソース(オブジェクト)に関して明らかにそれぞれのユーザ(そして、ユーザ・プロセス)の認可された活動を記載するのは妥当なシステムで不可能です。 実システムでは、あるテクニックは、承認を与えて、チェックするプロセスを簡素化するのに使用されます。
One approach, popularized in UNIX systems, is to assign to each object three classes of user: owner, group and world. The owner is either the creator of the object or the user assigned as owner by the super-user. The owner permissions (read, write and execute) apply only to the owner. A group is a collection of users which share access rights to an object. The group permissions (read, write and execute) apply to all users in the group (except the owner). The world refers to everybody else with access to the system. The world permissions (read, write and execute) apply to all users (except the owner and members of the group).
UNIXシステムに普及する1つのアプローチはユーザの3つのクラスを各オブジェクトに割り当てることです: 所有者、グループ、および世界。 所有者は、オブジェクトのクリエイターか所有者としてスーパーユーザによって選任されたユーザのどちらかです。 所有者許容(読んで、書いて、実行する)は所有者だけに適用されます。 グループはユーザの収集です(オブジェクトとアクセス権を共有します)。 グループ許容(読んで、書いて、実行する)はグループ(所有者を除いた)のすべてのユーザに適用されます。 世界はシステムへのアクセスで他の人皆について言及します。 世界許容(読んで、書いて、実行する)はすべてのユーザ(グループの所有者とメンバーを除いた)に適用されます。
Another approach is to attach to an object a list which explicitly contains the identity of all permitted users (or groups). This is an Access Control List (ACL). The advantage of ACLs are that they are
別のアプローチは明らかにユーザ(または、グループ)に受入れられたすべてのアイデンティティを含むリストをオブジェクトに添付することです。 これはAccess Control List(ACL)です。 ACLsの利点は彼らがそうであるということです。
Fraser, Ed. Informational [Page 29] RFC 2196 Site Security Handbook September 1997
フレーザ、[29ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
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 アクセス
4.5.1 Physical Access
4.5.1 物理的なアクセス
Restrict physical access to hosts, allowing access only to those people who are supposed to use the hosts. Hosts include "trusted" 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, especially those connected to your network. Make sure people's work areas mesh well with access restrictions; otherwise they will find ways to circumvent your physical security (e.g., jamming doors open).
ホストを使用するべきであるそれらの人々だけへのアクセスを許して、物理的なアクセスをホストに制限してください。 ホストは「信じられた」端末(特別なタスクに捧げられたすなわち、システム操作卓として非認証された使用にそのようなものを許容する端末、オペレータ端末、および端末)、個々のマイクロコンピュータ、およびワークステーション(特にあなたのネットワークに関連づけられたもの)を入れます。 人々の作業領域がアクセス制限とよく合うのを確実にしてください。 さもなければ、彼らはあなたの物理的なセキュリティを回避する方法を見つけるでしょう(例えばジャムドアは開きます)。
Keep original and backup copies of data and programs safe. Apart from keeping them in good condition for backup purposes, they must be 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 problems if one of your staff's portable computer is stolen. Consider developing guidelines for the kinds of data that should be 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 portable computer.
携帯用のホストは特定のリスクです。 あなたのスタッフのポータブル・コンピュータの1つが盗まれるとそれが問題を起こさないのを確実にしてください。 ポータブル・コンピュータにそれがあるときデータがどう保護されるべきであるか(例えば、暗号化)と同様にポータブル・コンピュータのディスクの上に住むことができるべきであるデータの種類でガイドラインを開発すると考えてください。
Other areas where physical access should be restricted is the wiring closets and important network elements like file servers, name server hosts, and routers.
物理的なアクセスが制限されているのが、配線クロゼットであるということであるべきである他の領域と重要なネットワーク要素はファイルサーバー、ネームサーバホスト、およびルータが好きです。
4.5.2 Walk-up Network Connections
4.5.2 ウォーカップのネットワーク接続
By "walk-up" connections, we mean network connection points located 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 that it allows any user to attach an unauthorized host to your network. This increases the risk of attacks via techniques such as
このサービスを提供するのが必要であるかどうか考えてください、どんなユーザもそれで権限のないホストをあなたのネットワークに付けることができるのを覚えておいて。 これはテクニックを通した攻撃の危険を増強します。
Fraser, Ed. Informational [Page 30] RFC 2196 Site Security Handbook September 1997
フレーザ、[30ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
IP address spoofing, packet sniffing, etc. Users and site management must appreciate the risks involved. If you decide to provide walk-up connections, plan the service carefully and define precisely where you will provide it so that you can ensure the necessary physical access security.
IPアドレススプーフィング、パケットスニフィングなど ユーザと会場設営はかかわった危険に感謝しなければなりません。 エレベーターのない建物の接続を提供すると決めるなら、慎重にサービスを計画してください、そして、必要な物理的なアクセス保護を確実にすることができるように正確にどこにそれを提供するかを定義してください。
A walk-up host should be authenticated before its user is permitted to access resources on your network. As an alternative, it may be possible to control physical access. For example, if the service is to be used by students, you might only provide walk-up connection sockets in student laboratories.
ユーザがあなたのネットワークに関するリソースにアクセスすることが許可されている前にエレベーターのない建物のホストは認証されるべきです。 代替手段として、物理的なアクセサリーを制御するのは可能であるかもしれません。 例えば、サービスが学生によって使用されるだけことであるなら、あなたはエレベーターのない建物の接続ソケットを学生実験室に供給するかもしれません。
If you are providing walk-up access for visitors to connect back to their home networks (e.g., to read e-mail, etc.) in your facility, 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 他のネットワーク技術
Technologies considered here include X.25, ISDN, SMDS, DDS and Frame Relay. All are provided via physical links which go through telephone exchanges, providing the potential for them to be diverted. Crackers are certainly interested in telephone switches as well as in data networks!
ここで考えられた技術はX.25、ISDN、SMDS、DDS、およびFrame Relayを含んでいます。 それらが紛らされる可能性を提供して、電話交換に直面している物理的なリンクを通してすべてを提供します。 確かに、クラッカーは電話スイッチとデータ網に興味を持っています!
With switched technologies, use Permanent Virtual Circuits or Closed User Groups whenever this is possible. Technologies which provide authentication and/or encryption (such as IPv6) are evolving rapidly; consider using them on links where security is important.
切り換えられた技術で、これが可能であるときはいつも、Permanent Virtual CircuitsかClosedユーザグループを使用してください。 認証、そして/または、暗号化(IPv6などの)を提供する技術は急速に発達することです。 セキュリティが重要であるリンクの上にそれらを使用すると考えてください。
4.5.4 Modems
4.5.4 モデム
4.5.4.1 Modem Lines Must Be Managed
4.5.4.1 モデム回線を管理しなければなりません。
Although they provide convenient access to a site for its users, they can also provide an effective detour around the site's firewalls. For this reason it is essential to maintain proper control of modems.
サイトへの便利なアクセスをユーザに提供しますが、また、彼らはサイトのファイアウォールの周りで有効な回り道を提供できます。 この理由で、モデムの適切なコントロールを維持するのは不可欠です。
Don't allow users to install a modem line without proper authorization. This includes temporary installations (e.g., plugging a modem into a facsimile or telephone line overnight).
ユーザに適切な承認なしでモデム回線をインストールさせないでください。 これは仮設物(例えば、夜通し、ファクシミリか電話回線にモデムのプラグを差し込む)を含んでいます。
Fraser, Ed. Informational [Page 31] RFC 2196 Site Security Handbook September 1997
フレーザ、[31ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
Maintain a register of all your modem lines and keep your register up 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 ダイヤルインのユーザを認証しなければなりません。
A username and password check should be completed before a user can access anything on your network. Normal password security considerations are particularly important (see section 4.1.1).
ユーザがあなたのネットワークで何にでもアクセスできる前にユーザ名とパスワードチェックは終了するべきです。 正常なパスワードセキュリティ問題は特に重要です(セクション4.1.1を見てください)。
Remember that telephone lines can be tapped, and that it is quite easy to intercept messages to cellular phones. Modern high-speed modems use more sophisticated modulation techniques, which makes them somewhat more difficult to monitor, but it is prudent to assume that hackers know how to eavesdrop on your lines. For this reason, you should use one-time passwords if at all possible.
電話回線を盗聴できて、携帯電話にメッセージを傍受するのがかなり簡単であることを覚えていてください。 近代的な高速モデムは、より精巧な変調のテクニックを使用しますが、(それらをモニターするのをいくらか難しくします)ハッカーがあなたの系列を立ち聞きする方法を知っていると仮定するのは慎重です。 できれば、この理由のために、あなたはワンタイムパスワードを使用するべきです。
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.
単一のダイヤルインのポイント(例えば、単一の大きいモデムプール)を持っているのが役立っているので、同様に、すべてのユーザが認証されます。
Users will occasionally mis-type a password. Set a short delay - say two seconds - after the first and second failed logins, and force a disconnect after the third. This will slow down automated password attacks. Don't tell the user whether the username, the password, or both, were incorrect.
ユーザは時折誤タイプにパスワードを望んでいます。 少し遅れを設定してください--1番目と秒が3日以降ログインに失敗して、分離を強制した後に2秒言ってください。 これは自動化されたパスワード攻撃を減速させるでしょう。 ユーザ名、パスワード、または両方が不正確であったかどうかユーザに言わないでください。
4.5.4.3 Call-back Capability
4.5.4.3 呼び戻し能力
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). Call-back is useful since if someone were to guess a username and password, they are disconnected, 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.
いくつかのダイヤルインサーバが呼び戻し施設を提供します。(すなわち、ユーザが直通電話にかけて、認証される、次に、システムが呼び出しから切断する、コールバックする、指定された数で) だれかがユーザ名とパスワードを推測するつもりであったなら、それら切断されて、次に、システムがパスワードが解読された実施している者をコールバックするので、呼び戻しは役に立ちます。 サーバからの乱呼出しはせいぜい疑わしげです。 これは、ユーザが1つの位置(サーバが彼らにダイヤルし返すために構成されるところ)からログインするだけであり、そこに関連している電話充電が呼び戻し位置であったならもちろんそこでそうするかもしれないことを意味します。
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
4.5.4.4 すべてのログインが登録されるべきです。
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
すべてがログインして、うまくいくか、または失敗していることにかかわらず登録されるべきです。 しかしながら、丸太のままで正しいパスワードを保たないでください。 むしろ、単にうまくいっているログイン試みるとしてそれらを登録してください。 ほとんどの無効なパスワードがそうであるので
Fraser, Ed. Informational [Page 32] RFC 2196 Site Security Handbook September 1997
フレーザ、[32ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
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.
認定ユーザによってmistypedされて、彼らは実際のパスワードからの単独のキャラクタで異なるだけです。 したがって、そのようなログを安全に保つことができないなら、それを全く登録しないでください。
If Calling Line Identification is available, take advantage of it by recording the calling number for each login attempt. Be sensitive to the privacy issues raised by Calling Line Identification. Also be aware that Calling Line Identification is not to be trusted (since 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.
Calling線Identificationが利用可能であるなら、それぞれのログイン試みの呼ぶ番号を記録することによって、それを利用してください。 Calling線Identificationによって提起されたプライバシーの問題に敏感にしてください。 また、Calling線Identificationを信じてはいけないのを(電話スイッチと前進の電話番号に侵入するか、または侵入者が他の変更を行うのが知られているので)意識してください。 認証に使用するのではなく、情報の目的だけにデータを使用してください。
4.5.4.5 Choose Your Opening Banner Carefully
4.5.4.5 慎重に初めのバナーを選んでください。
Many sites use a system default contained in a message of the day 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., University of XYZ, Student Records System). Instead, give your site name, a short warning that sessions may be monitored, and a username/password prompt. Verify possible legal issues related to the text you put into the banner.
短いバナーを表示しなさい、ただし、「誘っている」名前(例えば、XYZの大学、Student Records System)を提供しないでください。 代わりに、サイト名、セッションがモニターされるかもしれないという短い警告、およびユーザ名/パスワードを迅速に与えてください。 あなたがバナーに置くテキストに関連する可能な法律問題について確かめてください。
For high-security applications, consider using a "blind" password (i.e., give no response to an incoming call until the user has typed in a password). This effectively simulates a dead modem.
高セキュリティアプリケーションには、「盲目」のパスワードを使用すると考えてください(すなわち、かかってきた電話へのユーザがパスワードをタイプするまでの応答がいないでください)。 事実上、これは死んでいるモデムをシミュレートします。
4.5.4.6 Dial-out Authentication
4.5.4.6 ダイヤルアウト認証
Dial-out users should also be authenticated, particularly since your site will have to pay their telephone charges.
また、あなたのサイトが特に彼らの電話料を支払わなければならないので、ダイヤルアウトユーザは認証されるべきです。
Never allow dial-out from an unauthenticated dial-in call, and 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 chain of logins. This can be hard to detect, particularly if a 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 for both dial-in and dial-out. This can be implemented easily if you run separate dial-in and dial-out modem pools.
最小限では、同じモデム、両方にダイヤルインで使用されるべき電話回線、およびダイヤルアウトを許容しないでください。 あなたがダイヤルインとダイヤルアウトの別々のモデムプールを動かすなら、容易にこれを実装することができます。
Fraser, Ed. Informational [Page 33] RFC 2196 Site Security Handbook September 1997
フレーザ、[33ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
4.5.4.7 Make Your Modem Programming as "Bullet-proof" as Possible
4.5.4.7 モデムプログラミングをできるだけ「弾丸耐」であるのにしてください。
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 modems into command mode!
それらが使用中である間、モデムのプログラムを変えられることができないのを確認してください。 最小限では、3とサインがダイヤルインのモデムをコマンドモードに入れないのを確実にしてください!
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 each call. This precaution will protect you against accidental 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 from an access server, verify that the server hangs up the phone line properly. It is equally important that the server forces logouts from whatever sessions were active if the user hangs up unexpectedly.
モデムが清潔に呼び出しを終えるのをチェックしてください。 ユーザがアクセス・サーバーからログアウトするときには、サーバが適切に電話回線を掛けることを確かめてください。 サーバ力がいかなるユーザが不意にハングアップするなら活発であったセッションからもログアウトするのは、等しく重要です。
4.6 Auditing
4.6 監査
This section covers the procedures for collecting data generated by network activity, which may be useful in analyzing the security of a network and responding to security incidents.
このセクションはネットワークのセキュリティを分析して、セキュリティインシデントに応じる際に役に立つかもしれないネットワーク活動で生成された資料収集のために手順をカバーします。
4.6.1 What to Collect
4.6.1 集めるべきこと
Audit data should include any attempt to achieve a different security level by any person, process, or other entity in the network. This includes login and logout, super user access (or the non-UNIX equivalent), ticket generation (for Kerberos, for example), and any other change of access or status. It is especially important to note "anonymous" or "guest" access to public servers.
監査データはどんな人、プロセス、または他の実体でもネットワークで異なったセキュリティー・レベルを達成するどんな試みも含むべきです。 これはログインを含んでいます、そして、ログアウトしてください、スーパーユーザアクセス(または、非UNIX同等物)、チケット世代(例えばケルベロスのために)、そして、いかなる他のもアクセスか状態を変えます。 公開サーバへの「匿名」か「ゲスト」アクセスに注意するのは特に重要です。
The actual data to collect will differ for different sites and for different types of access changes within a site. In general, the information you want to collect includes: username and hostname, for login and logout; previous and new access rights, for a change of access rights; and a timestamp. Of course, there is much more information which might be gathered, depending on what the system makes available and how much space is available to store that information.
集める実際のデータは異なったサイトとアクセス変化の異なったタイプのためにサイトの中で異なるでしょう。 一般に、あなたが集めたい情報は: そして、ユーザ名とログインのためのホスト名、ログアウトしてください。 aがアクセス権を変えるので前の、そして、新しいアクセス権 そして、タイムスタンプ。 もちろん、集められるかもしれない多くの詳しい情報があります、システムで何が利用可能になるか、そして、どのくらいのスペースがその情報を保存するために利用可能であるかよって。
One very important note: do not gather passwords. This creates an enormous potential security breach if the audit records should be improperly accessed. Do not gather incorrect passwords either, as they often differ from valid passwords by only a single character or transposition.
1つの非常に重要な注意: パスワードを集めないでください。 監査記録が不適切にアクセスされるなら、これは莫大な潜在的機密保護違反を作成します。 単独のキャラクタか転置だけで有効なパスワードとしばしば異なっているとき、間違ったパスワードを集めないでください。
Fraser, Ed. Informational [Page 34] RFC 2196 Site Security Handbook September 1997
フレーザ、[34ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
4.6.2 Collection Process
4.6.2 収集プロセス
The collection process should be enacted by the host or resource being accessed. Depending on the importance of the data and the need to have it local in instances in which services are being denied, data could be kept local to the resource until needed or be transmitted to storage after each event.
アクセスされていて、収集プロセスはホストかリソースによって制定されるべきです。 サービスが否定されているデータの重要性とそれをインスタンスで地方にする必要性によって、データを必要になるまでリソースに地方に保ったか、または各イベントの後にストレージに送ることができました。
There are basically three ways to store audit records: in a read/write file on a host, on a write-once/read-many device (e.g., a CD-ROM or a specially configured tape drive), or on a write-only device (e.g., a line printer). Each method has advantages and disadvantages.
基本的に、監査記録を保存する3つの方法があります: ホスト、-一度書いている/多くを読んでいるデバイス(例えば、CD-ROMか特に、構成されたテープドライブ)、またはaのファイルをaに、読み込むか、または書いてください、書く、-単に、デバイス(例えば、ラインプリンタ)。 各メソッドには、利点と損失があります。
File system logging is the least resource intensive of the three methods and the easiest to configure. It allows instant access to the records for analysis, which may be important if an attack is in progress. File system logging is also the least reliable method. If the logging host has been compromised, the file system is usually the first thing to go; an intruder could easily cover up traces of the intrusion.
ファイルシステム伐採は、3つのメソッドで徹底的な最少のリソースと構成する中で最も簡単なものです。 それは攻撃が進行しているなら重要であるかもしれない分析のための記録への即時のアクセスを許します。 また、ファイルシステム伐採は最少の確かな方法です。 伐採ホストが感染されたなら、通常、ファイルシステムは行く最初のものです。 侵入者は容易に侵入の跡を隠すことができました。
Collecting audit data on a write-once device is slightly more effort to configure than a simple file, but it has the significant advantage of greatly increased security because an intruder could not alter the data showing that an intrusion has occurred. The disadvantage of this method is the need to maintain a supply of storage media and the cost of that media. Also, the data may not be instantly available.
監査データを-一度書いているデバイスに集めるのは、簡単なファイルより構成するわずかに多くの取り組みですが、それには、侵入者が侵入が起こったのを示すデータを変更できなかったので、大いに増強されたセキュリティの重要な利点があります。 このメソッドの不都合は記憶媒体の供給を維持する必要性であり、その費用はメディアです。 また、即座に、データを得ることができないかもしれません。
Line printer logging is useful in system where permanent and immediate logs are required. A real time system is an example of this, where the exact point of a failure or attack must be recorded. A laser printer, or other device which buffers data (e.g., a print server), may suffer from lost data if buffers contain the needed data at a critical instant. The disadvantage of, literally, "paper trails" is the need to keep the printer fed and the need to scan records by hand. There is also the issue of where to store the, potentially, enormous volume of paper which may be generated.
ラインプリンタ伐採は永久的で即座のログが必要であるシステムで役に立ちます。 リアルタイムシステムはこの例です。(そこでは、失敗か攻撃の正確なポイントを記録しなければなりません)。 バッファが重要な瞬間に必要なデータを含むなら、データ(例えば、プリント・サーバ)をバッファリングするレーザープリンタ、または対向機器がロストデータが欠点であるかもしれません。 不都合である、「ペーパートレール」は、文字通り、与えられたプリンタを保つ必要性と手で記録をスキャンする必要性です。 また、どこに作られるかもしれない紙の潜在的に莫大なボリュームを保存するかに関する問題があります。
For each of the logging methods described, there is also the issue of securing the path between the device generating the log and actual logging device (i.e., the file server, tape/CD-ROM drive, printer). If that path is compromised, logging can be stopped or spoofed or both. In an ideal world, the logging device would be directly
それぞれの伐採メソッドのために、説明されていて、また、デバイス(すなわち、ファイルサーバー、テープ/CD-ROM装置、プリンタ)をデバイスの生成することのログの、そして、実際の伐採の間の経路に固定する問題があります。 その経路は感染されて、伐採を止まるか、または偽造することができるということであるか、そして、両方。 理想の世界では、伐採デバイスが直接そうでしょう。
Fraser, Ed. Informational [Page 35] RFC 2196 Site Security Handbook September 1997
フレーザ、[35ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
attached by a single, simple, point-to-point cable. Since that is usually impractical, the path should pass through the minimum number of networks and routers. Even if logs can be blocked, spoofing can be prevented with cryptographic checksums (it probably isn't necessary to encrypt the logs because they should not contain sensitive information in the first place).
単一の、そして、簡単で、二地点間のケーブルで、付きました。 それが通常非実用的であるので、経路はネットワークとルータの最小の数を通り抜けるべきです。 ログを妨げることができても、暗号のチェックサムでスプーフィングを防ぐことができます(第一に機密情報を含むべきでないので、ログを暗号化するのはたぶん必要ではありません)。
4.6.3 Collection Load
4.6.3 収集負荷
Collecting audit data may result in a rapid accumulation of bytes so storage availability for this information must be considered in advance. There are a few ways to reduce the required storage space. First, data can be compressed, using one of many methods. Or, the required space can be minimized by keeping data for a shorter period of time with only summaries of that data kept in long-term archives. One major drawback to the latter method involves incident response. Often, an incident has been ongoing for some period of time when a site notices it and begins to investigate. At that point in time, it's very helpful to have detailed audit logs available. If these are just summaries, there may not be sufficient detail to fully handle the incident.
監査データを集めるとバイトの急速な蓄積がもたらされるかもしれないので、あらかじめ、この情報のためのストレージの有用性を考えなければなりません。 必要な集積スペースを減少させるいくつかの方法があります。 まず最初に、多くのメソッドの1つを使用して、データを圧縮できます。 または、長期のアーカイブに概要だけがある、より短い期間の間のそのデータに関するデータを保ち続けることによって、必要なスペースを最小にすることができます。 後者のメソッドへの1つの主要な欠点がインシデントレスポンスにかかわります。 サイトがそれに気付いて、調査し始めるとき、しばしば、インシデントはいつかの期間の間、進行中です。 その時、時間では、利用可能な精査ログを持っているのは非常に役立っています。 これらがただ概要であるなら、インシデントを完全に扱うことができるくらいの詳細がないかもしれません。
4.6.4 Handling and Preserving Audit Data
4.6.4 取り扱いと監査データを保存すること。
Audit data should be some of the most carefully secured data at the site and in the backups. If an intruder were to gain access to audit logs, the systems themselves, in addition to the data, would be at risk.
監査データはサイトにおけるバックアップの最も慎重に機密保護しているデータのいくつかであるべきです。 侵入者がログを監査するためにアクセスを得るなら、データに加えて、システム自体は危険でしょうに。
Audit data may also become key to the investigation, apprehension, and prosecution of the perpetrator of an incident. For this reason, it is advisable to seek the advice of legal council when deciding how audit data should be treated. This should happen before an incident occurs.
また、監査データはインシデントの加害者の調査、憂慮、および起訴に主要になるかもしれません。 この理由で、監査データがどう扱われるべきであるかを決めるときの法的な協議会のアドバイスを求めるのは賢明です。 インシデントが起こる前にこれは起こるべきです。
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 an event, and it may create liability resulting from improper treatment of the data.
データハンドリングプランがインシデントの前で適切に定義されないなら、イベントの余波には償還請求が全くないことを意味するかもしれません、そして、データの不適当な処理から生じる責任を作成するかもしれません。
4.6.5 Legal Considerations
4.6.5 法的な問題
Due to the content of audit data, there are a number of 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 for consequences resulting both from its existence and its content.
監査データの内容のために、あなたの弁護士によって扱われる必要があるかもしれない起こる多くの法律問題があります。 監査データを集めて、保存するなら、あなたは、ともに存在とその内容から生じる結果のために準備される必要があります。
Fraser, Ed. Informational [Page 36] RFC 2196 Site Security Handbook September 1997
フレーザ、[36ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
One area concerns the privacy of individuals. In certain instances, audit data may contain personal information. Searching through the data, even for a routine check of the system's security, could represent an invasion of privacy.
1つの領域が個人のプライバシーに関係があります。 あるインスタンスでは、監査データは個人情報を含むかもしれません。 データを隅々まで捜すと、システムのセキュリティの通常の小切手のためにさえ、プライバシー侵害は表されるかもしれません。
A second area of concern involves knowledge of intrusive behavior originating from your site. If an organization keeps audit data, is it responsible for examining it to search for incidents? If a host in one organization is used as a launching point for an attack against another organization, can the second organization use the audit data of the first organization to prove negligence on the part of that organization?
2番目の気になる所はあなたのサイトから発する押し付けがましい態度に関する知識にかかわります。 組織が監査データを保つなら、インシデントを捜し求めるのはそれを調べるのに責任がありますか? 1つの組織のホストが攻撃に発射ポイントとして別の組織に対して使用されるなら、2番目の組織はその組織側の怠慢を立証する最初の組織に関する監査データを使用できますか?
The above examples are meant to be comprehensive, but should motivate your organization to consider the legal issues involved with audit data.
上記の例は、包括的であることが意味されますが、監査データにかかわる法律問題を考えるためにあなたの組織を動機づけるべきです。
4.7 Securing Backups
4.7 バックアップを固定すること。
The procedure of creating backups is a classic part of operating a computer system. Within the context of this document, backups are addressed as part of the overall security plan of a site. There are several aspects to backups that are important within this context:
バックアップを創造する手順はコンピュータ・システムを操作する古典的な部分です。 このドキュメントの文脈の中では、バックアップはサイトの総合的な警備計画の一部として宛てられます。 この文脈の中で重要なバックアップへのいくつかの局面があります:
(1) Make sure your site is creating backups
(2) Make sure your site is using offsite storage for backups. The
storage site should be carefully selected for both its security
and its availability.
(3) Consider encrypting your backups to provide additional protection
of the information once it is off-site. However, be aware that
you will need a good key management scheme so that you'll be
able to recover data at any point in the future. Also, make
sure you will have access to the necessary decryption programs
at such time in the future as you need to perform the
decryption.
(4) Don't always assume that your backups are good. There have been
many instances of computer security incidents that have gone on
for long periods of time before a site has noticed the incident.
In such cases, backups of the affected systems are also tainted.
(5) Periodically verify the correctness and completeness of your
backups.
(1) サイトがバックアップ(2)があなたのサイトがバックアップにオフサイトストレージを使用しているのを確信するようにする作成であることを確実にしてください。 置き場はセキュリティとその有用性の両方のために慎重に選択されるべきです。 (3) いったんオフサイトになったあとに情報の追加保護を提供するためにバックアップを暗号化すると考えてください。 しかしながら、将来任意な点でデータを回復できるように良いかぎ管理体系を必要とするのを意識してください。 また、未来の復号化を実行するのが必要であるような時に必要な復号化プログラムに必ず近づく手段を持ってくださいだろう。 (4) いつもバックアップが良いと仮定しないでください。 サイトがインシデントに気付く前に長期間の間に先へ進んでいるコンピュータセキュリティインシデントの多くのインスタンスがありました。 また、そのような場合、影響を受けるシステムのバックアップは汚れます。 (5) 定期的にバックアップの正当性と完全性について確かめてください。
5. Security Incident Handling
5. セキュリティインシデント取り扱い
This chapter of the document will supply guidance to be used before, during, and after a computer security incident occurs on a host, network, site, or multi-site environment. The operative philosophy in the event of a breach of computer security is to react according
コンピュータセキュリティインシデントの前、およびコンピュータセキュリティインシデントとコンピュータセキュリティインシデントの後に使用されるべきドキュメント意志の供給指導の本章はホスト(ネットワーク、サイト、またはマルチサイト環境)の上に起こります。 工員哲学がコンピュータセキュリティの不履行の場合、反応することになっている
Fraser, Ed. Informational [Page 37] RFC 2196 Site Security Handbook September 1997
フレーザ、[37ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
to a plan. This is true whether the breach is the result of an external intruder attack, unintentional damage, a student testing some new program to exploit a software vulnerability, or a disgruntled employee. Each of the possible types of events, such as those just listed, should be addressed in advance by adequate contingency plans.
プランに。 これは不履行が外部の侵入者攻撃、意図的でない損害、ソフトウェア脆弱性を利用するために何らかの新プログラムをテストする学生、または不満を抱いた従業員の結果であるか否かに関係なく、本当です。 それぞれの可能なタイプのただ記載されたものなどのイベントはあらかじめ、適切な緊急時対策によって扱われるべきです。
Traditional computer security, while quite important in the overall site security plan, usually pays little attention to how to actually 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 to tracking down the source of the incident, collecting evidence to be used in prosecution efforts, preparing for the recovery of the system, and protecting the valuable data contained on the system.
総合的なサイト警備計画でかなり重要ですが、通常、伝統的なコンピュータセキュリティは少ししか1つがいったん起こると実際にどう攻撃を扱うかに注意を向けません。 結果は、攻撃が進行しているとき、急いで多くの決定をするということであり、インシデントの源を捜し出すのにダメージが大きい場合があります、起訴取り組みに使用されるために証拠固めて、システムの回復の用意をして、システムの上に含まれた貴重な資料を保護して。
One of the most important, but often overlooked, benefits for efficient incident handling is an economic one. Having both technical and managerial personnel respond to an incident requires considerable resources. If trained to handle incidents efficiently, less staff time is required when one occurs.
効率的な付随している取り扱いのための最も重要な、しかし、しばしば見落とされた利益の1つは経済ものです。 技術的で経営者の両方の人員にインシデントに応じさせるのがかなりのリソースを必要とします。 1つが起こるとき、効率的にインシデントを扱うよう訓練されるなら、より少ないスタッフ時間が必要です。
Due to the world-wide network most incidents are not restricted to a single site. Operating systems vulnerabilities apply (in some cases) to several millions of systems, and many vulnerabilities are exploited within the network itself. Therefore, it is vital that all sites with involved parties be informed as soon as possible.
世界的なネットワークのため、ほとんどのインシデントはただ一つのサイトに制限されません。 オペレーティングシステム脆弱性は(いくつかの場合)システムの数個の数百万に適用されます、そして、多くの脆弱性がネットワーク自体の中で利用されます。 したがって、関係者に伴うすべてのサイトができるだけ早く知識があるのは、重大です。
Another benefit is related to public relations. News about computer security incidents tends to be damaging to an organization's stature among current or potential clients. Efficient incident handling minimizes the potential for negative exposure.
別の利益は広報に関連します。 コンピュータセキュリティインシデントに関するニュースは、現在の、または、潜在的のクライアントの中で組織の身長にダメージが大きい傾向があります。 効率的な付随している取り扱いは否定的暴露の可能性を最小にします。
A final benefit of efficient incident handling is related to legal issues. It is possible that in the near future organizations may be held responsible because one of their nodes was used to launch a network attack. In a similar vein, people who develop patches or workarounds may be sued if the patches or workarounds are ineffective, resulting in compromise of the systems, or, if the patches or workarounds themselves damage systems. Knowing about operating system vulnerabilities and patterns of attacks, and then taking appropriate measures to counter these potential threats, is critical to circumventing possible legal problems.
効率的な付随している取り扱いの最終的な恩恵は法律問題に関連します。 彼らのノードの1つがネットワーク攻撃に着手するのに使用されたので近い将来の組織におけるそれが責任を負わせられるのは、可能です。 似たような仕方で、パッチか回避策が効力がないなら、パッチか回避策を開発する人々は訴えられるかもしれません、または、パッチか回避策自体がシステムオペレーティングシステム脆弱性に関して知っていることを破損して、攻撃のパターンと、次に、これらの潜在的な脅威に対抗する穏当な処置を取るのが可能な法律問題を回避するのに重要であるならシステムの感染をもたらして。
Fraser, Ed. Informational [Page 38] RFC 2196 Site Security Handbook September 1997
フレーザ、[38ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
The sections in this chapter provide an outline and starting point for creating your site's policy for handling security incidents. The sections are:
本章のセクションは取り扱いセキュリティインシデントのためのあなたのサイトの方針を作成するためのアウトラインと出発点を提供します。 セクションは以下の通りです。
(1) Preparing and planning (what are the goals and objectives in
handling an incident).
(2) Notification (who should be contacted in the case of an
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).
- Notification (who should be notified about the incident)
- Protecting evidence and activity logs (what records should be
kept from before, during, and after the incident)
- Containment (how can the damage be limited)
- Eradication (how to eliminate the reasons for the incident)
- Recovery (how to reestablish service and systems)
- Follow Up (what actions should be taken after the incident)
(5) Aftermath (what are the implications of past incidents).
(6) Administrative response to incidents.
(1) (インシデントを扱うことにおいて目標と目的であること)を準備して、計画していること。 (2) 通知(インシデントの場合で連絡するべきです)。 - 地元のマネージャと人員--法施行と調査の政府機関(チームを扱うコンピュータセキュリティインシデント)は、インシデントを特定しながら、サイト--内部のコミュニケーション--広報とプレスリリース(3)に影響して、かかわりました(それはインシデントです、そして、どれくらい重大であるかは、それです)。 (4) (インシデントが起こるとするべきであること)を扱います。 - 通知(インシデントに関して通知されるべきである)--証拠と活動記録(記録がインシデントの前、およびインシデントとインシデントの後に妨げられるべきである何)を保護するか--封じ込め、(どうしたら損害を制限できるか、)、--根絶(どうインシデントの理由を排除するか)(回復(サービスとシステムをどう回復させる))は(5) 余波(過去のインシデントの含意であること)を追求します(動作はインシデントの後に取られたものであるべきです)。 (6) インシデントへの管理応答。
The remainder of this chapter will detail the issues involved in each of the important topics listed above, and provide some guidance as to what should be included in a site policy for handling incidents.
本章の残りは、上に記載されたそれぞれの重要な話題にかかわる問題を詳しく述べて、取り扱いインシデントのためのサイト方針に含まれるべきであることに関して何らかの指導を提供するでしょう。
5.1 Preparing and Planning for Incident Handling
5.1 付随している取り扱いを準備して、計画を立てること。
Part of handling an incident is being prepared to respond to an incident before the incident occurs in the first place. This includes establishing a suitable level of protections as explained in the preceding chapters. Doing this should help your site prevent incidents as well as limit potential damage resulting from them when they do occur. Protection also includes preparing incident handling guidelines as part of a contingency plan for your organization or site. Having written plans eliminates much of the ambiguity which occurs during an incident, and will lead to a more appropriate and thorough set of responses. It is vitally important to test the proposed plan before an incident occurs through "dry runs". A team might even consider hiring a tiger team to act in parallel with the dry run. (Note: a tiger team is a team of specialists that try to penetrate the security of a system.)
インシデントを扱う一部がインシデントが第一に起こる前にインシデントに応じるように準備されています。 これは、先の章で説明されるように適当なレベルの保護を確立するのを含んでいます。 これをするのは、あなたのサイトが起こるときそれらから生じる限界可能性のあるダメージと同様にインシデントを防ぐのを助けるべきです。 また、保護は、あなたの組織かサイトのために緊急時対策の一部として付随している取り扱いガイドラインを準備するのを含んでいます。 企画書を持っているのは、インシデントの間に起こるあいまいさの多くを排除して、より適切で徹底的な応答に通じるでしょう。 インシデントが「模擬試験」を通して起こる前に計画案をテストするのはきわめて重要です。 チームは、模擬試験と平行して行動するために虎のチームを雇うと考えさえするかもしれません。 (注意: 虎のチームはシステムのセキュリティに入り込もうとする専門家のチームです。)
Fraser, Ed. Informational [Page 39] RFC 2196 Site Security Handbook September 1997
フレーザ、[39ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
Learning to respond efficiently to an incident is important for a number of reasons:
効率的にインシデントに応じることを学ぶのは様々な意味で重要です:
(1) Protecting the assets which could be compromised
(2) Protecting resources which could be utilized more
profitably if an incident did not require their services
(3) Complying with (government or other) regulations
(4) Preventing the use of your systems in attacks against other
systems (which could cause you to incur legal liability)
(5) Minimizing the potential for negative exposure
(1) インシデントが他のシステム(あなたに法的責任を被らせることができた)に対して攻撃におけるあなたのシステムの使用を防ぎながら規則(4)に従いながら(何らかの政府)彼らのサービス(3)を必要としないなら(5) 否定的暴露の可能性を最小にしながら、より有益に利用できるリソースを保護しながら(2)であると感染することができた資産を保護すること。
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 prioritized differently depending on the site. A specific set of objectives can be identified for dealing with incidents:
どんなセットのあらかじめ計画された手順のようにも、インシデントを扱うために1セットの目標に注意を向けなければなりません。 サイトに異なってよって、これらの目標は最優先するでしょう。 インシデントに対処するために特定のセットの目的を特定できます:
(1) Figure out how it happened.
(2) Find out how to avoid further exploitation of the same
vulnerability.
(3) Avoid escalation and further incidents.
(4) Assess the impact and damage of the incident.
(5) Recover from the incident.
(6) Update policies and procedures as needed.
(7) Find out who did it (if appropriate and possible).
(1) それがどのように起こったか理解してください。 (2) 同じ脆弱性のさらなる攻略を避ける方法を調べてください。 (3) 増大と一層のインシデントを避けてください。 (4) インシデントの影響と損害を査定してください。 (5) インシデントから、回復してください。 (6) 必要に応じて方針と手順をアップデートしてください。 (7) だれがそれをしたか調べてください(適切であって、可能であるなら)。
Due to the nature of the incident, there might be a conflict between analyzing the original source of a problem and restoring systems and services. Overall goals (like assuring the integrity of critical systems) might be the reason for not analyzing an incident. Of course, this is an important management decision; but all involved parties must be aware that without analysis the same incident may happen again.
インシデントの自然のために、問題の一次資料を分析して、システムとサービスを復旧するとき、闘争があるかもしれません。 全体的な目的(保全にクリティカル・システムを保証するような)はインシデントを分析しない理由であるかもしれません。 もちろん、これは重要な経営上の決定です。 しかし、すべての関係者が分析がなければ、同じインシデントが再び起こるかもしれないのを意識しているに違いありません。
It is also important to prioritize the actions to be taken during an incident well in advance of the time an incident occurs. Sometimes an incident may be so complex that it is impossible to do everything at once to respond to it; priorities are essential. Although priorities will vary from institution to institution, the following suggested priorities may serve as a starting point for defining your organization's response:
また、インシデントが起こる時代のよく前にインシデントの間、取るために動作を最優先させるのも重要です。 時々、インシデントが非常に複雑であるかもしれないので、すぐにそれに応じるためにすべてをするのは不可能です。 プライオリティは不可欠です。 団体によってプライオリティは異なるでしょうが、以下の提案されたプライオリティはあなたの組織の応答を定義するための出発点として機能するかもしれません:
(1) Priority one -- protect human life and people's
safety; human life always has precedence over all
other considerations.
(1)優先権1--人間の寿命と人々の安全を保護してください。 人間の寿命には、他のすべての問題の上の先行がいつもあります。
(2) Priority two -- protect classified and/or sensitive
data. Prevent exploitation of classified and/or
sensitive systems, networks or sites. Inform affected
(2)優先権two--分類されたそして/または、機密のデータを保護してください。 分類されたそして/または、敏感なシステム、ネットワークまたはサイトの攻略を防いでください。 影響を受けた状態で、知らせてください。
Fraser, Ed. Informational [Page 40] RFC 2196 Site Security Handbook September 1997
フレーザ、[40ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
classified and/or sensitive systems, networks or sites
about already occurred penetrations.
(Be aware of regulations by your site or by government)
分類されたそして/または、敏感なシステム、ネットワークまたはサイトがおよそ既に現れました。ペネトレーション。 (あなたのサイトか政府は規則を意識しています)
(3) Priority three -- protect other data, including
proprietary, scientific, managerial and other data,
because loss of data is costly in terms of resources.
Prevent exploitations of other systems, networks or
sites and inform already affected systems, networks or
sites about successful penetrations.
(3)優先権three--他のデータを保護してください、独占で、科学的で、経営者の、そして、他のデータを含んでいて、データの喪失がリソースで高価であるので。 他のシステム、ネットワークまたはサイトの攻略を防いでください、そして、うまくいっているペネトレーションに関する既に影響を受けるシステム、ネットワークまたはサイトを知らせてください。
(4) Priority four -- prevent damage to systems (e.g., loss
or alteration of system files, damage to disk drives,
etc.). Damage to systems can result in costly down
time and recovery.
(4)優先権four--システム(例えば、損失やシステムファイルの変更、ディスクドライブへの損傷など)への損傷を防いでください。 システムへの損傷は高価な休止時間と回復をもたらすことができます。
(5) Priority five -- minimize disruption of computing
resources (including processes). It is better in many
cases to shut a system down or disconnect from a network
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.
(5)優先権five--コンピューティング資源の分裂を最小にしてください(プロセスを含んでいて)。 多くの場合、システムダウンを閉じるか、またはネットワークから切断するのがデータかシステムへの損傷の危険を冒すより良いです。サイトは停止して、切断して、寝ずに起きていることの間のトレードオフを評価しなければならないでしょう。 さらなる損害の観点からさえ上がっているシステムを現れさせ続けるのを必要とするかもしれない適所にあるサービス契約があるかもしれません。 しかしながら、インシデントの損害と範囲はサービス契約がくつがえされなければならないかもしれないほど大規模であるかもしれません。
An important implication for defining priorities is that once human life and national security considerations have been addressed, it is generally more important to save data than system software and hardware. Although it is undesirable to have any damage or loss during an incident, systems can be replaced. However, the loss or compromise of data (especially classified or proprietary data) is usually not an acceptable outcome under any circumstances.
プライオリティを定義するための重要な含意は人間の寿命と国家安全保障問題がいったん扱われると、一般に、データを保存するのがシステムソフトとハードウェアより重要であるということです。 インシデントの間、どんな損害や損失も持っているのが望ましくないのですが、システムを取り替えることができます。 しかしながら、通常、データ(特に分類されたか独占であるデータ)の損失か感染がどうあっても許容できる結果ではありません。
Another important concern is the effect on others, beyond the systems and networks where the incident occurs. Within the limits imposed by government regulations it is always important to inform affected parties as soon as possible. Due to the legal implications of this topic, it should be included in the planned procedures to avoid further delays and uncertainties for the administrators.
別の重要な関心はインシデントが起こるシステムとネットワークを超えた他のものへの効果です。 中では、知らせるのがいつも重要である政府規制によって課された限界ができるだけ早く、パーティーに影響しました。 この話題の法的な含意のため、それは、管理者のためにさらなる遅れと不明確なことを避けるために計画された手順に含まれるべきです。
Any plan for responding to security incidents should be guided by local policies and regulations. Government and private sites that deal with classified material have specific rules that they must follow.
セキュリティインシデントに応じるためのどんなプランもローカルの方針と規則によって誘導されるべきです。 機密事項に対処する政府と個人的なサイトが続かなければならないという特定の規則を持っています。
Fraser, Ed. Informational [Page 41] RFC 2196 Site Security Handbook September 1997
フレーザ、[41ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
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 mechanisms to monitor and trace intruders if your site does not plan to take action against the intruders if they are caught. Other organizations may have policies that affect your plans. Telephone companies often release information about telephone traces only to 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.
取り扱いインシデントは、退屈であり、援助要員が扱うことができたいろいろな通常のタスクを必要とすることができます。 特定するのが役立つかもしれない技術スタッフを解放するために、タスクで助ける補助スタッフは以下が好きです。 写真複写、fax'ingなど
5.2 Notification and Points of Contact
5.2 通知と連絡先
It is important to establish contacts with various personnel before a real incident occurs. Many times, incidents are not real emergencies. Indeed, often you will be able to handle the activities internally. However, there will also be many times when others outside your immediate department will need to be included in the 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.
本当のインシデントが起こる前に様々な人員と共に接触するのは重要です。 何回も、インシデントは本当の非常時ではありません。 本当に、しばしば、あなたは内部的に活動を扱うことができるでしょう。 しかしながら、また、あなたの即座の部の外の他のものが付随している取り扱いに含まれる必要がある何回もあるでしょう。 これらの追加接触は地元のマネージャとシステム管理者(インターネットの、そして、様々な捜査機関に関する他のサイトへのドメイン管理者)を含んでいます。 インシデントが起こる前にこれらの接触と知り合うのは、あなたの付随している取り扱いプロセスをより効率的にするのを助けるでしょう。
For each type of communication contact, specific "Points of Contact" (POC) should be defined. These may be technical or administrative in nature and may include legal or investigative agencies as well as service providers and vendors. When establishing these contact, it is important to decide how much information will be shared with each 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.
それぞれのタイプのコミュニケーション接触に関しては、特定の「連絡先」(POC)は定義されるべきです。 これらは、現実に技術的であるか、または管理であるかもしれなく、サービスプロバイダーとベンダーと同様に法的であるか調査の政府機関を含むかもしれません。 これらの接触を設置するとき、どのくらいの情報がそれぞれのクラスの接触と共有されるかを決めるのは重要です。 早めにどんな情報がサイトのユーザ、公衆(プレスを含んでいる)、および他のサイトと共有されるかを定義するのは特に重要です。
Settling these issues are especially important for the local person responsible for handling the incident, since that is the person responsible for the actual notification of others. A list of 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 appropriate person during an incident when many urgent events are ongoing. It is strongly recommended that all relevant telephone numbers (also electronic mail addresses and fax numbers) be included in the site security policy. The names and contact information of all individuals who will be directly involved in the handling of an incident should be placed at the top of this list.
それが他のものの実際の通知に責任がある人であるのでインシデントを扱うのに責任がある土地の人にとって、これらの問題が特に重要であるのに決着をつけます。 それぞれのこれらのカテゴリにおける接触のリストはインシデントの間のこの人のための重要な時間貯蓄家です。 多くの緊急のイベントが進行中であるときに、インシデントの間、適切な人を見つけるのはかなり難しい場合があります。 すべての関連電話番号(電子メールアドレスともファックス番号)がサイト安全保障政策に含まれることが強く勧められます。 直接インシデントの取り扱いにかかわるすべての個人の名前と問い合わせ先はこのリストの上部に置かれるべきです。
Fraser, Ed. Informational [Page 42] RFC 2196 Site Security Handbook September 1997
フレーザ、[42ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
5.2.1 Local Managers and Personnel
5.2.1 地元のマネージャと人員
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 major mistake that can be made is to have a number of people who are each working independently, but are not working together. This will only add to the confusion of the event and will probably lead to wasted or ineffective effort.
インシデントが進行中とき、主要な問題は、だれがプレーヤーの多数の活動を調整するのを担当しているかを決めています。 することができる主要な誤りはそれぞれ独自に働いていますが、一緒に働いていない多くの人々がいることです。 これは、イベントの混乱の一助となるだけであり、たぶん無駄であるか効果がない取り組みに通じるでしょう。
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 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 as to the interpretation of policy applied to the event. In contrast, the POC must coordinate the effort of all the parties involved with handling the event.
独身のPOCはインシデントを扱うのに責任がある人であるかもしれません。 だれがPOCになるだろうか、そして、だれがインシデントを担当して人になるかを決めるときいっぱいにする2つの異なった役割があります。 インシデント担当の人はイベントに適用された方針の解釈に関して決定をするでしょう。 対照的に、POCはイベントを扱うのにかかわるすべてのパーティーの取り組みを調整しなければなりません。
The POC must be a person with the technical expertise to successfully coordinate the efforts of the system managers and users involved in monitoring and reacting to the attack. Care should be taken when identifying who this person will be. It should not necessarily be the same person who has administrative responsibility for the compromised systems since often such administrators have knowledge only sufficient for the day to day use of the computers, and lack in depth technical expertise.
POCは、首尾よく攻撃にモニターして、反応するのにかかわるシステム・マネージャとユーザの取り組みを調整するためには技術的専門知識をもっている人でなければなりません。 この人がだれになるかを特定するとき、注意するべきです。 それは必ずそのような管理者がしばしば単にその1日にコンピュータの日の使用、および深さ技術的専門知識における不足に十分な状態で心得があるので感染されたシステムのための行政責任を持っている同じ人であるべきであるというわけではありません。
Another important function of the POC is to maintain contact with law enforcement and other external agencies to assure that multi-agency involvement occurs. The level of involvement will be determined by management decisions as well as legal constraints.
POCの別の重要な機能は複数機関かかわり合いが起こることを保証するために法施行との接触と他の外部の政府機関を維持することです。 関与水準は法的な規制と同様に経営上の決定で決定するでしょう。
A single POC should also be the single person in charge of collecting evidence, since as a rule of thumb, the more people that touch a potential piece of evidence, the greater the possibility that it will be inadmissible in court. To ensure that evidence will be acceptable to the legal community, collecting evidence should be done following predefined procedures in accordance with local laws and legal regulations.
また、証拠固めることを担当して独身のPOCは独身の人であるべきです、原則として、親指では、潜在的証拠に触れる人々が多ければ多いほど、法廷で承認しがたくなる可能性が、より大きいので。 証拠が法的な共同体に許容できるようになるのを保証するために、地域法と法的な規則によると、事前に定義された手順に従うのが証拠固められるべきです。
One of the most critical tasks for the POC is the coordination of all relevant processes. Responsibilities may be distributed over the whole site, involving multiple independent departments or groups. This will require a well coordinated effort in order to achieve overall success. The situation becomes even more complex if multiple sites are involved. When this happens, rarely will a single POC at one site be able to adequately coordinate the handling of the entire incident. Instead, appropriate incident response teams should be involved.
POCのための最も重要なタスクの1つはすべての関連プロセスのコーディネートです。 複数の独立している部かグループにかかわって、責任は全体のサイトにわたって分配されるかもしれません。 これは、総合的な成功を遂げるためによく調整された取り組みを必要とするでしょう。 複数のサイトがかかわるなら、状況はさらに複雑になります。 これが起こるとき、めったに、1つのサイトの独身のPOCは適切に全体のインシデントの取り扱いを調整できないでしょう。 代わりに、適切なインシデントレスポンスチームはかかわるべきです。
Fraser, Ed. Informational [Page 43] RFC 2196 Site Security Handbook September 1997
フレーザ、[43ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
The incident handling process should provide some escalation mechanisms. In order to define such a mechanism, sites will need to create an internal classification scheme for incidents. Associated with each level of incident will be the appropriate POC and procedures. As an incident is escalated, there may be a change in the POC which will need to be communicated to all others involved in handling the incident. When a change in the POC occurs, old POC should brief the new POC in all background information.
付随している取り扱いプロセスはいくつかの増大メカニズムを前提とするはずです。そのようなメカニズムを定義するために、サイトは、インシデントの内部の分類体系を作成する必要があるでしょう。 それぞれのレベルのインシデントに関連づけられているのは、適切なPOCと手順になるでしょう。 インシデントが徐々に拡大されるので、インシデントを扱うのにかかわるすべての他のものとコミュニケートする必要があるPOCにおける変化があるかもしれません。 POCにおける変化が起こると、古いPOCはすべての基礎的な情報で新しいPOCに事情を知らせるはずです。
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 法の執行と調査の政府機関
In the event of an incident that has legal consequences, it is important to establish contact with investigative agencies (e.g, the FBI and Secret Service in the U.S.) as soon as possible. Local law enforcement, local security offices, and campus police departments 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.
法的な結果を持っているインシデントの場合、できるだけ早く調査の政府機関(米国のe.のg、FBI、および財務省検察局)と共に接触するのは重要です。 また、地方の法施行、地方の警察施設、およびキャンパス警察署も適宜知識があるべきです。 このセクションは立ち向かわれる問題の多くについて説明しますが、各組織にはそれらがどう法施行と調査の政府機関と対話するかに影響を与えるそれ自身の地方の、そして、政府の法と規則があると認められます。 指摘する中で最も重要なポイントは各サイトが、これらの問題を終える必要があるということです。
A primary reason for determining these point of contact well in advance of an incident is that once a major attack is in progress, there is little time to call these agencies to determine exactly who the correct point of contact is. Another reason is that it is important to cooperate with these agencies in a manner that will foster a good working relationship, and that will be in accordance with the working procedures of these agencies. Knowing the working procedures in advance, and the expectations of your point of contact is a big step in this direction. For example, it is important to gather evidence that will be admissible in any subsequent legal proceedings, and this will require prior knowledge of how to gather such evidence. A final reason for establishing contacts as soon as possible is that it is impossible to know the particular agency that 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.
インシデントのよく前でこれらの連絡先を決定するプライマリ理由は大規模な攻撃がいったん進行していると、正しい連絡先がちょうどだれであるかを決定するためにこれらの政府機関に電話をする時間がほとんどないということです。 別の理由は良い仕事上のお付き合いを伸ばして、これらの政府機関の働く手順によると、ある方法でこれらの政府機関と協力するのが重要であるということです。 あらかじめ働く手順を知って、あなたの連絡先への期待はそうです。この方向への大きいステップ。 例えば、どんなその後の合法的な処置でも容認できる証拠を集めるのが重要であり、これはどうそのような証拠を集めるかに関する先の知識を必要とするでしょう。 できるだけ早く接触する最終的な理由はどんな与えられたインシデントでも管轄を仮定する特定の政府機関を知るのが不可能であるということです。 インシデントに応じる接触と早くから正規のルートを見つけるとする作成はかなりスムーズに行きます。
Fraser, Ed. Informational [Page 44] RFC 2196 Site Security Handbook September 1997
フレーザ、[44ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
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 a minimum, your legal counsel needs to be involved to protect the legal and financial interests of your site or organization. There are many legal and practical issues, a few of which are:
あなたの組織かサイトに弁護士がいるなら、あなたは、あなたが、インシデントが進行していることを学んだすぐ後にこのオフィスに通知する必要があります。 最小限では、あなたの弁護士は、あなたのサイトか組織の法的で財政的な関心を保護するためにかかわる必要があります。 多くの法的で実用的な問題があります。そのいくつかはことです:。
(1) Whether your site or organization is willing to risk negative
publicity or exposure to cooperate with legal prosecution
efforts.
(1)は、あなたのサイトか組織であることにかかわらず法による起訴取り組みに協力するためにマイナスの評判か暴露を危険にさらしても構わないと思っています。
(2) Downstream liability--if you leave a compromised system as is so
it can be monitored and another computer is damaged because the
attack originated from your system, your site or organization
may be liable for damages incurred.
(2)川下責任--あなたがそれをモニターできるようにそのままで感染されたシステムを残して、攻撃があなたのシステムから発したので別のコンピュータが破損しているなら、あなたのサイトか組織が被られた損害賠償に支払いの義務があるかもしれません。
(3) Distribution of information--if your site or organization
distributes information about an attack in which another site or
organization may be involved or the vulnerability in a product
that may affect ability to market that product, your site or
organization may again be liable for any damages (including
damage of reputation).
(3)情報の流通--あなたのサイトか組織が別のサイトか組織がかかわるかもしれない攻撃か製品の中のその製品を売り出す能力に影響するかもしれない脆弱性の情報を分配するなら、あなたのサイトか組織が再びどんな損害賠償にも支払いの義務があるかもしれません(評判の損害を含んでいて)。
(4) Liabilities due to monitoring--your site or organization may be
sued if users at your site or elsewhere discover that your site
is monitoring account activity without informing users.
モニターによる(4)負債--ユーザが、あなたのサイトにおいてほかの場所であなたのサイトがユーザに知らせないでアカウント活動をモニターしていると発見するなら、あなたのサイトか組織が訴えられるかもしれません。
Unfortunately, there are no clear precedents yet on the liabilities or responsibilities of organizations involved in a security incident or who might be involved in supporting an investigative effort. Investigators will often encourage organizations to help trace and monitor intruders. Indeed, most investigators cannot pursue computer intrusions without extensive support from the organizations involved. However, investigators cannot provide protection from liability claims, and these kinds of efforts may drag out for months and may take a lot of effort.
残念ながら、まだ調査の取り組みをサポートするのにセキュリティインシデントにかかわった組織かそれともだれがかかわるかもしれないかに関する負債か責任に関するどんな明確な先例もありません。 捜査官は、しばしば組織が跡を助けて、侵入者をモニターするよう奨励するでしょう。 本当に、ほとんどの捜査官は組織からの大規模な支持のない侵入がかかわったコンピュータを追求できません。 しかしながら、捜査官が責任クレームから保護を提供できないで、これらの種類の取り組みは、何カ月もだらだらと続いて、多くの取り組みを取るかもしれません。
On the other hand, an organization's legal council may advise extreme caution and suggest that tracing activities be halted and an intruder shut out of the system. This, in itself, may not provide protection from liability, and may prevent investigators from identifying the perpetrator.
他方では、組織の法的な協議会は、極端な警告を教えて、追跡活動が止められるのを示すかもしれません、そして、侵入者はシステムから閉じました。 これによって、捜査官は、本来責任から保護を前提としないで、加害者を特定できないかもしれません。
The balance between supporting investigative activity and limiting liability is tricky. You'll need to consider the advice of your legal counsel and the damage the intruder is causing (if any) when making your decision about what to do during any particular incident.
調査の活動をサポートして、責任を限定することの間のバランスは扱いにくいです。 あなたは、どんな特定のインシデントの間にもするべきことに関するあなたの決定をするとき、あなたの弁護士のアドバイスと侵入者がもたらしている(もしあれば)損害を考える必要があるでしょう。
Fraser, Ed. Informational [Page 45] RFC 2196 Site Security Handbook September 1997
フレーザ、[45ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
Your legal counsel should also be involved in any decision to contact investigative agencies when an incident occurs at your site. The decision to coordinate efforts with investigative agencies is most properly that of your site or organization. Involving your legal counsel will also foster the multi-level coordination between your site and the particular investigative agency involved, which in turn results in an efficient division of labor. Another result is that you are likely to obtain guidance that will help you avoid future legal mistakes.
また、インシデントがあなたのサイトに起こるとき、あなたの弁護士は調査の政府機関に連絡するというどんな決定にもかかわるべきです。 調査の政府機関と共に取り組みを調整するという決定は最も適切にそうです。あなたのサイトか組織のもの。 また、あなたの弁護士にかかわると、かかわったあなたのサイトと特定の調査の政府機関の間のマルチレベルコーディネートは伸ばされるでしょう。(順番に、それは、効率的な分業をもたらします)。 別の結果はあなたをあなたが将来の法的な誤りを避けるのを助ける指導を得そうであるということです。
Finally, your legal counsel should evaluate your site's written procedures for responding to incidents. It is essential to obtain a "clean bill of health" from a legal perspective before you actually carry out these procedures.
最終的に、あなたの弁護士はインシデントに応じるためのあなたのサイトの書かれた手順を評価するべきです。 あなたが実際にこれらの手順を行う前に法的な見解から「健康証明書」を得るのは不可欠です。
It is vital, when dealing with investigative agencies, to verify that the person who calls asking for information is a legitimate representative from the agency in question. Unfortunately, many well intentioned people have unknowingly leaked sensitive details about incidents, allowed unauthorized people into their systems, etc., because a caller has masqueraded as a representative of a government agency. (Note: this word of caution actually applies to all external contacts.)
電話をする照会する人が問題の政府機関からの正統の代表であることを確かめるために調査の政府機関と取り引きするとき、それは重大です。 残念ながら、多くのよく意図を持った人々がインシデントに関する機密の詳細を知らずに漏らしました、と権限のない人々は彼らのシステムなどに許しました、訪問者が政府機関の代表のふりをしたので。 (注意: 警告のこの単語は実際にすべての外部の接触に適用されます。)
A similar consideration is using a secure means of communication. Because many network attackers can easily re-route electronic mail, avoid using electronic mail to communicate with other agencies (as well as others dealing with the incident at hand). Non-secured phone lines (the phones normally used in the business world) are also frequent targets for tapping by network intruders, so be careful!
同様の考慮はコミュニケーションの安全な手段を使用しています。 多くのネットワーク攻撃者が容易に電子メールを別ルートで送ることができるので、他の政府機関(手元のインシデントに対処する他のものと同様に)とコミュニケートするのに電子メールを使用するのを避けてください。 また、非機密保護している電話回線(通常、企業の動きを見ると使用される電話)がネットワークで侵入者を叩くための頻繁な目標であるので、注意してください!
There is no one established set of rules for responding to an incident when the local government becomes involved. Normally (in the U.S.), except by legal order, no agency can force you to monitor, to disconnect from the network, to avoid telephone contact with the suspected attackers, etc. Each organization will have a set of local and national laws and regulations that must be adhered to when handling incidents. It is recommended that each site be familiar with those laws and regulations, and identify and get know the contacts for agencies with jurisdiction well in advance of handling an incident.
地方自治体がかかわるようになるとインシデントに応じるための規則の設立された1セットがありません。 通常(米国で)、法秩序以外に、どんな政府機関も、ネットワークから切断して、疑われた攻撃者との電話接触などを避けるためにモニターにあなたを強制できません。 インシデントを扱うとき、各組織には、1セットのローカルの、そして、国家の法と固く守らなければならない規則があるでしょう。 得てください。そして、それぞれのサイトがそれらの法と規則に身近であることが、お勧めである、特定、インシデントを扱うよく前の管轄との政府機関に関する接触を知ってください。
5.2.3 Computer Security Incident Handling Teams
5.2.3 コンピュータセキュリティインシデント取り扱いチーム
There are currently a number of of Computer Security Incident Response teams (CSIRTs) such as the CERT Coordination Center, the German DFN-CERT, and other teams around the globe. Teams exist for many major government agencies and large corporations. If such a
現在、数がある、コンピュータでは、Security Incident Responseは地球の周りでCERTコーディネートセンターや、ドイツのDFN-CERTや、他のチームなどの(CSIRTs)を組にします。 チームは多くの主要な政府機関と大企業のために存在します。 そのようなaです。
Fraser, Ed. Informational [Page 46] RFC 2196 Site Security Handbook September 1997
フレーザ、[46ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
team is available, notifying it should be of primary consideration during the early stages of an incident. These teams are responsible for coordinating computer security incidents over a range of sites and larger entities. Even if the incident is believed to be contained within a single site, it is possible that the information 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 system's hardware or software, the vendor (or supplier) and a Computer Security Incident Handling team should be notified as soon as possible. This is especially important because many other systems are vulnerable, and these vendor and response team organizations can help disseminate help to other affected sites.
不履行がシステムのハードウェアかソフトウェアの欠点のため起こったのが、決定しているなら、ベンダー(または、供給者)とコンピュータSecurity Incident Handlingチームはできるだけ早く、通知されるべきです。 他の多くのシステムが害を被りやすいので、これは特に重要です、そして、これらのベンダーと応答チーム組織は他の関係部位に助けを広めるのを助けることができます。
In setting up a site policy for incident handling, it may be desirable to create a subgroup, much like those teams that already exist, that will be responsible for handling computer security incidents for the site (or organization). If such a team is created, it is essential that communication lines be opened between this team and other teams. Once an incident is under way, it is difficult to open a trusted dialogue between other teams if none has existed before.
付随している取り扱いのためのサイト方針をセットアップするのにおいて、サブグループを創設するのは望ましいかもしれません、既に既存の、そして、サイト(または、組織)において、取り扱いコンピュータセキュリティインシデントに責任があるそれらのチームのように。 そのようなチームが創設されるなら、通信回線がこのチームと他のチームの間で開けられるのは、不可欠です。インシデントがいったん進行中になると、なにも以前存在したことがないなら、他のチームの間の信じられた対話を開くのは難しいです。
5.2.4 Affected and Involved Sites
5.2.4 影響を受けてかかわったサイト
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 is not limited to the local site, or it may emerge only after further analysis.
インシデントが他のサイトに影響を与えるなら、それらを知らせるのは、良い習慣です。 インシデントがローカル・サイトに制限されないのが、始めから明白であるかもしれないか、またはそれはさらなる分析の後にだけ出て来るかもしれません。
Each site may choose to contact other sites directly or they can pass the information to an appropriate incident response team. It is often very difficult to find the responsible POC at remote sites and the incident response team will be able to facilitate contact by making use of already established channels.
各サイトが、他のサイトに直接接触するのを選ぶかもしれませんか、またはそれらは適切なインシデントレスポンスチームに情報を通過できます。 リモートサイトで責任があるPOCを見つけるのがしばしば非常に難しく、インシデントレスポンスチームは、既に確立したチャンネルを利用することによって、接触を容易にすることができるでしょう。
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 sharing and logging of information about other sites before an incident occurs.
セキュリティインシデントから起こる法的、そして、責任問題はサイトからサイトまで異なるでしょう。 インシデントが起こる前の他のサイトの情報の共有と伐採のための方針を定義するのは重要です。
Information about specific people is especially sensitive, and may be subject to privacy laws. To avoid problems in this area, irrelevant information should be deleted and a statement of how to handle the remaining information should be included. A clear statement of how 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
特定の人々に関する情報は、特に機密であり、プライバシー法を受けることがあるかもしれません。 この領域で問題を避けるために、無関係の情報は削除されるべきです、そして、どう残っている情報を扱うかに関する声明は含まれるべきです。 どう使用されているかに関するこの情報がことである明確な声明は不可欠です。 セキュリティインシデントのサイトを知らせるだれも公衆でそれに関して読みたがっていません。
Fraser, Ed. Informational [Page 47] RFC 2196 Site Security Handbook September 1997
フレーザ、[47ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
press. Incident response teams are valuable in this respect. When they pass information to responsible POCs, they are able to protect the anonymity of the original source. But, be aware that, in many cases, the analysis of logs and information at other sites will reveal addresses of your site.
押してください。 インシデントレスポンスチームはこの点で貴重です。 責任があるPOCsに情報を通過するとき、彼らは一次資料の匿名を保護できます。 しかし、他のサイトのログと情報の分析が多くの場合であなたのサイトのアドレスを明らかにするのを意識してください。
All the problems discussed above should be not taken as reasons not to involve other sites. In fact, the experiences of existing teams reveal that most sites informed about security problems are not even aware that their site had been compromised. Without timely information, other sites are often unable to take action against intruders.
他のサイトにかかわらない理由として上で議論したすべての問題をみなすべきではありません。 事実上、ほとんどのサイトが警備上の問題に関して知らせたチームが明らかにする存在の経験はそれらのサイトが感染されたのを意識してさえいません。 時宜を得た情報がなければ、他のサイトは侵入者にとって行動をしばしば起こすことができません。
5.2.5 Internal Communications
5.2.5 内部のコミュニケーション
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.
顧客と契約パートナーとのコミュニケーションは分別がありますが、敏感な方法で扱われるべきです。 1つは、チェックリストを準備することによって、本題の用意をすることができます。 インシデントが起こるとき、インシデントの特定の事情に1か2つの文の追加と共にチェックリストを使用できます。
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
5.2.6 広報--プレスリリース
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.
コンピュータセキュリティインシデントに捧げられたメディア報道の量における物凄い成長が合衆国にありました。 インターネットが成長して、国際的に広がり続けているとき、そのようなマスコミ報道は必ず他国に達するでしょう。 そのようなメディアの関心がまだ起こっていない国からの読者、米国の経験から学ぶことができて、forwarnedされて、準備されるべきです。
Fraser, Ed. Informational [Page 48] RFC 2196 Site Security Handbook September 1997
フレーザ、[48ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
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 many issues to consider when deciding this particular issue. First 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 relations office is trained in the type and wording of information released, and will help to assure that the image of the site is protected during and after the incident (if possible). A public relations office has the advantage that you can communicate candidly with them, and provide a buffer between the constant press attention and the need of the POC to maintain control over the incident.
考える中で最も重要な問題の1つがいつか、プレスを通してだれ、どのくらい一般に釈放しますか? この特定の問題について決めると考えるために、多くの問題があります。 まず第一に、広報課がサイトに存在するなら、連絡としてこのオフィスをプレスに使用するのは重要です。 広報課は、発表された情報のタイプと言葉遣いで訓練されて、サイトのイメージがインシデントとインシデントの後に保護されることを保証するのを助けるでしょう(できれば)。 広報課はPOCがインシデントのコントロールを維持する一定のプレス注意と必要性の間にあなたが率直にそれらとコミュニケートして、バッファを提供できる利点を持っています。
If a public relations office is not available, the information released to the press must be carefully considered. If the information is sensitive, it may be advantageous to provide only minimal or overview information to the press. It is quite possible that any information provided to the press will be quickly reviewed by the perpetrator of the incident. Also note that misleading the press can often backfire and cause more damage than releasing sensitive information.
広報課が利用可能でないなら、慎重にプレスに発表された情報を考えなければなりません。 情報が機密であるなら、最小量だけか概要情報をプレスに提供するのは有利であるかもしれません。 プレスに提供されたどんな情報もインシデントの加害者によってすばやく再検討されるのは、かなり可能です。 また、プレスをミスリードするのがしばしば裏目に出て、機密情報を発表するより多くの損害をもたらすことができることに注意してください。
While it is difficult to determine in advance what level of detail to provide to the press, some guidelines to keep in mind are:
あらかじめどんなレベルの詳細をプレスに明らかにするかを決定するのが難しいのですが、覚えておくいくつかのガイドラインは以下の通りです。
(1) Keep the technical level of detail low. Detailed
information about the incident may provide enough
information for others to launch similar attacks on
other sites, or even damage the site's ability to
prosecute the guilty party once the event is over.
(1) 詳細の技術水準を低く保ってください。 インシデントの詳細な情報は、他のものが他のサイトに対する同様の攻撃に着手できるくらいの情報を提供するか、またはイベントがいったん終わるようになると犯人を起訴するサイトの能力を破損さえするかもしれません。
(2) Keep the speculation out of press statements.
Speculation of who is causing the incident or the
motives are very likely to be in error and may cause
an inflamed view of the incident.
(2) 記者声明に思惑を入れないようにしてください。 だれがインシデントを引き起こすかに関する思惑か動機が、間違っているのが非常にありそうであり、インシデントの炎症を起こしている視点を引き起こすかもしれません。
(3) Work with law enforcement professionals to assure that
evidence is protected. If prosecution is involved,
assure that the evidence collected is not divulged to
the press.
(3) 法施行専門家と共に働いて、証拠が保護されることを保証してください。 起訴がかかわるなら、集められた証拠がプレスに明かされないと安心してください。
(4) Try not to be forced into a press interview before you are
prepared. The popular press is famous for the "2 am"
interview, where the hope is to catch the interviewee off
guard and obtain information otherwise not available.
(4) 用意ができている前に記者会見に強制されようとしないでください。 ポピュラーなプレスは「2はそうです」というインタビューで有名です、会見相手が油断しているのを捕らえて、そうでなければ、利用可能でない情報を得るところで望みがことである。
(5) Do not allow the press attention to detract from the
handling of the event. Always remember that the successful
closure of an incident is of primary importance.
(5) イベントの取り扱いからプレス注意を減じさせないでください。 いつもインシデントのうまくいっている閉鎖がプライマリに重要であることを覚えていてください。
Fraser, Ed. Informational [Page 49] RFC 2196 Site Security Handbook September 1997
フレーザ、[49ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
5.3 Identifying an Incident
5.3 インシデントを特定すること。
5.3.1 Is It Real?
5.3.1 それは本当ですか?
This stage involves determining if a problem really exists. Of course many if not most signs often associated with virus infection, system intrusions, malicious users, etc., are simply anomalies such as hardware failures or suspicious system/user behavior. To assist in identifying whether there really is an incident, it is usually helpful to obtain and use any detection software which may be available. Audit information is also extremely useful, especially in determining whether there is a network attack. It is extremely important to obtain a system snapshot as soon as one suspects that something is wrong. Many incidents cause a dynamic chain of events to occur, and an initial system snapshot may be the most valuable tool for identifying the problem and any source of attack. Finally, it is important to start a log book. Recording system events, telephone conversations, time stamps, etc., can lead to a more rapid and systematic identification of the problem, and is the basis for subsequent stages of incident handling.
このステージは、問題が本当に存在するかどうか決定することを伴います。 もちろん、多くやしばしばウイルス感染に関連しているほとんどのサイン、システム侵入、悪意あるユーザーなどが単にハードウェアの故障か疑わしげなシステム/ユーザの振舞いなどの例外です。 インシデントが本当にあるかどうか特定するのを助けるために、通常、どんな利用可能であるかもしれない検出ソフトウェアも入手して、使用するのは役立っています。 また、ネットワーク攻撃があるかどうか特に決定する際に監査情報も非常に役に立ちます。 人がその何かを疑うとすぐに、システムスナップを得るのが間違っているのは、非常に重要です。 イベントのダイナミックなチェーンは多くのインシデントで現れます、そして、初期のシステムスナップは、問題と攻撃のどんな源も特定するための最も貴重なツールであるかもしれません。 最終的に、航海日誌を始動するのは重要です。 システムイベント、電話での会話、タイムスタンプなどを記録するのは、問題の、より急速で系統的な識別に通じることができて、その後のステージの付随している取り扱いの基礎です。
There are certain indications or "symptoms" of an incident that deserve special attention:
特別な注意に値するインシデントのある指摘か「兆候」があります:
(1) System crashes.
(2) New user accounts (the account RUMPLESTILTSKIN has been
unexpectedly created), or high activity on a previously
low usage account.
(3) New files (usually with novel or strange file names,
such as data.xx or k or .xx ).
(4) Accounting discrepancies (in a UNIX system you might
notice the shrinking of an accounting file called
/usr/admin/lastlog, something that should make you very
suspicious that there may be an intruder).
(5) Changes in file lengths or dates (a user should be
suspicious if .EXE files in an MS DOS computer have
unexplainedly grown by over 1800 bytes).
(6) Attempts to write to system (a system manager notices
that a privileged user in a VMS system is attempting to
alter RIGHTSLIST.DAT).
(7) Data modification or deletion (files start to disappear).
(8) Denial of service (a system manager and all other users
become locked out of a UNIX system, now in single user mode).
(9) Unexplained, poor system performance
(10) Anomalies ("GOTCHA" is displayed on the console or there
are frequent unexplained "beeps").
(11) Suspicious probes (there are numerous unsuccessful login
attempts from another node).
(1) システムクラッシュ。 (2) 新しいユーザアカウント(アカウントRUMPLESTILTSKINは不意に作成された)、または以前に低い用法アカウントにおける高い活動。 (3) 新しいファイル(通常、data.xx、kまたは.xxなどの目新しいか奇妙なファイル名がある)。 (4) 食い違い(UNIXシステムでは、あなたは/usr/admin/lastlogと呼ばれる課金ファイルを縮小することに気付くかもしれません、あなたを侵入者がいるかもしれないのが非常に疑わしげにするべきである何か)を説明します。 (5) ファイルの長さか日付(MS-DOSコンピュータの.EXEファイルがunexplainedlyに1800バイト以上成長したなら、ユーザは不審に思っているべきである)の変化。 (6) システム(システム・マネージャは、VMSシステムの特権ユーザが、RIGHTSLIST.DATを変更するのを試みているのに気付く)に書くのを試みます。 (7) データ変更か削除(ファイルは見えなくなり始めます)。 (8) サービス(システム・マネージャと他のすべてのユーザがUNIXシステムからロックされるようになります、現在、シングルユーザーモードで)の否定。 (9) 説明されないで、貧しいシステム性能(10)例外(コンソールの上に"GOTCHA"を表示するか、または頻繁な説明されなかった「ビープ音」があります)。 (11) 疑わしげな徹底的調査(別のノードからの頻繁な失敗のログイン試みがあります)。
Fraser, Ed. Informational [Page 50] RFC 2196 Site Security Handbook September 1997
フレーザ、[50ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
(12) Suspicious browsing (someone becomes a root user on a UNIX
system and accesses file after file on many user accounts.)
(13) Inability of a user to log in due to modifications of his/her
account.
(12) 疑わしげなブラウジング(だれかがUNIXシステムの上で根のユーザになって、アクセスは多くのユーザアカウントのファイルの後にファイルされます。) (13) ユーザがその人のアカウントの変更のためログインできないこと。
By no means is this list comprehensive; we have just listed a number of common indicators. It is best to collaborate with other technical and computer security personnel to make a decision as a group about whether an incident is occurring.
このリストは決して、包括的ではありません。 私たちはちょうど多くの一般的なインディケータを記載したところです。 インシデントが起こるかどうかに関するグループとして決定するために他の技術的、そして、コンピュータセキュリティ人員と協力するのは最も良いです。
5.3.2 Types and Scope of Incidents
5.3.2 インシデントのタイプと範囲
Along with the identification of the incident is the evaluation of the scope and impact of the problem. It is important to correctly identify the boundaries of the incident in order to effectively deal with it and prioritize responses.
インシデントの識別と共に、問題の範囲と影響の評価はそうですか? 事実上、それに対処するために正しくインシデントの境界を特定して、応答を最優先させるのは重要です。
In order to identify the scope and impact a set of criteria should be defined which is appropriate to the site and to the type of connections available. Some of the issues include:
範囲と影響を特定するために、1セットの評価基準は定義されるべきです(サイトと接続の手があいているタイプに、適切です)。 問題のいくつかは:
(1) Is this a multi-site incident?
(2) Are many computers at your site affected by this incident?
(3) Is sensitive information involved?
(4) What is the entry point of the incident (network,
phone line, local terminal, etc.)?
(5) Is the press involved?
(6) What is the potential damage of the incident?
(7) What is the estimated time to close out the incident?
(8) What resources could be required to handle the incident?
(9) Is law enforcement involved?
(1) これはマルチサイトインシデントですか? (2) あなたのサイトの多くのコンピュータがこのインシデントで影響を受けますか? (3) 機密情報はかかわりますか? (4) インシデント(ネットワーク、電話回線、ローカル・ターミナルなど)のエントリー・ポイントは何ですか? (5) プレスはかかわりますか? (6) インシデントの可能性のあるダメージは何ですか? (7) インシデントを見切り売りするおよそ時間は何ですか? (8) インシデントを扱うためにどんなリソースを必要とすることができますか? (9) 法施行はかかわりますか?
5.3.3 Assessing the Damage and Extent
5.3.3 損害と範囲を算定すること。
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 the incident, and aid investigation and prosecution. As soon as the breach has occurred, the entire system and all of its components should be considered suspect. System software is the most probable target. Preparation is key to be able to detect all changes for a possibly tainted system. This includes checksumming all media from the vendor using a algorithm which is resistant to tampering. (See sections 4.3)
インシデント、援助調査、および起訴の本質に関する何らかの洞察に通じるべきであるのを除いて、損害の分析とインシデントの範囲はかなり時間がかかっている場合があります。 不履行が起こるとすぐに、コンポーネントの全体のシステムとすべてが疑わしいと考えられるべきです。 システムソフトは最もありえそうな目標です。 準備は、ことによると汚れているシステムのためにすべての変化を検出できるように主要です。 これは、抵抗力があるアルゴリズムを使用するベンダーから改ざんまですべてのメディアをchecksummingするのを含んでいます。 (セクション4.3を見ます)
Assuming original vendor distribution media are available, an analysis of all system files should commence, and any irregularities should be noted and referred to all parties involved in handling the incident. It can be very difficult, in some cases, to decide which
元売業者分配メディアが利用可能であると仮定する場合、すべてのシステムファイルの分析が始まるべきであり、どんな不規則もインシデントを扱うのにかかわるすべてのパーティーを、注意されて、参照されるべきです。 それは、どれを決めるかためにいくつかの場合で非常に難しい場合があります。
Fraser, Ed. Informational [Page 51] RFC 2196 Site Security Handbook September 1997
フレーザ、[51ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
backup media are showing a correct system status. Consider, for example, that the incident may have continued for months or years before discovery, and the suspect may be an employee of the site, or otherwise have intimate knowledge or access to the systems. In all cases, the pre-incident preparation will determine what recovery is possible.
バックアップメディアは正しいシステム状態を示しています。 例えば、インシデントが何カ月もの発見の何年も前に続いたかもしれなくて、容疑者がサイトの従業員であるかもしれないと考えるか、またはさもなければ、詳細な知識かアクセスをシステムに持ってください。ケースであり全部で、プレインシデント準備は、どんな回復が可能であるかを決定するでしょう。
If the system supports centralized logging (most do), go back over the logs and look for abnormalities. If process accounting and connect time accounting is enabled, look for patterns of system usage. To a lesser extent, disk usage may shed light on the incident. Accounting can provide much helpful information in an analysis of an incident and subsequent prosecution. Your ability to address all aspects of a specific incident strongly depends on the success of this analysis.
システム支援が伐採を集結したなら(大部分はそうします)、ログの上で戻ってください、そして、異常を探してください。 プロセス会計学と接続時間の会計が可能にされるなら、システム使用のパターンを探してください。 ある程度、ディスクの使用状況はインシデントを解明するかもしれません。 会計はインシデントとその後の起訴の分析に多くの役立つ情報を提供できます。 強く特定のインシデントの全面を扱うあなたの能力はこの分析の成功に依存します。
5.4 Handling an Incident
5.4 インシデントを扱うこと。
Certain steps are necessary to take during the handling of an incident. In all security related activities, the most important point to be made is that all sites should have policies in place. Without defined policies and goals, activities undertaken will remain 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 affected systems and to limit the impact and damage. In the worst case scenario, shutting down the system, or disconnecting the system from the network, may the only practical solution.
最も基本的な目的の1つは、影響を受けるシステムのコントロールを復元して、影響と損害を制限することです。 最悪の場合、システムを止めるか、またはネットワークからシステムから切断するのは唯一の実際的な解決がそうするかもしれません。
As the activities involved are complex, try to get as much help as necessary. While trying to solve the problem alone, real damage might occur due to delays or missing information. Most administrators take the discovery of an intruder as a personal challenge. By proceeding this way, other objectives as outlined in the local policies may not always be considered. Trying to catch intruders may be a very low priority, compared to system integrity, for example. Monitoring a hacker's activity is useful, but it might not be considered worth the risk to allow the continued access.
かかわる活動が複雑であるので、必要なだけの助けを得るようにしてください。 単独で問題を解決していようとしている間、本当の損害は遅れかなくなった情報のため発生するかもしれません。 ほとんどの管理者が個人的な挑戦として侵入者の発見をみなします。 このように続くことによって、ローカルの方針で概説されている他の目的はいつも考えられるかもしれないというわけではありません。 例えば、システム保全と比べて、侵入者を捕らえようとするのは、非常に低い優先度であるかもしれません。 ハッカーの活動をモニターするのは役に立ちますが、それは継続的なアクセサリーを許容するためにリスクの価値があると考えられないかもしれません。
5.4.1 Types of Notification and Exchange of Information
5.4.1 通知と情報交換のタイプ
When you have confirmed that an incident is occurring, the appropriate personnel must be notified. How this notification is achieved is very important to keeping the event under control both from a technical and emotional standpoint. The circumstances should be described in as much detail as possible, in order to aid prompt acknowledgment and understanding of the problem. Great care should
あなたが、インシデントが起こっていると確認したとき、適切な要員に通知しなければなりません。 この通知がどう達成されるかは、ともに技術的で感情的な見地からイベントを抑えるのに非常に重要です。 事情はできるだけ多くの詳細に説明されるべきです、問題の迅速な承認と理解を支援するために。 高度の注意はそうするべきです。
Fraser, Ed. Informational [Page 52] RFC 2196 Site Security Handbook September 1997
フレーザ、[52ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
be taken when determining to which groups detailed technical information is given during the notification. For example, it is helpful to pass this kind of information to an incident handling team as they can assist you by providing helpful hints for eradicating the vulnerabilities involved in an incident. On the other hand, putting the critical knowledge into the public domain (e.g., via USENET newsgroups or mailing lists) may potentially put a large number of systems at risk of intrusion. It is invalid to assume that all administrators reading a particular newsgroup have access to operating system source code, or can even understand an advisory well enough to take adequate steps.
詳細な技術資料が通知の間、どのグループに与えられているかを決定するときには、取ってください。 例えば、彼らがインシデントにかかわる脆弱性を根絶するための役立っているヒントを提供することによってあなたを補助できるので、この種類の情報を付随している取り扱いチームに通過するのは役立っています。 他方では、公共の場(例えば、ユーズネットかメーリングリストを通した)に重要な知識を入れるのは侵入で危険なシステムの潜在的に置かれた多くがそうするかもしれません。 特定のニュースグループを読んでいるすべての管理者がオペレーティングシステムソースコードに近づく手段を持っているか、または状況報告を適切な方法を採ることができるくらいよく理解さえできると仮定するのは無効です。
First of all, any notification to either local or off-site personnel must be explicit. This requires that any statement (be it an electronic mail message, phone call, fax, beeper, or semaphone) providing information about the incident be clear, concise, and fully qualified. When you are notifying others that will help you handle an event, a "smoke screen" will only divide the effort and create confusion. If a division of labor is suggested, it is helpful to provide information to each participant about what is being accomplished in other efforts. This will not only reduce duplication of effort, but allow people working on parts of the problem to know where to obtain information relevant to their part of the incident.
まず、地方かオフサイト人員へのどんな通知も明白でなければなりません。 これは、インシデントの情報を提供するどんな声明(電子メールメッセージ、電話、ファックス、ポケベル、またはsemaphoneであることにかかわらず)も明確で、簡潔で、完全に適切であることを必要とします。 あなたがあなたがイベントを扱うのを助ける他のものに通知しているとき、「煙幕」は、取り組みを分割するだけであり、混乱を作成するでしょう。 分業が示されるなら、他の取り組みで達成されていることに関して各関係者に情報を提供するのは役立っています。 これで、問題の部分に取り組んでいる人々は、取り組みの複製を抑えるだけではなく、どこでそれらのインシデントの部分に関連している情報を得るかを知ることができるでしょう。
Another important consideration when communicating about the incident is to be factual. Attempting to hide aspects of the incident by providing false or incomplete information may not only prevent a successful resolution to the incident, but may even worsen the situation.
別の重要な考慮すべき事柄はインシデントについて話し合うとき、事実上ことです。 誤ったか不完全な情報を提供することによってインシデントの局面を隠すのを試みるのが、うまくいっている解決をインシデントに防ぐだけではありませんが、状況を悪化させさえするかもしれません。
The choice of language used when notifying people about the incident can have a profound effect on the way that information is received. When you use emotional or inflammatory terms, you raise the potential for damage and negative outcomes of the incident. It is important to remain calm both in written and spoken communications.
インシデントに関して人々に通知するとき使用される言語の選択は情報が受信されている方法で効果を持つことができます。 感情的であるか扇動的の用語を使用すると、あなたはインシデントの損害と否定的結果の可能性を上げます。 ともに書かれて話されたコミュニケーションで穏やかなままであることは重要です。
Another consideration is that not all people speak the same language. Due to this fact, misunderstandings and delay may arise, especially if it is a multi-national incident. Other international concerns include differing legal implications of a security incident and cultural differences. However, cultural differences do not only exist between countries. They even exist within countries, between different social or user groups. For example, an administrator of a university system might be very relaxed about attempts to connect to the system via telnet, but the administrator of a military system is likely to consider the same action as a possible attack.
別の考慮はすべての人々が同じ言語を話すというわけではないということです。 この事実のため、誤解と遅れは特にそれが多国籍のインシデントであるなら起こるかもしれません。 他の国際的な関心はセキュリティインシデントと文化の相違の異なった法的な含意を含んでいます。 しかしながら、文化の相違は国の間に存在するだけではありません。 それらは社会的であるかユーザの異なったグループの間の国の中に存在してさえいます。 例えば、大学システムの管理者はtelnetでシステムに接続する試みに関して非常に伸びやかであるかもしれませんが、軍用システムの管理者は同じ動作が可能な攻撃であるとみなしそうです。
Fraser, Ed. Informational [Page 53] RFC 2196 Site Security Handbook September 1997
フレーザ、[53ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
Another issue associated with the choice of language is the notification of non-technical or off-site personnel. It is important to accurately describe the incident without generating undue alarm or confusion. While it is more difficult to describe the incident to a non-technical audience, it is often more important. A non-technical description may be required for upper-level management, the press, or law enforcement liaisons. The importance of these communications cannot be underestimated and may make the difference between resolving the incident properly and escalating to some higher level of damage.
言語の選択に関連している別の問題は非技術系かオフサイト人員が通知書です。 正確に過度のアラームか混乱を生成しないでインシデントについて説明するのは重要です。 非技術系の聴衆にインシデントについて説明するのが、より難しいのですが、それはしばしばより重要です。 非技術系の記述が経営上層部、プレス、または法施行連絡に必要であるかもしれません。 これらのコミュニケーションの重要性は、過小評価できないで、適切にインシデントを決議して、何らかのより高いレベルの損害に徐々に拡大するところの違いを作るかもしれません。
If an incident response team becomes involved, it might be necessary to fill out a template for the information exchange. Although this may seem to be an additional burden and adds a certain delay, it helps the team to act on this minimum set of information. The response team may be able to respond to aspects of the incident of which the local administrator is unaware. If information is given out to someone else, the following minimum information should be provided:
インシデントレスポンスチームがかかわるようになるなら、情報交換のためのテンプレートに書き込むのが必要であるかもしれません。 これは、追加負担であるように思えるかもしれなくて、ある遅れを言い足しますが、それは、チームがこの最小の情報に影響するのを助けます。 応答チームは地元の管理者が気づかないインシデントの局面に応じることができるかもしれません。 情報を他の誰かに発表するなら、以下の最小の情報を提供するべきです:
(1) timezone of logs, ... in GMT or local time
(2) information about the remote system, including host names,
IP addresses and (perhaps) user IDs
(3) all log entries relevant for the remote site
(4) type of incident (what happened, why should you care)
(1) グリニッジ標準時のログのタイムゾーンかインシデントのホスト名、IPアドレス、および(恐らく)リモートサイト(4)において、関連しているすべての航空日誌記入事項がタイプするユーザID(3)を含むリモートシステムの現地時間(2)情報(ことが起こった、まあ、あなたが気にかけるなら)
If local information (i.e., local user IDs) is included in the log entries, it will be necessary to sanitize the entries beforehand to avoid privacy issues. In general, all information which might assist a remote site in resolving an incident should be given out, unless local policies prohibit this.
ローカルの情報(すなわち、ローカルのユーザID)が航空日誌記入事項に含まれていると、あらかじめプライバシーの問題を避けるためにエントリーを殺菌するのが必要でしょう。 一般に、インシデントを決議するのにリモートサイトを助けるかもしれないすべての情報を発表するべきです、ローカルの方針がこれを禁止しないなら。
5.4.2 Protecting Evidence and Activity Logs
5.4.2 証拠と活動記録を保護すること。
When you respond to an incident, document all details related to the incident. This will provide valuable information to yourself and others as you try to unravel the course of events. Documenting all details will ultimately save you time. If you don't document every relevant phone call, for example, you are likely to forget a significant portion of information you obtain, requiring you to contact the source of information again. At the same time, recording details will provide evidence for prosecution efforts, providing the case moves in that direction. Documenting an incident will also help you perform a final assessment of damage (something your management, as well as law enforcement officers, will want to know), and will provide the basis for later phases of the handling process: eradication, recovery, and follow-up "lessons learned."
インシデントに応じるときには、インシデントに関連するすべての詳細を記録してください。 あなたがすう勢を解こうとするとき、これは自分と他のものに貴重な情報を提供するでしょう。 すべての詳細を記録すると、時間は結局、あなたに節約するでしょう。 あらゆる関連電話を記録するというわけではないなら、例えば、あなたはあなたが得る情報の重要な部分を忘れそうです、あなたが再び情報源に連絡するのが必要であることで。 同時に、詳細を記録すると、ケースがその方向に移行すると、起訴取り組みに関する証拠は提供されるでしょう。 インシデントを記録するのは、また、あなたが損害(あなたの経営者側が法施行役員と同様に知りたくなること)の最終的な判断を実行するのを助けて、取り扱いプロセスの後期の基礎を前提とするでしょう: 根絶、回復、および追跡している「学習されたレッスン。」
Fraser, Ed. Informational [Page 54] RFC 2196 Site Security Handbook September 1997
フレーザ、[54ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
During the initial stages of an incident, it is often infeasible to determine whether prosecution is viable, so you should document as if you are gathering evidence for a court case. At a minimum, you should record:
インシデントの初期の間、あなたが裁判事件に関する集会証拠であるかのように記録するべきであって、起訴が実行可能であるかどうか決定するのはしばしば実行不可能です。 最小限では、あなたは記録するべきです:
(1) all system events (audit records)
(2) all actions you take (time tagged)
(3) all external conversations (including the person with whom
you talked, the date and time, and the content of the
conversation)
(1) すべてのシステムイベント、(2) あなたが取るすべての(監査記録)行動(タグ付けをされた時間)、(3) すべての外部の会話(あなたが話した人、日時、および会話の内容を含んでいます)
The most straightforward way to maintain documentation is keeping a log book. This allows you to go to a centralized, chronological source of information when you need it, instead of requiring you to page through individual sheets of paper. Much of this information is potential evidence in a court of law. Thus, when a legal follow-up is a possibility, one should follow the prepared procedures and avoid 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
copies of your logbook (as well as media you use to record
system events) to a document custodian.
(2) The custodian should store these copied pages in a secure
place (e.g., a safe).
(3) When you submit information for storage, you should
receive a signed, dated receipt from the document
custodian.
(1) 定期的(例えば毎日)のドキュメント管理人へのあなたの航海日誌(あなたがシステムイベントを記録するのに使用するメディアと同様に)の写真複写されて、署名しているコピーにおける回転。 (2) 管理人は安全な場所(例えば、金庫)にこれらのコピーされたページを保存するべきです。 (3) ストレージのための情報を提出するとき、あなたはドキュメント管理人から署名していて、時代遅れの領収書を受け取ることができます。
Failure to observe these procedures can result in invalidation of any evidence you obtain in a court of law.
これらの手順を観測しない場合、あなたが裁判所で得るどんな証拠についても無効にするのをもたらすことができます。
5.4.3 Containment
5.4.3 封じ込め
The purpose of containment is to limit the extent of an attack. An essential part of containment is decision making (e.g., determining whether to shut a system down, disconnect from a network, monitor system or network activity, set traps, disable functions such as remote file transfer, etc.).
封じ込めの目的は攻撃の範囲を制限することです。 封じ込めの不可欠の部分は意志決定(例えば、閉じるために、システムダウン(ネットワーク、モニタシステムまたはネットワーク活動からの分離)が罠を設定したかどうか決定して、遠隔ファイル転送などの機能を無効にする)です。
Sometimes this decision is trivial; shut the system down if the information is classified, sensitive, or proprietary. Bear in mind that removing all access while an incident is in progress obviously notifies all users, including the alleged problem users, that the administrators are aware of a problem; this may have a deleterious
時々、この決定は些細です。 情報が分類される、機密であるか、または独占であるなら、システムダウンを閉じてください。 インシデントが進行している間、すべてのアクセスを取り除くのが、管理者が問題を意識しているように明らかに申し立てられた問題ユーザを含むすべてのユーザに通知するのを覚えておいてください。 これで、aは有害になるかもしれません。
Fraser, Ed. Informational [Page 55] RFC 2196 Site Security Handbook September 1997
フレーザ、[55ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
effect on an investigation. In some cases, it is prudent to remove all access or functionality as soon as possible, then restore normal operation in limited stages. In other cases, it is worthwhile to risk some damage to the system if keeping the system up might enable you to identify an intruder.
調査への効果。 いくつかの場合、できるだけ早く、すべてのアクセスか機能性を取り除いて、次に、限局期で通常の操作を復元するのは慎重です。 他の場合では、システムを手入れするのが、あなたが侵入者を特定するのを可能にするかもしれないなら、システムへのいくらかの損傷の危険を冒す価値があります。
This stage should involve carrying out predetermined procedures. Your organization or site should, for example, define acceptable risks in dealing with an incident, and should prescribe specific actions and strategies accordingly. This is especially important when a quick decision is necessary and it is not possible to first contact all involved parties to discuss the decision. In the absence of predefined procedures, the person in charge of the incident will often not have the power to make difficult management decisions (like to lose the results of a costly experiment by shutting down a system). A final activity that should occur during this stage of incident handling is the notification of appropriate authorities.
This stage should involve carrying out predetermined procedures. Your organization or site should, for example, define acceptable risks in dealing with an incident, and should prescribe specific actions and strategies accordingly. This is especially important when a quick decision is necessary and it is not possible to first contact all involved parties to discuss the decision. In the absence of predefined procedures, the person in charge of the incident will often not have the power to make difficult management decisions (like to lose the results of a costly experiment by shutting down a system). A final activity that should occur during this stage of incident handling is the notification of appropriate authorities.
5.4.4 Eradication
5.4.4 Eradication
Once the incident has been contained, it is time to eradicate the cause. But before eradicating the cause, great care should be taken to collect all necessary information about the compromised system(s) and the cause of the incident as they will likely be lost when cleaning up the system.
Once the incident has been contained, it is time to eradicate the cause. But before eradicating the cause, great care should be taken to collect all necessary information about the compromised system(s) and the cause of the incident as they will likely be lost when cleaning up the system.
Software may be available to help you in the eradication process, such as anti-virus software. If any bogus files have been created, archive them before deleting them. In the case of virus infections, it is important to clean and reformat any media containing infected files. Finally, ensure that all backups are clean. Many systems infected with viruses become periodically re-infected simply because people do not systematically eradicate the virus from backups. After eradication, a new backup should be taken.
Software may be available to help you in the eradication process, such as anti-virus software. If any bogus files have been created, archive them before deleting them. In the case of virus infections, it is important to clean and reformat any media containing infected files. Finally, ensure that all backups are clean. Many systems infected with viruses become periodically re-infected simply because people do not systematically eradicate the virus from backups. After eradication, a new backup should be taken.
Removing all vulnerabilities once an incident has occurred is difficult. The key to removing vulnerabilities is knowledge and understanding of the breach.
Removing all vulnerabilities once an incident has occurred is difficult. The key to removing vulnerabilities is knowledge and understanding of the breach.
It may be necessary to go back to the original distribution media and re-customize the system. To facilitate this worst case scenario, a record of the original system setup and each customization change should be maintained. In the case of a network-based attack, it is important to install patches for each operating system vulnerability which was exploited.
It may be necessary to go back to the original distribution media and re-customize the system. To facilitate this worst case scenario, a record of the original system setup and each customization change should be maintained. In the case of a network-based attack, it is important to install patches for each operating system vulnerability which was exploited.
Fraser, Ed. Informational [Page 56] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 56] RFC 2196 Site Security Handbook September 1997
As discussed in section 5.4.2, a security log can be most valuable during this phase of removing vulnerabilities. The logs showing how the incident was discovered and contained can be used later to help determine how extensive the damage was from a given incident. The steps taken can be used in the future to make sure the problem does not resurface. Ideally, one should automate and regularly apply the same test as was used to detect the security incident.
As discussed in section 5.4.2, a security log can be most valuable during this phase of removing vulnerabilities. The logs showing how the incident was discovered and contained can be used later to help determine how extensive the damage was from a given incident. The steps taken can be used in the future to make sure the problem does not resurface. Ideally, one should automate and regularly apply the same test as was used to detect the security incident.
If a particular vulnerability is isolated as having been exploited, the next step is to find a mechanism to protect your system. The security mailing lists and bulletins would be a good place to search for this information, and you can get advice from incident response teams.
If a particular vulnerability is isolated as having been exploited, the next step is to find a mechanism to protect your system. The security mailing lists and bulletins would be a good place to search for this information, and you can get advice from incident response teams.
5.4.5 Recovery
5.4.5 Recovery
Once the cause of an incident has been eradicated, the recovery phase defines the next stage of action. The goal of recovery is to return the system to normal. In general, bringing up services in the order of demand to allow a minimum of user inconvenience is the best practice. Understand that the proper recovery procedures for the system are extremely important and should be specific to the site.
Once the cause of an incident has been eradicated, the recovery phase defines the next stage of action. The goal of recovery is to return the system to normal. In general, bringing up services in the order of demand to allow a minimum of user inconvenience is the best practice. Understand that the proper recovery procedures for the 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, it is still possible that holes, and even traps, could be lurking in the system. One of the most important stages of responding to incidents is also the most often omitted, the follow-up stage. In the follow-up stage, the system should be monitored for items that may have been missed during the cleanup stage. It would be prudent to utilize some of the tools mentioned in chapter 7 as a start. Remember, these tools don't replace continual system monitoring and good systems administration practices.
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 the system. One of the most important stages of responding to incidents is also the most often omitted, the follow-up stage. In the follow-up stage, the system should be monitored for items that may have been missed during the cleanup stage. It would be prudent to utilize some of the tools mentioned in chapter 7 as a start. Remember, these tools don't replace continual system monitoring and good systems administration practices.
The most important element of the follow-up stage is performing a postmortem analysis. Exactly what happened, and at what times? How well did the staff involved with the incident perform? What kind of information did the staff need quickly, and how could they have gotten that information as soon as possible? What would the staff do differently next time?
The most important element of the follow-up stage is performing a postmortem analysis. Exactly what happened, and at what times? How well did the staff involved with the incident perform? What kind of information did the staff need quickly, and how could they have gotten that information as soon as possible? What would the staff do differently next time?
After an incident, it is prudent to write a report describing the exact sequence of events: the method of discovery, correction procedure, monitoring procedure, and a summary of lesson learned. This will aid in the clear understanding of the problem. Creating a formal chronology of events (including time stamps) is also important for legal reasons.
After an incident, it is prudent to write a report describing the exact sequence of events: the method of discovery, correction procedure, monitoring procedure, and a summary of lesson learned. This will aid in the clear understanding of the problem. Creating a formal chronology of events (including time stamps) is also important for legal reasons.
Fraser, Ed. Informational [Page 57] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 57] RFC 2196 Site Security Handbook September 1997
A follow-up report is valuable for many reasons. It provides a reference to be used in case of other similar incidents. It is also important to, as quickly as possible obtain a monetary estimate of the amount of damage the incident caused. This estimate should include costs associated with any loss of software and files (especially the value of proprietary data that may have been disclosed), hardware damage, and manpower costs to restore altered files, reconfigure affected systems, and so forth. This estimate may become the basis for subsequent prosecution activity. The report can also help justify an organization's computer security effort to management.
A follow-up report is valuable for many reasons. It provides a reference to be used in case of other similar incidents. It is also important to, as quickly as possible obtain a monetary estimate of the amount of damage the incident caused. This estimate should include costs associated with any loss of software and files (especially the value of proprietary data that may have been disclosed), hardware damage, and manpower costs to restore altered files, reconfigure affected systems, and so forth. This estimate may become the basis for subsequent prosecution activity. The report can also help justify an organization's computer security effort to management.
5.5 Aftermath of an Incident
5.5 Aftermath of an Incident
In the wake of an incident, several actions should take place. These actions can be summarized as follows:
In the wake of an incident, several actions should take place. These actions can be summarized as follows:
(1) An inventory should be taken of the systems' assets,
(i.e., a careful examination should determine how the
system was affected by the incident).
(1) An inventory should be taken of the systems' assets, (i.e., a careful examination should determine how the system was affected by the incident).
(2) The lessons learned as a result of the incident
should be included in revised security plan to
prevent the incident from re-occurring.
(2) The lessons learned as a result of the incident should be included in revised security plan to prevent the incident from re-occurring.
(3) A new risk analysis should be developed in light of the
incident.
(3) A new risk analysis should be developed in light of the incident.
(4) An investigation and prosecution of the individuals
who caused the incident should commence, if it is
deemed desirable.
(4) An investigation and prosecution of the individuals who caused the incident should commence, if it is deemed desirable.
If an incident is based on poor policy, and unless the policy is changed, then one is doomed to repeat the past. Once a site has recovered from and incident, site policy and procedures should be reviewed to encompass changes to prevent similar incidents. Even without an incident, it would be prudent to review policies and procedures on a regular basis. Reviews are imperative due to today's changing computing environments.
If an incident is based on poor policy, and unless the policy is changed, then one is doomed to repeat the past. Once a site has recovered from and incident, site policy and procedures should be reviewed to encompass changes to prevent similar incidents. Even without an incident, it would be prudent to review policies and procedures on a regular basis. Reviews are imperative due to today's changing computing environments.
The whole purpose of this post mortem process is to improve all security measures to protect the site against future attacks. As a result of an incident, a site or organization should gain practical knowledge from the experience. A concrete goal of the post mortem is to develop new proactive methods. Another important facet of the aftermath may be end user and administrator education to prevent a reoccurrence of the security problem.
The whole purpose of this post mortem process is to improve all security measures to protect the site against future attacks. As a result of an incident, a site or organization should gain practical knowledge from the experience. A concrete goal of the post mortem is to develop new proactive methods. Another important facet of the aftermath may be end user and administrator education to prevent a reoccurrence of the security problem.
Fraser, Ed. Informational [Page 58] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 58] RFC 2196 Site Security Handbook September 1997
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 assume that one should protect other networks. During the handling of an incident, certain system vulnerabilities of one's own systems 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. 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 intruder.
It is one thing to protect one's own network, but quite another to assume that one should protect other networks. During the handling of an incident, certain system vulnerabilities of one's own systems 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. 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 intruder.
The best rule when it comes to propriety is to not use any facility of remote sites which is not public. This clearly excludes any entry onto a system (such as a remote shell or login session) which is not expressly permitted. This may be very tempting; after a breach of security is detected, a system administrator may have the means to "follow it up," to ascertain what damage is being done to the remote site. Don't do it! Instead, attempt to reach the appropriate point of contact for the affected site.
The best rule when it comes to propriety is to not use any facility of remote sites which is not public. This clearly excludes any entry onto a system (such as a remote shell or login session) which is not expressly permitted. This may be very tempting; after a breach of security is detected, a system administrator may have the means to "follow it up," to ascertain what damage is being done to the remote site. Don't do it! Instead, attempt to reach the appropriate point of contact for the affected site.
5.6.2 Good Internet Citizenship
5.6.2 Good Internet Citizenship
During a security incident there are two choices one can make. First, a site can choose to watch the intruder in the hopes of catching him; or, the site can go about cleaning up after the incident and shut the intruder out of the systems. This is a decision that must be made very thoughtfully, as there may be legal liabilities if you choose to leave your site open, knowing that an intruder is using your site as a launching pad to reach out to other sites. Being a good Internet citizen means that you should try to alert other sites that may have been impacted by the intruder. These affected sites may be readily apparent after a thorough review of your log files.
During a security incident there are two choices one can make. First, a site can choose to watch the intruder in the hopes of catching him; or, the site can go about cleaning up after the incident and shut the intruder out of the systems. This is a decision that must be made very thoughtfully, as there may be legal liabilities if you choose to leave your site open, knowing that an intruder is using your site as a launching pad to reach out to other sites. Being a good Internet citizen means that you should try to alert other sites that may have been impacted by the intruder. These affected sites may be readily apparent after a thorough review of your log files.
5.6.3 Administrative Response to Incidents
5.6.3 Administrative Response to Incidents
When a security incident involves a user, the site's security policy should describe what action is to be taken. The transgression should be taken seriously, but it is very important to be sure of the role the user played. Was the user naive? Could there be a mistake in attributing the security breach to the user? Applying administrative action that assumes the user intentionally caused the incident may
When a security incident involves a user, the site's security policy should describe what action is to be taken. The transgression should be taken seriously, but it is very important to be sure of the role the user played. Was the user naive? Could there be a mistake in attributing the security breach to the user? Applying administrative action that assumes the user intentionally caused the incident may
Fraser, Ed. Informational [Page 59] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 59] RFC 2196 Site Security Handbook September 1997
not be appropriate for a user who simply made a mistake. It may be appropriate to include sanctions more suitable for such a situation in your policies (e.g., education or reprimand of a user) in addition to more stern measures for intentional acts of intrusion and system misuse.
not be appropriate for a user who simply made a mistake. It may be appropriate to include sanctions more suitable for such a situation in your policies (e.g., education or reprimand of a user) in addition to more stern measures for intentional acts of intrusion and system misuse.
6. Ongoing Activities
6. Ongoing Activities
At this point in time, your site has hopefully developed a complete security policy and has developed procedures to assist in the configuration and management of your technology in support of those 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. Unfortunately, that isn't possible. Your systems and networks are 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 take to help you keep up with the changes around you so that you can initiate corresponding actions to address those changes. The following is a starter set and you may add others as appropriate for your site.
At this point in time, your site has hopefully developed a complete security policy and has developed procedures to assist in the configuration and management of your technology in support of those 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. Unfortunately, that isn't possible. Your systems and networks are 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 take to help you keep up with the changes around you so that you can initiate corresponding actions to address those changes. The following is a starter set and you may add others as appropriate for your site.
(1) Subscribe to advisories that are issued by various security incident
response teams, like those of the CERT Coordination Center, and
update your systems against those threats that apply to your site's
technology.
(1) Subscribe to advisories that are issued by various security incident response teams, like those of the CERT Coordination Center, and update your systems against those threats that apply to your site's technology.
(2) Monitor security patches that are produced by the vendors of your
equipment, and obtain and install all that apply.
(2) Monitor security patches that are produced by the vendors of your equipment, and obtain and install all that apply.
(3) Actively watch the configurations of your systems to identify any
changes that may have occurred, and investigate all anomalies.
(3) Actively watch the configurations of your systems to identify any 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 relevant mailing lists and USENET newsgroups to keep up to
date with the latest information being shared by fellow
administrators.
(5) Read relevant mailing lists and USENET newsgroups to keep up to date with the latest information being shared by fellow administrators.
(6) Regularly check for compliance with policies and procedures. This
audit should be performed by someone other than the people who
define or implement the policies and procedures.
(6) Regularly check for compliance with policies and procedures. This audit should be performed by someone other than the people who define or implement the policies and procedures.
7. Tools and Locations
7. Tools and Locations
This chapter provides a brief list of publicly available security technology which can be downloaded from the Internet. Many of the items described below will undoubtedly be surpassed or made obsolete before this document is published.
This chapter provides a brief list of publicly available security technology which can be downloaded from the Internet. Many of the items described below will undoubtedly be surpassed or made obsolete before this document is published.
Fraser, Ed. Informational [Page 60] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 60] RFC 2196 Site Security Handbook September 1997
Some of the tools listed are applications such as end user programs (clients) and their supporting system infrastructure (servers). 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.
Some of the tools listed are applications such as end user programs (clients) and their supporting system infrastructure (servers). 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.
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 one of the following archive sites:
Most of the tools and applications described below can be found in one of the following archive sites:
(1) CERT Coordination Center
ftp://info.cert.org:/pub/tools
(2) DFN-CERT
ftp://ftp.cert.dfn.de/pub/tools/
(3) Computer Operations, Audit, and Security Tools (COAST)
coast.cs.purdue.edu:/pub/tools
(1) CERT Coordination Center ftp://info.cert.org:/pub/tools (2) DFN-CERT ftp://ftp.cert.dfn.de/pub/tools/ (3) Computer Operations, Audit, and Security Tools (COAST) coast.cs.purdue.edu:/pub/tools
It is important to note that many sites, including CERT and COAST are mirrored throughout the Internet. Be careful to use a "well known" mirror site to retrieve software, and to use verification tools (md5 checksums, etc.) to validate that software. A clever cracker might advertise security software that has intentionally been designed to provide access to data or systems.
It is important to note that many sites, including CERT and COAST are mirrored throughout the Internet. Be careful to use a "well known" mirror site to retrieve software, and to use verification tools (md5 checksums, etc.) to validate that software. A clever cracker might advertise security software that has intentionally been designed to provide access to data or systems.
Tools
Tools
COPS DES Drawbridge identd (not really a security tool) ISS Kerberos logdaemon lsof MD5 PEM PGP rpcbind/portmapper replacement SATAN sfingerd S/KEY smrsh
COPS DES Drawbridge identd (not really a security tool) ISS Kerberos logdaemon lsof MD5 PEM PGP rpcbind/portmapper replacement SATAN sfingerd S/KEY smrsh
Fraser, Ed. Informational [Page 61] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 61] RFC 2196 Site Security Handbook September 1997
ssh swatch TCP-Wrapper tiger Tripwire* TROJAN.PL
ssh swatch TCP-Wrapper tiger Tripwire* TROJAN.PL
8. Mailing Lists and Other Resources
8. Mailing Lists and Other Resources
It would be impossible to list all of the mail-lists and other resources dealing with site security. However, these are some "jump- points" from which the reader can begin. All of these references are for the "INTERNET" constituency. More specific (vendor and geographical) resources can be found through these references.
It would be impossible to list all of the mail-lists and other resources dealing with site security. However, these are some "jump- points" from which the reader can begin. All of these references are for the "INTERNET" constituency. More specific (vendor and geographical) resources can be found through these references.
Mailing Lists
Mailing Lists
(1) CERT(TM) Advisory
Send mail to: cert-advisory-request@cert.org
Message Body: subscribe cert <FIRST NAME> <LAST NAME>
(1) CERT(TM) Advisory Send mail to: cert-advisory-request@cert.org Message Body: subscribe cert <FIRST NAME> <LAST NAME>
A CERT advisory provides information on how to obtain a patch or
details of a workaround for a known computer security problem.
The CERT Coordination Center works with vendors to produce a
workaround or a patch for a problem, and does not publish
vulnerability information until a workaround or a patch is
available. A CERT advisory may also be a warning to our
constituency about ongoing attacks (e.g.,
"CA-91:18.Active.Internet.tftp.Attacks").
A CERT advisory provides information on how to obtain a patch or details of a workaround for a known computer security problem. The CERT Coordination Center works with vendors to produce a workaround or a patch for a problem, and does not publish vulnerability information until a workaround or a patch is available. A CERT advisory may also be a warning to our constituency about ongoing attacks (e.g., "CA-91:18.Active.Internet.tftp.Attacks").
CERT advisories are also published on the USENET newsgroup:
comp.security.announce
CERT advisories are also published on the USENET newsgroup: comp.security.announce
CERT advisory archives are available via anonymous FTP from
info.cert.org in the /pub/cert_advisories directory.
CERT advisory archives are available via anonymous FTP from info.cert.org in the /pub/cert_advisories directory.
(2) VIRUS-L List
Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu
Message Body: subscribe virus-L FIRSTNAME LASTNAME
(2) VIRUS-L List Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu Message Body: subscribe virus-L FIRSTNAME LASTNAME
VIRUS-L is a moderated mailing list with a focus
on computer virus issues. For more information,
including a copy of the posting guidelines, see
the file "virus-l.README", available by anonymous
FTP from cs.ucr.edu.
VIRUS-L is a moderated mailing list with a focus on computer virus issues. For more information, including a copy of the posting guidelines, see the file "virus-l.README", available by anonymous FTP from cs.ucr.edu.
Fraser, Ed. Informational [Page 62] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 62] RFC 2196 Site Security Handbook September 1997
(3) Internet Firewalls
Send mail to: majordomo@greatcircle.com
Message Body: subscribe firewalls user@host
(3) Internet Firewalls Send mail to: majordomo@greatcircle.com Message Body: subscribe firewalls user@host
The Firewalls mailing list is a discussion forum for
firewall administrators and implementors.
The Firewalls mailing list is a discussion forum for firewall administrators and implementors.
USENET newsgroups
USENET newsgroups
(1) comp.security.announce
The comp.security.announce newsgroup is moderated
and is used solely for the distribution of CERT
advisories.
(1) comp.security.announce The comp.security.announce newsgroup is moderated and is used solely for the distribution of CERT advisories.
(2) comp.security.misc
The comp.security.misc is a forum for the
discussion of computer security, especially as it
relates to the UNIX(r) Operating System.
(2) comp.security.misc The comp.security.misc is a forum for the discussion of computer security, especially as it relates to the UNIX(r) Operating System.
(3) alt.security
The alt.security newsgroup is also a forum for the
discussion of computer security, as well as other
issues such as car locks and alarm systems.
(3) alt.security The alt.security newsgroup is also a forum for the discussion of computer security, as well as other issues such as car locks and alarm systems.
(4) comp.virus
The comp.virus newsgroup is a moderated newsgroup
with a focus on computer virus issues. For more
information, including a copy of the posting
guidelines, see the file "virus-l.README",
available via anonymous FTP on info.cert.org
in the /pub/virus-l directory.
(4) comp.virus The comp.virus newsgroup is a moderated newsgroup with a focus on computer virus issues. For more information, including a copy of the posting guidelines, see the file "virus-l.README", available via anonymous FTP on info.cert.org in the /pub/virus-l directory.
(5) comp.risks
The comp.risks newsgroup is a moderated forum on
the risks to the public in computers and related
systems.
(5) comp.risks The comp.risks newsgroup is a moderated forum on the risks to the public in computers and related systems.
World-Wide Web Pages
World-Wide Web Pages
(1) http://www.first.org/
(1) http://www.first.org/
Computer Security Resource Clearinghouse. The main focus is on
crisis response information; information on computer
security-related threats, vulnerabilities, and solutions. At the
same time, the Clearinghouse strives to be a general index to
computer security information on a broad variety of subjects,
including general risks, privacy, legal issues, viruses,
assurance, policy, and training.
Computer Security Resource Clearinghouse. The main focus is on crisis response information; information on computer security-related threats, vulnerabilities, and solutions. At the same time, the Clearinghouse strives to be a general index to computer security information on a broad variety of subjects, including general risks, privacy, legal issues, viruses, assurance, policy, and training.
Fraser, Ed. Informational [Page 63] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 63] RFC 2196 Site Security Handbook September 1997
(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
sources on Network and Computer Security. There is no implied
fitness to the Tools, Techniques and Documents contained within this
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
education and legitimate use of computer security techniques only.
This Reference Index contains a list of links to information sources on Network and Computer Security. There is no implied fitness to the Tools, Techniques and Documents contained within this 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 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.
Information is organized by source and each section is organized
by topic. Recent modifications are noted in What's New page.
This page features general information about computer security. Information is organized by source and each section is organized by topic. Recent modifications are noted in What's New page.
(4) http://csrc.ncsl.nist.gov
(4) http://csrc.ncsl.nist.gov
This archive at the National Institute of Standards and Technology's
Computer Security Resource Clearinghouse page contains a number of
announcements, programs, and documents related to computer security.
This archive at the National Institute of Standards and Technology's Computer Security Resource Clearinghouse page contains a number of announcements, programs, and documents related to computer security.
* CERT and Tripwire are registered in the U.S. Patent and Trademark Office
* CERT and Tripwire are registered in the U.S. Patent and Trademark Office
9. References
9. References
The following references may not be available in all countries.
The following references may not be available in all countries.
[Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and McAuliffe, "The Law and The Internet", USENIX 1995 Technical Conference on UNIX and Advanced Computing, New Orleans, LA, January 16-20, 1995.
[Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and McAuliffe, "The Law and The Internet", USENIX 1995 Technical Conference on UNIX and Advanced Computing, New Orleans, LA, January 16-20, 1995.
[ABA, 1989] American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989.
[ABA, 1989] American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989.
[Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989.
[Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989.
[Barrett, 1996] D. Barrett, "Bandits on the Information Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.
[Barrett, 1996] D. Barrett, "Bandits on the Information Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.
[Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, Telecommunications and Data Communications", McGraw-Hill, 1992.
[Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, Telecommunications and Data Communications", McGraw-Hill, 1992.
[Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, April 1989.
[Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, April 1989.
Fraser, Ed. Informational [Page 64] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 64] RFC 2196 Site Security Handbook September 1997
[Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, October 1990.
[Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, October 1990.
[Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings of the Third Usenix Security Symposium, Baltimore, MD. September, 1992.
[Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings of the Third Usenix Security Symposium, Baltimore, MD. September, 1992.
[Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. Bender, New York, NY, 1978-present.
[Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. Bender, New York, NY, 1978-present.
[Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", Dow Jones- Irwin, Homewood, IL. 1990.
[Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", Dow Jones- Irwin, Homewood, IL. 1990.
[Brand, 1990] R. Brand, "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 June 1990.
[Brand, 1990] R. Brand, "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 June 1990.
[Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.
[Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.
[BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, "BS 7799 : 1995 Code of Practice for Information Security Management", British Standards Institution, London, 54, Effective 15 February 1995.
[BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, "BS 7799 : 1995 Code of Practice for Information Security Management", British Standards Institution, London, 54, Effective 15 February 1995.
[Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88.
[Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88.
[Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987.
[Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987.
[Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and The Law", MIT Press, Cambridge, MA, 1995.
[Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and The Law", MIT Press, Cambridge, MA, 1995.
[CCH, 1989] Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989.
[CCH, 1989] Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989.
[Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, Baltimore, MD, September 1992.
[Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, Baltimore, MD, September 1992.
[Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.
[Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.
Fraser, Ed. Informational [Page 65] RFC 2196 Site Security Handbook September 1997
Fraser, Ed. Informational [Page 65] RFC 2196 Site Security Handbook September 1997
[Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.
[Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.
[Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker is Lured, Endured, and Studied", AT&T Bell Laboratories.
[Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker is Lured, Endured, and Studied", AT&T Bell Laboratories.
[Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, Reading, MA, 1994.
[Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, Reading, MA, 1994.
[Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, National Institute of Justice, Washington, DC, July 1989.
[Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, National Institute of Justice, Washington, DC, July 1989.
[Cooper, 1989] J. Cooper, "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989.
[Cooper, 1989] J. Cooper, "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989.
[CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989.
[CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989.
[CSC-STD-002-85, 1985] Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.
[CSC-STD-002-85, 1985] Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.
[Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.
[Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.
[Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and Systems Administrators", Addision-Wesley, Reading, MA, 1992.
[Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and Systems Administrators", Addision-Wesley, Reading, MA, 1992.
[DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988.
[DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988.
[DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989.
[DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989.
[Denning, 1990] P. Denning, Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990.
[Denning, 1990] P. Denning, Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990.
[Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", Massachusetts Institute of Technology, February 1989.
[EichinとRochlis、1989] M.Eichin、およびJ.Rochlis、「顕微鏡座とピンセットで:、」 「1988年11月のインターネットウイルスの分析」、マサチューセッツ工科大学、1989年2月。
Fraser, Ed. Informational [Page 66] RFC 2196 Site Security Handbook September 1997
フレーザ、[66ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 February 1989.
[エイゼンバーグet(アル)と89]T.エイゼンバーグとD.グリースとJ.HartmanisとD.ホルコム、M.リンとT.サントーロ、「コンピュータワーム」コーネル大学(1989年2月6日)。
[Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford University Press, NY, 1990. (376 pages, includes bibliographical references).
[Ermann、WilliansとグティエレスとD.Ermann、1990年の]M.ウィリアムズとC.グティエレス、エディターズ「コンピュータ、倫理、および社会」オックスフォード大学出版局、ニューヨーク、1990 (376ページ、インクルード参照。)
[Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS Security Checker System", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, Pgs. 165-170, June 1990.
[ファーマーとSpafford、1990] D.農業者とE.Spafford、「巡査セキュリティはシステムが数奇です」、1990年夏のUSENIXコンファレンスの議事、アナハイム(カリフォルニア)Pgs。 165-170と、1990年6月。
[Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley, Reading, MA, 1991.
[MA、1991年の]リクFarrow、「UNIXシステムセキュリティ」、アディソン-ウエスリーが読む1991に子を産ませてください。
[Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial Tactics and Techniques", Litigation Course Handbook Series No. 280, Prepared for distribution at the Computer Litigation, 1985: Trial Tactics and Techniques Program, February-March 1985.
W.フェニック、[フェニック、1985]議長、「コンピュータ訴訟、1985:」 「トライアルTacticsとTechniques」、Litigation Course Handbook Series No.280、コンピュータLitigation、1985での分配のためのPrepared: 指揮法が1985年2月-3月にプログラムするトライアル。
[Fites 1989] M. Fites, P. Kratz, and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989.
[ファイツ1989]M.ファイツ、P.クラッツ、およびA.Brebner、コンピュータサイエンスは「コンピュータ情報システムのコントロールとセキュリティ」と1989に押します。
[Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.
[ファイツ、ジョンソンとクラッツ、ファイツ、1992年の]ジョンソンとクラッツ、「コンピュータウィルス危機」ヴァン・Hostrandラインホルト、2番目の版、1992。
[Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[森林学者、モリソン、1990年の]T.森林学者、およびP.モリソン、「コンピュータ倫理:」 MITは、「コンピューティングにおける物語と倫理的ジレンマ」と押して、ケンブリッジ(MA)は1990です。
[Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. (192 pages including index.)
[フォスターとMorrision、1990] T.森林学者、およびP.モリソン、「コンピュータ倫理:」 MITは、「コンピューティングにおける物語と倫理的ジレンマ」と押して、ケンブリッジ(MA)は1990です。 (インデックスを含む192ページ。)
[GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer Security - Virus Highlights Need for Improved Internet Management", United States General Accounting Office, Washington, DC, 1989.
[カオ/IMTEX-89-57、会計検査院、1989の]米国の「ハイライトが改良されたインターネット管理に必要とするコンピュータセキュリティ--ウイルス」合衆国会計検査院ワシントン(DC)1989。
[Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford, "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, May 1991.
[ガーフィンケルとSpafford、1991] S.ガーフィンケル、E.Spafford、「実用的なunixセキュリティ」、オライリー、および仲間(ISBN0-937175-72-2)は1991がそうするかもしれません。
[Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & Associates, Sebastopol, CA, 1996.
[ガーフィンケル、1995]S.ガーフィンケルと「PGP: プリティ・グッド・プライバシ」とオライリーと仲間、Sebastopol、カリフォルニア1996
Fraser, Ed. Informational [Page 67] RFC 2196 Site Security Handbook September 1997
フレーザ、[67ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford, "Practical UNIX and Internet Security", O'Reilly & Associates, Sebastopol, CA, 1996.
[ガーフィンケルとSpafford、1996] S.ガーフィンケル、E.Spafford、および「実用的なUNIXとインターネットセキュリティ」、オライリーと仲間、Sebastopol、カリフォルニア1996
[Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[Gemignani、1989] M.Gemignaniと、「ウイルスと刑法」、ACMに関するコミュニケーション、Vol.32、No.6、Pgs。 669-671と、1989年6月。
[Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell Publishing, 1996.
[グッデル、1996]J.グッデル、「コンピュータ泥棒とさむらい:」 そして、「ケビンの実話、Mitnick、-、デルが発行されることでの彼を探した男性」1996
[Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO, 1989.
[グールド、1989]C.グールド、エディタ、「情報ウェブ:」 「コンピュータのネットワーク化の倫理的で社会的な含意」、Westviewプレス、ボウルダー、CO、1989。
[Greenia, 1989] M. Greenia, "Computer Security Information Sourcebook", Lexikon Services, Sacramento, CA, 1989.
[Greenia、1989] M.Greenia、「コンピュータセキュリティ情報底本」、Lexikonサービス、サクラメント、カリフォルニア、1989。
[Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk: Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & Schuster, 1991.
[ハーフナーとマルコフ、1991]K.ハーフナーとJ.マルコフ、「サイバーパンク:」 「コンピュータ国境の無法者とハッカー」と試金石とサイモンとシュスター、1991。
[Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix Network Protocol Security Study: Network Information Service", Texas A&M University.
[ヘス、Safford、および犬] D.ヘス、D.Safford、およびU.犬、「unixネットワーク・プロトコルセキュリティは研究します」。 「ネットワーク情報サービス」、テキサスA&M大学。
[Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages, includes bibliographical references and index.)
[ホフマン、1990]L.ホフマン、「プログラムをだましてください」 「ウイルス、ワーム、およびトロイの木馬」はNostrandラインホルト、ニューヨーク、1990をバンに積みます。 (384のページ、インクルード参照、およびインデックス。)
[Howard, 1995] G. Howard, "Introduction to Internet Security: From Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.
[ハワード、1995]G.ハワード、「インターネットセキュリティへの序論:」 「基礎から以遠」、第一の出版、Rocklin、カリフォルニア1995。
[Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, "Protection of Computer Systems and Software: New Approaches for Combating Theft of Software and Unauthorized Intrusion", Papers presented at a workshop sponsored by the National Science Foundation, 1986.
[Hubandとシェルトン、1986]F.Huband、R.シェルトン、エディターズ、「コンピュータ・システムとソフトウェアの保護:」 Papersは、国立科学財団、1986年までに後援されたワークショップに「SoftwareとUnauthorized IntrusionのCombating Theftのための新しいApproaches」と提示しました。
[Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security Techniques", New Riders Publishing, Indianapolis, IN, 1995.
[ヒューズ、1995]L.ヒューズJr.、「実際に役に立つインターネットセキュリティのテクニック」新しいライダーが発行することでのインディアナポリス(IN)1995。
[IAB-RFC1087, 1989] Internet Activities Board, "Ethics and the Internet", RFC 1087, IAB, January 1989. Also appears in the Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.
[IAB-RFC1087、1989]インターネット、活動ボードと、「倫理学とインターネット」、RFC1087、IAB、1月1989日 また、ACMのCommunications、Vol.32、No.6、Pgでは、現れます。 710 1989年6月。
Fraser, Ed. Informational [Page 68] RFC 2196 Site Security Handbook September 1997
フレーザ、[68ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & Associates, Sebastopol, CA, 1995.
[Icove、シーガー、VonStorch、1995]D.Icove、K.シーガー、およびW.VonStorch、「コンピュータ犯罪:」 「Crimefighterのハンドブック」とオライリーと仲間、Sebastopol、カリフォルニア1995
[IVPC, 1996] IVPC, "International Virus Prevention Conference '96 Proceedings", NCSA, 1996.
[IVPC、1996] IVPC、「国際ウイルス防止コンファレンス96年の議事」、NCSA、1996。
[Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems".
[ジョンソンとポデスタ]D.ジョンソン、および「会社コンピュータシステムズの電子メールのアクセスと使用と公開のときに企業目的を定式化する」J.ポデスタ。
[Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The Ongoing War Against Information Sabotage", M&T Books, 1994.
[ケーン、1994]P.ケーン、「PCセキュリティとウイルスの防止ハンドブック:」 「情報サボタージュに対する進行中の戦争」、M&Tの本、1994。
[Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall, Englewood Cliffs, NJ, 1995.
[コーフマン、パールマン、Speciner、1995年の]C.コーフマン、R.パールマン、およびM.Speciner、「セキュリティをネットワークでつないでください」 「公立の世界の私信」、新米のホール、イングルウッドがけ、ニュージャージー、1995。
[Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software and Strict Registration Procedures will be Implemented this Year", Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 1990.
[ケント、1990]S.ケント、「インターネットにプライバシーをメールしてください」 「新しいSoftwareとStrict Registration ProceduresはImplementedがこのYearであったならそうするでしょう」、Business Communications Review、Vol.20、No.1、Pg。 55 1990年1月1日。
[Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution", Delta, 1984.
[課税、1984] S.課税、「ハッカー:」 「コンピュータ革命の幸福の旅路」、デルタ、1984。
[Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems Audit Group, 1996.
[ルイス、1996]S.ルイス、「災害復旧イエローページ」、システム監査グループ、1996。
[Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin Mitnick", Little, Brown, Boston, MA., 1996.
[Littleman、1996] J.Littleman、「逃亡者は勝負事をします」。 「ケビンMitnickのオンライン」と、小さくて、茶色のボストン(MA)、1996
[Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure Communication in Internet Environments: A Hierarchical Key Management Scheme for End-to-End Encryption", IEEE Transactions on Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[LuとSundareshan、1989]のW.LuとM.Sundareshan、「インターネット環境におけるコミュニケーションを保証してください」 「終端間暗号化の階層的なKey Management体系」、コミュニケーション、Vol.37、No.10、Pgの上のIEEEトランザクション。 1014、1989年10月1日。
[Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for Multilevel Security in Computer Networks", IEEE Transactions on Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.
[LuとSundareshan、1990] W.LuとM.Sundareshan、「多レベルセキュリティのためのコンピュータネットワークのモデル」、ソフトウェア工学、Vol.16、No.6、647ページ(1990年6月1日)のIEEEトランザクション。
[Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989.
[マーチンとシンチンゲル、1989]M.マーチン、およびR.シンチンゲル、「工学の倫理学」、マクグロー・ヒル、第2版、1989。
[Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal of Cryptology, Vol. 3, No. 1.
[Merkle]R.Merkle、「速いソフトウェア一方通行のハッシュ関数」、暗号理論、Vol.3、No.1のジャーナル。
Fraser, Ed. Informational [Page 69] RFC 2196 Site Security Handbook September 1997
フレーザ、[69ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report Contributors: D. Fester and H. Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by Institute for Law and Justice, Inc., under contract number OJP-85-C-006, Washington, DC, 1989.
[マキューエン、1989]J.マキューエン、「専用コンピュータ犯罪ユニット」と、貢献者は報告します: D。 化膿とH.ニュージェント、国立司法研究所、法のためのInstituteとOJP85C006、ワシントン、契約番号DCの下の司法のInc.による米国司法省1989年のPrepared。
[MIT, 1989] Massachusetts Institute of Technology, "Teaching Students About Responsible Use of Computers", MIT, 1985-1986. Also reprinted in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena Project, MIT, June 1989.
[MIT、1989] マサチューセッツ工科大学、「コンピュータの責任ある利用に関して学生に教えます」、MIT、1985-1986。 また、ACMのCommunications、Vol.32、No.6、Pgでは、増刷されています。 704 アティナプロジェクト、MIT、1989年6月。
[Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX-based Gateways", Digital Western Research Laboratory Research Report 89/4, March 1989.
[Mogel、1989] ムガール人、J.、「簡単でフレキシブルなデータグラムアクセスはUNIXベースのゲートウェイに制御します」、デジタル西洋の研究所研究レポート89/4、1989年3月。
[Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password Checker for Unix"
[Muffett、1992]A.Muffett、「バージョン4.1を解いてください」 「unixのための分別があるパスワード市松模様」
[NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995.
[NCSA1、1995] NCSA、「NCSAファイアウォール方針ガイド」、1995。
[NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention Policy Model", NCSA, 1995.
[NCSA2、1995] NCSA、「NCSAの法人のコンピュータウィルス防止政策モデル」、NCSA、1995。
[NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 Proceedings", 1996.
1996の[NCSA、1996]NCSAと、「ファイアウォールとインターネットセキュリティコンファレンス96年の議事」
[NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines for Formal Verification Systems", Shipping list no.: 89-660-P, The Center, Fort George G. Meade, MD, 1 April 1990.
[NCSC-89-660-P、1990] 国家のコンピュータSecurityセンター、「正式な検証制度のためのガイドライン」、送料リストノー: 89-660P、センター、とりでジョージG.ミード(MD)1990年4月1日。
[NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of Computer Security Terms", Shipping list no.: 89-254-P, The Center, Fort George G. Meade, MD, 21 October 1988.
[NCSC-89-254-P、1988] 国家のコンピュータSecurityセンター、「コンピュータセキュリティ用語の用語集」、送料リストノー: 89-254P、センター、とりでジョージG.ミード(MD)1988年10月21日。
[NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989.
ティント、[NCSC-C1-001-89、1989]M.、「コンピュータウイルス:」 国家のコンピュータセキュリティは、「防止、検出、および処理」と中心に置きます。1989年6月のC1技術報告書C1-001-89。
[NCSC Conference, 1989] National Computer Security Conference, "12th National Computer Security Conference: Baltimore Convention Center, Baltimore, MD, 10-13 October, 1989: Information Systems Security, Solutions for Today - Concepts for Tomorrow", National Institute of Standards and National Computer Security Center, 1989.
[NCSCコンファレンス、1989] 国家のコンピュータセキュリティコンファレンス、「第12国家のコンピュータセキュリティコンファレンス:」 ボルチモアコンベンションセンター、1989年ボルチモア(MD)10-13 10月: 「情報システムセキュリティ、今日のソリューション--、明日の概念、」、規格の国家の研究所と国家のコンピュータセキュリティセンター、1989
[NCSC-CSC-STD-003-85, 1985] National Computer Security Center, "Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", CSC-STD-003-85, NCSC, 25 June 1985.
[NCSC-CSC-STD-003-85、1985] 国家のコンピュータセキュリティセンター、「国防総省を適用するための指導は特定の環境におけるコンピュータシステム評価を信じました」、CSC-STD-003-85、NCSC、1985年6月25日。
Fraser, Ed. Informational [Page 70] RFC 2196 Site Security Handbook September 1997
フレーザ、[70ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[NCSC-STD-004-85, 1985] National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 June 1985.
[NCSC-STD-004-85、1985] 国家のコンピュータセキュリティセンター、「CSC-STD-003-85の後ろの技術的な原理:」 「コンピュータセキュリティ要件」、CSC-STD-004-85、NCSC、1985年6月25日。
[NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985.
[NCSC-STD-005-85、1985] 国家のコンピュータセキュリティセンター、「磁気残留分極安全ガイドライン」、CSC-STD-005-85、NCSC、1985年11月15日。
[NCSC-TCSEC, 1985] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001- 83, NCSC, December 1985.
[NCSC-TCSEC、1985] 国家のコンピュータセキュリティセンター、「信じられたコンピュータシステム評価」、DoD 5200.28-STD、CSC-STD-001- 83、NCSC、1985年12月。
[NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 September 1987, 29 pages.
[NCSC-TG-003、1987] NCSC、「信じられたシステムにおける任意のアクセスコントロールを理解していることへのガイド」、NCSC-TG-003、1987年9月30日、29ページのバージョン-1。
[NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
[NCSC-TG-001、1988] NCSC、「信じられたシステムにおける監査を理解していることへのガイド」、NCSC-TG-001、1988年6月1日、25ページのバージョン-2。
[NCSC-TG-004, 1988] National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
[NCSC-TG-004、1988] 国家のコンピュータセキュリティセンター、「コンピュータセキュリティ用語の用語集」、NCSC-TG-004、NCSC、1988年10月21日。
[NCSC-TG-005, 1987] National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
[NCSC-TG-005、1987] 国家のコンピュータセキュリティセンター、「信じられたネットワーク解釈」、NCSC-TG-005、NCSC、1987年7月31日。
[NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988, 31 pages.
[NCSC-TG-006、1988] NCSC、「信じられたシステムの構成管理を理解していることへのガイド」、NCSC-TG-006、1988年3月28日、31ページのバージョン-1。
[NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX Working Group (TRUSIX) rationale for selecting access control list features for the UNIX system", Shipping list no.: 90-076-P, The Center, Fort George G. Meade, MD, 1990.
[NCSC-TRUSIX、1990] 国家のコンピュータSecurityセンター、「UNIXシステムのためのアクセスコントロールリスト機能を選択するための信じられたUNIX作業部会(TRUSIX)原理」、送料リストノー: 90-076P、センター、とりでジョージ・G.ミード(MD)1990。
[NRC, 1991] National Research Council, "Computers at Risk: Safe Computing in the Information Age", National Academy Press, 1991.
[NRC、1991] 調査評議会、「危険なコンピュータ:」 「情報化時代の安全なコンピューティング」、国家のアカデミープレス、1991。
[Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein, "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood Cliffs, NJ, 2nd ed. 1995.
[et Nemeth、アル、1995]E.NemethとG.スナイダー、S.SeebassとT.ハイン、「UNIXシステム政権ハンドブック。」(Prentice Hall PTR、イングルウッドCliffs、ニュージャージーの2番目の教育) 1995.
[NIST, 1989] National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500-166, August 1989.
[NIST、1989] 米国商務省標準技術局、「コンピュータウイルスと関連脅威:」 「マネジメント・ガイド」、NISTの特別な公表500-166、1989年8月。
[NSA] National Security Agency, "Information Systems Security Products and Services Catalog", NSA, Quarterly Publication.
[NSA]国家安全保障局、「情報システムセキュリティ製品とサービスはカタログに載る」NSA、季刊刊行物。
Fraser, Ed. Informational [Page 71] RFC 2196 Site Security Handbook September 1997
フレーザ、[71ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[NSF, 1988] National Science Foundation, "NSF Poses Code of Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688, June 1989. Also appears in the minutes of the regular meeting of the Division Advisory Panel for Networking and Communications Research and Infrastructure, Dave Farber, Chair, November 29-30, 1988.
[NSF、1988] 科学基金、「NSFはネットワーク倫理の規範を引き起こす」ACMに関するコミュニケーション、Vol.32、No.6、Pg。 688 1989年6月。 また、事業部Advisory Panelの例会の議事録の間、1988年11月29日〜30日にNetworkingとCommunications ResearchとInfrastructure、デーヴ・ファーバー、議長に見えます。
[NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 pages.
[NTISSAM、1987]NTISS、「オフィス・オートメーション安全ガイドラインの顧問メモ」、NTISSAM COMPUSEC/1-87、1987年1月16日、58ページ。
[OTA-CIT-310, 1987] United States Congress, Office of Technology Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for Electronic Information", OTA-CIT-310, October 1987.
合衆国議会、[OTA-CIT-310、1987]技術評価局、「防御しているシークレット、データを共有します:」 「電子情報のための新しい錠とキー」、OTA-CIT-310、10月1987日
[OTA-TCT-606] Congress of the United States, Office of Technology Assessment, "Information Security and Privacy in Network Environments", OTA-TCT-606, September 1994.
合衆国、技術評価局、「情報セキュリティとプライバシーは中で環境をネットワークでつなぐ」OTA-TCT-606、1994年9月の[OTA-TCT-606]議会。
[Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer Security Risk Management", Van Nostrand Reinhold, NY, 1989.
[パーマーとポッター、1989]I.パーマー、およびG.ポッター、「コンピュータセキュリティリスク管理」はNostrandラインホルト、ニューヨーク、1989をバンに積みます。
[Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource Manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., August 1989.
[パーカー、1989]D.パーカー、「コンピュータ犯罪:」 「刑事裁判リソースマニュアル」、最高裁判所判事の米国部、国立司法研究所、司法のオフィスは契約番号OJP86C002の下でワシントンDC(1989年8月)をプログラムします。
[Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. (245 pages).
[パーカー、スウォープ、ベイカー、1990年の]D.パーカー、S.スウォープ、およびB.ベイカー、「倫理的な闘争:」 「情報、コンピュータサイエンス、技術、およびビジネス」、QED情報科学Inc.、ウェルズリー、MA。 (245ページ。)
[Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, Englewood Cliffs, NJ, 1989.
[Pfleeger、1989] C.Pfleeger、「コンピューティングにおけるセキュリティ」、新米のホール、イングルウッドがけ、ニュージャージー、1989。
[Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 1990.
J.Quarterman、[Quarterman、1990]J.、「マトリクス:」 ベッドフォード、Digitalが「世界中のコンピュータネットワークと会議システム」と押す、MA、1990
[Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World Conference on Systems Management and Security, 1992.
[Ranum1、1992] M.Ranum、「インターネットファイアウォール」、システム管理とセキュリティにおける世界会議の議事、1992。
[Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment Corporation Washington Open Systems Resource Center, June 12, 1992.
[Ranum2、1992] M.Ranum、「ネットワークファイアウォール」とDECワシントンオープンシステムリソースは、1992年6月12日に中心に置きます。
[Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993.
[Ranum、1993] M.Ranum、「ファイアウォールについて考えます」、1993。
Fraser, Ed. Informational [Page 72] RFC 2196 Site Security Handbook September 1997
フレーザ、[72ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and Methods for Internet Firewalls", Trustest Information Systems, 1994.
[RanumとAvolio、1994] M.Ranum、F.Avolio、および「インターネットファイアウォールへのツールキットとメソッド」、Trustest情報システム、1994
[Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX Network Security"
[ラインハート、1992]R.ラインハート、「UNIXネットワークセキュリティの建築概要」
[Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX Network Security", ARINC Research Corporation, February 18, 1993.
[ラインハート、1993]R.ラインハート、「UNIXネットワークセキュリティの建築概要」、ARINC研究社、1993年2月18日。
[Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135, USC/Information Sciences Institute, Marina del Rey, CA, December 1989.
[レイノルズ-RFC1135、1989] インターネット、RFC1135、USC/情報Sciences Institute、マリナデルレイのHelminthiasis、カリフォルニア1989年12月。
[Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991.
[ラッセルとGangemi、1991] D.ラッセル、G.Gangemi、「コンピュータセキュリティ基礎」オライリー、および仲間、Sebastopol、カリフォルニア1991。
[Schneier 1996] B. Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, New York, second edition, 1996.
[シュナイアー1996]B.シュナイアー、「適用された暗号:」 「C」とジョン・ワイリーとソンス、ニューヨーク、第2版、1996年のプロトコル、Algorithms、およびSource Code
[Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, February 1989.
[セーレー、1989]D.セーレー、「ワームのツアー」、1989年の冬のUSENIXコンファレンスの議事、Usenix協会(サンディエゴ(カリフォルニア)1989年2月)。
[Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.
[ショー、1986]E.ショーJr.、「1986年のコンピューター詐欺濫用防止法」、連邦議会議事録(1986年6月3日)、ワシントンDC(1986年6月3日)。
[Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw- by the Man Who Did It", Hyperion, 1996.
[Shimomura、1996] J.マルコフがいるT.Shimomura、「分解: ケビンMitnick、アメリカの最重要手配人コンピュータの追求と捕獲はそれをした男性を追放する」ヒペリオン、1996。
[Shirey, 1990] R. Shirey, "Defense Data Network Security Architecture", Computer Communication Review, Vol. 20, No. 2, Page 66, 1 April 1990.
[Shirey、1990] R.Shirey、「ディフェンスデータ網セキュリティー体系」、コンピュータコミュニケーションは再検討されます、Vol.20、No.2、66ページ、1990年4月1日。
[Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters of Deception: The Gang that Ruled Cyberspace", Harper Collins Publishers, 1995.
[SlatallaとQuittner、1995] M.SlatallaとJ.Quittner、「詐欺のマスターズ:」 「Gang、そのRuled Cyberspace、」、ハーパーコリンズPublishers、1995
[Smith, 1989] M. Smith, "Commonsense Computer Security: Your Practical Guide to Preventing Accidental and Deliberate Electronic Data Loss", McGraw-Hill, New York, NY, 1989.
[スミス、1989]M.スミス、「常識的なコンピュータセキュリティ:」 「偶然の、そして、慎重な電子データの損失を防ぐことへのあなたの実用的なガイド」、マグロウヒル、ニューヨーク(ニューヨーク)1989。
[Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth Annual Computer Security Incident Handling Workshop, Boston, MA, July 25-29, 1995.
[スミス、1995]D.スミス、「インシデントレスポンスチームを形成します」、第6例年のコンピュータセキュリティインシデント取り扱いワークショップ(ボストン(MA)1995年7月25日〜29日)。
Fraser, Ed. Informational [Page 73] RFC 2196 Site Security Handbook September 1997
フレーザ、[73ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[Spafford, 1988] E. Spafford, "The Internet Worm Program: An Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, January 1989. Also issued as Purdue CS Technical Report CSD-TR-823, 28 November 1988.
[Spafford、1988] E.Spafford、「インターネットワームはプログラムを作ります」。 「分析」、コンピュータコミュニケーションレビュー、Vol.19、No.1、ACM SIGCOM、1989年1月。 また、パドゥーCS Technical Report CSD-TR-823、1988年11月28日として、発行されています。
[Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm", Proceedings of the European Software Engineering Conference 1989, Warwick England, September 1989. Proceedings published by Springer- Verlag as: Lecture Notes in Computer Science #387. Also issued as Purdue Technical Report #CSD-TR-933.
[Spafford、1989] G.Spafford、「インターネットワームの分析」、ヨーロッパのソフトウェア工学コンファレンス1989、ウォリックイギリス(1989年9月)の議事。 議事は以下としてSpringer- Verlagによって発行されました。 コンピュータ科学#387で注意について講義してください。 また、パドゥーTechnical Report#CSD-TR-933として、発行されています。
[Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats", ADAPSO, 1989. (109 pages.)
[Spafford、Keaphy、Ferbrache、1989]E.Spafford、K.ヒーフィー、およびD.Ferbrache、「コンピュータウイルス:」 「電子破壊とプログラムされた脅威に対処します」、ADAPSO、1989。 (109ページ。)
[Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG Books, Foster City CA, 1995.
[Stallings1、1995] W.ストーリング(「インターネットセキュリティハンドブック」、IDGの本)は市のカリフォルニア、1995を伸ばしています。
[Stallings2, 1995] W. Stallings, "Network and InterNetwork Security", Prentice Hall, , 1995.
[Stallings2、1995] W.ストーリングズと、「ネットワークとインターネットワークセキュリティ」、新米のホール、1995
[Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for PGP Users" PTR Prentice Hall, 1995.
[Stallings3、1995]W.ストーリングズ、「プライバシーを守ってください」 「PGPユーザのためのガイド」PTRの新米のホール、1995。
[Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988.
[ストール、1988]C.ストール、「陰険なハッカーに忍び寄ります」、ACMに関するコミュニケーション、Vol.31、No.5、Pgs。 484-497 ACM、ニューヨーク(ニューヨーク)は1988がそうするかもしれません。
[Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2, Doubleday, 1989.
[ストール、1989]C.ストール、「カッコウの卵」、ISBN00385-24946-2、ダブルデー、1989。
[Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the Firewall, and Other Applications Relays", Digital Equipment Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993.
[Treeseとウォルマン、1993]G.TreeseとA.ウォルマン、「ファイアウォールの、そして、他のアプリケーションリレーによるX」、ディジタルイクイップメント社、ケンブリッジは1993年5月3日に研究所、CRL93/10について研究します。
[Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986", U.S. Senate Committee on the Judiciary, 1986.
[Trible、1986] P.Trible、「1986年のコンピューター詐欺濫用防止法」、司法部、1986年の米国上院委員会。
[Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control, and booby traps", Mathematics and Computing Science, Eindhoven University of Technology, The Netherlands.
[Venema]W.Venema、「TCPラッパー:」 Technology、オランダの「ネットワーク監視、アクセスコントロール、およびばか者は捕らえる」、Mathematics、およびComputing Science、アイントホーフェン大学。
[USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop", Portland, OR, August 29-30, 1988.
[USENIX、1988] USENIX、「USENIX議事:」 「UNIXセキュリティワークショップ」、ポートランド(OR)1988年8月29日〜30日。
[USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II Workshop", Portland, OR, August 27-28, 1990.
[USENIX、1990] USENIX、「USENIX議事:」 「UNIXセキュリティIIワークショップ」、ポートランド(OR)1990年8月27日〜28日。
Fraser, Ed. Informational [Page 74] RFC 2196 Site Security Handbook September 1997
フレーザ、[74ページ]RFC2196サイトセキュリティハンドブック1997年9月の情報のエド
[USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security III", Baltimore, MD, September 14-16, 1992.
[USENIX、1992] USENIX、「USENIXシンポジウム議事:」 「UNIXセキュリティIII」、ボルチモア(MD)1992年9月14日〜16日。
[USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security IV", Santa Clara, CA, October 4-6, 1993.
[USENIX、1993] USENIX、「USENIXシンポジウム議事:」 「UNIXセキュリティIV」、サンタクララ(カリフォルニア)1993年10月4日〜6日。
[USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium", Salt Lake City, UT, June 5-7, 1995.
[USENIX、1995] USENIX、「第5USENIX UNIXセキュリティシンポジウム」、ソルトレイクシティー、1995年6月5日〜7日の間のユタ。
[Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V. Hampel, and H. Sartorio, "Computer Security: A Comprehensive Controls Checklist", John Wiley and Sons, Interscience Publication, 1987.
[木、et.al、1987]C.Wood、W.バンクスS.Guarro、A.ガルシア、V.ハンペル、およびH.Sartorio、「コンピュータセキュリティ:」 「包括的なコントロールチェックリスト」とジョン・ワイリーと息子、Interscience公表、1987
[Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for Telecommunications Networks and LANS", Artech House, 1993.
[ローベル、1993]L.ローベル、「テレコミュニケーションネットワークとLANSのための書くことの災害回復対策」、Artech家、1993。
[Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A Manual with Case Studies", Wiley, New York, NY, 1989.
[バラバンネーニ、1989]S.バラバンネーニ、「監査のコンピュータセキュリティ:」 「ケーススタディがあるマニュアル」、ワイリー、ニューヨーク(ニューヨーク)1989。
Security Considerations
セキュリティ問題
This entire document discusses security issues.
この全体のドキュメントは安全保障問題について議論します。
Editor Information
エディタ情報
Barbara Y. Fraser Software Engineering Institute Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213
バーバラY.フレーザソフトウェア工学研究所カーネギーメロン大学5000フォーブズ・Avenueピッツバーグ、PA 15213
Phone: (412) 268-5010 Fax: (412) 268-6989 EMail: byf@cert.org
以下に電話をしてください。 (412) 268-5010 Fax: (412) 268-6989 メールしてください: byf@cert.org
Fraser, Ed. Informational [Page 75]
フレーザ、エド、情報[75ページ]
一覧
スポンサーリンク
