RFC1244 日本語訳
1244 Site Security Handbook. J.P. Holbrook, J.K. Reynolds. July 1991. (Format: TXT=259129 bytes) (Obsoleted by RFC2196) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Holbrook
Request for Comments: 1244 CICNet
FYI: 8 J. Reynolds
ISI
Editors
July 1991
コメントを求めるワーキンググループP.ホルブルック要求をネットワークでつないでください: 1244CICNet FYI: 8 J.レイノルズISIエディターズ1991年7月
Site Security Handbook
サイトセキュリティハンドブック
Status of this Memo
このMemoの状態
This handbook is the product of the Site Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). This FYI RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このハンドブックは、Site Security Policy Handbook作業部会(SSPHWG)の製品と、Security Areaの協力とインターネット・エンジニアリング・タスク・フォースのUser Services Area(IETF)です。 このFYI RFCはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Contributing Authors
作者を寄付します。
The following are the authors of the Site Security Handbook. Without their dedication, this handbook would not have been possible.
↓これはSite Security Handbookの作者です。 彼らの奉納がなければ、このハンドブックは可能でなかったでしょう。
Dave Curry (Purdue University), Sean Kirkpatrick (Unisys), Tom Longstaff (LLNL), Greg Hollingsworth (Johns Hopkins University), Jeffrey Carpenter (University of Pittsburgh), Barbara Fraser (CERT), Fred Ostapik (SRI NISC), Allen Sturtevant (LLNL), Dan Long (BBN), Jim Duncan (Pennsylvania State University), and Frank Byrum (DEC).
ジェフリー大工(ピッツバーグ大学)(バーバラ・フレーザ(本命))のデーヴCurry(パデュー大学)、ショーン・カークパトリック(ユニシス)、トム・ロングスタッフ(LLNL)、グレッグ・ホリングスワース(ジョーンズ・ホプキンス大学)、フレッドOstapik(様のNISC)、アレン・スタートバント(LLNL)、標識浮標の長い(BBN)、ジム・ダンカン(ペンシルバニア州立大学)、およびフランク・バイラム(12月)。
Editors' Note
エディタの注意
This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. As such, this document is necessarily incomplete. There are some clear shortfalls; for example, this document focuses mostly on resources available in the United States. In the spirit of the Internet's "Request for Comments" series of notes, we encourage feedback from users of this handbook. In particular, those who utilize this document to craft their own policies and procedures.
このFYI RFCはインターネットでどう安全保障問題に対処するかにおけるインターネットユーザ指導を提供することへの最初の試みです。 そういうものとして、このドキュメントは必ず不完全です。 いくつかの明確な不足分があります。 例えば、このドキュメントはほとんど合衆国で利用可能なリソースに焦点を合わせます。 インターネットの注意の「コメントを求める要求」シリーズの精神では、私たちはこのハンドブックの使用者からの反応を奨励します。 特に、これを利用する人がそれら自身の方針と手順を工芸品に記録します。
This handbook is meant to be a starting place for further research and should be viewed as a useful resource, but not the final authority. Different organizations and jurisdictions will have different resources and rules. Talk to your local organizations, consult an informed lawyer, or consult with local and national law enforcement. These groups can help fill in the gaps that this document cannot hope to cover.
このハンドブックは、さらなる調査のための始めの場所であることが意味されて、最終的な権威ではなく、役に立つリソースとして見なされるべきです。 異なった組織と管内には、異なったリソースと規則があるでしょう。 地元の組織と話すか、知識がある弁護士に相談するか、または地方の、そして、国家の法施行と相談してください。 これらのグループは、このドキュメントがカバーすることを望むことができない不足に記入するのを助けることができます。
Site Security Policy Handbook Working Group [Page 1] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[1ページ]RFC1244サイトセキュリティハンドブック1991年7月
Finally, we intend for this FYI RFC to grow and evolve. Please send comments and suggestions to: ssphwg@cert.sei.cmu.edu.
最終的に、このFYI RFCは成長して、私たちは進化するつもりです。 以下のことのためにコメントと提案を送ってください。 ssphwg@cert.sei.cmu.edu 。
Table of Contents
目次
1. Introduction..................................................... 3 1.1 Purpose of this Work............................................ 3 1.2 Audience........................................................ 3 1.3 Definitions..................................................... 4 1.4 Related Work.................................................... 4 1.5 Scope........................................................... 4 1.6 Why Do We Need Security Policies and Procedures?................ 5 1.7 Basic Approach.................................................. 7 1.8 Organization of this Document................................... 7 2. Establishing Official Site Policy on Computer Security........... 9 2.1 Brief Overview.................................................. 9 2.2 Risk Assessment................................................. 10 2.3 Policy Issues................................................... 13 2.4 What Happens When the Policy Is Violated........................ 19 2.5 Locking In or Out............................................... 21 2.6 Interpreting the Policy......................................... 23 2.7 Publicizing the Policy.......................................... 23 3. Establishing Procedures to Prevent Security Problems............. 24 3.1 Security Policy Defines What Needs to be Protected.............. 24 3.2 Identifing Possible Problems.................................... 24 3.3 Choose Controls to Protect Assets in a Cost-Effective Way....... 26 3.4 Use Multiple Strategies to Protect Assets....................... 26 3.5 Physical Security............................................... 27 3.6 Procedures to Recognize Unauthorized Activity................... 27 3.7 Define Actions to Take When Unauthorized Activity is Suspected.. 29 3.8 Communicating Security Policy................................... 30 3.9 Resources to Prevent Security Breaches.......................... 34 4. Types of Security Procedures..................................... 56 4.1 System Security Audits.......................................... 56 4.2 Account Management Procedures................................... 57 4.3 Password Management Procedures.................................. 57 4.4 Configuration Management Procedures............................. 60 5. Incident Handling................................................ 61 5.1 Overview........................................................ 61 5.2 Evaluation...................................................... 65 5.3 Possible Types of Notification.................................. 67 5.4 Response........................................................ 71 5.5 Legal/Investigative............................................. 73 5.6 Documentation Logs.............................................. 77 6. Establishing Post-Incident Procedures............................ 78 6.1 Overview........................................................ 78 6.2 Removing Vulnerabilities........................................ 78 6.3 Capturing Lessons Learned....................................... 80
1. 序論… 3 1.1 このWorkの目的… 3 1.2聴衆… 3 1.3の定義… 1.4が関係づけた4は働いています… 4 1.5範囲… 4 1.6 私たちはなぜ安全保障政策と手順を必要としますか? 5 1.7 基本的なアプローチ… 7 1.8 このDocumentの組織… 7 2. コンピュータセキュリティに関する公式サイト方針を確立します… 9 2.1 概要に事情を知らせてください… 9 2.2 査定を危険にさらしてください… 10 2.3 方針問題… 13 2.4 方針であるときに、何が起こるかは違反されます… 19 2.5 中か外では、ロックします… 21 2.6 方針を解釈します… 23 2.7 方針をピーアールします… 23 3. 警備上の問題を防ぐために手順を確立します… 24 3.1 セキュリティPolicy Defines Whatは、Protectedである必要があります… 24 3.2 起こりうる問題をIdentifingします… 24 3.3 コントロールを選んで、費用対効果に優れた方法で資産を保護してください… 26 3.4 複数の戦略を使用して、資産を保護してください… 26 3.5 物理的なセキュリティ… 27 無許可の行為を認識する3.6の手順… 3.7はActionsを定義します。27、Take When Unauthorized Activityには、Suspectedがあります。 29 3.8 安全保障政策を伝えます… 30 機密保護違反を防ぐ3.9のリソース… 34 4. セキュリティ手順のタイプ… 56 4.1 システムセキュリティ監査… 56 4.2 管理が手順であることを説明してください… 57 4.3 パスワード管理手順… 57 4.4 構成管理手順… 60 5. 付随している取り扱い… 61 5.1概要… 61 5.2評価… 65 5.3 可能なタイプに関する通知… 67 5.4応答… 71 5.5 法的であるか調査… 73 5.6 ドキュメンテーションログ… 77 6. ポストインシデント手順を確立します… 78 6.1概要… 78 6.2 脆弱性を取り除きます… 78 6.3 レッスンを得るのは学びました… 80
Site Security Policy Handbook Working Group [Page 2] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[2ページ]RFC1244サイトセキュリティハンドブック1991年7月
6.4 Upgrading Policies and Procedures............................... 81 7. References....................................................... 81 8. Annotated Bibliography........................................... 83 8.1 Computer Law.................................................... 84 8.2 Computer Security............................................... 85 8.3 Ethics.......................................................... 91 8.4 The Internet Worm............................................... 93 8.5 National Computer Security Center (NCSC)........................ 95 8.6 Security Checklists............................................. 99 8.7 Additional Publications......................................... 99 9. Acknlowledgements................................................101 10. Security Considerations.........................................101 11. Authors' Addresses..............................................101
6.4 方針と手順をアップグレードさせます… 81 7. 参照… 81 8. 図書目録を注釈します… 83 8.1 コンピュータ法… 84 8.2コンピュータセキュリティ… 85 8.3の倫理… 91 8.4 インターネットワーム… 93 8.5 国家のコンピュータセキュリティセンター(NCSC)… 95 8.6 セキュリティチェックリスト… 99 8.7 追加刊行物… 99 9. Acknlowledgements…101 10. セキュリティ問題…101 11. 作者のアドレス…101
1. Introduction
1. 序論
1.1 Purpose of this Work
1.1 このWorkの目的
This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. This guide lists issues and factors that a site must consider when setting their own policies. It makes some recommendations and gives 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 the policies.
このガイドは、安全保障政策を設定するためのフレームワークと手順にすぎません。 有効なセットの方針と手順を持つために、そして、サイトは、政策を多くの決定をして、協定を獲得して、伝えて、実施しなければならないでしょう。
1.2 Audience
1.2 聴衆
The audience for this work are system administrators and decision makers (who are more traditionally called "administrators" or "middle management") at sites. 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 any 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.
この仕事のためのプライマリーオーディエンスはインターネットコミュニティのメンバーであるサイトです。 しかしながら、このドキュメントは他のサイトとのコミュニケーションを許容するどんなサイトも役に立つべきです。 安全保障政策への一般的なガイドとして、また、このドキュメントも孤立系によってサイトの役に立つかもしれません。
Site Security Policy Handbook Working Group [Page 3] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[3ページ]RFC1244サイトセキュリティハンドブック1991年7月
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, PC's or other devices that have access to the Internet. A site may be a end user of Internet services or a service provider such as a regional network. However, most of the focus of this guide is on those end users of Internet services.
このガイドの目的のために、「サイト」は、コンピュータを所有しているどんな組織かネットワーク関連のリソースです。 これらのリソースはインターネットに近づく手段を持っているユーザが使用するホストコンピュータ、ルータ、ターミナルサーバ、PCまたは対向機器を含むかもしれません。 サイトは、インターネットのサービスのエンドユーザか地域ネットワークなどのサービスプロバイダーであるかもしれません。 しかしながら、インターネットのサービスのそれらのエンドユーザの上にこのガイドの焦点の大部分があります。
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.
私たちは、サイトには合意とサポートで実際にリソースを所有している人からそれ自体に方針と手順を設定する能力があると思います。
The "Internet" is those set of networks and machines that use the TCP/IP protocol suite, connected through gateways, and sharing a common name and address spaces [1].
「インターネット」は、TCP/IPプロトコル群を使用するそれらのセットのネットワークとマシンです、ゲートウェイを通して接続されて、一般名とアドレス空間[1]を共有して。
The term "system administrator" is used to cover all those who are responsible for the day-to-day operation of resources. This may be a number of individuals or an organization.
「システム管理者」という用語は、リソースの日常業務に責任があるすべてのそれらをカバーするのに使用されます。 これは、個体数か組織であるかもしれません。
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 IETF Security Policy Working Group (SPWG) is working on a set of recommended security policy guidelines for the Internet [23]. These guidelines may be adopted as policy by regional networks or owners of other resources. This handbook should be a useful tool to help sites implement those policies as desired or required. However, even implementing the proposed policies isn't enough to secure a site. The proposed Internet policies deal only with network access security. It says nothing about how sites should deal with local security issues.
IETF Security Policy作業部会(SPWG)はインターネット[23]のためのお勧めの安全保障政策ガイドラインのセットに取り組んでいます。 これらのガイドラインは方針として他のリソースの地域ネットワークか所有者によって採用されるかもしれません。 このハンドブックは、サイトが望まれているか、または必要であるようにそれらの政策を実施するのを助けるためには有益な手段であるべきです。 しかしながら、提案された政策を実施さえする、サイトを保証するために十分ではありません。 提案されたインターネット方針はネットワークアクセス保護だけに対処します。 サイトがどうローカルの安全保障問題に対処するべきであるかに関してそれは沈黙します。
1.5 Scope
1.5 範囲
This document covers issues about what a computer security policy should contain, what kinds of procedures are need to enforce security, and some recommendations about how to deal with the problem. When developing a security policy, close attention should be made not only on the security needs and requirements of the local network, but also the security needs and requirements of the other interconnected networks.
このドキュメントはコンピュータセキュリティ方針が含むべきであることに関する問題をカバーしていて、手順の種類がものであることは、どう問題に対処するかに関してセキュリティ、およびいくつかの推薦を実施する必要があります。 安全保障政策を開発するとき、企業内情報通信網の安全要求と要件でするだけではなく、他の相互接続ネットワークの安全要求と要件でも周到な注意をするべきです。
Site Security Policy Handbook Working Group [Page 4] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[4ページ]RFC1244サイトセキュリティハンドブック1991年7月
This is not a cookbook for computer security. Each site has different needs; the security needs of a corporation might well be different than the security needs of an academic institution. Any security plan has to conform to the needs and culture of the site.
これはコンピュータセキュリティのための料理の本ではありません。 各サイトは異なるニーズを持っています。 会社の安全要求はたぶんアカデミックな団体の安全要求と異なっているでしょう。 どんな警備計画もサイトの必要性と文化に従わなければなりません。
This handbook does not cover details of how to do risk assessment, contingency planning, or physical security. These things are essential in setting and implementing effective security policy, but this document leaves treatment of those issues to other documents. We will try to provide some pointers in that direction.
このハンドブックはどうリスクアセスメント、コンティンジェンシー・プランニング、または物理的なセキュリティをするかに関する詳細をカバーしていません。 これらのものは効果的な安全保障政策を設定して、実装するのにおいて不可欠ですが、このドキュメントはそれらの問題の処理を他のドキュメントに残します。 私たちはその方向にいくつかの指針を提供しようとするでしょう。
This document also doesn't talk about how to design or implement secure systems or programs.
このドキュメントも安全なシステムかプログラムを設計するか、またはどう実装するかに関して話しません。
1.6 Why Do We Need Security Policies and Procedures?
1.6 私たちはなぜ安全保障政策と手順を必要としますか?
For most sites, the interest in computer security is proportional to the perception of risk and threats.
ほとんどのサイトにおいて、コンピュータセキュリティへの関心はリスクと脅威の認知に比例しています。
The world of computers has changed dramatically over the past twenty-five years. Twenty-five years ago, most computers were centralized and managed by data centers. Computers were kept in locked rooms and staffs of people made sure they were carefully managed and physically secured. Links outside a site were unusual. Computer security threats were rare, and were basically concerned with insiders: authorized users misusing accounts, theft and vandalism, and so forth. These threats were well understood and dealt with using standard techniques: computers behind locked doors, and accounting for all resources.
コンピュータの世界は過去25年間劇的に変化しています。 25年前に、ほとんどのコンピュータが、データセンターによって集結されて、管理されました。 コンピュータは固定部屋に保たれて、人々のスタッフは自分達が慎重に管理されて、物理的に機密保護されたのを確実にしました。 サイトの外のリンクは珍しかったです。 コンピュータセキュリティの脅威は、まれであり、基本的にインサイダーに関係がありました: アカウント、窃盗、破壊などを誤用する認定ユーザ。 標準のテクニックを使用することで、これらの脅威は、よく理解されて、対処されました: 後ろのコンピュータはすべてのリソースのためにドア、および会計をロックしました。
Computing in the 1990's is radically different. Many systems are in private offices and labs, often managed by individuals or persons employed outside a computer center. Many systems are connected into the Internet, and from there around the world: the United States, Europe, Asia, and Australia are all connected together.
1990年代に計算するのは根本的に異なっています。 多くのシステムがしばしばコンピュータセンターの外で雇われた個人か人々によって経営された個人事務所と研究室にあります。 多くのシステムがインターネットの中と、そして、そこから世界中に接続されます: 合衆国、ヨーロッパ、アジア、およびオーストラリアは皆、一緒につなげられます。
Security threats are different today. The time honored advice says "don't write your password down and put it in your desk" lest someone find it. With world-wide Internet connections, someone could get into your system from the other side of the world and steal your password in the middle of the night when your building is locked up. Viruses and worms can be passed from machine to machine. The Internet allows the electronic equivalent of the thief who looks for open windows and doors; now a person can check hundreds of machines for vulnerabilities in a few hours.
軍事的脅威は今日、異なっています。 だれかがそれを見つけるといけないのでアドバイスが、「パスワードを書き留めないでください、そして、机にそれを置いてください」と言うと光栄に思っている時間。 だれかが、世界的なインターネット接続と共に、世界の果てからあなたのシステムに入って、あなたのビルが鍵をかけられる夜中にあなたのパスワードを横取りできました。 マシンからマシンまでウィルス・ワームを通過できます。 インターネットは開いている窓とドアを探す泥棒の電子同等物を許容します。 今、人は脆弱性がないかどうか数時間で何百台ものマシンをチェックできます。
System administrators and decision makers have to understand the security threats that exist, what the risk and cost of a problem
システム管理者と意思決定者が存在する軍事的脅威を理解しなければならない、何、問題のリスクと費用
Site Security Policy Handbook Working Group [Page 5] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[5ページ]RFC1244サイトセキュリティハンドブック1991年7月
would be, and what kind of action they want to take (if any) to prevent and respond to security threats.
あって、彼らがどういう動作を取りたがっているかは、軍事的脅威に防いで、応じるために取ります(もしあれば)。
As an illustration of some of the issues that need to be dealt with in security problems, consider the following scenarios (thanks to Russell Brand [2, BRAND] for these):
警備上の問題で対処される必要がある問題のいくつかのイラストと、以下のシナリオ(これらのためのラッセルBrand[2、BRAND]のおかげで)を考えてください:
- A system programmer gets a call reporting that a
major underground cracker newsletter is being
distributed from the administrative machine at his
center to five thousand sites in the US and
Western Europe.
- システム・プログラマは呼び出しに主要な地下クラッカーニュースレターが彼のセンターの管理マシンから米国と西欧の5,000のサイトに分配されていると報告させます。
Eight weeks later, the authorities call to inform
you the information in one of these newsletters
was used to disable "911" in a major city for
five hours.
8週間後に、当局は、あなたに知らせるために電話をします。これらのニュースレターの1つにおける情報は、5時間大都市で「911」を無効にするのに使用されました。
- A user calls in to report that he can't login to his
account at 3 o'clock in the morning on a Saturday. The
system staffer can't login either. After rebooting to
single user mode, he finds that password file is empty.
By Monday morning, your staff determines that a number
of privileged file transfers took place between this
machine and a local university.
- ユーザは、彼が土曜日の午前の3時にアカウントにログインできないと報告するのを回収します。 システム従業員はログインできません。 シングルユーザーモードにリブートした後に、彼は、パスワードファイルが空であることがわかります。 月曜日の朝までには、あなたのスタッフは、多くの特権があるファイル転送がこのマシンと地元大学の間の場所を取ったと決心しています。
Tuesday morning a copy of the deleted password file is
found on the university machine along with password
files for a dozen other machines.
火曜日の朝、削除されたパスワードファイルのコピーは他の1ダースのマシンのためのパスワードファイルに伴う大学マシンの上で見つけられます。
A week later you find that your system initialization
files had been altered in a hostile fashion.
1週間後に、あなたは、あなたのシステム初期化ファイルが敵対的なやり方で変更されたのがわかります。
- You receive a call saying that a breakin to a government
lab occurred from one of your center's machines. You
are requested to provide accounting files to help
trackdown the attacker.
- あなたは政府研究室へのbreakinがあなたのセンターのマシンの1つから現れたと言う呼び出しを受けます。 あなたが攻撃者のtrackdownを助けるために課金ファイルを提供するよう要求されています。
A week later you are given a list of machines at your
site that have been broken into.
1週間後に、あなたのサイトの侵入されたマシンのリストをあなたに与えます。
- A reporter calls up asking about the breakin at your
center. You haven't heard of any such breakin.
- レポーターは、あなたのセンターのbreakinに関して尋ねながら、呼び出します。 あなたは少しのそのようなbreakinについても聞いていません。
Three days later, you learn that there was a breakin.
The center director had his wife's name as a password.
3日後に、あなたは、breakinがあったことを学びます。 センターディレクターには、パスワードとして彼の妻の名前がありました。
Site Security Policy Handbook Working Group [Page 6] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[6ページ]RFC1244サイトセキュリティハンドブック1991年7月
- A change in system binaries is detected.
- システムバイナリーにおける変化は検出されます。
The day that it is corrected, they again are changed.
This repeats itself for some weeks.
それが直っていることの日に、再びそれらを変えます。 これは数週間繰り返し言います。
- If an intruder is found on your system, should you
leave the system open to monitor the situation or should
you close down the holes and open them up again later?
- 侵入者があなたのシステムの上で見つけられるなら、状況をモニターするために開いた状態でシステムを残すべきであるか、あなたは、後で穴を閉鎖して、再びそれらを開けるべきですか?
- If an intruder is using your site, should you call law
enforcement? Who makes that decision? If law enforcement asks
you to leave your site open, who makes that decision?
- 侵入者があなたのサイトを使用しているなら、あなたは、法施行と呼ぶべきですか? だれがその決定をしますか? 法施行が、あなたのサイトを開いた状態でおくようにあなたに頼むなら、だれがその決定をしますか?
- What steps should be taken if another site calls you and says
they see activity coming from an account on your system? What
if the account is owned by a local manager?
- 別のサイトにあなたに電話をして、活動があなたのシステムの上でアカウントから来るのを見ると書いているなら、どんな方法を取るべきですか? アカウントが地元のマネージャによって所有されていると、どうなるでしょうか?
1.7 Basic Approach
1.7 基本的なアプローチ
Setting security policies and procedures really means developing a plan for how to deal with computer security. One way to approach this task is suggested by Fites, et. al. [3, FITES]:
安全保障政策と手順を設定するのは、本当にどうコンピュータセキュリティに対処するかために計画を作り上げることを意味します。 このタスクにアプローチする1つの方法がetファイツ、アルによって提案されます。 [3、ファイツ]:
- Look at what you are trying to protect.
- Look at what you need to protect it from.
- Determine how likely the threats are.
- Implement measures which will protect your assets in a
cost-effective manner.
- Review the process continuously, and improve things every time
a weakness is found.
- あなたが保護しようとしているものを見てください。 - 何からそれを保護するのが必要であるか見てください。 - 脅威がどれくらいありそうであるか決定してください。 - 費用対効果に優れた方法であなたの資産を保護する政策を実施してください。 - 絶え間なくプロセスを見直してください、そして、弱点が見つけられるときはいつも、ものを改良してください。
This handbook will concentrate mostly on the last two steps, but the first three are critically important to making effective decisions about security. One old truism in security is that the cost of protecting yourself against a threat should be less than the cost recovering if the threat were to strike you. Without reasonable knowledge of what you are protecting and what the likely threats are, following this rule could be difficult.
このハンドブックはほとんど最後の2ステップに集中するでしょうが、最初の3は批判的にセキュリティに関する有効な決定をするのに重要です。 1つの古い公理は安全に脅威に対して我が身をかばう費用が脅威があなたを打つことであるなら費用回復以下であるということです。 あなたが何を保護しているか、そして、ありそうな脅威が何であるかに関する妥当な知識がなければ、この規則に従うのは難しいかもしれません。
1.8 Organization of this Document
1.8 このDocumentの組織
This document is organized into seven parts in addition to this introduction.
このドキュメントはこの序論に加えて7つの部品へまとめられます。
The basic form of each section is to discuss issues that a site might want to consider in creating a computer security policy and setting procedures to implement that policy. In some cases, possible options are discussed along with the some of the ramifications of those
それぞれのセクションの基本的なフォームはサイトがコンピュータセキュリティ方針を作成して、手順を設定する際にその政策を実施すると考えたがっているかもしれない問題について議論することです。 いくつかの場合、可能なオプションについて議論する、それらの分岐のいくつか
Site Security Policy Handbook Working Group [Page 7] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[7ページ]RFC1244サイトセキュリティハンドブック1991年7月
choices. As far as possible, this document tries not to dictate the choices a site should make, since these depend on local circumstances. Some of the issues brought up may not apply to all sites. Nonetheless, all sites should at least consider the issues brought up here to ensure that they do not miss some important area.
選択。 できるだけ、このドキュメントはサイトがするべきである選択を書き取らないようにします、これらが地元の事情によるので。 持って来られた問題のいくつかがすべてのサイトに適用されないかもしれません。 それにもかかわらず、すべてのサイトが、ここに持って来られた問題が、何らかの重要な領域が恋しくないのを保証すると少なくとも考えるべきです。
The overall flow of the document is to discuss policy issues followed by the issues that come up in creating procedures to implement the policies.
ドキュメントの総合的な流れは政策問題について議論することです、続いて、政策を実施するために手順を作成する際に来る問題について議論します。
Section 2 discusses setting official site policies for access to computing resources. It also goes into the issue of what happens when the policy is violated. The policies will drive the procedures that need to be created, so decision makers will need to make choices about policies before many of the procedural issues in following sections can be dealt with. A key part of creating policies is doing some kind of risk assessment to decide what really needs to be protected and the level of resources that should be applied to protect them.
セクション2は、コンピューティング資源へのアクセスのための公式サイト方針を設定すると論じます。 また、それは方針が違反されるとき、何が起こるかに関する問題を調べます。 方針が作成される必要がある手順を追い立てるので、意思決定者は、以下の章の手続き上の問題の多くに対処できる前に方針に関する選択をする必要があるでしょう。 作成方針の主要な部分は、本当に保護される必要があるものとそれらを保護するために適用されるべきであるリソースのレベルについて決めるためにある種のリスクアセスメントをしています。
Once policies are in place, procedures to prevent future security problems should be established. Section 3 defines and suggests actions to take when unauthorized activity is suspected. Resources to prevent secruity breaches are also discussed.
方針が適所にいったんあると、将来の警備上の問題を防ぐ手順は確立されるべきです。 セクション3は、無許可の行為が疑われるとき、取るために動作を定義して、示します。 また、secruity不履行を防ぐリソースについて議論します。
Section 4 discusses types of procedures to prevent security problems. Prevention is a key to security; as an example, the Computer Emergency Response Team/Coordination Center (CERT/CC) at Carnegie- Mellon University (CMU) estimates that 80% or more of the problems they see have to do with poorly chosen passwords.
セクション4は、警備上の問題を防ぐために手順のタイプについて論じます。防止はセキュリティのキーです。 例として、カーネギーメロン大学(米カーネギーメロン大学)のコンピュータ緊急対応チーム/コーディネートセンター(CERT/CC)は、それらが認める80%か一層の問題が不十分に選ばれたパスワードと関係があると見積もっています。
Section 5 discusses incident handling: what kinds of issues does a site face when someone violates the security policy. Many decisions will have to made on the spot as the incident occurs, but many of the options and issues can be discussed in advance. At very least, responsibilities and methods of communication can be established before an incident. Again, the choices here are influenced by the policies discussed in section 2.
セクション5は付随している取り扱いについて論じます: だれかが安全保障政策に違反するとき、サイトはどんな種類の問題に直面していますか? インシデントが起こるとき、多くの決定が議論に即座に人工でならなければならないでしょうが、あらかじめ、オプションと問題の多くについて議論できます。 少なくとも、インシデントの前でコミュニケーションの責任とメソッドを確立できます。 一方、セクション2で議論した方針でここでの選択に影響を及ぼされます。
Section 6 deals with what happens after a security violation has been dealt with. Security planning is an on-going cycle; just after an incident has occurred is an excellent opportunity to improve policies and procedures.
セクション6は安全の侵害が対処された後に起こることに対処します。 セキュリティ計画は継続しているサイクルです。 インシデントが起こったすぐ後に、向上する素晴らしい機会は、方針と手順ですか?
The rest of the document provides references and an annotated bibliography.
ドキュメントの残りは参照と注釈付きの書誌を提供します。
Site Security Policy Handbook Working Group [Page 8] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[8ページ]RFC1244サイトセキュリティハンドブック1991年7月
2. Establishing Official Site Policy on Computer Security
2. コンピュータセキュリティに関する公式サイト方針を確立します。
2.1 Brief Overview
2.1 簡潔な概要
2.1.1 Organization Issues
2.1.1 組織問題
The goal in developing an official site policy on computer
security is to define the organization's expectations of proper
computer and network use and to define procedures to prevent and
respond to security incidents. In order to do this, aspects of
the particular organization must be considered.
コンピュータセキュリティに関する公式サイト方針を開発することにおける目標は、適切なコンピュータとネットワーク使用への組織の期待を定義して、セキュリティインシデントに防いで、反応させる手順を定義することです。 これをするために、特定の組織の局面を考えなければなりません。
First, the goals and direction of the organization should be
considered. For example, a military base may have very different
security concerns from a those of a university.
まず最初に、組織の目標と方向は考えられるべきです。 例えば、軍事基地には、大学のものからの非常に異なった安全上の配慮があるかもしれません。
Second, the site security policy developed must conform to
existing policies, rules, regulations and laws that the
organization is subject to. Therefore it will be necessary to
identify these and take them into consideration while developing
the policy.
2番目に、開発されたサイト安全保障政策は組織を条件としている既存の方針、規則、規則、および法に従わなければなりません。 したがって、これらを特定して、それらを考慮に入れるのが方針を開発する間、必要でしょう。
Third, unless the local network is completely isolated and
standalone, it is necessary to consider security implications in a
more global context. The policy should address the issues when
local security problems develop as a result of a remote site as
well as when problems occur on remote systems as a result of a
local host or user.
そして、3番目、企業内情報通信網が完全に隔離されるというわけではなくて、スタンドアロン、よりグローバルな文脈でのセキュリティ含意を考えるのが必要です。 ローカルの警備上の問題が問題がローカル・ホストかユーザの結果、リモートシステムの上に起こる時と同様にリモートサイトの結果、展開すると、方針は問題を扱うべきです。
2.1.2 Who Makes the Policy?
2.1.2 だれが方針を作りますか?
Policy creation must be a joint effort by technical personnel, who
understand the full ramifications of the proposed policy and the
implementation of the policy, and by decision makers who have the
power to enforce the policy. A policy which is neither
implementable nor enforceable is useless.
方針作成は技術者と方針を実施するパワーを持っている意思決定者による共同努力であるに違いありません。(その技術者は、提案された方針の完全な分岐と方針の実装を理解しています)。 実装可能でなくて、また実施できない方針は、役に立ちません。
Since a computer security policy can affect everyone in an
organization, it is worth taking some care to make sure you have
the right level of authority in on the policy decisions. Though a
particular group (such as a campus information services group) may
have responsibility for enforcing a policy, an even higher group
may have to support and approve the policy.
コンピュータセキュリティ方針が組織の皆に影響できるので、政策決定に関係してあなたには権威の正しいレベルがあるのを確実にするためにいくつか注意する価値があります。 特定のグループ(サービスが分類するキャンパス情報などの)には、政策を実行することへの責任があるかもしれませんが、さらに高いグループは、方針をサポートして、承認しなければならないかもしれません。
2.1.3 Who is Involved?
2.1.3 Involvedはだれですか?
Establishing a site policy has the potential for involving every
computer user at the site in a variety of ways. Computer users
サイト方針を確立すると、すべてのコンピュータユーザにかかわる可能性はサイトにさまざまな方法で持たれています。 コンピュータユーザ
Site Security Policy Handbook Working Group [Page 9] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[9ページ]RFC1244サイトセキュリティハンドブック1991年7月
may be responsible for personal password administration. Systems
managers are obligated to fix security holes and to oversee the
system.
個人的なパスワード管理に責任があるかもしれません。 セキュリティーホールを修理して、システム・マネージャがシステムを監督するのが義務付けられます。
It is critical to get the right set of people involved at the
start of the process. There may already be groups concerned with
security who would consider a computer security policy to be their
area. Some of the types of groups that might be involved include
auditing/control, organizations that deal with physical security,
campus information systems groups, and so forth. Asking these
types of groups to "buy in" from the start can help facilitate the
acceptance of the policy.
人々の右のセットをプロセスの始めで伴わせるのは、重要です。 既に、セキュリティで、だれが、コンピュータセキュリティ方針がそれらの領域であると考えるかを心配しているグループがあるかもしれません。 かかわるかもしれないグループのタイプの中には、監査/コントロール、物理的なセキュリティに対処する組織、キャンパス情報システムグループなどを入れる人もいます。 これらのタイプのグループに始めから「買う」尋ねるのは、方針の承認を容易にするのを助けることができます。
2.1.4 Responsibilities
2.1.4 責任
A key element of a computer security policy is making sure
everyone knows their own responsibility for maintaining security.
A computer security policy cannot anticipate all possibilities;
however, it can ensure that each kind of problem does have someone
assigned to deal with it.
コンピュータセキュリティ方針の主要な要素は、皆が警備を維持することへのそれら自身の責任を知っているのを確実にしています。 コンピュータセキュリティ方針はすべての可能性を予期できるというわけではありません。 しかしながら、それは、それに対処するために各種類の問題でだれかを選任するのを確実にすることができます。
There may be levels of responsibility associated with a policy on
computer security. At one level, each user of a computing
resource may have a responsibility to protect his account. A user
who allows his account to be compromised increases the chances of
compromising other accounts or resources.
コンピュータセキュリティに関する方針に関連している責任のレベルがあるかもしれません。 1つのレベルでは、コンピューティング資源の各ユーザは彼のアカウントを保護する責任を持っているかもしれません。 彼のアカウントを感染させるユーザは他のアカウントかリソースに感染するという可能性を増強します。
System managers may form another responsibility level: they must
help to ensure the security of the computer system. Network
managers may reside at yet another level.
システム・マネージャは別の責任レベルを形成するかもしれません: 彼らは、コンピュータ・システムのセキュリティを確実にするのを助けなければなりません。 ネットワークマネージャはさらに別のレベルに住むかもしれません。
2.2 Risk Assessment
2.2 リスクアセスメント
2.2.1 General Discussion
2.2.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. Is is the
process of examining all of your risks, and ranking those risks by
level of severity. This process involves making cost-effective
危険分析は、何を保護するか、そして、あなたが、必要があるあなたが、何からそれを保護する必要があるか、そして、どのようにそれを保護するかを決定することを伴います。 あなたのリスクのすべてを調べるプロセスであり、厳しさのレベルでそれらの危険を格付けすること。 このプロセスは、費用対効果に優れているのに作ることを伴います。
Site Security Policy Handbook Working Group [Page 10] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[10ページ]RFC1244サイトセキュリティハンドブック1991年7月
decisions on what you want to protect. The old security adage
says that you should not spend more to protect something than it
is actually worth.
あなたが保護したいことに関する決定。 古いセキュリティ格言には、あなたが何かを保護するために実際に価値があった状態でそれ以上を費やすべきでないと書かれています。
A full treatment of risk analysis is outside the scope of this
document. [3, FITES] and [16, PFLEEGER] provide introductions to
this topic. However, there are two elements of a risk analysis
that will be briefly covered in the next two sections:
このドキュメントの範囲の外に危険分析の完全な処理があります。 [3、ファイツ]と[16、PFLEEGER]はこの話題に序論を提供します。 しかしながら、次の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.
各資産のために、セキュリティの基本的な目標は、有用性と、秘密性と、保全です。 各脅威は目で脅威がどうこれらの領域に影響するかもしれないかに調べられるべきです。
2.2.2 Identifying the Assets
2.2.2 資産を特定すること。
One step in a risk analysis is to identify all the things that
need to be protected. Some things are obvious, like 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 [16, PFLEEGER,
page 459]; this list is adapted from that source:
カテゴリの1つのリストがPfleeger[16、PFLEEGER、459ページ]によって勧められます。 このリストはそのソースから適合させられます:
1. Hardware: cpus, boards, keyboards, terminals,
workstations, personal computers, printers, disk
drives, communication lines, terminal servers, routers.
1. ハードウェア: cpus、ボード、キーボード、端末、ワークステーション、パーソナルコンピュータ、プリンタ、ディスクドライブ、通信回線、ターミナルサーバ、ルータ。
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, people needed to run systems.
4. 人々: ユーザ、人々はシステムを動かす必要がありました。
5. Documentation: on programs, hardware, systems, local
administrative procedures.
5. ドキュメンテーション: プログラム、ハードウェア、システム、ローカルの行政手続に関して。
6. Supplies: paper, forms, ribbons, magnetic media.
6. 供給: 紙、フォーム、リボン、磁気媒体。
Site Security Policy Handbook Working Group [Page 11] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[11ページ]RFC1244サイトセキュリティハンドブック1991年7月
2.2.3 Identifying the Threats
2.2.3 脅威を特定すること。
Once the assets requiring protection are identified, it is
necessary to identify threats to those assests. 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.
保護を必要とする資産がいったん特定されると、それらのassestsへの脅威を特定するのが必要です。 そして、損失のどんな可能性が存在するかを決定するために脅威を調べることができます。 それは、あなたがどんな脅威から資産を保護しようとしているかを考えるのを助けます。
The following sections describe a few of the possible threats.
以下のセクションは可能な脅威のいくつかについて説明します。
2.2.3.1 Unauthorized Access
2.2.3.1 不正アクセス
A common threat that concerns many sites is unauthorized access
to computing facilities. Unauthorized access takes many forms.
One means of unauthorized access is the use of another user's
account to gain access to a system. The use of any computer
resource without prior permission may be considered
unauthorized access to computing facilities.
多くのサイトに関する一般的な脅威はコンピュータ設備への不正アクセスです。 不正アクセスは多くの形を取ります。不正アクセスの1つの手段はシステムへのアクセスを得る別のユーザのアカウントの使用です。 どんなコンピュータリソースの使用もコンピュータ設備への不正アクセスであると事前の許可なしに考えられるかもしれません。
The seriousness of an unauthorized access will vary from site
to site. For some sites, the mere act of granting access to an
unauthorized user may cause irreparable harm by negative media
coverage. For other sites, an unauthorized access opens the
door to other security threats. In addition, some sites may be
more frequent targets than others; hence the risk from
unauthorized access will vary from site to site. The Computer
Emergency Response Team (CERT - see section 3.9.7.3.1) has
observed that well-known universities, government sites, and
military sites seem to attract more intruders.
サイトによって不正アクセスの重大さは異なるでしょう。 いくつかのサイトに、権限のないユーザへのアクセスを承諾する単なる行為は否定的メディア報道で回復不能の損害を引き起こすかもしれません。 他のサイトに、不正アクセスは他の軍事的脅威を可能にします。 さらに、いくつかのサイトが他のものより頻繁な目標であるかもしれません。 したがって、サイトによって不正アクセスからのリスクは異なるでしょう。 コンピュータ緊急対応チーム、(CERT--より多くの侵入者を引き付けるために思える.1が)持っている.3がそんなによく知られる大学、政府サイト、および軍事の遺跡を観測したセクション3.9.7を見てください。
2.2.3.2 Disclosure of Information
2.2.3.2 情報の公開
Another common threat is disclosure of information. Determine
the value or sensitivity of the information stored on your
computers. Disclosure of a password file might allow for
future unauthorized accesses. A glimpse of a proposal may give
a competitor an unfair advantage. A technical paper may
contain years of valuable research.
別の一般的な脅威は情報の公開です。 あなたのコンピュータで保存された情報の値か感度を決定してください。 パスワードファイルの公開は今後の不正アクセスを考慮するかもしれません。 提案の一瞥は不正な利益を競争相手に与えるかもしれません。 専門紙は何年もの貴重な研究を含むかもしれません。
2.2.3.3 Denial of Service
2.2.3.3 サービス妨害
Computers and networks provide valuable services to their
users. Many people rely on these services in order to perform
their jobs efficiently. When these services are not available
when called upon, a loss in productivity results.
コンピュータとネットワークは彼らのユーザに対する貴重なサービスを提供します。 多くの人々が、効率的に彼らの仕事を実行するためにこれらのサービスに依存します。 訪問される場合これらのサービスが利用可能でないときに、生産性における損失は結果として生じます。
Denial of service comes in many forms and might affect users in
a number of ways. A network may be rendered unusable by a
サービスの否定は、多くのフォームに入って、多くの方法でユーザに影響するかもしれません。 ネットワークはaによって使用不可能に表されるかもしれません。
Site Security Policy Handbook Working Group [Page 12] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[12ページ]RFC1244サイトセキュリティハンドブック1991年7月
rogue packet, jamming, or by a disabled network component. A
virus might slow down or cripple a computer system. Each site
should determine which services are essential, and for each of
these services determine the affect to the site if that service
were to become disabled.
詰め込んでいるパケットか障害があるネットワーク要素で、放浪してください。 ウイルスは、コンピュータ・システムを減速するか、または無力にするかもしれません。 そのサービスが障害があるようになるなら、各サイトは、どのサービスが不可欠であるかを決定して、それぞれのこれらのサービスのために感情をサイトに決定するでしょうに。
2.3 Policy Issues
2.3 方針問題
There are a number of issues that must be addressed when developing a security policy. These are:
安全保障政策を開発するとき扱わなければならない多くの問題があります。 これらは以下の通りです。
1. Who is allowed to use the resources?
2. What is the proper use of the resources?
3. Who is authorized to grant access and approve usage?
4. Who may have system administration privileges?
5. What are the user's rights and responsibilities?
6. What are the rights and responsibilities of the
system administrator vs. those of the user?
7. What do you do with sensitive information?
1. だれがリソースを使用できますか? 2. リソースの適切な使用は何ですか? 3. アクセスを承諾して、だれが用法を承認するのに権限を与えられますか? 4. だれに、システム管理特権があるかもしれませんか? 5. ユーザの権利と責任は何ですか? 6. 権利とシステム管理者対ユーザのものの責任は何ですか? 7. あなたは機密情報で何をしますか?
These issues will be discussed below. In addition you may wish to include a section in your policy concerning ethical use of computing resources. Parker, Swope and Baker [17, PARKER90] and Forester and Morrison [18, FORESTER] are two useful references that address ethical issues.
以下でこれらの問題について議論するでしょう。 さらに、あなたは方針にコンピューティング資源の倫理的な使用に関してセクションを含みたがっているかもしれません。 パーカー、スウォープ、ベイカー[17、PARKER90]、Forester、およびモリソン[18、FORESTER]は倫理的問題を扱う2つの役に立つ参照箇所です。
2.3.1 Who is Allowed to use the Resources?
2.3.1 AllowedはResourcesを使用する、だれですか?
One step you must take in developing your security policy is
defining who is allowed to use your system and services. The
policy should explicitly state who is authorized to use what
resources.
あなたの安全保障政策を開発するあなたが中に入れなければならないワンステップは、だれがあなたのシステムとサービスを利用できるかを定義しています。 方針は、だれが何を使用するのに権限を与えられるかを明らかに述べるべきです。リソース。
2.3.2 What is the Proper Use of the Resources?
2.3.2 ResourcesのProper Useは何ですか?
After determining who is allowed access to system resources it is
necessary to provide guidelines for the acceptable use of the
resources. You may have different guidelines for different types
of users (i.e., students, faculty, external users). The policy
should state what is acceptable use as well as unacceptable use.
It should also include types of use that may be restricted.
システム資源へのアクセスがだれに許されているかを決定した後に、リソースの許容できる使用のためのガイドラインを提供するのが必要です。 あなたは異なったタイプのユーザ(すなわち、学生、教授陣、社外利用者)への異なったガイドラインを持つことができます。 方針は容認できない使用と同様に許容できる使用であることを述べるべきです。 また、それは制限されるかもしれない使用のタイプを含むべきです。
Define limits to access and authority. You will need to consider
the level of access various users will have and what resources
will be available or restricted to various groups of people.
アクセスする限界と権威を定義してください。 あなたは、様々なユーザが持っているアクセスのレベルとリソースがそうすることが利用可能であるか人々の様々なグループに制限されていると考える必要があるでしょう。
Your acceptable use policy should clearly state that individual
users are responsible for their actions. Their responsibility
方針が明確にそうするべきであるあなたの許容できる使用は、個々のユーザは彼らの動作に責任があると述べます。 それらの責任
Site Security Policy Handbook Working Group [Page 13] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[13ページ]RFC1244サイトセキュリティハンドブック1991年7月
exists regardless of the security mechanisms that are in place.
It should be clearly stated that breaking into accounts or
bypassing security is not permitted.
適所にあるセキュリティー対策にかかわらず、存在しています。 アカウントに侵入するか、またはセキュリティを迂回させるのが受入れられないと明確に述べられているべきです。
The following points should be covered when developing an
acceptable use policy:
許容できる使用を開発するとき、以下のポイントがカバーされているべきである、方針:
o Is breaking into accounts permitted?
o Is cracking passwords permitted?
o Is disrupting service permitted?
o Should users assume that a file being world-readable
grants them the authorization to read it?
o Should users be permitted to modify files that are
not their own even if they happen to have write
permission?
o Should users share accounts?
o o Isがo Isが受入れられたサービスを中断して、受入れられたパスワードを解読して、受入れられたアカウント--ファイルが世界読み込み可能であることで、それを読むために承認を彼らに与えるShouldユーザが仮定する○--o Shouldユーザに侵入して、起こってもそれら自身のでないファイルを変更することが許可されてください、許可(o Shouldユーザシェアアカウント)を書かせます。
The answer to most of these questions will be "no".
これらの質問の大部分の答えは「いいえ」でしょう。
You may wish to incorporate a statement in your policies
concerning copyrighted and licensed software. Licensing
agreements with vendors may require some sort of effort on your
part to ensure that the license is not violated. In addition, you
may wish to inform users that the copying of copyrighted software
may be a violation of the copyright laws, and is not permitted.
あなたは著作権があって認可されたソフトウェアに関して声明を方針に取り入れたがっているかもしれません。 ベンダーとのライセンス契約は、ライセンスが違反されないのを保証するためにあなたの部分の上である種の取り組みを必要とするかもしれません。 さらに、あなたは、版権のあるソフトウェアのコピーが著作権法の違反であるかもしれなく、受入れられないことをユーザに知らせたがっているかもしれません。
Specifically concerning copyrighted and/or licensed software, you
may wish to include the following information:
特に著作権があるそして/または、認可されたソフトウェアに関して、あなたは以下の情報を含みたがっているかもしれません:
o Copyrighted and licensed software may not be duplicated
unless it is explicitly stated that you may do so.
o Methods of conveying information on the
copyright/licensed status of software.
o When in doubt, DON'T COPY.
o あなたがそうソフトウェアo WhenのCopyright/認可された状態で疑問(DON'T COPY)で情報を伝達する. o Methodsができると明らかに述べられない場合、著作権があって認可されたソフトウェアはコピーされないかもしれません。
Your acceptable use policy is very important. A policy which does
not clearly state what is not permitted may leave you unable to
prove that a user violated policy.
あなたの許容できる使用、方針は非常に重要です。 明確に受入れられないことを述べない方針はあなたをユーザが方針に違反したと立証できない状態でおくかもしれません。
There are exception cases like tiger teams and users or
administrators wishing for "licenses to hack" -- you may face the
situation where users will want to "hack" on your services for
security research purposes. You should develop a policy that will
determine whether you will permit this type of research on your
services and if so, what your guidelines for such research will
be.
虎のチームとユーザや管理者のような「ハックするライセンス」を望んでいる例外ケースがあります--あなたはユーザがセキュリティ研究目的のためのあなたのサービスのときに「ハックしたくなる」ところに状況に直面できます。 あなたはあなたがあなたのサービスのこのタイプの研究を可能にするかどうかと、そうだとすれば、そのような調査のためのあなたのガイドラインがなるか何を決定する方針を開発するべきです。
Points you may wish to cover in this area:
あなたがこの領域でカバーしたいかもしれないポイント:
Site Security Policy Handbook Working Group [Page 14] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[14ページ]RFC1244サイトセキュリティハンドブック1991年7月
o Whether it is permitted at all.
o What type of activity is permitted: breaking in, releasing
worms, releasing viruses, etc..
o What type of controls must be in place to ensure that it
does not get out of control (e.g., separate a segment of
your network for these tests).
o How you will protect other users from being victims of
these activities, including external users and networks.
o The process for obtaining permission to conduct these
tests.
o それが. 活動のo Whatタイプで受入れられるかどうかが受入れられます: ウイルスをリリースして、ワームをリリースして、押し入って、などコントロールのo Whatタイプは、これらのテストを行うためには制御しきれなさ(例えば、これらのテストのためにあなたのネットワークの区分を切り離す)に. o Howを手に入れないのを保証するために、適所では、あなたがこれらの活動の犠牲者であるのから他のユーザを保護するでしょう、社外利用者とネットワーク○ 許可を得るためのプロセスを含んでいてことでなければなりません。
In cases where you do permit these activities, you should isolate
the portions of the network that are being tested from your main
network. Worms and viruses should never be released on a live
network.
これらの活動を可能にする場合では、あなたはあなたの主なネットワークからテストされているネットワークの一部を隔離するべきです。 ワームとウイルスはライブネットワークで決してリリースされるべきではありません。
You may also wish to employ, contract, or otherwise solicit one or
more people or organizations to evaluate the security of your
services, of which may include "hacking". You may wish to provide
for this in your policy.
あなたは、1つ以上の人か組織に雇いたいか、契約したいか、またはまた、そうでなければ、どれが、「ハックすること」を含むかもしれないかについてあなたのサービスのセキュリティを評価するために請求したがっているかもしれません。 あなたの方針であなたはこれに備えたがっているかもしれません。
2.3.3 Who Is Authorized to Grant Access and Approve Usage?
2.3.3 アクセスを承諾して、だれが用法を承認するのに権限を与えられますか?
Your policy should state who is authorized to grant access to your
services. Further, it must be determined what type of access they
are permitted to give. If you do not have control over who is
granted access to your system, you will not have control over who
is using your system. Controlling who has the authorization to
grant access will also enable you to know who was or was not
granting access if problems develop later.
あなたの方針は、だれがあなたのサービスへのアクセスを承諾するのに権限を与えられるかを述べるべきです。 さらに、彼らがどんなタイプのアクセスを与えることが許可されているかは決定していなければなりません。 あなたのシステムへのだれのアクセスが承諾されるかのコントロールがないと、あなたには、だれがあなたのシステムを使用しているかのコントロールがないでしょう。 また、アクセスを承諾するためにだれに承認があるかを制御するのがあなたが、だれがいたか、または問題が後で発生するならアクセスを承諾していなかったかを知っているのを可能にするでしょう。
There are many schemes that can be developed to control the
distribution of access to your services. The following are the
factors that you must consider when determining who will
distribute access to your services:
あなたのサービスへのアクセスの分配を制御するために開発できる多くの体系があります。 ↓これはだれがあなたのサービスへのアクセスを広げるかを決定するときあなたが考えなければならない要素です:
o Will you be distributing access from a centralized
point or at various points?
o あなたは集結されたポイントか様々なポイントでアクセスを広げることでしょうか?
You can have a centralized distribution point to a distributed
system where various sites or departments independently authorize
access. The trade off is between security and convenience. The
more centralized, the easier to secure.
あなたは集結された分配に様々なサイトか部が独自にアクセサリーを認可するところに分散システムを示させることができます。 離れて取り引きしてください。セキュリティと便利の間には、あります。 より多くが集中すれば集結するほど、機密保護するのは、より簡単です。
o What methods will you use for creating accounts and
terminating access?
o あなたは、アカウントを作成して、アクセスを終えるのにどんなメソッドを使用するでしょうか?
From a security standpoint, you need to examine the mechanism that
セキュリティ見地から、あなたが、メカニズムを調べる必要がある、それ
Site Security Policy Handbook Working Group [Page 15] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[15ページ]RFC1244サイトセキュリティハンドブック1991年7月
you will be using to create accounts. In the least restrictive
case, the people who are authorized to grant access would be able
to go into the system directly and create an account by hand or
through vendor supplied mechanisms. Generally, these mechanisms
place a great deal of trust in the person running them, and the
person running them usually has a large amount of privileges. If
this is the choice you make, you need to select someone who is
trustworthy to perform this task. The opposite solution is to
have an integrated system that the people authorized to create
accounts run, or the users themselves may actually run. Be aware
that even in the restrictive case of having a mechanized facility
to create accounts does not remove the potential for abuse.
あなたは、アカウントを作成するのに使用するでしょう。 最も制限していない場合では、アクセスを承諾するのに権限を与えられる人々は、直接システムを調べて、手の近く、または、ベンダーの供給されたメカニズムを通してアカウントを作成できるでしょう。一般に、これらのメカニズムはそれらを実行する人に多くの信頼を置きます、そして、通常、それらを実行する人は多量の特権を持っています。 これがする選択であるなら、あなたは、だれか信頼できる人がこのタスクを実行するのを選択する必要があります。 反対のソリューションが人々がアカウントを作成するのを認可した融合システムを稼働させることであるまたはユーザ自身は実際に走るかもしれません。 アカウントを作成する機械化された施設を持つ制限している場合さえにおけるそれが乱用の可能性を取り除かないのを意識してください。
You should have specific procedures developed for the creation of
accounts. These procedures should be well documented to prevent
confusion and reduce mistakes. A security vulnerability in the
account authorization process is not only possible through abuse,
but is also possible if a mistake is made. Having clear and well
documented procedure will help ensure that these mistakes won't
happen. You should also be sure that the people who will be
following these procedures understand them.
あなたはアカウントの作成のために特定の手順を開発させるべきです。 これらの手順は、混乱を防いで、誤りを抑えるためによく記録されるべきです。 アカウント承認プロセスのセキュリティの脆弱性も、乱用で可能であるだけではありませんが、また、誤りをするなら、可能です。 手順をはっきりと、よく記録したのは、これらの誤りが起こらないのを確実にするのを助けるでしょう。 また、あなたもこれらの手順に従う人々がそれらを理解しているのを確信しているべきです。
The granting of access to users is one of the most vulnerable of
times. You should ensure that the selection of an initial
password cannot be easily guessed. You should avoid using an
initial password that is a function of the username, is part of
the user's name, or some algorithmically generated password that
can easily be guessed. In addition, you should not permit users
to continue to use the initial password indefinitely. If
possible, you should force users to change the initial password
the first time they login. Consider that some users may never
even login, leaving their password vulnerable indefinitely. Some
sites choose to disable accounts that have never been accessed,
and force the owner to reauthorize opening the account.
ユーザへのアクセスを与えるのは最も被害を受け易い回の1つです。 あなたは、容易に初期のパスワードの選択を推測できないのを保証するべきです。 あなたは、初期のパスワードを使用するのを避けるべきです、すなわち、ユーザ名の機能がユーザの名前の一部です、または、いくらかのalgorithmicallyが容易に推測できるパスワードを生成しました。 さらに、あなたは、ユーザが、初期のパスワードを無期限に使用し続けているのを許容するべきではありません。 できれば、彼らが初めてログインするとき、あなたはユーザに初期のパスワードを強制的に変えさせるべきです。 彼らのパスワードを被害を受け易い状態で無期限において、何人かのユーザが決してログインさえしないかもしれないと考えてください。 いくつかのサイトが、口座を開きながら、一度もアクセスされたことがないアカウント、および力が再認可する所有者であると無効にするのを選びます。
2.3.4 Who May Have System Administration Privileges?
2.3.4 だれに、システム管理特権があるかもしれませんか?
One security decision that needs to be made very carefully is who
will have access to system administrator privileges and passwords
for your services. Obviously, the system administrators will need
access, but inevitably other users will request special
privileges. The policy should address this issue. Restricting
privileges is one way to deal with threats from local users. The
challenge is to balance restricting access to these to protect
security with giving people who need these privileges access so
that they can perform their tasks. One approach that can be taken
is to grant only enough privilege to accomplish the necessary
tasks.
非常に慎重に作られている必要がある1つのセキュリティ決定はあなたのサービスのためのシステム管理者特権とパスワードへのだれにアクセスがあるかということです。 明らかに、システム管理者はアクセスを必要とするでしょうが、必然的に他のユーザは特権を要求するでしょう。 方針はこの問題を扱うべきです。 特権を制限するのは地元のユーザから脅威に対処することにおいて一方通行です。 挑戦は自己のタスクを実行できるようにこれらを必要とする人々に特権アクセスを与えるのにセキュリティを保護するためにアクセスをこれらに制限しながらバランスをとることです。 取ることができる1つのアプローチは必要なタスクを達成できるくらいの特権だけを与えることです。
Site Security Policy Handbook Working Group [Page 16] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[16ページ]RFC1244サイトセキュリティハンドブック1991年7月
Additionally, people holding special privileges should be
accountable to some authority and this should also be identified
within the site's security policy. If the people you grant
privileges to are not accountable, you run the risk of losing
control of your system and will have difficulty managing a
compromise in security.
さらに、特権を保持している人々は何らかの権威に責任があるべきです、そして、また、これはサイトの安全保障政策の中で特定されるべきです。 あなたが特権を与える人々は責任がないと、あなたが、あなたのシステムの損をしているコントロールの危険を冒して、安全に感染を管理するのに苦労するでしょう。
2.3.5 What Are The Users' Rights and Responsibilities?
2.3.5 ユーザの権利と責任は何ですか?
The policy should incorporate a statement on the users' rights and
responsibilities concerning the use of the site's computer systems
and services. It should be clearly stated that users are
responsible for understanding and respecting the security rules of
the systems they are using. The following is a list of topics
that you may wish to cover in this area of the policy:
方針はサイトのコンピュータ・システムとサービスの使用に関してユーザの権利と責任に関する声明を取り入れるべきです。 ユーザはそれらが使用しているシステムのセキュリティ規則を理解して、尊敬するのに責任があると明確に述べられているべきです。 ↓これはあなたが方針のこの領域でカバーしたいかもしれない話題のリストです:
o What guidelines you have regarding resource consumption
(whether users are restricted, and if so, what the
restrictions are).
o What might constitute abuse in terms of system performance.
o Whether users are permitted to share accounts or let others
use their accounts.
o How "secret" users should keep their passwords.
o How often users should change their passwords and any other
password restrictions or requirements.
o Whether you provide backups or expect the users to create
their own.
o Disclosure of information that may be proprietary.
o Statement on Electronic Mail Privacy (Electronic
Communications Privacy Act).
o Your policy concerning controversial mail or postings to
mailing lists or discussion groups (obscenity, harassment,
etc.).
o Policy on electronic communications: mail forging, etc.
o あなたはリソース消費に関して変えました。ユーザは制限されます、そして、そうだとすれば、制限が何であるかということです) . o Whatはシステム性能に関して乱用を構成するかもしれません。o Whetherユーザは、アカウントを共有するか、または他のものに彼らのアカウントを使用させるのが可能にされます。どんなガイドライン、(o Howの「秘密」のユーザが、しばしば彼らのパスワード. o Howがユーザであることを保つべきであるかどうかがいかなる他の彼らのパスワードとパスワード制限か要件も変えるべきであるか; あなたが提供するo Whetherは、ユーザが情報の独占であるかもしれないそれら自身の. o Disclosureを作成するとバックアップをとるか、または予想します。ElectronicメールPrivacy(電子通信プライバシー法)論議を呼んだメールに関するo Your方針かメーリングリストか議論への任命でのo Statementは電子通信で. o Policyを分類します(わいせつ、ハラスメントなど): メール鍛造物など
The Electronic Mail Association sponsored a white paper on the
privacy of electronic mail in companies [4]. Their basic
recommendation is that every site should have a policy on the
protection of employee privacy. They also recommend that
organizations establish privacy policies that deal with all media,
rather than singling out electronic mail.
ElectronicメールAssociationは会社[4]で電子メールのプライバシーに関する白書を後援しました。 彼らの基本的な推薦はあらゆるサイトには従業員プライバシーの保護に関する方針があるべきであるということです。 また、彼らは、組織が電子メールを選び抜くよりむしろすべてのメディアと取り引きするプライバシーに関する方針を確立することを勧めます。
They suggest five criteria for evaluating any policy:
彼らはどんな方針も評価する5つの評価基準を示します:
1. Does the policy comply with law and with duties to
third parties?
1. 方針は法と第三者への義務に応じますか?
2. Does the policy unnecessarily compromise the interest of
2. 方針は不必要に関心に感染します。
Site Security Policy Handbook Working Group [Page 17] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[17ページ]RFC1244サイトセキュリティハンドブック1991年7月
the employee, the employer or third parties?
従業員、雇い主であるまたは第三者ですか?
3. Is the policy workable as a practical matter and likely to
be enforced?
3. 方針は、実用的な件として実行可能であって、実施されそうですか?
4. Does the policy deal appropriately with all different
forms of communications and record keeping with the office?
4. 方針は適切にオフィスとのすべての異なったフォームのコミュニケーションと記録的なキープに対処しますか?
5. Has the policy been announced in advance and agreed to by
all concerned?
5. 方針は、あらかじめ、発表されて、発表されるのにすべてによって関係があった状態で同意しましたか?
2.3.6 What Are The Rights and Responsibilities of System
Administrators Versus Rights of Users
2.3.6 権利とシステム管理者対ユーザの権利の責任は何ですか?
There is a tradeoff between a user's right to absolute privacy and
the need of system administrators to gather sufficient information
to diagnose problems. There is also a distinction between a
system administrator's need to gather information to diagnose
problems and investigating security violations. The policy should
specify to what degree system administrators can examine user
files to diagnose problems or for other purposes, and what rights
you grant to the users. You may also wish to make a statement
concerning system administrators' obligation to maintaining the
privacy of information viewed under these circumstances. A few
questions that should be answered are:
絶対プライバシーへのユーザの権利と問題を診断するために十分な情報を集めるシステム管理者の必要性の間には、見返りがあります。また、問題を診断するために情報を集めるシステム管理者の必要性と安全の侵害を調査するとき、区別があります。 方針は、システム管理者が問題か他の目的のために診断するユーザ・ファイルをどの度合いに調べることができるか、そして、あなたがどんな権利をユーザに与えるかを指定するべきです。 また、あなたはシステム管理者の義務に関してこういう事情ですから見られた情報のプライバシーを維持するのにステートメントを発表したがっているかもしれません。 答えられるべきであるいくつかの質問は以下の通りです。
o Can an administrator monitor or read a user's files
for any reason?
o What are the liabilities?
o Do network administrators have the right to examine
network or host traffic?
o 管理者は、何かo Whatが負債であるo Doネットワーク管理者が権利がある理由でネットワークかホストトラフィックを調べるためにユーザのファイルをモニターしますか、読むことができますか?
2.3.7 What To Do With Sensitive Information
2.3.7 機密情報でするべきこと
Before granting users access to your services, you need to
determine at what level you will provide for the security of data
on your systems. By determining this, you are determining the
level of sensitivity of data that users should store on your
systems. You do not want users to store very sensitive
information on a system that you are not going to secure very
well. You need to tell users who might store sensitive
information what services, if any, are appropriate for the storage
of sensitive information. This part should include storing of
data in different ways (disk, magnetic tape, file servers, etc.).
Your policy in this area needs to be coordinated with the policy
concerning the rights of system administrators versus users (see
section 2.3.6).
あなたのサービスへのユーザのアクセスを承諾する前に、あなたは、あなたがどんなレベルに備えるかであなたのシステムに関するデータのセキュリティを決定する必要があります。これを決定することによって、あなたはユーザがあなたのシステムの上に保存するべきであるデータの感度のレベルを決心しています。ユーザにあなたがそれほどよく固定しないシステムの非常に機密の情報を保存して欲しくはありません。 あなたは、だれが機密情報のストレージに、もしあればどんなサービスが適切であるかという機密情報を保存するかもしれないかをユーザに言う必要があります。 この部分は、データが異なった方法(ディスク、磁気テープ、ファイルサーバーなど)で保存されるのを含んでいるはずです。 この領域のあなたの方針は、システム管理者対ユーザの権利に関して方針で調整される必要があります(セクション2.3.6を見てください)。
Site Security Policy Handbook Working Group [Page 18] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[18ページ]RFC1244サイトセキュリティハンドブック1991年7月
2.4 What Happens When the Policy is Violated
2.4 どんなHappens When Policyは危険な誘惑であるか。
It is obvious that when any type of official policy is defined, be it related to computer security or not, it will eventually be broken. The violation may occur due to an individual's negligence, accidental mistake, having not been properly informed of the current policy, or not understanding the current policy. It is equally possible that an individual (or group of individuals) may knowingly perform an act that is in direct violation of the defined policy.
どんなタイプの公式方針も結局定義されるとき、コンピュータセキュリティに関連されるか否かに関係なく、それが壊れているのは、明白です。 違反は個人の怠慢のため起こるかもしれません、偶然の誤り、適切に通貨政策について知らされるか、または通貨政策を理解であったので。 個人(または、個体群)が故意に定義された方針の直接違反中であることの行為を実行するのは、等しく可能です。
When a policy violation has been detected, the immediate course of action should be pre-defined to ensure prompt and proper enforcement. An investigation should be performed to determine how and why the violation occurred. Then the appropriate corrective action should be executed. The type and severity of action taken varies depending on the type of violation that occurred.
方針違反が検出されたとき、即座の行動は、迅速で適切な実施を確実にするために事前に定義されるべきです。 調査は、違反がどのように、なぜ起こったかを決定するために実行されるべきです。 そして、適切な修正措置は実行されるべきです。 起こった違反のタイプに頼っていて、取られた行動のタイプと厳しさは異なります。
2.4.1 Determining the Response to Policy Violations
2.4.1 方針違反への応答を決定すること。
Violations to policy may be committed by a wide variety of users.
Some may be local users and others may be from outside the local
environment. Sites may find it helpful to define what it
considers "insiders" and "outsiders" based upon administrative,
legal or political boundaries. These boundaries imply what type
of action must be taken to correct the offending party; from a
written reprimand to pressing legal charges. So, not only do you
need to define actions based on the type of violation, you also
need to have a clearly defined series of actions based on the kind
of user violating your computer security policy. This all seems
rather complicated, but should be addressed long before it becomes
necessary as the result of a violation.
方針への違反はさまざまなユーザによって遂行されるかもしれません。 何かが地元のユーザであるかもしれません、そして、他のものは地方の環境の外から来ているかもしれません。 サイトによって、管理の、または、法的であるか政治上の境界に基づいているそれが「インサイダーと部外者」であると考えることを定義するのが役立っているのがわかるかもしれません。 これらの境界は、動作のタイプがそうしなければならないものが違反した当事者の誤りを正すのに要するのを含意します。 書かれた叱責から法的な充電を押すまで。 それで、単にではなくあなたは、違反のタイプに基づく動作を定義する必要があります、また、明確に定義されたシリーズの動作をあなたのコンピュータセキュリティ方針に違反するユーザの種類に基づかせているのが必要です。 これはすべて、かなり複雑に見えますが、違反の結果として必要になるずっと前に扱われるべきです。
One point to remember about your policy is that proper education
is your best defense. For the outsiders who are using your
computer legally, it is your responsibility to verify that these
individuals are aware of the policies that you have set forth.
Having this proof may assist you in the future if legal action
becomes necessary.
あなたの方針に関して覚えている1ポイントは適切な教育があなたの最も良いディフェンスであるということです。 あなたのコンピュータを法的に使用している部外者にとって、これらの個人があなたが旅に出たのを方針を意識していることを確かめるのは、あなたの責任です。 この証拠を持っていると、訴訟が必要になるなら、あなたは将来、補助されるかもしれません。
As for users who are using your computer illegally, the problem is
basically the same. What type of user violated the policy and how
and why did they do it? Depending on the results of your
investigation, you may just prefer to "plug" the hole in your
computer security and chalk it up to experience. Or if a
significant amount of loss was incurred, you may wish to take more
drastic action.
不法にあなたのコンピュータを使用しているユーザに関して、問題は基本的に同じです。 どんなタイプのユーザは方針に違反したか、そして、彼らはどのように、なぜそれをしましたか? あなたの調査の結果によって、あなたは、あなたのコンピュータセキュリティで穴を「ふさい」で、それを経験までチョークで書くのをただ好むことができます。 または、重要な欠損額が被られたなら、あなたは、より抜本的な行動を取りたがっているかもしれません。
Site Security Policy Handbook Working Group [Page 19] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[19ページ]RFC1244サイトセキュリティハンドブック1991年7月
2.4.2 What to do When Local Users Violate the Policy of a Remote
Site
2.4.2、こと、WhenローカルユーザーViolateにRemote SiteのPolicyをします。
In the event that a local user violates the security policy of a
remote site, the local site should have a clearly defined set of
administrative actions to take concerning that local user. The
site should also be prepared to protect itself against possible
actions by the remote site. These situations involve legal issues
which should be addressed when forming the security policy.
地元のユーザがリモートサイトの安全保障政策に違反する場合、ローカル・サイトには、その地元のユーザに関して取る明確に定義されたセットの管理行動があるべきです。 また、サイトはリモートサイトのそばで可能な動作に対して我が身をかばうように準備されるべきです。 これらの状況は安全保障政策を形成するとき扱われるべきである法律問題にかかわります。
2.4.3 Defining Contacts and Responsibilities to Outside
Organizations
2.4.3 接触と責任を組織の外と定義すること。
The local security policy should include procedures for
interaction with outside organizations. These include law
enforcement agencies, other sites, external response team
organizations (e.g., the CERT, CIAC) and various press agencies.
The procedure should state who is authorized to make such contact
and how it should be handled. Some questions to be answered
include:
ローカルの安全保障政策は外の組織との相互作用のための手順を含むべきです。 これらは警察機関、他のサイト、外部応答チーム組織(例えば、CERT、CIAC)、および様々な通信社を含んでいます。 手順は、だれがそのような接触を作るかに権限を与えられて、それがどのように扱われるべきであるかを述べるべきです。 答えられるいくつかの質問は:
o Who may talk to the press?
o When do you contact law enforcement and investigative agencies?
o If a connection is made from a remote site, is the
system manager authorized to contact that site?
o Can data be released? What kind?
o だれがマスコミに話すかもしれませんか?o Whenは接触法施行であって調査の政府機関をあなたにします--接続がリモートサイトから作られるo If、システム・マネージャが、サイト?o Canデータが発表されるのに連絡するのに権限を与えられますか? どんな種類?
Detailed contact information should be readily available along
with clearly defined procedures to follow.
詳細な問い合わせ先は従う明確に定義された手順と共に容易に利用可能であるべきです。
2.4.4 What are the Responsibilities to our Neighbors and Other
Internet Sites?
2.4.4 私たちのネイバーズとOtherインターネットSitesへのResponsibilitiesは何ですか?
The Security Policy Working Group within the IETF is working on a
document entitled, "Policy Guidelines for the Secure Operation of
the Internet" [23]. It addresses the issue that the Internet is a
cooperative venture and that sites are expected to provide mutual
security assistance. This should be addressed when developing a
site's policy. The major issue to be determined is how much
information should be released. This will vary from site to site
according to the type of site (e.g., military, education,
commercial) as well as the type of security violation that
occurred.
IETFの中のSecurity Policy作業部会は題するドキュメントに取り組んでいます、「インターネットの安全な操作のための政策文書」[23]。 インターネットがある問題に共同事業を扱います、そして、サイトが互いの安全保障援助を提供すると予想されます。 サイトの方針を開発するとき、これは扱われるべきです。 断固とする主要な問題はどのくらいの情報が発表されるべきであるかということです。 起こった安全の侵害のタイプと同様にサイト(例えば、軍、教育、コマーシャル)のタイプに従って、これはサイトによって異なるでしょう。
2.4.5 Issues for Incident Handling Procedures
2.4.5 付随している取り扱い手順のための問題
Along with statements of policy, the document being prepared
should include procedures for incident handling. This is covered
方針の声明と共に、準備されるドキュメントは付随している取り扱いのための手順を含んでいるはずです。 これはカバーされています。
Site Security Policy Handbook Working Group [Page 20] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[20ページ]RFC1244サイトセキュリティハンドブック1991年7月
in detail in the next chapter. There should be procedures
available that cover all facets of policy violation.
詳細である、次の章で。 方針違反のすべての一面をカバーする利用可能な手順があるべきです。
2.5 Locking In or Out
2.5 中か外ではロックすること。
Whenever a site suffers an incident which may compromise computer security, the strategies for reacting may be influenced by two opposing pressures.
サイトがコンピュータセキュリティに感染するかもしれないインシデントを受けるときはいつも、反応するための戦略は、2時までに圧力に反対しながら、影響を及ぼされるかもしれません。
If management fears that the site is sufficiently vulnerable, it may choose a "Protect and Proceed" strategy. This approach will have as its primary goal the protection and preservation of the site facilities and to provide for normalcy for its users as quickly as possible. Attempts will be made to actively interfere with the intruder's processes, prevent further access and begin immediate damage assessment and recovery. This process may involve shutting down the facilities, closing off access to the network, or other drastic measures. The drawback is that unless the intruder is identified directly, they may come back into the site via a different path, or may attack another site.
経営者側が、サイトが十分被害を受け易いと恐れるなら、それは「保護してください、そして、続いてください」という戦略を選ぶかもしれません。 そして、このアプローチにはプライマリ目標としてサイト施設の保護と保存がある、ユーザのためにできるだけはやく正常に備えるために。 活発に侵入者のプロセスを妨げて、さらなるアクセスを防いで、即座の攻撃成果の判定と回復を始めるのを試みをするでしょう。 このプロセスはネットワークへのアクセスをふさいで、施設を止めるか、または他の抜本にかかわるかもしれません。 欠点は侵入者が直接特定されない場合、彼らが異なった経路を通ってサイトに戻るか、または別のサイトに攻撃するかもしれないということです。
The alternate approach, "Pursue and Prosecute", adopts the opposite philosophy and goals. The primary goal is to allow intruders to continue their activities at the site until the site can identify the responsible persons. This approach is endorsed by law enforcement agencies and prosecutors. The drawback is that the agencies cannot exempt a site from possible user lawsuits if damage is done to their systems and data.
補欠がアプローチして、「追求して、起訴する」、反対の哲学と目標を採用します。 プライマリ目標はサイトが責任者を特定できるまで侵入者がサイトで彼らの活動を続けているのを許容することです。 このアプローチは警察機関と検察官によって是認されます。 欠点は損害がそれらのシステムとデータに与えられるなら政府機関がサイトから可能なユーザ訴訟から免除できないということです。
Prosecution is not the only outcome possible if the intruder is identified. If the culprit is an employee or a student, the organization may choose to take disciplinary actions. The computer security policy needs to spell out the choices and how they will be selected if an intruder is caught.
侵入者が特定されるなら、起訴は可能な唯一の結果ではありません。 罪人が従業員か学生であるなら、組織は、懲戒するのを選ぶかもしれません。 コンピュータセキュリティ方針は、選択と侵入者が引っかかるとそれらがどう選択されるかを詳しく説明する必要があります。
Careful consideration must be made by site management regarding their approach to this issue before the problem occurs. The strategy adopted might depend upon each circumstance. Or there may be a global policy which mandates one approach in all circumstances. The pros and cons must be examined thoroughly and the users of the facilities must be made aware of the policy so that they understand their vulnerabilities no matter which approach is taken.
この問題への彼らのアプローチに関する会場設営は問題が起こる前に熟慮をしなければなりません。 採用された戦略は各状況に依存するかもしれません。 または、命令1がすべての事情でアプローチするグローバルな方針があるかもしれません。 賛否両論を徹底的に調べなければなりません、そして、どのアプローチを取っても彼らが自分達の脆弱性を理解するように、施設のユーザを方針を意識するようにしなければなりません。
The following are checklists to help a site determine which strategy to adopt: "Protect and Proceed" or "Pursue and Prosecute".
↓これはサイトが、どの戦略を採用したらよいかを決定するのを助けるチェックリストです: 保護してください、そして、続いてください。「」 「追求して、起訴します」。
Site Security Policy Handbook Working Group [Page 21] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[21ページ]RFC1244サイトセキュリティハンドブック1991年7月
Protect and Proceed
保護してください、そして、続いてください。
1. If assets are not well protected.
1. 資産がよく保護されないなら。
2. If continued penetration could result in great
financial risk.
2. 続けられているなら、侵入はかなりの財政危機をもたらすかもしれません。
3. If the possibility or willingness to prosecute
is not present.
3. 可能性か起訴する意欲が存在していないなら。
4. If user base is unknown.
4. ユーザベースが未知であるなら。
5. If users are unsophisticated and their work is
vulnerable.
5. ユーザが世慣れていないか、そして、彼らの仕事は被害を受け易いです。
6. If the site is vulnerable to lawsuits from users, e.g.,
if their resources are undermined.
6. 例えば、彼らのリソースが弱体化させられるならサイトがユーザからの訴訟に被害を受け易いなら。
Pursue and Prosecute
追求して、起訴します。
1. If assets and systems are well protected.
1. 資産とシステムがよく保護されるなら。
2. If good backups are available.
2. 良いバックアップが利用可能であるなら。
3. If the risk to the assets is outweighed by the
disruption caused by the present and possibly future
penetrations.
3. 資産へのリスクが現在の、そして、ことによると将来のペネトレーションによって引き起こされた分裂より軽いなら。
4. If this is a concentrated attack occurring with great
frequency and intensity.
4. これがきわめて頻繁に起こる集中攻撃と強度であるなら。
5. If the site has a natural attraction to intruders, and
consequently regularly attracts intruders.
5. サイトが自然なアトラクションを侵入者に持って、定期的にその結果侵入者を引き付けるなら。
6. If the site is willing to incur the financial (or other)
risk to assets by allowing the penetrator continue.
6. サイトが、針入度計を許容することによって財政的で(他)の危険を資産へ被っても構わないと思っているなら、続いてください。
7. If intruder access can be controlled.
7. 侵入者アクセスを制御できるなら。
8. If the monitoring tools are sufficiently well-developed
to make the pursuit worthwhile.
8. モニターしているツールが追求を価値があるようにするように十分よく開発されているなら。
9. If the support staff is sufficiently clever and knowledgable
about the operating system, related utilities, and systems
to make the pursuit worthwhile.
9. 補助スタッフが追求を価値があるようにするオペレーティングシステム、関連するユーティリティ、およびシステムに関して十分賢明であって、博識であるなら。
10. If there is willingness on the part of management to
prosecute.
10. 意欲が遂行する管理側のあれば。
Site Security Policy Handbook Working Group [Page 22] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[22ページ]RFC1244サイトセキュリティハンドブック1991年7月
11. If the system adminitrators know in general what kind of
evidence would lead to prosecution.
11. システムadminitratorsが、どういう証拠が起訴につながるかを一般に知っているなら。
12. If there is established contact with knowledgeable law
enforcement.
12. 博識な法施行との接触が設置されるなら。
13. If there is a site representative versed in the relevant
legal issues.
13. サイトがあれば、代表は関連法律問題で作詩をしました。
14. If the site is prepared for possible legal action from
its own users if their data or systems become compromised
during the pursuit.
14. 彼らのデータかシステムが追求の間、感染されるようになるならサイトが可能な訴訟のためにそれ自身のユーザから準備されるなら。
2.6 Interpreting the Policy
2.6 方針を解釈すること。
It is important to define who will interpret the policy. This could be an individual or a committee. No matter how well written, the policy will require interpretation from time to time and this body would serve to review, interpret, and revise the policy as needed.
だれが方針を解釈するかを定義するのは重要です。 これは、個人か委員会であるかもしれません。 どれくらい上手に書かれなかった問題、全く方針は時々解釈を必要として、このボディーは必要に応じて方針を見直して、解釈して、改訂するのに役立つでしょう。
2.7 Publicizing the Policy
2.7 方針をピーアールすること。
Once the site security policy has been written and established, a vigorous process should be engaged to ensure that the policy statement is widely and thoroughly disseminated and discussed. A mailing of the policy should not be considered sufficient. A period for comments should be allowed before the policy becomes effective to ensure that all affected users have a chance to state their reactions and discuss any unforeseen ramifications. Ideally, the policy should strike a balance between protection and productivity.
サイト安全保障政策がいったん書かれていて、確立されると、活発なプロセスについて、施政方針が広さと徹底的に広められるのを保証するために従事して、議論するべきです。 十分であると方針の郵送を考えるべきではありません。 方針がすべての影響を受けるユーザには彼らの反応を述べて、どんな予期しない分岐についても議論する機会があるのを保証するのに有効になる前にコメントのための期間は許容されるべきです。 理想的に、方針は保護と生産性の間のバランスの心を打つべきです。
Meetings should be held to elicit these comments, and also to ensure that the policy is correctly understood. (Policy promulgators are not necessarily noted for their skill with the language.) These meetings should involve higher management as well as line employees. Security is a collective effort.
会合が、これらのコメントを引き出して、また、方針が正しく理解されているのを保証するために行われるべきです。 (方針公布者は言語による彼らの技能で必ず有名であるというわけではありません。) これらのミーティングは直属の部下と同様に上級管理職にかかわるべきです。 セキュリティは結集した力です。
In addition to the initial efforts to publicize the policy, it is essential for the site to maintain a continual awareness of its computer security policy. Current users may need periodic reminders New users should have the policy included as part of their site introduction packet. As a condition for using the site facilities, it may be advisable to have them sign a statement that they have read and understood the policy. Should any of these users require legal action for serious policy violations, this signed statement might prove to be a valuable aid.
方針をピーアールする初期の取り組みに加えて、サイトがコンピュータセキュリティ方針の絶え間ない認識を維持するのは、不可欠です。 彼らのサイト序論パケットの一部として方針を含んで、現在のユーザはNewユーザが持つべきである周期的な督促状を必要とするかもしれません。 サイト施設を使用するための状態として、彼らが方針を読んで、理解していたという声明を調印させるのは、賢明であるかもしれません。 これらのユーザのどれかが重大な方針違反のための訴訟を必要とするなら、声明であると署名されるこれは役に立つ援助であると判明するかもしれません。
Site Security Policy Handbook Working Group [Page 23] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[23ページ]RFC1244サイトセキュリティハンドブック1991年7月
3. Establishing Procedures to Prevent Security Problems
3. 警備上の問題を防ぐために手順を確立します。
The security policy defines what needs to be protected. This section discusses security procedures which specify what steps will be used to carry out the security policy.
安全保障政策は、何が、保護される必要であるかを定義します。 このセクションはどんなステップが安全保障政策を行うのに使用されるかを指定するセキュリティ手順について論じます。
3.1 Security Policy Defines What Needs to be Protected
3.1 セキュリティPolicy Defines Whatは、Protectedである必要があります。
The security policy defines the WHAT's: what needs to be protected, what is most important, what the priorities are, and what the general approach to dealing with security problems should be.
安全保障政策はWHATのものを定義します: 何が、保護される必要があるか、そして、何が最も重要であるか、そして、プライオリティは何です、そして、警備上の問題に対処することへの一般的方法は何であるべきですか?
The security policy by itself doesn't say HOW things are protected. That is the role of security procedures, which this section discusses. The security policy should be a high level document, giving general strategy. The security procedures need to set out, in detail, the precise steps your site will take to protect itself.
それ自体で安全保障政策は、HOWものが保護されると言いません。 それはセキュリティ手順の役割です。(このセクションは手順について論じます)。 一般的な戦略を与えて、安全保障政策は高い平らなドキュメントであるべきです。 セキュリティ手順は、詳細に、あなたのサイトが我が身をかばうために採る正確な方法を出す必要があります。
The security policy should include a general risk assessment of the types of threats a site is mostly likely to face and the consequences of those threats (see section 2.2). Part of doing a risk assessment will include creating a general list of assets that should be protected (section 2.2.2). This information is critical in devising cost-effective procedures.
安全保障政策はサイトがほとんど直面していそうである脅威のタイプとそれらの脅威の結果の一般的なリスクアセスメントを含むべきです(セクション2.2を見てください)。 リスクアセスメントをする一部が、保護されるべきである一般的な財産目録(セクション2.2.2)を作成するのを含むでしょう。 この情報は費用対効果に優れた手順について工夫するのにおいて重要です。
It is often tempting to start creating security procedures by deciding on different mechanisms first: "our site should have logging on all hosts, call-back modems, and smart cards for all users." This approach could lead to some areas that have too much protection for the risk they face, and other areas that aren't protected enough. Starting with the security policy and the risks it outlines should ensure that the procedures provide the right level of protect for all assets.
それは最初に異なったメカニズムを決めることによってセキュリティ手順を作成し始めるのにしばしば誘惑しています: 「私たちのサイトはすべてのホスト、呼び戻しモデム、およびすべてのユーザのためのスマートカードに伐採を持つべきです。」 このアプローチはそれらが直面している危険のためのあまりに多くの保護を持っているいくつかの領域、および十分保護されない他の領域につながるかもしれません。 安全保障政策とリスクからそれを始めて、アウトラインは、手順が平らな状態で権利を提供するのを確実にするべきです。すべての資産で、保護してください。
3.2 Identifing Possible Problems
3.2 起こりうる問題をIdentifingすること。
To determine risk, vulnerabilities must be identified. Part of the purpose of the policy is to aid in shoring up the vulnerabilities and thus to decrease the risk in as many areas as possible. Several of the more popular problem areas are presented in sections below. This list is by no means complete. In addition, each site is likely to have a few unique vulnerabilities.
危険を決定するために、脆弱性を特定しなければなりません。 方針の目的の一部は、脆弱性を支える際に支援して、その結果、できるだけ多くの領域で危険を減少させることです。 いくつかの、よりポピュラーな問題領域が下のセクションで提示されます。 このリストは決して完全ではありません。 さらに、それぞれのサイトはいくつかのユニークな脆弱性を持っていそうです。
3.2.1 Access Points
3.2.1 アクセスポイント
Access points are typically used for entry by unauthorized users.
Having many access points increases the risk of access to an
organization's computer and network facilities.
アクセスポイントはエントリーに権限のないユーザによって通常使用されます。 多くのアクセスポイントを持っていると、組織のコンピュータとネットワーク施設へのアクセスの危険は増強されます。
Site Security Policy Handbook Working Group [Page 24] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[24ページ]RFC1244サイトセキュリティハンドブック1991年7月
Network links to networks outside the organization allow access
into the organization for all others connected to that external
network. A network link typically provides access to a large
number of network services, and each service has a potential to be
compromised.
組織の外におけるネットワークへのネットワークリンクはその外部のネットワークに接続されたすべての他のもののための組織にアクセスを許します。 ネットワークリンクは多くのネットワーク・サービスへのアクセスを通常提供します、そして、各サービスには、感染するべき可能性があります。
Dialup lines, depending on their configuration, may provide access
merely to a login port of a single system. If connected to a
terminal server, the dialup line may give access to the entire
network.
それらの構成によって、ダイヤルアップ回線は単にただ一つのシステムのログインポートへのアクセスを提供するかもしれません。 ターミナルサーバに接続されるなら、ダイヤルアップ回線は全体のネットワークへのアクセスを与えるかもしれません。
Terminal servers themselves can be a source of problem. Many
terminal servers do not require any kind of authentication.
Intruders often use terminal servers to disguise their actions,
dialing in on a local phone and then using the terminal server to
go out to the local network. Some terminal servers are configured
so that intruders can TELNET [19] in from outside the network, and
then TELNET back out again, again serving to make it difficult to
trace them.
ターミナルサーバ自体は問題の源であるかもしれません。 多くのターミナルサーバはどんな種類の認証も必要としません。 侵入者は彼らの動作を変装するのにしばしばターミナルサーバを使用します、地方の電話で直通電話にかけて、次に、企業内情報通信網に出かけるのにターミナルサーバを使用して。 いくつかのターミナルサーバが構成されるので、次に、ネットワーク、およびTELNETの外からの中の侵入者缶のTELNET[19]は再びバックして出ます、再び彼らをたどるのを難しくするのに役立って。
3.2.2 Misconfigured Systems
3.2.2 Misconfiguredシステム
Misconfigured systems form a large percentage of security holes.
Today's operating systems and their associated software have
become so complex that understanding how the system works has
become a full-time job. Often, systems managers will be non-
specialists chosen from the current organization's staff.
Misconfiguredシステムはセキュリティーホールの大きな割合を形成します。 今日のオペレーティングシステムとそれらの関連ソフトウェアがとても複雑になったので、システムがどのように働くかを理解しているのがフルタイムの仕事になりました。 しばしば、システム・マネージャは現在の組織のスタッフから選ばれた非専門家になるでしょう。
Vendors are also partly responsible for misconfigured systems. To
make the system installation process easier, vendors occasionally
choose initial configurations that are not secure in all
environments.
また、ベンダーもmisconfiguredシステムに一部責任感が強いです。システムインストールプロセスをより簡単にするように、ベンダーは時折すべての環境で安全でない初期の構成を選びます。
3.2.3 Software Bugs
3.2.3 ソフトウェアのバグ
Software will never be bug free. Publicly known security bugs are
common methods of unauthorized entry. Part of the solution to
this problem is to be aware of the security problems and to update
the software when problems are detected. When bugs are found,
they should be reported to the vendor so that a solution to the
problem can be implemented and distributed.
ソフトウェアには、バグが決してないでしょう。 公的に知られているセキュリティバグは権限のないエントリーの共通方法です。 この問題への解決の一部は、問題が検出されるとき、警備上の問題を意識していて、ソフトウェアをアップデートすることです。 バグが見つけられるとき、それらは、問題へのソリューションを実現して、分配できるようにベンダーに報告されるべきです。
3.2.4 "Insider" Threats
3.2.4 「インサイダー」の脅威
An insider to the organization may be a considerable threat to the
security of the computer systems. Insiders often have direct
access to the computer and network hardware components. The
ability to access the components of a system makes most systems
組織へのインサイダーは. インサイダーがコンピュータへのアクセスをしばしば指示させるコンピュータ・システムのセキュリティへのかなりの脅威であり、ハードウェアの部品をネットワークでつなぐかもしれません。 システムの部品にアクセスする能力は大部分システムにします。
Site Security Policy Handbook Working Group [Page 25] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[25ページ]RFC1244サイトセキュリティハンドブック1991年7月
easier to compromise. Most desktop workstations can be easily
manipulated so that they grant privileged access. Access to a
local area network provides the ability to view possibly sensitive
data traversing the network.
感染するのは、より簡単です。 容易にほとんどのデスクトップ型ワークステーションを操ることができるので、彼らは特権的アクセスを承諾します。 ローカル・エリア・ネットワークへのアクセスはことによると極秘データネットワーク転送を見る能力を提供します。
3.3 Choose Controls to Protect Assets in a Cost-Effective Way
3.3は、費用対効果に優れた方法で資産を保護するためにコントロールを選びます。
After establishing what is to be protected, and assessing the risks these assets face, it is necessary to decide how to implement the controls which protect these assets. The controls and protection mechanisms should be selected in a way so as to adequately counter the threats found during risk assessment, and to implement those controls in a cost effective manner. It makes little sense to spend an exorbitant sum of money and overly constrict the user base if the risk of exposure is very small.
何が保護されて、危険を評価するかこれらの資産が面していることであるかを確証した後に、これらの資産を保護するコントロールを実装する方法を決めるのが必要です。 コントロールと保護メカニズムは適切にリスクアセスメントの間に見つけられた脅威に対抗するために方法で選択されるべきです、そして、それらを実装するのは費用効率がよい方法で制御されます。 暴露のリスクが非常に低いなら、それはほとんど法外な金額を費やして、ユーザベースをひどく締めつける意味になりません。
3.3.1 Choose the Right Set of Controls
3.3.1 コントロールの右のセットを選んでください。
The controls that are selected represent the physical embodiment
of your security policy. They are the first and primary line of
defense in the protection of your assets. It is therefore most
important to ensure that the controls that you select are the
right set of controls. If the major threat to your system is
outside penetrators, it probably doesn't make much sense to use
biometric devices to authenticate your regular system users. On
the other hand, if the major threat is unauthorized use of
computing resources by regular system users, you'll probably want
to establish very rigorous automated accounting procedures.
選択されるコントロールはあなたの安全保障政策の物理的な具体化を表します。 それらはあなたの資産の保護で1番目の、そして、プライマリの防衛線です。 したがって、あなたが選択するコントロールがコントロールの右のセットであることを保証するのは最も重要です。 針入度計の外にあなたのシステムへの大きな脅威があるなら、それはたぶんあなたの等軸晶系ユーザを認証するのにバイオメトリックなデバイスを使用する多くの意味になりません。 他方では、大きな脅威が等軸晶系ユーザによるコンピューティング資源の無断使用であるなら、あなたはたぶん非常に厳密な自動化された会計手順を確立したくなるでしょう。
3.3.2 Use Common Sense
3.3.2 常識を使用してください。
Common sense is the most appropriate tool that can be used to
establish your security policy. Elaborate security schemes and
mechanisms are impressive, and they do have their place, yet there
is little point in investing money and time on an elaborate
implementation scheme if the simple controls are forgotten. For
example, no matter how elaborate a system you put into place on
top of existing security controls, a single user with a poor
password can still leave your system open to attack.
常識はあなたの安全保障政策を証明するのに使用できる中で最も適切なツールです。 精巧なセキュリティ体系とメカニズムは印象的です、そして、それらには、自己のところがありますが、簡単なコントロールが忘れられているなら、投資のお金の少ないポイントと時間が精巧な実現体系にあります。 例えば、あなたが存在の上のセキュリティが制御される場所にどれくらい精巧なシステムを置いても、不十分なパスワードをもっているシングルユーザーはまだ攻撃するために開いた状態であなたのシステムを残すことができます。
3.4 Use Multiple Strategies to Protect Assets
3.4は、資産を保護するのに複数の戦略を使用します。
Another method of protecting assets is to use multiple strategies. In this way, if one strategy fails or is circumvented, another strategy comes into play to continue protecting the asset. By using several simpler strategies, a system can often be made more secure than if one very sophisticated method were used in its place. For example, dial-back modems can be used in conjunction with traditional
資産を保護する別のメソッドは複数の戦略を使用することです。 このように、1つの戦略が失敗するか、または回避されるなら、別の戦略は、資産を保護し続けるためにプレーに入ります。 いくつかの、より簡単な戦略を使用することによって、システムを非常に高度なメソッドが1であるなら場所で使用されたより安全にしばしばすることができます。 例えば、伝統的に関連してダイヤル逆モデムを使用できます。
Site Security Policy Handbook Working Group [Page 26] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[26ページ]RFC1244サイトセキュリティハンドブック1991年7月
logon mechanisms. Many similar approaches could be devised that provide several levels of protection for assets. However, it's very easy to go overboard with extra mechanisms. One must keep in mind exactly what it is that needs to be protected.
ログオンメカニズム資産のためのいくつかのレベルの保護を提供する多くの同様のアプローチについて工夫できました。 しかしながら、.念頭にそれがまさにものであることを保たなければならない付加的なメカニズムで船から落ちるのに、非常にたやすく、それが、保護される必要があるということです。
3.5 Physical Security
3.5 物理的なセキュリティ
It is a given in computer security if the system itself is not physically secure, nothing else about the system can be considered secure. With physical access to a machine, an intruder can halt the machine, bring it back up in privileged mode, replace or alter the disk, plant Trojan horse programs (see section 2.13.9.2), or take any number of other undesirable (and hard to prevent) actions.
システム自体が肉体的に安全でないならコンピュータセキュリティでそれが当然のことである、安全であるとシステムに関する他に何もを考えることができます。 望ましくない、そして、(防ぎにくいです)もう一方についていずれも達するセクション2.13.9の.2)、または撮影を見てください。侵入者は、マシンへの物理的なアクセスで、ディスクをマシンを止めるか、特権があるモードでそれを返すか、取り替えるか、または変更できます、プラントトロイの木馬プログラム、(動作。
Critical communications links, important servers, and other key machines should be located in physically secure areas. Some security systems (such as Kerberos) require that the machine be physically secure.
重要なコミュニケーションリンク、重要なサーバ、および他の主要なマシンは肉体的に安全な領域に位置するべきです。 いくつかのセキュリティシステム(ケルベロスなどの)が、マシンが肉体的に安全であることを必要とします。
If you cannot physically secure machines, care should be taken about trusting those machines. Sites should consider limiting access from non-secure machines to more secure machines. In particular, allowing trusted access (e.g., the BSD Unix remote commands such as rsh) from these kinds of hosts is particularly risky.
あなたが物理的にマシンを固定できないなら、それらのマシンを信じることに関して注意するべきです。 サイトは、非安全なマシンからのアクセスをより安全なマシンに制限すると考えるべきです。 これらの種類のホストから信じられたアクセス(例えば、rshなどのBSD Unixのリモートコマンド)を許すのは特に特に、危険です。
For machines that seem or are intended to be physically secure, care should be taken about who has access to the machines. Remember that custodial and maintenance staff often have keys to rooms.
見えるか、または肉体的に安全であることを意図するマシンにおいて、だれがマシンに近づく手段を持つかに関して注意するべきです。 そして、覚えている、そんなに保管、整備員はしばしば部屋のキーを持っています。
3.6 Procedures to Recognize Unauthorized Activity
無許可の行為を認識する3.6の手順
Several simple procedures can be used to detect most unauthorized uses of a computer system. These procedures use tools provided with the operating system by the vendor, or tools publicly available from other sources.
コンピュータ・システムのほとんどの無断使用を検出するのにいくつかの簡単な手順を用いることができます。 これらの手順はオペレーティングシステムがベンダーによって提供されたツール、または他のソースから公的に利用可能なツールを使用します。
3.6.1 Monitoring System Use
3.6.1 監視システム使用
System monitoring can be done either by a system administrator, or
by software written for the purpose. Monitoring a system involves
looking at several parts of the system and searching for anything
unusual. Some of the easier ways to do this are described in this
section.
システム管理者、または目的のために書かれたソフトウェアはシステムの監視ができます。 システムをモニターするのは、システムと何でも捜し求める数個の部品を珍しく見ることを伴います。 これをする近道のいくつかがこのセクションで説明されます。
The most important thing about monitoring system use is that it be
done on a regular basis. Picking one day out of the month to
monitor the system is pointless, since a security breach can be
isolated to a matter of hours. Only by maintaining a constant
監視システム使用の周りの最も重要なものは定期的にそれをするということです。 システムをモニターする月からのある日の選択は無意味です、何時間もの問題に機密保護違反を隔離できるので。 単に定数を維持することによって
Site Security Policy Handbook Working Group [Page 27] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[27ページ]RFC1244サイトセキュリティハンドブック1991年7月
vigil can you expect to detect security violations in time to
react to them.
あなたが時間内にそれらに反応するために安全の侵害を検出すると予想する不寝番缶。
3.6.2 Tools for Monitoring the System
3.6.2 システムをモニターするためのツール
This section describes tools and methods for monitoring a system
against unauthorized access and use.
このセクションは不正アクセスと使用に対してシステムをモニターするためのツールとメソッドを説明します。
3.6.2.1 Logging
3.6.2.1 伐採
Most operating systems store numerous bits of information in
log files. Examination of these log files on a regular basis
is often the first line of defense in detecting unauthorized
use of the system.
ほとんどのオペレーティングシステムがログファイルの多数のビットの情報を保存します。 定期的にしばしばこれらのログファイルの調査はシステムの無断使用を検出することにおいて防御の第一線です。
- Compare lists of currently logged in users and past
login histories. Most users typically log in and out
at roughly the same time each day. An account logged
in outside the "normal" time for the account may be in
use by an intruder.
- ユーザと過去のログイン歴史に登録された現在のリストを比較してください。 ほとんどのユーザは、毎日、通常ログインして、およそ同時にそうします。 アカウントのための「正常な」時間ログインされたアカウントは侵入者で使用中であるかもしれません。
- Many systems maintain accounting records for billing
purposes. These records can also be used to determine
usage patterns for the system; unusual accounting records
may indicate unauthorized use of the system.
- 多くのシステムが支払い目的のための会計帳簿を維持します。 また、システムのために用法パターンを決定するのにこれらの記録を使用できます。 珍しい会計帳簿はシステムの無断使用を示すかもしれません。
- System logging facilities, such as the UNIX "syslog"
utility, should be checked for unusual error messages
from system software. For example, a large number of
failed login attempts in a short period of time may
indicate someone trying to guess passwords.
- UNIX"syslog"ユーティリティなどのシステム伐採施設はシステムソフトからの珍しいエラーメッセージがないかどうかチェックされるべきです。 例えば、多くの失敗したログイン試みが、短時間にパスワードを推測しようとしながら、だれかを示すかもしれません。
- Operating system commands which list currently executing
processes can be used to detect users running programs
they are not authorized to use, as well as to detect
unauthorized programs which have been started by an
intruder.
- それらが認可されないプログラムを動かすと使用されるユーザを検出して、侵入者によって始動された権限のないプログラムを検出するのに現在プロセスを実行しながら記載するオペレーティングシステムコマンドは使用できます。
3.6.2.2 Monitoring Software
3.6.2.2 モニターしているソフトウェア
Other monitoring tools can easily be constructed using standard
operating system software, by using several, often unrelated,
programs together. For example, checklists of file ownerships
and permission settings can be constructed (for example, with
"ls" and "find" on UNIX) and stored off-line. These lists can
then be reconstructed periodically and compared against the
master checklist (on UNIX, by using the "diff" utility).
Differences may indicate that unauthorized modifications have
数個の、そして、しばしば関係ないプログラムを一緒に使用することによって標準のオペレーティングシステムソフトウェアを使用することで容易に他のモニターしているツールを構成できます。 例えば、ファイル所有権と許可設定に関するチェックリストをオフラインで構成して(例えばUNIXの上に"ls"と「掘り出し物」がある状態で)、保存できます。 次に、マスターチェックリスト(「デフ」ユーティリティを使用するのによるUNIXの)に対してこれらのリストを定期的に再建して、たとえることができます。 違いは、権限のない変更がそうしたのを示すかもしれません。
Site Security Policy Handbook Working Group [Page 28] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[28ページ]RFC1244サイトセキュリティハンドブック1991年7月
been made to the system.
システムに作られています。
Still other tools are available from third-party vendors and
public software distribution sites. Section 3.9.9 lists
several sources from which you can learn what tools are
available and how to get them.
まだ他のツールはサードパーティのベンダーと公共のソフトウェア配布サイトから利用可能です。 セクション3.9 .9 あなたがどんなツールが利用可能であるか、そして、どのようにそれらを得るかを学ぶことができるいくつかのソースを記載します。
3.6.2.3 Other Tools
3.6.2.3 他のツール
Other tools can also be used to monitor systems for security
violations, although this is not their primary purpose. For
example, network monitors can be used to detect and log
connections from unknown sites.
これはそれらのプライマリ目的ではありませんが、また、安全の侵害のシステムをモニターするのに他のツールを使用できます。 例えば、未知のサイトから接続を検出して、登録するのにネットワークモニターを使用できます。
3.6.3 Vary the Monitoring Schedule
3.6.3 モニターしているスケジュールを変えてください。
The task of system monitoring is not as daunting as it may seem.
System administrators can execute many of the commands used for
monitoring periodically throughout the day during idle moments
(e.g., while talking on the telephone), rather than spending fixed
periods of each day monitoring the system. By executing the
commands frequently, you will rapidly become used to seeing
"normal" output, and will easily spot things which are out of the
ordinary. In addition, by running various monitoring commands at
different times throughout the day, you make it hard for an
intruder to predict your actions. For example, if an intruder
knows that each day at 5:00 p.m. the system is checked to see that
everyone has logged off, he will simply wait until after the check
has completed before logging in. But the intruder cannot guess
when a system administrator might type a command to display all
logged-in users, and thus he runs a much greater risk of
detection.
見えるかもしれないように威圧するとしてシステムの監視に関するタスクがありません。 システム管理者は活動していない少し(例えば、電話で話している間)の間の日の間中に毎日システムをモニターする一定期間を費やすより定期的にむしろモニターに使用されるコマンドの多くを実行できます。 頻繁にコマンドを実行することによって、あなたは、急速に「正常な」出力を見るのに慣れて、容易に普通が使い果たされたものを見つけるでしょう。 さらに、1日の間中いろいろな時間に様々なモニターしているコマンドを実行することによって、あなたは侵入者があなたの動作を予測するのを困難にします。 例えば、侵入者が、その毎日の午後5時にシステムが皆がログオフしたことを確認するためにチェックされるのを知っていると、彼はチェックが待った後まで単にログインする前に完成していた状態で待つでしょう。 しかし、侵入者は、システム管理者がいつすべてのログインしているユーザを表示するコマンドをタイプするかもしれないかを推測できません、そして、その結果、彼は検出のはるかに高い危険を冒します。
Despite the advantages that regular system monitoring provides,
some intruders will be aware of the standard logging mechanisms in
use on systems they are attacking. They will actively pursue and
attempt to disable monitoring mechanisms. Regular monitoring
therefore is useful in detecting intruders, but does not provide
any guarantee that your system is secure, nor should monitoring be
considered an infallible method of detecting unauthorized use.
通常のシステムの監視が提供する利点にもかかわらず、何人かの侵入者がそれらが攻撃しているシステムの上で使用中の標準の伐採メカニズムを意識するでしょう。 彼らは、あなたのシステムが安全であり、無断使用を検出する絶対確実なメソッドであるとモニターを考えるべきでないというどんな保証も提供しないのを除いて、侵入者を検出しながら、したがってメカニズム定期的なモニターが役に立つモニターを無効にするのを活発に追求して、試みるでしょう。
3.7 Define Actions to Take When Unauthorized Activity is Suspected
3.7が定義する、Take When Unauthorized ActivityへのActionsはSuspectedです。
Sections 2.4 and 2.5 discussed the course of action a site should
take when it suspects its systems are being abused. The computer
security policy should state the general approach towards dealing
with these problems.
システムが誤用されていると疑うとき、セクション2.4と2.5はサイトが取るべきである行動について論じました。 コンピュータセキュリティ方針はこれらの問題に対処することに向かった一般的方法を述べるべきです。
Site Security Policy Handbook Working Group [Page 29] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[29ページ]RFC1244サイトセキュリティハンドブック1991年7月
The procedures for dealing with these types of problems should be
written down. Who has authority to decide what actions will be
taken? Should law enforcement be involved? Should your
organization cooperate with other sites in trying to track down an
intruder? Answers to all the questions in section 2.4 should be
part of the incident handling procedures.
これらのタイプの問題に対処するための手順は書き留められるべきです。 だれに、どんな行動が取られるかを決める権威がありますか? 法施行はかかわるべきですか? あなたの組織は侵入者を捜し出そうとする際に他のサイトに協力するべきですか? セクション2.4でのすべての質問の解答は手順を扱うインシデントの一部であるべきです。
Whether you decide to lock out or pursue intruders, you should
have tools and procedures ready to apply. It is best to work up
these tools and procedures before you need them. Don't wait until
an intruder is on your system to figure out how to track the
intruder's actions; you will be busy enough if an intruder
strikes.
侵入者を締め出すか、または追跡すると決めるか否かに関係なく、あなたはツールと手順を適用する準備ができているようにするべきです。 あなたがそれらを必要とする前にこれらのツールと手順を興奮させるのは最も良いです。 侵入者の動作を追跡する方法を理解するために侵入者があなたのシステムの上にいるまで、待たないでください。 侵入者が打つなら、あなたは十分忙しくなるでしょう。
3.8 Communicating Security Policy
3.8 安全保障政策を伝えること。
Security policies, in order to be effective, must be communicated to both the users of the system and the system maintainers. This section describes what these people should be told, and how to tell them.
Security policies, in order to be effective, must be communicated to both the users of the system and the system maintainers. This section describes what these people should be told, and how to tell them.
3.8.1 Educating the Users
3.8.1 Educating the Users
Users should be made aware of how the computer systems are
expected to be used, and how to protect themselves from
unauthorized users.
Users should be made aware of how the computer systems are expected to be used, and how to protect themselves from unauthorized users.
3.8.1.1 Proper Account/Workstation Use
3.8.1.1 Proper Account/Workstation Use
All users should be informed about what is considered the
"proper" use of their account or workstation ("proper" use is
discussed in section 2.3.2). This can most easily be done at
the time a user receives their account, by giving them a policy
statement. Proper use policies typically dictate things such
as whether or not the account or workstation may be used for
personal activities (such as checkbook balancing or letter
writing), whether profit-making activities are allowed, whether
game playing is permitted, and so on. These policy statements
may also be used to summarize how the computer facility is
licensed and what software licenses are held by the
institution; for example, many universities have educational
licenses which explicitly prohibit commercial uses of the
system. A more complete list of items to consider when writing
a policy statement is given in section 2.3.
All users should be informed about what is considered the "proper" use of their account or workstation ("proper" use is discussed in section 2.3.2). This can most easily be done at the time a user receives their account, by giving them a policy statement. Proper use policies typically dictate things such as whether or not the account or workstation may be used for personal activities (such as checkbook balancing or letter writing), whether profit-making activities are allowed, whether game playing is permitted, and so on. These policy statements may also be used to summarize how the computer facility is licensed and what software licenses are held by the institution; for example, many universities have educational licenses which explicitly prohibit commercial uses of the system. A more complete list of items to consider when writing a policy statement is given in section 2.3.
3.8.1.2 Account/Workstation Management Procedures
3.8.1.2 Account/Workstation Management Procedures
Each user should be told how to properly manage their account
Each user should be told how to properly manage their account
Site Security Policy Handbook Working Group [Page 30] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 30] RFC 1244 Site Security Handbook July 1991
and workstation. This includes explaining how to protect files
stored on the system, how to log out or lock the terminal or
workstation, and so on. Much of this information is typically
covered in the "beginning user" documentation provided by the
operating system vendor, although many sites elect to
supplement this material with local information.
and workstation. This includes explaining how to protect files stored on the system, how to log out or lock the terminal or workstation, and so on. Much of this information is typically covered in the "beginning user" documentation provided by the operating system vendor, although many sites elect to supplement this material with local information.
If your site offers dial-up modem access to the computer
systems, special care must be taken to inform users of the
security problems inherent in providing this access. Issues
such as making sure to log out before hanging up the modem
should be covered when the user is initially given dial-up
access.
If your site offers dial-up modem access to the computer systems, special care must be taken to inform users of the security problems inherent in providing this access. Issues such as making sure to log out before hanging up the modem should be covered when the user is initially given dial-up access.
Likewise, access to the systems via local and wide-area
networks presents its own set of security problems which users
should be made aware of. Files which grant "trusted host" or
"trusted user" status to remote systems and users should be
carefully explained.
Likewise, access to the systems via local and wide-area networks presents its own set of security problems which users should be made aware of. Files which grant "trusted host" or "trusted user" status to remote systems and users should be carefully explained.
3.8.1.3 Determining Account Misuse
3.8.1.3 Determining Account Misuse
Users should be told how to detect unauthorized access to their
account. If the system prints the last login time when a user
logs in, he or she should be told to check that time and note
whether or not it agrees with the last time he or she actually
logged in.
Users should be told how to detect unauthorized access to their account. If the system prints the last login time when a user logs in, he or she should be told to check that time and note whether or not it agrees with the last time he or she actually logged in.
Command interpreters on some systems (e.g., the UNIX C shell)
maintain histories of the last several commands executed.
Users should check these histories to be sure someone has not
executed other commands with their account.
Command interpreters on some systems (e.g., the UNIX C shell) maintain histories of the last several commands executed. Users should check these histories to be sure someone has not executed other commands with their account.
3.8.1.4 Problem Reporting Procedures
3.8.1.4 Problem Reporting Procedures
A procedure should be developed to enable users to report
suspected misuse of their accounts or other misuse they may
have noticed. This can be done either by providing the name
and telephone number of a system administrator who manages
security of the computer system, or by creating an electronic
mail address (e.g., "security") to which users can address
their problems.
A procedure should be developed to enable users to report suspected misuse of their accounts or other misuse they may have noticed. This can be done either by providing the name and telephone number of a system administrator who manages security of the computer system, or by creating an electronic mail address (e.g., "security") to which users can address their problems.
3.8.2 Educating the Host Administrators
3.8.2 Educating the Host Administrators
In many organizations, computer systems are administered by a wide
variety of people. These administrators must know how to protect
their own systems from attack and unauthorized use, as well as how
In many organizations, computer systems are administered by a wide variety of people. These administrators must know how to protect their own systems from attack and unauthorized use, as well as how
Site Security Policy Handbook Working Group [Page 31] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 31] RFC 1244 Site Security Handbook July 1991
to communicate successful penetration of their systems to other
administrators as a warning.
to communicate successful penetration of their systems to other administrators as a warning.
3.8.2.1 Account Management Procedures
3.8.2.1 Account Management Procedures
Care must be taken when installing accounts on the system in
order to make them secure. When installing a system from
distribution media, the password file should be examined for
"standard" accounts provided by the vendor. Many vendors
provide accounts for use by system services or field service
personnel. These accounts typically have either no password or
one which is common knowledge. These accounts should be given
new passwords if they are needed, or disabled or deleted from
the system if they are not.
Care must be taken when installing accounts on the system in order to make them secure. When installing a system from distribution media, the password file should be examined for "standard" accounts provided by the vendor. Many vendors provide accounts for use by system services or field service personnel. These accounts typically have either no password or one which is common knowledge. These accounts should be given new passwords if they are needed, or disabled or deleted from the system if they are not.
Accounts without passwords are generally very dangerous since
they allow anyone to access the system. Even accounts which do
not execute a command interpreter (e.g., accounts which exist
only to see who is logged in to the system) can be compromised
if set up incorrectly. A related concept, that of "anonymous"
file transfer (FTP) [20], allows users from all over the
network to access your system to retrieve files from (usually)
a protected disk area. You should carefully weigh the benefits
that an account without a password provides against the
security risks of providing such access to your system.
Accounts without passwords are generally very dangerous since they allow anyone to access the system. Even accounts which do not execute a command interpreter (e.g., accounts which exist only to see who is logged in to the system) can be compromised if set up incorrectly. A related concept, that of "anonymous" file transfer (FTP) [20], allows users from all over the network to access your system to retrieve files from (usually) a protected disk area. You should carefully weigh the benefits that an account without a password provides against the security risks of providing such access to your system.
If the operating system provides a "shadow" password facility
which stores passwords in a separate file accessible only to
privileged users, this facility should be used. System V UNIX,
SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD
Tahoe, as well as others, provide this feature. It protects
passwords by hiding their encrypted values from unprivileged
users. This prevents an attacker from copying your password
file to his or her machine and then attempting to break the
passwords at his or her leisure.
If the operating system provides a "shadow" password facility which stores passwords in a separate file accessible only to privileged users, this facility should be used. System V UNIX, SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD Tahoe, as well as others, provide this feature. It protects passwords by hiding their encrypted values from unprivileged users. This prevents an attacker from copying your password file to his or her machine and then attempting to break the passwords at his or her leisure.
Keep track of who has access to privileged user accounts (e.g.,
"root" on UNIX or "MAINT" on VMS). Whenever a privileged user
leaves the organization or no longer has need of the privileged
account, the passwords on all privileged accounts should be
changed.
Keep track of who has access to privileged user accounts (e.g., "root" on UNIX or "MAINT" on VMS). Whenever a privileged user leaves the organization or no longer has need of the privileged account, the passwords on all privileged accounts should be changed.
3.8.2.2 Configuration Management Procedures
3.8.2.2 Configuration Management Procedures
When installing a system from the distribution media or when
installing third-party software, it is important to check the
installation carefully. Many installation procedures assume a
"trusted" site, and hence will install files with world write
When installing a system from the distribution media or when installing third-party software, it is important to check the installation carefully. Many installation procedures assume a "trusted" site, and hence will install files with world write
Site Security Policy Handbook Working Group [Page 32] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 32] RFC 1244 Site Security Handbook July 1991
permission enabled, or otherwise compromise the security of
files.
permission enabled, or otherwise compromise the security of files.
Network services should also be examined carefully when first
installed. Many vendors provide default network permission
files which imply that all outside hosts are to be "trusted",
which is rarely the case when connected to wide-area networks
such as the Internet.
Network services should also be examined carefully when first installed. Many vendors provide default network permission files which imply that all outside hosts are to be "trusted", which is rarely the case when connected to wide-area networks such as the Internet.
Many intruders collect information on the vulnerabilities of
particular system versions. The older a system, the more
likely it is that there are security problems in that version
which have since been fixed by the vendor in a later release.
For this reason, it is important to weigh the risks of not
upgrading to a new operating system release (thus leaving
security holes unplugged) against the cost of upgrading to the
new software (possibly breaking third-party software, etc.).
Bug fixes from the vendor should be weighed in a similar
fashion, with the added note that "security" fixes from a
vendor usually address fairly serious security problems.
Many intruders collect information on the vulnerabilities of particular system versions. The older a system, the more likely it is that there are security problems in that version which have since been fixed by the vendor in a later release. For this reason, it is important to weigh the risks of not upgrading to a new operating system release (thus leaving security holes unplugged) against the cost of upgrading to the new software (possibly breaking third-party software, etc.). Bug fixes from the vendor should be weighed in a similar fashion, with the added note that "security" fixes from a vendor usually address fairly serious security problems.
Other bug fixes, received via network mailing lists and the
like, should usually be installed, but not without careful
examination. Never install a bug fix unless you're sure you
know what the consequences of the fix are - there's always the
possibility that an intruder has suggested a "fix" which
actually gives him or her access to your system.
Other bug fixes, received via network mailing lists and the like, should usually be installed, but not without careful examination. Never install a bug fix unless you're sure you know what the consequences of the fix are - there's always the possibility that an intruder has suggested a "fix" which actually gives him or her access to your system.
3.8.2.3 Recovery Procedures - Backups
3.8.2.3 Recovery Procedures - Backups
It is impossible to overemphasize the need for a good backup
strategy. File system backups not only protect you in the
event of hardware failure or accidental deletions, but they
also protect you against unauthorized changes made by an
intruder. Without a copy of your data the way it's "supposed"
to be, it can be difficult to undo something an attacker has
done.
It is impossible to overemphasize the need for a good backup strategy. File system backups not only protect you in the event of hardware failure or accidental deletions, but they also protect you against unauthorized changes made by an intruder. Without a copy of your data the way it's "supposed" to be, it can be difficult to undo something an attacker has done.
Backups, especially if run daily, can also be useful in
providing a history of an intruder's activities. Looking
through old backups can establish when your system was first
penetrated. Intruders may leave files around which, although
deleted later, are captured on the backup tapes. Backups can
also be used to document an intruder's activities to law
enforcement agencies if necessary.
Backups, especially if run daily, can also be useful in providing a history of an intruder's activities. Looking through old backups can establish when your system was first penetrated. Intruders may leave files around which, although deleted later, are captured on the backup tapes. Backups can also be used to document an intruder's activities to law enforcement agencies if necessary.
A good backup strategy will dump the entire system to tape at
least once a month. Partial (or "incremental") dumps should be
A good backup strategy will dump the entire system to tape at least once a month. Partial (or "incremental") dumps should be
Site Security Policy Handbook Working Group [Page 33] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 33] RFC 1244 Site Security Handbook July 1991
done at least twice a week, and ideally they should be done
daily. Commands specifically designed for performing file
system backups (e.g., UNIX "dump" or VMS "BACKUP") should be
used in preference to other file copying commands, since these
tools are designed with the express intent of restoring a
system to a known state.
done at least twice a week, and ideally they should be done daily. Commands specifically designed for performing file system backups (e.g., UNIX "dump" or VMS "BACKUP") should be used in preference to other file copying commands, since these tools are designed with the express intent of restoring a system to a known state.
3.8.2.4 Problem Reporting Procedures
3.8.2.4 Problem Reporting Procedures
As with users, system administrators should have a defined
procedure for reporting security problems. In large
installations, this is often done by creating an electronic
mail alias which contains the names of all system
administrators in the organization. Other methods include
setting up some sort of response team similar to the CERT, or
establishing a "hotline" serviced by an existing support group.
As with users, system administrators should have a defined procedure for reporting security problems. In large installations, this is often done by creating an electronic mail alias which contains the names of all system administrators in the organization. Other methods include setting up some sort of response team similar to the CERT, or establishing a "hotline" serviced by an existing support group.
3.9 Resources to Prevent Security Breaches
3.9 Resources to Prevent Security Breaches
This section discusses software, hardware, and procedural resources that can be used to support your site security policy.
This section discusses software, hardware, and procedural resources that can be used to support your site security policy.
3.9.1 Network Connections and Firewalls
3.9.1 Network Connections and Firewalls
A "firewall" is put in place in a building to provide a point of
resistance to the entry of flames into another area. Similarly, a
secretary's desk and reception area provides a point of
controlling access to other office spaces. This same technique
can be applied to a computer site, particularly as it pertains to
network connections.
A "firewall" is put in place in a building to provide a point of resistance to the entry of flames into another area. Similarly, a secretary's desk and reception area provides a point of controlling access to other office spaces. This same technique can be applied to a computer site, particularly as it pertains to network connections.
Some sites will be connected only to other sites within the same
organization and will not have the ability to connect to other
networks. Sites such as these are less susceptible to threats
from outside their own organization, although intrusions may still
occur via paths such as dial-up modems. On the other hand, many
other organizations will be connected to other sites via much
larger networks, such as the Internet. These sites are
susceptible to the entire range of threats associated with a
networked environment.
Some sites will be connected only to other sites within the same organization and will not have the ability to connect to other networks. Sites such as these are less susceptible to threats from outside their own organization, although intrusions may still occur via paths such as dial-up modems. On the other hand, many other organizations will be connected to other sites via much larger networks, such as the Internet. These sites are susceptible to the entire range of threats associated with a networked environment.
The risks of connecting to outside networks must be weighed
against the benefits. It may be desirable to limit connection to
outside networks to those hosts which do not store sensitive
material, keeping "vital" machines (such as those which maintain
company payroll or inventory systems) isolated. If there is a
need to participate in a Wide Area Network (WAN), consider
restricting all access to your local network through a single
The risks of connecting to outside networks must be weighed against the benefits. It may be desirable to limit connection to outside networks to those hosts which do not store sensitive material, keeping "vital" machines (such as those which maintain company payroll or inventory systems) isolated. If there is a need to participate in a Wide Area Network (WAN), consider restricting all access to your local network through a single
Site Security Policy Handbook Working Group [Page 34] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 34] RFC 1244 Site Security Handbook July 1991
system. That is, all access to or from your own local network
must be made through a single host computer that acts as a
firewall between you and the outside world. This firewall system
should be rigorously controlled and password protected, and
external users accessing it should also be constrained by
restricting the functionality available to remote users. By using
this approach, your site could relax some of the internal security
controls on your local net, but still be afforded the protection
of a rigorously controlled host front end.
system. That is, all access to or from your own local network must be made through a single host computer that acts as a firewall between you and the outside world. This firewall system should be rigorously controlled and password protected, and external users accessing it should also be constrained by restricting the functionality available to remote users. By using this approach, your site could relax some of the internal security controls on your local net, but still be afforded the protection of a rigorously controlled host front end.
Note that even with a firewall system, compromise of the firewall
could result in compromise of the network behind the firewall.
Work has been done in some areas to construct a firewall which
even when compromised, still protects the local network [6,
CHESWICK].
Note that even with a firewall system, compromise of the firewall could result in compromise of the network behind the firewall. Work has been done in some areas to construct a firewall which even when compromised, still protects the local network [6, CHESWICK].
3.9.2 Confidentiality
3.9.2 Confidentiality
Confidentiality, the act of keeping things hidden or secret, is
one of the primary goals of computer security practitioners.
Several mechanisms are provided by most modern operating systems
to enable users to control the dissemination of information.
Depending upon where you work, you may have a site where
everything is protected, or a site where all information is
usually regarded as public, or something in-between. Most sites
lean toward the in-between, at least until some penetration has
occurred.
Confidentiality, the act of keeping things hidden or secret, is one of the primary goals of computer security practitioners. Several mechanisms are provided by most modern operating systems to enable users to control the dissemination of information. Depending upon where you work, you may have a site where everything is protected, or a site where all information is usually regarded as public, or something in-between. Most sites lean toward the in-between, at least until some penetration has occurred.
Generally, there are three instances in which information is
vulnerable to disclosure: when the information is stored on a
computer system, when the information is in transit to another
system (on the network), and when the information is stored on
backup tapes.
Generally, there are three instances in which information is vulnerable to disclosure: when the information is stored on a computer system, when the information is in transit to another system (on the network), and when the information is stored on backup tapes.
The first of these cases is controlled by file permissions, access
control lists, and other similar mechanisms. The last can be
controlled by restricting access to the backup tapes (by locking
them in a safe, for example). All three cases can be helped by
using encryption mechanisms.
The first of these cases is controlled by file permissions, access control lists, and other similar mechanisms. The last can be controlled by restricting access to the backup tapes (by locking them in a safe, for example). All three cases can be helped by using encryption mechanisms.
3.9.2.1 Encryption (hardware and software)
3.9.2.1 Encryption (hardware and software)
Encryption is the process of taking information that exists in
some readable form and converting it into a non-readable form.
There are several types of commercially available encryption
packages in both hardware and software forms. Hardware
encryption engines have the advantage that they are much faster
than the software equivalent, yet because they are faster, they
Encryption is the process of taking information that exists in some readable form and converting it into a non-readable form. There are several types of commercially available encryption packages in both hardware and software forms. Hardware encryption engines have the advantage that they are much faster than the software equivalent, yet because they are faster, they
Site Security Policy Handbook Working Group [Page 35] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 35] RFC 1244 Site Security Handbook July 1991
are of greater potential benefit to an attacker who wants to
execute a brute-force attack on your encrypted information.
are of greater potential benefit to an attacker who wants to execute a brute-force attack on your encrypted information.
The advantage of using encryption is that, even if other access
control mechanisms (passwords, file permissions, etc.) are
compromised by an intruder, the data is still unusable.
Naturally, encryption keys and the like should be protected at
least as well as account passwords.
The advantage of using encryption is that, even if other access control mechanisms (passwords, file permissions, etc.) are compromised by an intruder, the data is still unusable. Naturally, encryption keys and the like should be protected at least as well as account passwords.
Information in transit (over a network) may be vulnerable to
interception as well. Several solutions to this exist, ranging
from simply encrypting files before transferring them (end-to-
end encryption) to special network hardware which encrypts
everything it sends without user intervention (secure links).
The Internet as a whole does not use secure links, thus end-
to-end encryption must be used if encryption is desired across
the Internet.
Information in transit (over a network) may be vulnerable to interception as well. Several solutions to this exist, ranging from simply encrypting files before transferring them (end-to- end encryption) to special network hardware which encrypts everything it sends without user intervention (secure links). The Internet as a whole does not use secure links, thus end- to-end encryption must be used if encryption is desired across the Internet.
3.9.2.1.1 Data Encryption Standard (DES)
3.9.2.1.1 Data Encryption Standard (DES)
DES is perhaps the most widely used data encryption
mechanism today. Many hardware and software implementations
exist, and some commercial computers are provided with a
software version. DES transforms plain text information
into encrypted data (or ciphertext) by means of a special
algorithm and "seed" value called a key. So long as the key
is retained (or remembered) by the original user, the
ciphertext can be restored to the original plain text.
DES is perhaps the most widely used data encryption mechanism today. Many hardware and software implementations exist, and some commercial computers are provided with a software version. DES transforms plain text information into encrypted data (or ciphertext) by means of a special algorithm and "seed" value called a key. So long as the key is retained (or remembered) by the original user, the ciphertext can be restored to the original plain text.
One of the pitfalls of all encryption systems is the need to
remember the key under which a thing was encrypted (this is
not unlike the password problem discussed elsewhere in this
document). If the key is written down, it becomes less
secure. If forgotten, there is little (if any) hope of
recovering the original data.
One of the pitfalls of all encryption systems is the need to remember the key under which a thing was encrypted (this is not unlike the password problem discussed elsewhere in this document). If the key is written down, it becomes less secure. If forgotten, there is little (if any) hope of recovering the original data.
Most UNIX systems provide a DES command that enables a user
to encrypt data using the DES algorithm.
Most UNIX systems provide a DES command that enables a user to encrypt data using the DES algorithm.
3.9.2.1.2 Crypt
3.9.2.1.2 Crypt
Similar to the DES command, the UNIX "crypt" command allows
a user to encrypt data. Unfortunately, the algorithm used
by "crypt" is very insecure (based on the World War II
"Enigma" device), and files encrypted with this command can
be decrypted easily in a matter of a few hours. Generally,
use of the "crypt" command should be avoided for any but the
most trivial encryption tasks.
Similar to the DES command, the UNIX "crypt" command allows a user to encrypt data. Unfortunately, the algorithm used by "crypt" is very insecure (based on the World War II "Enigma" device), and files encrypted with this command can be decrypted easily in a matter of a few hours. Generally, use of the "crypt" command should be avoided for any but the most trivial encryption tasks.
Site Security Policy Handbook Working Group [Page 36] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 36] RFC 1244 Site Security Handbook July 1991
3.9.2.2 Privacy Enhanced Mail
3.9.2.2 Privacy Enhanced Mail
Electronic mail normally transits the network in the clear
(i.e., anyone can read it). This is obviously not the optimal
solution. Privacy enhanced mail provides a means to
automatically encrypt electronic mail messages so that a person
eavesdropping at a mail distribution node is not (easily)
capable of reading them. Several privacy enhanced mail
packages are currently being developed and deployed on the
Internet.
Electronic mail normally transits the network in the clear (i.e., anyone can read it). This is obviously not the optimal solution. Privacy enhanced mail provides a means to automatically encrypt electronic mail messages so that a person eavesdropping at a mail distribution node is not (easily) capable of reading them. Several privacy enhanced mail packages are currently being developed and deployed on the Internet.
The Internet Activities Board Privacy Task Force has defined a
draft standard, elective protocol for use in implementing
privacy enhanced mail. This protocol is defined in RFCs 1113,
1114, and 1115 [7,8,9]. Please refer to the current edition of
the "IAB Official Protocol Standards" (currently, RFC 1200
[21]) for the standardization state and status of these
protocols.
The Internet Activities Board Privacy Task Force has defined a draft standard, elective protocol for use in implementing privacy enhanced mail. This protocol is defined in RFCs 1113, 1114, and 1115 [7,8,9]. Please refer to the current edition of the "IAB Official Protocol Standards" (currently, RFC 1200 [21]) for the standardization state and status of these protocols.
3.9.3 Origin Authentication
3.9.3 Origin Authentication
We mostly take it on faith that the header of an electronic mail
message truly indicates the originator of a message. However, it
iseasy to "spoof", or forge the source of a mail message. Origin
authentication provides a means to be certain of the originator of
a message or other object in the same way that a Notary Public
assures a signature on a legal document. This is done by means of
a "Public Key" cryptosystem.
We mostly take it on faith that the header of an electronic mail message truly indicates the originator of a message. However, it iseasy to "spoof", or forge the source of a mail message. Origin authentication provides a means to be certain of the originator of a message or other object in the same way that a Notary Public assures a signature on a legal document. This is done by means of a "Public Key" cryptosystem.
A public key cryptosystem differs from a private key cryptosystem
in several ways. First, a public key system uses two keys, a
Public Key that anyone can use (hence the name) and a Private Key
that only the originator of a message uses. The originator uses
the private key to encrypt the message (as in DES). The receiver,
who has obtained the public key for the originator, may then
decrypt the message.
A public key cryptosystem differs from a private key cryptosystem in several ways. First, a public key system uses two keys, a Public Key that anyone can use (hence the name) and a Private Key that only the originator of a message uses. The originator uses the private key to encrypt the message (as in DES). The receiver, who has obtained the public key for the originator, may then decrypt the message.
In this scheme, the public key is used to authenticate the
originator's use of his or her private key, and hence the identity
of the originator is more rigorously proven. The most widely
known implementation of a public key cryptosystem is the RSA
system [26]. The Internet standard for privacy enhanced mail
makes use of the RSA system.
In this scheme, the public key is used to authenticate the originator's use of his or her private key, and hence the identity of the originator is more rigorously proven. The most widely known implementation of a public key cryptosystem is the RSA system [26]. The Internet standard for privacy enhanced mail makes use of the RSA system.
3.9.4 Information Integrity
3.9.4 Information Integrity
Information integrity refers to the state of information such that
it is complete, correct, and unchanged from the last time in which
Information integrity refers to the state of information such that it is complete, correct, and unchanged from the last time in which
Site Security Policy Handbook Working Group [Page 37] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 37] RFC 1244 Site Security Handbook July 1991
it was verified to be in an "integral" state. The value of
information integrity to a site will vary. For example, it is
more important for military and government installations to
prevent the "disclosure" of classified information, whether it is
right or wrong. A bank, on the other hand, is far more concerned
with whether the account information maintained for its customers
is complete and accurate.
it was verified to be in an "integral" state. The value of information integrity to a site will vary. For example, it is more important for military and government installations to prevent the "disclosure" of classified information, whether it is right or wrong. A bank, on the other hand, is far more concerned with whether the account information maintained for its customers is complete and accurate.
Numerous computer system mechanisms, as well as procedural
controls, have an influence on the integrity of system
information. Traditional access control mechanisms maintain
controls over who can access system information. These mechanisms
alone are not sufficient in some cases to provide the degree of
integrity required. Some other mechanisms are briefly discussed
below.
Numerous computer system mechanisms, as well as procedural controls, have an influence on the integrity of system information. Traditional access control mechanisms maintain controls over who can access system information. These mechanisms alone are not sufficient in some cases to provide the degree of integrity required. Some other mechanisms are briefly discussed below.
It should be noted that there are other aspects to maintaining
system integrity besides these mechanisms, such as two-person
controls, and integrity validation procedures. These are beyond
the scope of this document.
It should be noted that there are other aspects to maintaining system integrity besides these mechanisms, such as two-person controls, and integrity validation procedures. These are beyond the scope of this document.
3.9.4.1 Checksums
3.9.4.1 Checksums
Easily the simplest mechanism, a simple checksum routine can
compute a value for a system file and compare it with the last
known value. If the two are equal, the file is probably
unchanged. If not, the file has been changed by some unknown
means.
Easily the simplest mechanism, a simple checksum routine can compute a value for a system file and compare it with the last known value. If the two are equal, the file is probably unchanged. If not, the file has been changed by some unknown means.
Though it is the easiest to implement, the checksum scheme
suffers from a serious failing in that it is not very
sophisticated and a determined attacker could easily add enough
characters to the file to eventually obtain the correct value.
Though it is the easiest to implement, the checksum scheme suffers from a serious failing in that it is not very sophisticated and a determined attacker could easily add enough characters to the file to eventually obtain the correct value.
A specific type of checksum, called a CRC checksum, is
considerably more robust than a simple checksum. It is only
slightly more difficult to implement and provides a better
degree of catching errors. It too, however, suffers from the
possibility of compromise by an attacker.
A specific type of checksum, called a CRC checksum, is considerably more robust than a simple checksum. It is only slightly more difficult to implement and provides a better degree of catching errors. It too, however, suffers from the possibility of compromise by an attacker.
Checksums may be used to detect the altering of information.
However, they do not actively guard against changes being made.
For this, other mechanisms such as access controls and
encryption should be used.
Checksums may be used to detect the altering of information. However, they do not actively guard against changes being made. For this, other mechanisms such as access controls and encryption should be used.
Site Security Policy Handbook Working Group [Page 38] RFC 1244 Site Security Handbook July 1991
Site Security Policy Handbook Working Group [Page 38] RFC 1244 Site Security Handbook July 1991
3.9.4.2 Cryptographic Checksums
3.9.4.2 Cryptographic Checksums
Cryptographic checksums (also called cryptosealing) involve
breaking a file up into smaller chunks, calculating a (CRC)
checksum for each chunk, and adding the CRCs together.
Depending upon the exact algorithm used, this can result in a
nearly unbreakable method of determining whether a file has
been changed. This mechanism suffers from the fact that it is
sometimes computationally intensive and may be prohibitive
except in cases where the utmost integrity protection is
desired.
Cryptographic checksums (also called cryptosealing) involve breaking a file up into smaller chunks, calculating a (CRC) checksum for each chunk, and adding the CRCs together. Depending upon the exact algorithm used, this can result in a nearly unbreakable method of determining whether a file has been changed. This mechanism suffers from the fact that it is sometimes computationally intensive and may be prohibitive except in cases where the utmost integrity protection is desired.
Another related mechanism, called a one-way hash function (or a
Manipulation Detection Code (MDC)) can also be used to uniquely
identify a file. The idea behind these functions is that no
two inputs can produce the same output, thus a modified file
will not have the same hash value. One-way hash functions can
be implemented efficiently on a wide variety of systems, making
unbreakable integrity checks possible. (Snefru, a one-way hash
function available via USENET as well as the Internet is just
one example of an efficient one-way hash function.) [10]
Another related mechanism, called a one-way hash function (or a Manipulation Detection Code (MDC)) can also be used to uniquely identify a file. The idea behind these functions is that no two inputs can produce the same output, thus a modified file will not have the same hash value. One-way hash functions can be implemented efficiently on a wide variety of systems, making unbreakable integrity checks possible. (Snefru, a one-way hash function available via USENET as well as the Internet is just one example of an efficient one-way hash function.) [10]
3.9.5 Limiting Network Access
3.9.5 Limiting Network Access
The dominant network protocols in use on the Internet, IP (RFC
791) [11], TCP (RFC 793) [12], and UDP (RFC 768) [13], carry
certain control information which can be used to restrict access
to certain hosts or networks within an organization.
インターネットで使用中の優位なネットワーク・プロトコル(IP(RFC791)[11]、TCP(RFC793)[12]、およびUDP(RFC768)[13])は、組織の中で確信しているホストかネットワークへのアクセスを制限するのに使用できるある制御情報を運びます。
The IP packet header contains the network addresses of both the
sender and recipient of the packet. Further, the TCP and UDP
protocols provide the notion of a "port", which identifies the
endpoint (usually a network server) of a communications path. In
some instances, it may be desirable to deny access to a specific
TCP or UDP port, or even to certain hosts and networks altogether.
IPパケットのヘッダーは送付者とパケットの受取人の両方のネットワーク・アドレスを含みます。 さらに、TCPとUDPプロトコルはコミュニケーション経路の終点(通常ネットワークサーバ)を特定する「ポート」の概念を提供します。 ある場合に、特定のTCPかUDPポート、または、確信しているホストと全体でネットワークさえへのアクセスを拒絶するのは望ましいかもしれません。
3.9.5.1 Gateway Routing Tables
3.9.5.1 ゲートウェイ経路指定テーブル
One of the simplest approaches to preventing unwanted network
connections is to simply remove certain networks from a
gateway's routing tables. This makes it "impossible" for a
host to send packets to these networks. (Most protocols
require bidirectional packet flow even for unidirectional data
flow, thus breaking one side of the route is usually
sufficient.)
求められていないネットワーク接続を防ぐことへの最も簡単なアプローチの1つはゲートウェイの経路指定テーブルからあるネットワークを単に取り除くことです。 これで、ホストがこれらのネットワークにパケットを送るのが「不可能に」なります。 (ほとんどのプロトコルが単方向のデータフローのためにさえ双方向のパケット流動を必要として、その結果、通常、ルートの壊れている半面は十分です。)
This approach is commonly taken in "firewall" systems by
preventing the firewall from advertising local routes to the
ローカルのルートの広告を出すのからのファイアウォールを防ぐことによって、このアプローチは一般的に中に入れている「ファイアウォール」システムです。
Site Security Policy Handbook Working Group [Page 39] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[39ページ]RFC1244サイトセキュリティハンドブック1991年7月
outside world. The approach is deficient in that it often
prevents "too much" (e.g., in order to prevent access to one
system on the network, access to all systems on the network is
disabled).
外の世界。 しばしば「あまりに多く」を防ぐので(例えば、ネットワークの1台のシステムへのアクセスを防ぐために、ネットワークのすべてのシステムへのアクセスは障害があります)、アプローチは不十分です。
3.9.5.2 Router Packet Filtering
3.9.5.2 ルータパケットフィルタリング
Many commercially available gateway systems (more correctly
called routers) provide the ability to filter packets based not
only on sources or destinations, but also on source-destination
combinations. This mechanism can be used to deny access to a
specific host, network, or subnet from any other host, network,
or subnet.
多くの商業的に利用可能なゲートウェイシステム(正しくルータと、より呼ばれた)がソースか目的地だけではなく、ソース目的地組み合わせにも基づくパケットをフィルターにかける能力を提供します。 いかなる他のホスト、ネットワーク、またはサブネットからも特定のホスト、ネットワーク、またはサブネットへのアクセスを拒絶するのにこのメカニズムを使用できます。
Gateway systems from some vendors (e.g., cisco Systems) support
an even more complex scheme, allowing finer control over source
and destination addresses. Via the use of address masks, one
can deny access to all but one host on a particular network.
The cisco Systems also allow packet screening based on IP
protocol type and TCP or UDP port numbers [14].
いくつかのベンダー(例えば、コクチマスSystems)からのゲートウェイシステムはさらに複雑な体系をサポートします、ソースと送付先アドレスの、よりよいコントロールを許して。 アドレスマスクの使用で、人は特定のネットワークで1人のホストを除いた皆へのアクセスを拒絶できます。 また、コクチマスSystemsはIPプロトコルタイプに基づくパケット選別とTCPかUDPにポートナンバー[14]を許容します。
This can also be circumvented by "source routing" packets
destined for the "secret" network. Source routed packets may
be filtered out by gateways, but this may restrict other
legitimate activities, such as diagnosing routing problems.
また、「秘密」のネットワークのために運命づけられた「ソースルーティング」パケットはこれを回避できます。 ソースの発送されたパケットはゲートウェイによって無視されるかもしれませんが、これは他の正統の活動を制限するかもしれません、ルーティング問題を診断するのなどように。
3.9.6 Authentication Systems
3.9.6 認証システム
Authentication refers to the process of proving a claimed identity
to the satisfaction of some permission-granting authority.
Authentication systems are hardware, software, or procedural
mechanisms that enable a user to obtain access to computing
resources. At the simplest level, the system administrator who
adds new user accounts to the system is part of the system
authentication mechanism. At the other end of the spectrum,
fingerprint readers or retinal scanners provide a very high-tech
solution to establishing a potential user's identity. Without
establishing and proving a user's identity prior to establishing a
session, your site's computers are vulnerable to any sort of
attack.
認証は何らかの許可を与える権威の満足への要求されたアイデンティティを立証するプロセスについて言及します。 認証システムは、ユーザがコンピューティング資源へのアクセスを得るのを可能にするハードウェア、ソフトウェア、または手続き上のメカニズムです。 最も簡単なレベルでは、新しいユーザアカウントをシステムに追加するシステム管理者はシステム認証機構の一部です。 範囲内で対照的に一方の側に、指紋読取装置か網膜のスキャナが潜在的ユーザのアイデンティティを確立するのに非常にハイテクの解決法を提供します。 セッションを確立する前にユーザのアイデンティティを確立して、立証しないで、あなたのサイトのコンピュータはどんな種類の攻撃にも被害を受け易いです。
Typically, a user authenticates himself or herself to the system
by entering a password in response to a prompt.
Challenge/Response mechanisms improve upon passwords by prompting
the user for some piece of information shared by both the computer
and the user (such as mother's maiden name, etc.).
通常、ユーザは、自分か自分をプロンプトに対応してパスワードを入力することによって、システムに認証します。 挑戦/反応機構は、コンピュータとユーザの両方(母親の旧姓などの)によって共有された何らかの情報のためにユーザをうながすことによって、パスワードを改良します。
Site Security Policy Handbook Working Group [Page 40] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[40ページ]RFC1244サイトセキュリティハンドブック1991年7月
3.9.6.1 Kerberos
3.9.6.1 ケルベロス
Kerberos, named after the dog who in mythology is said to stand
at the gates of Hades, is a collection of software used in a
large network to establish a user's claimed identity.
Developed at the Massachusetts Institute of Technology (MIT),
it uses a combination of encryption and distributed databases
so that a user at a campus facility can login and start a
session from any computer located on the campus. This has
clear advantages in certain environments where there are a
large number of potential users who may establish a connection
from any one of a large number of workstations. Some vendors
are now incorporating Kerberos into their systems.
ケルベロス神話でハーデスのゲートに立つと言われている犬がユーザの要求されたアイデンティティを証明するのに大きいネットワークに使用されるソフトウェアの収集であったのの後に命名されて。 マサチューセッツ工科大学(MIT)で開発されています、それはキャンパス施設のユーザがログインして、キャンパスで見つけられたどんなコンピュータからのセッションも始めることができるように、暗号化と分散データベースの組み合わせを使用します。 これには、多くのワークステーションのいずれからも取引関係を築くかもしれない多くの潜在的ユーザがいるある環境における明らかに有利な立場があります。 現在それらのシステムにケルベロスを組み入れているベンダーもあります。
It should be noted that while Kerberos makes several advances
in the area of authentication, some security weaknesses in the
protocol still remain [15].
注意されて、それがケルベロスである間、認証の領域でいくつかの進歩をして、プロトコルのいくつかのセキュリティ弱点がまだ[15]のままで残っているということであるべきです。
3.9.6.2 Smart Cards
3.9.6.2 スマートカード
Several systems use "smart cards" (a small calculator-like
device) to help authenticate users. These systems depend on
the user having an object in their possession. One such system
involves a new password procedure that require a user to enter
a value obtained from a "smart card" when asked for a password
by the computer. Typically, the host machine will give the
user some piece of information that is entered into the
keyboard of the smart card. The smart card will display a
response which must then be entered into the computer before
the session will be established. Another such system involves
a smart card which displays a number which changes over time,
but which is synchronized with the authentication software on
the computer.
数個のシステムが、ユーザを認証するのを助けるのに、「スマートカード」(小さい計算機のようなデバイス)を使用します。 これらのシステムはそれらの所有物にオブジェクトを持っているユーザに頼っています。 そのようなシステムの1つはユーザがコンピュータでパスワードを求めるとき「スマートカード」から得る値を入れるのを必要とする新しいパスワード手順にかかわります。 通常、ホスト・マシンはスマートカードのキーボードに入力される何らかの情報をユーザに教えるでしょう。 スマートカードは次にセッションが確立される前にコンピュータに入れなければならない応答を表示するでしょう。 別のそのようなシステムは時間がたつにつれて変化する数を表示しますが、コンピュータの上の認証ソフトウェアと同期するスマートカードにかかわります。
This is a better way of dealing with authentication than with
the traditional password approach. On the other hand, some say
it's inconvenient to carry the smart card. Start-up costs are
likely to be high as well.
これは認証に対処する伝統的なパスワードアプローチより良い方法です。 他方では、或るものは、スマートカードを運ぶのが不便であると言います。 始動コストはまた、高い傾向があります。
3.9.7 Books, Lists, and Informational Sources
3.9.7 本、リスト、および情報のソース
There are many good sources for information regarding computer
security. The annotated bibliography at the end of this document
can provide you with a good start. In addition, information can
be obtained from a variety of other sources, some of which are
described in this section.
コンピュータセキュリティの情報のための多くの良いソースがあります。 このドキュメントの端の注釈付きの書誌は好調なスタートをあなたに提供できます。 さらに、他のさまざまなソースから情報を得ることができます。その或るものはこのセクションで説明されます。
Site Security Policy Handbook Working Group [Page 41] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[41ページ]RFC1244サイトセキュリティハンドブック1991年7月
3.9.7.1 Security Mailing Lists
3.9.7.1 セキュリティメーリングリスト
The UNIX Security mailing list exists to notify system
administrators of security problems before they become common
knowledge, and to provide security enhancement information. It
is a restricted-access list, open only to people who can be
verified as being principal systems people at a site. Requests
to join the list must be sent by either the site contact listed
in the Defense Data Network's Network Information Center's (DDN
NIC) WHOIS database, or from the "root" account on one of the
major site machines. You must include the destination address
you want on the list, an indication of whether you want to be
on the mail reflector list or receive weekly digests, the
electronic mail address and voice telephone number of the site
contact if it isn't you, and the name, address, and telephone
number of your organization. This information should be sent
to SECURITY-REQUEST@CPD.COM.
UNIX Securityメーリングリストは、周知の事実になる前に警備上の問題についてシステム管理者に通知して、セキュリティエンハンス情報を提供するために存在しています。 それは制限されたアクセスリストです、サイトで主要なシステムの人々であることを確かめることができない人々しか、開きます。 Defense Data NetworkのNetworkインフォメーション・センター(DDN NIC)のWHOISデータベースに記載されたサイト接触か、主要なサイトマシンの1つの「根」アカウントからリストを接合するという要求を送らなければなりません。 あなたはあなたの組織のあなたがリストで欲しい送付先アドレス、あなたがメール反射鏡リストにいたいか、またはそれがあなたでないなら毎週サイト接触のダイジェスト、電子メールアドレス、および声の電話番号を受け取りたいかどうかしるし、名前、アドレス、および電話番号を入れなければなりません。 この情報を SECURITY-REQUEST@CPD.COM に送るべきです。
The RISKS digest is a component of the ACM Committee on
Computers and Public Policy, moderated by Peter G. Neumann. It
is a discussion forum on risks to the public in computers and
related systems, and along with discussing computer security
and privacy issues, has discussed such subjects as the Stark
incident, the shooting down of the Iranian airliner in the
Persian Gulf (as it relates to the computerized weapons
systems), problems in air and railroad traffic control systems,
software engineering, and so on. To join the mailing list,
send a message to RISKS-REQUEST@CSL.SRI.COM. This list is also
available in the USENET newsgroup "comp.risks".
RISKSダイジェストはコンピュータの上のACM Committeeとピーター・G.ノイマンによって加減されたPublic Policyの部品です。 コンピュータと関連系と、コンピュータセキュリティとプライバシーの問題について議論するのに伴う公衆へのリスクにおけるディスカッション・フォーラムがスタークインシデントのような対象、ペルシャ湾(コンピューター化している武器体系に関連するとき)の中のイランの定期旅客機の撃墜、空気中の問題と鉄道交通管制システム、ソフトウェア工学などについて議論したということです。 メーリングリストを接合するには、メッセージを RISKS-REQUEST@CSL.SRI.COM に送ってください。 また、このリストもユーズネット"comp.risks"で利用可能です。
The VIRUS-L list is a forum for the discussion of computer
virus experiences, protection software, and related topics.
The list is open to the public, and is implemented as a
moderated digest. Most of the information is related to
personal computers, although some of it may be applicable to
larger systems. To subscribe, send the line:
VIRUS-Lリストはコンピュータウィルス経験、保護ソフトウェア、および関連した話題の議論のためのフォーラムです。 リストは、公開されていて、加減されたダイジェストとして実装されます。 情報の大部分はパーソナルコンピュータに関連します、それのいくつかが、より大きいシステムに適切であるかもしれませんが。申し込むには、系列を送ってください:
SUB VIRUS-L your full name
SUB VIRUS-Lはあなたのフルネームです。
to the address LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU. This
list is also available via the USENET newsgroup "comp.virus".
アドレス LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU に。 また、このリストもユーズネット"comp.virus"を通して利用可能です。
The Computer Underground Digest "is an open forum dedicated to
sharing information among computerists and to the presentation
and debate of diverse views." While not directly a security
list, it does contain discussions about privacy and other
security related topics. The list can be read on USENET as
alt.society.cu-digest, or to join the mailing list, send mail
コンピュータUnderground Digestは「コンピュータの仕事をする人の中の情報交換と、そして、さまざまの視点のプレゼンテーションと討論に捧げられたオープン・フォーラムです」。 セキュリティが直接でない記載している間、それはプライバシーについての議論と他のセキュリティ関連した話題を含んでいます。 リストはalt.society.cu-ダイジェストとしてUSENETを読み続けることであるかもしれませんかメーリングリストを接合するために、メールを送ってください。
Site Security Policy Handbook Working Group [Page 42] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[42ページ]RFC1244サイトセキュリティハンドブック1991年7月
to Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu).
Submissions may be mailed to: cud@chinacat.unicom.com.
ゴードンマイヤー( TK0JUT2%NIU.bitnet@mitvma.mit.edu )に。 以下のことのために差出を郵送するかもしれません。 cud@chinacat.unicom.com 。
3.9.7.2 Networking Mailing Lists
3.9.7.2 ネットワークメーリングリスト
The TCP-IP mailing list is intended to act as a discussion
forum for developers and maintainers of implementations of the
TCP/IP protocol suite. It also discusses network-related
security problems when they involve programs providing network
services, such as "Sendmail". To join the TCP-IP list, send a
message to TCP-IP-REQUEST@NISC.SRI.COM. This list is also
available in the USENET newsgroup "comp.protocols.tcp-ip".
TCP-IPメーリングリストがTCP/IPプロトコル群の実装の開発者と維持装置のためのディスカッション・フォーラムとして機能することを意図します。 また、「センドメール」などのネットワーク・サービスを提供するプログラムにかかわると、それはネットワーク関連の警備上の問題について議論します。 TCP-IPリストを接合するには、メッセージを TCP-IP-REQUEST@NISC.SRI.COM に送ってください。 また、このリストもユーズネット"comp.protocols.tcp-ip"で利用可能です。
SUN-NETS is a discussion list for items pertaining to
networking on Sun systems. Much of the discussion is related
to NFS, NIS (formally Yellow Pages), and name servers. To
subscribe, send a message to SUN-NETS-REQUEST@UMIACS.UMD.EDU.
SUN-ネットはシステムをSunにネットワークでつなぐことに関する項目のための議論リストです。議論の多くがNFSに関連します、NIS、(正式である、イエローページ)、そして、ネームサーバ。 申し込むには、メッセージを SUN-NETS-REQUEST@UMIACS.UMD.EDU に送ってください。
The USENET groups misc.security and alt.security also discuss
security issues. misc.security is a moderated group and also
includes discussions of physical security and locks.
alt.security is unmoderated.
また、USENETグループのミスクセキュリティとalt.securityは安全保障問題について議論します。ミスクセキュリティは、加減されたグループであり、また、物理的なセキュリティと錠の議論を含んでいます。alt.securityは非加減されます。
3.9.7.3 Response Teams
3.9.7.3 応答チーム
Several organizations have formed special groups of people to
deal with computer security problems. These teams collect
information about possible security holes and disseminate it to
the proper people, track intruders, and assist in recovery from
security violations. The teams typically have both electronic
mail distribution lists as well as a special telephone number
which can be called for information or to report a problem.
Many of these teams are members of the CERT System, which is
coordinated by the National Institute of Standards and
Technology (NIST), and exists to facilitate the exchange of
information between the various teams.
いくつかの組織が、コンピュータセキュリティ問題に対処するためにある特定の集団を形成しました。これらのチームは、安全の侵害から可能なセキュリティーホールに関して情報を集めて、適切な人々にそれを広めて、侵入者を追跡して、回復を助けます。 チームには、情報か問題を報告するために呼ぶことができる電子メール発送先リストと特別な電話番号の両方が通常あります。 これらのチームの多くがCERT Systemのメンバーです。(CERT Systemは、米国商務省標準技術局(NIST)によって調整されて、様々なチームの間の情報交換を容易にするために存在します)。
3.9.7.3.1 DARPA Computer Emergency Response Team
3.9.7.3.1 DARPAコンピュータ緊急対応チーム
The Computer Emergency Response Team/Coordination Center
(CERT/CC) was established in December 1988 by the Defense
Advanced Research Projects Agency (DARPA) to address
computer security concerns of research users of the
Internet. It is operated by the Software Engineering
Institute (SEI) at Carnegie-Mellon University (CMU). The
CERT can immediately confer with experts to diagnose and
solve security problems, and also establish and maintain
communications with the affected computer users and
コンピュータ緊急対応チーム/コーディネートセンター(CERT/CC)は、1988年12月にインターネットの研究ユーザのコンピュータセキュリティ関心を扱うために国防高等研究計画庁(DARPA)によって設置されました。 それはカーネギーメロン大学(米カーネギーメロン大学)でSoftware Engineering Institute(SEI)によって操作されます。 そしてCERTがすぐにまた、影響を受けるコンピュータユーザとのコミュニケーションを警備上の問題を診断して、解決して、確立して、維持するために専門家と打ち合わせることができる。
Site Security Policy Handbook Working Group [Page 43] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[43ページ]RFC1244サイトセキュリティハンドブック1991年7月
government authorities as appropriate.
適切な同じくらい政府当局。
The CERT/CC serves as a clearing house for the
identification and repair of security vulnerabilities,
informal assessments of existing systems, improvement of
emergency response capability, and both vendor and user
security awareness. In addition, the team works with
vendors of various systems in order to coordinate the fixes
for security problems.
CERT/CCは識別のためのクリアリングハウスとセキュリティの脆弱性、既存のシステムの非公式の査定、非常時の応答能力の改良、および両方の修理としてベンダーとユーザセキュリティ認識に役立ちます。 さらに、チームは、警備上の問題によってフィックスを調整するために様々なシステムのベンダーと共に働いています。
The CERT/CC sends out security advisories to the CERT-
ADVISORY mailing list whenever appropriate. They also
operate a 24-hour hotline that can be called to report
security problems (e.g., someone breaking into your system),
as well as to obtain current (and accurate) information
about rumored security problems.
適切であるときはいつも、CERT/CCはCERT- ADVISORYメーリングリストにセキュリティ状況報告を出します。 また、彼らは警備上の問題(例えば、あなたのシステムに侵入しているだれか)を報告して、噂されている警備上の問題の現在の、そして、(正確)の情報を得るために呼ぶことができる24時間のホットラインを操作します。
To join the CERT-ADVISORY mailing list, send a message to
CERT@CERT.SEI.CMU.EDU and ask to be added to the mailing
list. The material sent to this list also appears in the
USENET newsgroup "comp.security.announce". Past advisories
are available for anonymous FTP from the host
CERT.SEI.CMU.EDU. The 24-hour hotline number is (412) 268-
7090.
CERT-ADVISORYメーリングリストを接合するために、メッセージを CERT@CERT.SEI.CMU.EDU に送ってください、そして、メーリングリストに追加されるように頼んでください。 また、このリストに送られた材料はユーズネット"comp.security.announce"に現れます。 過去の状況報告はホストCERT.SEI.CMU.EDUからの公開FTPに利用可能です。 24時間のホットラインの番号は(412)268- 7090です。
The CERT/CC also maintains a CERT-TOOLS list to encourage
the exchange of information on tools and techniques that
increase the secure operation of Internet systems. The
CERT/CC does not review or endorse the tools described on
the list. To subscribe, send a message to CERT-TOOLS-
REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing
list.
また、CERT/CCは、インターネット・システムの安全な操作を増強するツールとテクニックで情報交換を奨励するためにCERT-TOOLSリストを維持します。CERT/CCは、リストで説明されたツールを、見直しもしませんし、是認もしません。 申し込むために、CERT-TOOLS REQUEST@CERT.SEI.CMU.EDU にメッセージを送ってください、そして、メーリングリストに追加されるように頼んでください。
The CERT/CC maintains other generally useful security
information for anonymous FTP from CERT.SEI.CMU.EDU. Get
the README file for a list of what is available.
CERT/CCはCERT.SEI.CMU.EDUから公開FTPのための他の一般に役に立つセキュリティ情報を保守します。 利用可能なことに関するリストのためのREADMEファイルを手に入れてください。
For more information, contact:
詳しくは、以下に連絡してください。
CERT
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
本命ソフトウェア工学研究所カーネギーメロン大学ピッツバーグ、PA15213-3890
(412) 268-7090
cert@cert.sei.cmu.edu.
(412)268-7090 cert@cert.sei.cmu.edu 。
Site Security Policy Handbook Working Group [Page 44] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[44ページ]RFC1244サイトセキュリティハンドブック1991年7月
3.9.7.3.2 DDN Security Coordination Center
3.9.7.3.2 DDNセキュリティコーディネートセンター
For DDN users, the Security Coordination Center (SCC) serves
a function similar to CERT. The SCC is the DDN's clearing-
house for host/user security problems and fixes, and works
with the DDN Network Security Officer. The SCC also
distributes the DDN Security Bulletin, which communicates
information on network and host security exposures, fixes,
and concerns to security and management personnel at DDN
facilities. It is available online, via kermit or anonymous
FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy-
nn.TXT (where "yy" is the year and "nn" is the bulletin
number). The SCC provides immediate assistance with DDN-
related host security problems; call (800) 235-3155 (6:00
a.m. to 5:00 p.m. Pacific Time) or send email to
SCC@NIC.DDN.MIL. For 24 hour coverage, call the MILNET
Trouble Desk (800) 451-7413 or AUTOVON 231-1713.
DDNユーザに関しては、Security Coordinationセンター(SCC)はCERTと同様の機能を果たします。 SCCはDDN Network安全担当官と共にホスト/ユーザ警備上の問題のためのDDN開拓地の家であり、修理して、働いています。 また、SCCはDDN Security Bulletinを分配します。(DDN Security BulletinはDDN施設でセキュリティと経営幹部へのネットワークの情報とホストセキュリティ暴露、フィックス、および関心を伝えます)。 それはオンラインで利用可能です、カーミットか公開FTPで、ホストNIC.DDN.MILから、SCCで: DDN-SECURITY-yy- nn.TXT("yy"がどこの1年と"nn"であるかは報告番号です)。 SCCは関係づけられるDDNに関する即座の支援ホスト警備上の問題を提供します。 (太平洋標準時午後5時0分までの午前6時)に(800)235-3155に電話をするか、またはメールを SCC@NIC.DDN.MIL に送ってください。 24時間の適用範囲に関しては、MILNET Trouble Deskを(800)451-7413かAUTOVON231-1713と呼んでください。
3.9.7.3.3 NIST Computer Security Resource and Response Center
3.9.7.3.3 NISTコンピュータセキュリティリソースと応答センター
The National Institute of Standards and Technology (NIST)
has responsibility within the U.S. Federal Government for
computer science and technology activities. NIST has played
a strong role in organizing the CERT System and is now
serving as the CERT System Secretariat. NIST also operates
a Computer Security Resource and Response Center (CSRC) to
provide help and information regarding computer security
events and incidents, as well as to raise awareness about
computer security vulnerabilities.
米国商務省標準技術局(NIST)はコンピュータサイエンスと技術活動のための米国連邦政府の中に責任を持っています。 NISTはCERT Systemを組織化する際に強い役割を果たして、現在、CERT System事務局として機能しています。 また、NISTは、コンピュータセキュリティイベントとインシデントの助けと情報を提供して、コンピュータセキュリティ脆弱性に関して関心を高めるために、コンピュータSecurity ResourceとResponseセンター(CSRC)を経営します。
The CSRC team operates a 24-hour hotline, at (301) 975-5200.
For individuals with access to the Internet, on-line
publications and computer security information can be
obtained via anonymous FTP from the host CSRC.NCSL.NIST.GOV
(129.6.48.87). NIST also operates a personal computer
bulletin board that contains information regarding computer
viruses as well as other aspects of computer security. To
access this board, set your modem to 300/1200/2400 BPS, 1
stop bit, no parity, and 8-bit characters, and call (301)
948-5717. All users are given full access to the board
immediately upon registering.
CSRCチームは(301)975-5200で24時間のホットラインを運用します。 インターネットへのアクセスの個人にとって、ホストCSRC.NCSL.NIST.GOVからの公開FTPでオンライン刊行物とコンピュータセキュリティ情報を得ることができる、(129.6 .48 .87)。 また、NISTはコンピュータセキュリティの他の局面と同様にコンピュータウイルスの情報を含むパーソナルコンピュータ掲示板を操作します。 このボードにアクセスするために、300/1200/2400BPS、1つのストップビット、同等がない、および8ビットのキャラクタにモデムを設定してください、そして、(301)948-5717と呼んでください。 すぐ登録でのボードへの完全なアクセスをすべてのユーザに与えます。
NIST has produced several special publications related to
computer security and computer viruses in particular; some
of these publications are downloadable. For further
information, contact NIST at the following address:
NISTはコンピュータセキュリティに関連するいくつかの特別な刊行物と特にコンピュータウイルスを発生させました。 これらの刊行物のいくつかがダウンローダブルです。 詳しくは、NISTは以下のアドレスで連絡します:
Site Security Policy Handbook Working Group [Page 45] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[45ページ]RFC1244サイトセキュリティハンドブック1991年7月
Computer Security Resource and Response Center
A-216 Technology
Gaithersburg, MD 20899
Telephone: (301) 975-3359
Electronic Mail: CSRC@nist.gov
コンピュータセキュリティリソースとセンターA-216Technologyゲイザースバーグ、Response MD 20899に電話をします: (301) 975-3359電子メール: CSRC@nist.gov
3.9.7.3.4 DOE Computer Incident Advisory Capability (CIAC)
3.9.7.3.4 コンピュータのDOEのインシデントの顧問能力(CIAC)
CIAC is the Department of Energy's (DOE's) Computer Incident
Advisory Capability. CIAC is a four-person team of computer
scientists from Lawrence Livermore National Laboratory
(LLNL) charged with the primary responsibility of assisting
DOE sites faced with computer security incidents (e.g.,
intruder attacks, virus infections, worm attacks, etc.).
This capability is available to DOE sites on a 24-hour-a-day
basis.
CIACはエネルギー省の(DOE)のコンピュータIncident Advisory Capabilityです。 CIACはコンピュータセキュリティインシデント(例えば、侵入者攻撃、ウイルス感染力、ワーム攻撃など)に直面していたDOEサイトを補助する責務で告発されたローレンス・リバモア国立研究所(LLNL)からのコンピュータ科学者の4人のチームです。 この能力は時間(毎日)の24ベースに関するDOEサイトに利用可能です。
CIAC was formed to provide a centralized response capability
(including technical assistance), to keep sites informed of
current events, to deal proactively with computer security
issues, and to maintain liaisons with other response teams
and agencies. CIAC's charter is to assist sites (through
direct technical assistance, providing information, or
referring inquiries to other technical experts), serve as a
clearinghouse for information about threats/known
incidents/vulnerabilities, develop guidelines for incident
handling, develop software for responding to
events/incidents, analyze events and trends, conduct
training and awareness activities, and alert and advise
sites about vulnerabilities and potential attacks.
CIACは、集結された応答能力(技術支援を含んでいる)を提供して、時事についてサイトを知らせ続けて、コンピュータセキュリティ問題に予測して対処して、他の応答チームと政府機関との連絡を主張するために形成されました。 CIACの特許は、脆弱性と起こり得るかもしれない攻撃に関してサイトをサイト(ダイレクト技術支援で他の技術家に情報を提供するか、または問い合せについて照会する)を補助して、インシデント/脆弱性を脅威の情報のための情報センターとして役立つか、または知って、付随している取り扱いのためにガイドラインを開発して、イベント/インシデントに応じるためにソフトウェアを開発して、イベントと傾向を分析して、トレーニングと認識活動を行って、警告して、教えることです。
CIAC's business hours phone number is (415) 422-8193 or FTS
532-8193. CIAC's e-mail address is CIAC@TIGER.LLNL.GOV.
CIACの営業時間電話番号は、(415)422-8193かFTS532-8193です。 CIACのEメールアドレスは CIAC@TIGER.LLNL.GOV です。
3.9.7.3.5 NASA Ames Computer Network Security Response Team
3.9.7.3.5 NASAエームズコンピュータネットワークセキュリティ応答チーム
The Computer Network Security Response Team (CNSRT) is NASA
Ames Research Center's local version of the DARPA CERT.
Formed in August of 1989, the team has a constituency that
is primarily Ames users, but it is also involved in
assisting other NASA Centers and federal agencies. CNSRT
maintains liaisons with the DOE's CIAC team and the DARPA
CERT. It is also a charter member of the CERT System. The
team may be reached by 24 hour pager at (415) 694-0571, or
by electronic mail to CNSRT@AMES.ARC.NASA.GOV.
コンピュータNetwork Security Response Team(CNSRT)は米航空宇宙局エイムズ研究所のDARPA CERTのローカルのバージョンです。 1989年8月に形成されています、チームには、主としてエームズユーザである選挙民がいますが、また、それは他のNASAのセンターズと連邦機関を補助するのにかかわります。 CNSRTはDOEのCIACチームとDARPA CERTとの連絡を維持します。 また、それはCERT Systemの創立委員です。 チームに(415)694-0571の24時間のポケットベル、または CNSRT@AMES.ARC.NASA.GOV への電子メールで達するかもしれません。
Site Security Policy Handbook Working Group [Page 46] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[46ページ]RFC1244サイトセキュリティハンドブック1991年7月
3.9.7.4 DDN Management Bulletins
3.9.7.4 DDN管理報告
The DDN Management Bulletin is distributed electronically by
the DDN NIC under contract to the Defense Communications Agency
(DCA). It is a means of communicating official policy,
procedures, and other information of concern to management
personnel at DDN facilities.
DDN Management BulletinはDDN NICによって契約に基づき電子的にDefense Communications Agency(DCA)に分配されます。 それはDDN施設の経営幹部にとって、重要な公式方針、手順、および他の情報を伝える手段です。
The DDN Security Bulletin is distributed electronically by the
DDN SCC, also under contract to DCA, as a means of
communicating information on network and host security
exposures, fixes, and concerns to security and management
personnel at DDN facilities.
DDN Security BulletinはDDN SCCによって電子的に分配されます、DCAへの契約に基づきも、DDN施設でセキュリティと経営幹部へのネットワークの情報とホストセキュリティ暴露、フィックス、および関心を伝える手段として。
Anyone may join the mailing lists for these two bulletins by
sending a message to NIC@NIC.DDN.MIL and asking to be placed on
the mailing lists. These messages are also posted to the
USENET newsgroup "ddn.mgt-bulletin". For additional
information, see section 8.7.
メッセージを NIC@NIC.DDN.MIL に送って、メーリングリストに置かれるように頼むことによって、だれでもこれらの2つの報告のためのメーリングリストに加わるかもしれません。 また、これらのメッセージはユーズネット「ddn.mgt-報告」に掲示されます。 追加情報に関しては、セクション8.7を見てください。
3.9.7.5 System Administration List
3.9.7.5 システム管理リスト
The SYSADM-LIST is a list pertaining exclusively to UNIX system
administration. Mail requests to be added to the list to
SYSADM-LIST-REQUEST@SYSADMIN.COM.
SYSADM-LISTは排他的にUNIXシステム管理に関係するリストです。 リストに追加されるという要求を SYSADM-LIST-REQUEST@SYSADMIN.COM に郵送してください。
3.9.7.6 Vendor Specific System Lists
3.9.7.6 ベンダーの特定のシステムリスト
The SUN-SPOTS and SUN-MANAGERS lists are discussion groups for
users and administrators of systems supplied by Sun
Microsystems. SUN-SPOTS is a fairly general list, discussing
everything from hardware configurations to simple UNIX
questions. To subscribe, send a message to SUN-SPOTS-
REQUEST@RICE.EDU. This list is also available in the USENET
newsgroup "comp.sys.sun". SUN-MANAGERS is a discussion list
for Sun system administrators and covers all aspects of Sun
system administration. To subscribe, send a message to SUN-
MANAGERS-REQUEST@EECS.NWU.EDU.
SUN-SPOTSとSUN-マネージャリストはサン・マイクロシステムズによって供給されたシステムのユーザと管理者のためのディスカッション・グループです。SUN-SPOTSはかなり一般的なリストです、ハードウェア・コンフィギュレーションから簡単なUNIX質問までのすべてについて議論して。 申し込むには、SUN-SPOTS REQUEST@RICE.EDU にメッセージを送ってください。 また、このリストもユーズネット"comp.sys.sun"で利用可能です。 SUN-マネージャは、Sunのシステム管理者への議論リストであり、Sunシステム管理の全面をカバーします。 申し込むには、SUN MANAGERS-REQUEST@EECS.NWU.EDU にメッセージを送ってください。
The APOLLO list discusses the HP/Apollo system and its
software. To subscribe, send a message to APOLLO-
REQUEST@UMIX.CC.UMICH.EDU. APOLLO-L is a similar list which
can be subscribed to by sending
アポロリストはヒューレット・パッカード/アポロシステムとそのソフトウェアについて議論します。 申し込むには、アポロ REQUEST@UMIX.CC.UMICH.EDU にメッセージを送ってください。 アポロ-Lは発信することによって加入できる同様のリストです。
SUB APOLLO-L your full name
SUB APOLLO-Lはあなたのフルネームです。
to LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU.
LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU に。
Site Security Policy Handbook Working Group [Page 47] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[47ページ]RFC1244サイトセキュリティハンドブック1991年7月
HPMINI-L pertains to the Hewlett-Packard 9000 series and HP/UX
operating system. To subscribe, send
HPMINI-Lはヒューレット・パッカード9000シリーズとヒューレット・パッカード/UXオペレーティングシステムに関係します。 申し込むには、発信してください。
SUB HPMINI-L your full name
SUB HPMINI-Lはあなたのフルネームです。
to LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU.
LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU に。
INFO-IBMPC discusses IBM PCs and compatibles, as well as MS-
DOS. To subscribe, send a note to INFO-IBMPC-REQUEST@WSMR-
SIMTEL20.ARMY.MIL.
INFO-IBMPCはIBM PC、compatibles、およびMS DOSについて議論します。 申し込むには、 INFO-IBMPC-REQUEST@WSMR- SIMTEL20.ARMY.MILに手紙を書いてください。
There are numerous other mailing lists for nearly every popular
computer or workstation in use today. For a complete list,
obtain the file "netinfo/interest-groups" via anonymous FTP
from the host FTP.NISC.SRI.COM.
今日、使用中のほとんどあらゆるポピュラーなコンピュータかワークステーションのための他の多数のメーリングリストがあります。 全リストに、ホストFTP.NISC.SRI.COMからの公開FTPで「netinfo/営利団体」というファイルを入手してください。
3.9.7.7 Professional Societies and Journals
3.9.7.7 専門家の学会とジャーナル
The IEEE Technical Committee on Security & Privacy publishes a
quarterly magazine, "CIPHER".
Security&Privacyの上のIEEE Technical Committeeは季刊雑誌、「暗号」を発行します。
IEEE Computer Society,
1730 Massachusetts Ave. N.W.
Washington, DC 2036-1903
IEEEコンピュータ社会、1730マサチューセッツAve。 ワシントン、北西DC2036-1903
The ACM SigSAC (Special Interest Group on Security, Audit, and
Controls) publishes a quarterly magazine, "SIGSAC Review".
ACM SigSAC(Security、Audit、およびControlsの上の特別利益団体Group)は季刊雑誌、「SIGSACレビュー」を発行します。
Association for Computing Machinery
11 West 42nd St.
New York, N.Y. 10036
42番目の計算機学会11の西聖ニューヨーク、ニューヨーク10036
The Information Systems Security Association publishes a
quarterly magazine called "ISSA Access".
情報システムSecurity Associationは「イッサAccess」と呼ばれる季刊雑誌を発行します。
Information Systems Security Association
P.O. Box 9457
Newport Beach, CA 92658
ニューポートビーチ、情報システムセキュリティ協会P.O. Box9457カリフォルニア 92658
"Computers and Security" is an "international journal for the
professional involved with computer security, audit and
control, and data integrity."
「コンピュータとSecurity」は「コンピュータセキュリティにかかわる専門家、オーディット・アンド・コントロール、およびデータ保全のための国際的なジャーナル」です。
Site Security Policy Handbook Working Group [Page 48] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[48ページ]RFC1244サイトセキュリティハンドブック1991年7月
$266/year, 8 issues (1990)
266/年、8ドルの問題(1990)
Elsevier Advanced Technology
Journal Information Center
655 Avenue of the Americas
New York, NY 10010
ニューヨーク、Elsevier先進技術ジャーナルインフォメーション・センター655アベニュー・オブ・ジ・アメリカズニューヨーク 10010
The "Data Security Letter" is published "to help data security
professionals by providing inside information and knowledgable
analysis of developments in computer and communications
security."
「データ機密保護手紙」は、「コンピュータと通信秘密保全における、開発の内部情報と博識な分析を提供することによって、データ機密保護専門家を助ける」ために発行されます。
$690/year, 9 issues (1990)
690/年、9ドルの問題(1990)
Data Security Letter
P.O. Box 1593
Palo Alto, CA 94302
パロアルト、データ機密保護手紙P.O. Box1593カリフォルニア 94302
3.9.8 Problem Reporting Tools
3.9.8 ツールを報告することにおける問題
3.9.8.1 Auditing
3.9.8.1 監査
Auditing is an important tool that can be used to enhance the
security of your installation. Not only does it give you a
means of identifying who has accessed your system (and may have
done something to it) but it also gives you an indication of
how your system is being used (or abused) by authorized users
and attackers alike. In addition, the audit trail
traditionally kept by computer systems can become an invaluable
piece of evidence should your system be penetrated.
監査はあなたのインストールのセキュリティを高めるのに使用できる重要なツールです。 また、だれがあなたのシステム(そして、それを興奮したかもしれない)にアクセスしたかを特定する手段をあなたに与えるだけではなく、それはあなたのシステムが認定ユーザと攻撃者によってどう同じく使用されるか(または、乱用されます)しるしをあなたに与えます。 さらに、あなたのシステムが理解されるなら、コンピュータ・システムによって伝統的に保たれた監査証跡は非常に貴重な証拠になることができます。
3.9.8.1.1 Verify Security
3.9.8.1.1 セキュリティについて確かめてください。
An audit trail shows how the system is being used from day
to day. Depending upon how your site audit log is
configured, your log files should show a range of access
attempts that can show what normal system usage should look
like. Deviation from that normal usage could be the result
of penetration from an outside source using an old or stale
user account. Observing a deviation in logins, for example,
could be your first indication that something unusual is
happening.
監査証跡はシステムが日々にどう使用される予定であるかを示しています。 あなたの現場監査ログがどう構成されるかによって、あなたのログファイルはどんな正常なシステム使用に似るべきであるかを示すことができるさまざまなアクセス試みを示しているべきです。 その正常な用法からの逸脱は外部のソースからの侵入が古いか聞き古したユーザアカウントを使用するという結果であるかもしれません。 例えば、ログインにおける逸脱を観測するのは、その何か珍しいものが起こっているというあなたの最初の指示であるかもしれません。
3.9.8.1.2 Verify Software Configurations
3.9.8.1.2 ソフトウェア構成について確かめてください。
One of the ruses used by attackers to gain access to a
system is by the insertion of a so-called Trojan Horse
program. A Trojan Horse program can be a program that does
システムへのアクセスを得るのに攻撃者によって使用された策略の1つがいわゆるトロイの木馬プログラムの挿入であります。 トロイの木馬プログラムはそれがするプログラムであるかもしれません。
Site Security Policy Handbook Working Group [Page 49] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[49ページ]RFC1244サイトセキュリティハンドブック1991年7月
something useful, or merely something interesting. It
always does something unexpected, like steal passwords or
copy files without your knowledge [25]. Imagine a Trojan
login program that prompts for username and password in the
usual way, but also writes that information to a special
file that the attacker can come back and read at will.
Imagine a Trojan Editor program that, despite the file
permissions you have given your files, makes copies of
everything in your directory space without you knowing about
it.
使い物、または単に何かおもしろいもの。 それはもうけ物パスワードやコピーファイルのようにあなたの知識[25]なしでいつも意表に出ます。 ユーザ名とパスワードのために不断のとおりうながしますが、それが攻撃者が戻ることができるという特別なファイルへのその情報をまた書くトロイのログインプログラムを想像してください、そして、自由自在に読んでください。 あなたがファイルを与えたファイル許容にもかかわらず、あなたのディレクトリスペースであなたなしですべてのコピーを作るトロイのEditorプログラムがそれに関して知ると想像してください。
This points out the need for configuration management of the
software that runs on a system, not as it is being
developed, but as it is in actual operation. Techniques for
doing this range from checking each command every time it is
executed against some criterion (such as a cryptoseal,
described above) or merely checking the date and time stamp
of the executable. Another technique might be to check each
command in batch mode at midnight.
それが開発されていないときシステムで動くソフトウェアにもかかわらず、それが実際の運営中であるときに、これは構成管理の必要性を指摘します。 何らかの評価基準(上で説明されたcryptosealなどの)に対して実行されるか、または単に実行可能の日付とタイムスタンプをチェックしているときはいつも、それぞれをチェックするのでこの範囲をするためのテクニックは命令します。 別のテクニックは真夜中にバッチ・モードにおける各コマンドをチェックすることであるかもしれません。
3.9.8.2 Tools
3.9.8.2 ツール
COPS is a security tool for system administrators that checks
for numerous common security problems on UNIX systems [27].
COPS is a collection of shell scripts and C programs that can
easily be run on almost any UNIX variant. Among other things,
it checks the following items and sends the results to the
system administrator:
COPSはシステム管理者のための多数の共通の安全保障問題がないかどうかUNIXシステム[27]の上でチェックするセキュリティツールです。 COPSはほとんどどんなUNIX異形の上でも容易に動かすことができるシェルスクリプトとCプログラムの収集です。 特に、以下の項目をチェックして、結果をシステム管理者に送ります:
- Checks "/dev/kmem" and other devices for world
read/writability.
- /書き易さが読まれた世界がないかどうか"/dev/kmem"と対向機器をチェックします。
- Checks special or important files and directories for
"bad" modes (world writable, etc.).
- 「悪い」モード(書き込み可能な世界など)がないかどうか特別であるか重要なファイルとディレクトリをチェックします。
- Checks for easily-guessed passwords.
- 容易に推測されたパスワードのためのチェック。
- Checks for duplicate user ids, invalid fields in the
password file, etc..
- 写しユーザイドのためのチェック、パスワードファイルの無効の分野など。
- Checks for duplicate group ids, invalid fields in the
group file, etc..
- 写しのためのチェックはイド、グループファイルの無効の分野などを分類します。
- Checks all users' home directories and their ".cshrc",
".login", ".profile", and ".rhosts" files for security
problems.
- チェックのすべてのユーザのホームディレクトリ、それらの".cshrc"、".login"、".profile"、および".rhosts"は警備上の問題を申し込みます。
- Checks all commands in the "/etc/rc" files and "cron"
- "/etc/rc"ファイルと"cron"のすべてのコマンドをチェックします。
Site Security Policy Handbook Working Group [Page 50] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[50ページ]RFC1244サイトセキュリティハンドブック1991年7月
files for world writability.
世界書き易さのためのファイル。
- Checks for bad "root" paths, NFS file systems exported
to the world, etc..
- 悪い「根」経路、世界にエクスポートされたNFSファイルシステムなどのためのチェック。
- Includes an expert system that checks to see if a given
user (usually "root") can be compromised, given that
certain rules are true.
- ある規則が正しいなら与えられたユーザ(通常、「根づく」)に感染することができるかどうか確認するためにチェックするエキスパートシステムを含んでいます。
- Checks for changes in the setuid status of programs on the
system.
- システムの上のプログラムのsetuid状態の変化のためのチェック。
The COPS package is available from the "comp.sources.unix"
archive on "ftp.uu.net", and also from the UNIX-SW repository
on the MILNET host "wsmr-simtel20.army.mil".
COPSパッケージは"ftp.uu.net"と、MILNETの上のUNIX-SW倉庫からもホスト"wsmr-simtel20.army.mil"という"comp.sources.unix"アーカイブから利用可能です。
3.9.9 Communication Among Administrators
3.9.9 管理者の中のコミュニケーション
3.9.9.1 Secure Operating Systems
3.9.9.1 セキュア・オペレーティング・システム
The following list of products and vendors is adapted from the
National Computer Security Center's (NCSC) Evaluated Products
List. They represent those companies who have either received
an evaluation from the NCSC or are in the process of a product
evaluation. This list is not complete, but it is
representative of those operating systems and add on components
available in the commercial marketplace.
製品とベンダーの以下のリストはNationalコンピュータSecurityセンター(NCSC)の評価のProducts Listから適合させられます。 彼らは、NCSCから評価を受け取った会社を代表するか、または製品評価の途中にいます。 それはそれらのオペレーティングシステムを代表しています、そして、このリストは完全ではありませんが、商業市場で利用可能なコンポーネントを加えてください。
For a more detailed listing of the current products appearing
in the NCSC EPL, contact the NCSC at:
NCSC EPLに現れる現在の製品の、より詳細なリストに関しては、以下でNCSCに連絡してください。
National Computer Security Center
9800 Savage Road
Fort George G. Meade, MD 20755-6000
(301) 859-4458
国家のコンピュータセキュリティセンター9800サヴェージ道路とりでジョージ・G.ミード、MD20755-6000(301)859-4458
Site Security Policy Handbook Working Group [Page 51] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[51ページ]RFC1244サイトセキュリティハンドブック1991年7月
Version Evaluation
Evaluated Product Vendor Evaluated Class
-----------------------------------------------------------------------
Secure Communications Honeywell Information 2.1 A1
Processor (SCOMP) Systems, Inc.
バージョン評価は製品のベンダーの評価のクラスを評価しました。----------------------------------------------------------------------- 安全なコミュニケーションハネウェル情報2.1A1プロセッサ(SCOMP)システムInc.
Multics Honeywell Information MR11.0 B2
Systems, Inc.
Multicsハネウェル情報MR11.0 B2システムInc.
System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1 System V 3.1.1 on AT&T 3B2/500and 3B2/600
AT&T3B2/500and 3B2/600の上のUNIX AT&T1.1.2B1システムV3.1.1に関するシステムV/MLS1.1.2
OS 1100 Unisys Corp. Security B1
Release 1
OS1100ユニシスのセキュリティB1リリース1
MPE V/E Hewlett-Packard Computer G.03.04 C2
Systems Division
MPE V/Eヒューレット・パッカードコンピュータG.03.04 C2システム区画
AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2
MV/ECLIPSEシリーズデータ・ゼネラル7.60C2の上のAOS/VS
VM/SP or VM/SP HPO with CMS, IBM Corp. 5 C2 RACF, DIRMAINT, VMTAPE-MS, ISPF
VM/SPかcmがあるVM/SP HPO、IBM社5のC2 RACF、DIRMAINT、VMTAPE-MS ISPF
MVS/XA with RACF IBM Corp. 2.2,2.3 C2
RACF IBM社2.2、2.3のC2とMVS/XA
AX/VMS Digital Equipment Corp. 4.3 C2
斧/VMSディジタル・イクイップメント社4.3C2
NOS Control Data Corp. NOS
Security C2
Eval Product
NOS制御データ社のNOSセキュリティC2 Eval製品
TOP SECRET CGA Software Products 3.0/163 C2
Group, Inc.
最高機密CGAソフト製品3.0/163C2グループInc.
Access Control Facility 2 SKK, Inc. 3.1.3 C2
アクセス制御施設2SKK Inc.3.1.3C2
UTX/32S Gould, Inc. Computer 1.0 C2
Systems Division
32UTX/年代のグールドInc.Computer1.0C2システム区画
A Series MCP/AS with Unisys Corp. 3.7 C2 InfoGuard Security Enhancements
AシリーズMCP/、ユニシス3.7のC2 InfoGuardセキュリティ増進
Primos Prime Computer, Inc. 21.0.1DODC2A C2 Resource Access Control IBM Corp. 1.5 C1 Facility (RACF)
PrimosプライムコンピュータInc.21.0.1DODC2A C2リソースアクセス制御IBM社1.5のC1施設(RACF)
Site Security Policy Handbook Working Group [Page 52] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[52ページ]RFC1244サイトセキュリティハンドブック1991年7月
Version Candidate
Candidate Product Vendor Evaluated Class
-----------------------------------------------------------------------
Boeing MLS LAN Boeing Aerospace A1 M1
バージョンの候補の候補の製品のベンダーの評価のクラス----------------------------------------------------------------------- ボーイングMLS LANボーイング航空宇宙A1 M1
Trusted XENIX Trusted Information
Systems, Inc. B2
信じられたXENIXは情報システムInc.B2を信じました。
VSLAN VERDIX Corp. B2
VSLAN VERDIX社のB2
System V/MLS AT&T B1
システムV/MLS AT&T B1
VM/SP with RACF IBM Corp. 5/1.8.2 C2 Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2
上限ワングラボラトリーズInc.1.0C2があるRACF IBM社5/1.8の.2C2ワングSVS/OSがあるVM/SP
3.9.9.2 Obtaining Fixes for Known Problems
3.9.9.2 フィックスを既知の問題に得ること。
It goes without saying that computer systems have bugs. Even
operating systems, upon which we depend for protection of our
data, have bugs. And since there are bugs, things can be
broken, both maliciously and accidentally. It is important
that whenever bugs are discovered, a should fix be identified
and implemented as soon as possible. This should minimize any
exposure caused by the bug in the first place.
明らかに、コンピュータ・システムには、バグがあります。 オペレーティングシステム(私たちは私たちのデータの保護のために当てにする)ではさえ、バグがあります。 そして、バグがあるので、陰湿に、そして偶然ものを壊すことができます。 特定されて、できるだけ早く実装されて、バグが発見されるときはいつも、aが修理されるのは、重要です。 これは第一にバグによって引き起こされたどんな暴露も最小にするべきです。
A corollary to the bug problem is: from whom do I obtain the
fixes? Most systems have some support from the manufacturer or
supplier. Fixes coming from that source tend to be implemented
quickly after receipt. Fixes for some problems are often
posted on the network and are left to the system administrators
to incorporate as they can. The problem is that one wants to
have faith that the fix will close the hole and not introduce
any others. We will tend to trust that the manufacturer's
fixes are better than those that are posted on the net.
バグ問題への推論は以下の通りです。 だれから、私はフィックスを得ますか? ほとんどのシステムには、メーカーか供給者からの何らかのサポートがあります。 そのソースから来るフィックスは、領収書の後にすぐに実装される傾向があります。 いくつかの問題のためのフィックスは、ネットワークにしばしば掲示されて、彼らが残すことができるように盛込むのがシステム管理者に残されます。 問題は人がフィックスが穴を塞いで、どんな他のものも紹介しないという信頼が欲しいということです。 私たちは、メーカーのフィックスがネットに掲示されるものより良いと信じる傾向があるでしょう。
3.9.9.3 Sun Customer Warning System
3.9.9.3 Sun顧客警戒態勢
Sun Microsystems has established a Customer Warning System
(CWS) for handling security incidents. This is a formal
process which includes:
サン・マイクロシステムズは取り扱いセキュリティインシデントのために、Customer Warning System(CWS)を設立しました。 これは正式なである:プロセスです。
- Having a well advertised point of contact in Sun
for reporting security problems.
- Pro-actively alerting customers of worms, viruses,
or other security holes that could affect their systems.
- Distributing the patch (or work-around) as quickly
as possible.
- 親活発に顧客を警告して、ワーム、ウイルス、またはそうすることができた他のセキュリティーホールではそれらのシステムに影響してください。報告警備上の問題によって、Sunでよく広告を出した連絡先を持っている、--. --できるだけはやく、パッチ(回避策)を広げます。
Site Security Policy Handbook Working Group [Page 53] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[53ページ]RFC1244サイトセキュリティハンドブック1991年7月
They have created an electronic mail address, SECURITY-
ALERT@SUN.COM, which will enable customers to report security
problems. A voice-mail backup is available at (415) 688-9081.
A "Security Contact" can be designated by each customer site;
this person will be contacted by Sun in case of any new
security problems. For more information, contact your Sun
representative.
彼らは電子メールアドレス、顧客が警備上の問題を報告するのを可能にするSECURITY ALERT@SUN.COM を作成しました。ボイスメールバックアップは(415)688-9081で利用可能です。 それぞれの顧客サイトは「セキュリティ接触」を指定できます。 この人はどんな新しい警備上の問題の場合にSunによって連絡されるでしょう。詳しくは、Sun代表に連絡してください。
3.9.9.4 Trusted Archive Servers
3.9.9.4 信じられたアーカイブサーバー
Several sites on the Internet maintain large repositories of
public-domain and freely distributable software, and make this
material available for anonymous FTP. This section describes
some of the larger repositories. Note that none of these
servers implements secure checksums or anything else
guaranteeing the integrity of their data. Thus, the notion of
"trust" should be taken as a somewhat limited definition.
インターネットに関するいくつかのサイトで、公共の場と自由に配置可能なソフトウェアの大きい倉庫を維持して、この材料は公開FTPに利用可能になります。 このセクションはいくつかの、より大きい倉庫について説明します。 これらのサーバのいずれもそれらのデータの保全を保証しながら安全なチェックサムか他の何も実装しないことに注意してください。 したがって、「信頼」の概念はいくらか限られた定義としてみなされるべきです。
3.9.9.4.1 Sun Fixes on UUNET
3.9.9.4.1 SunはUUNETに固定されます。
Sun Microsystems has contracted with UUNET Communications
Services, Inc., to make fixes for bugs in Sun software
available via anonymous FTP. You can access these fixes by
using the "ftp" command to connect to the host FTP.UU.NET.
Then change into the directory "sun-dist/security", and
obtain a directory listing. The file "README" contains a
brief description of what each file in this directory
contains, and what is required to install the fix.
サン・マイクロシステムズは、Sunにおけるバグのためのフィックスを公開FTPを通して利用可能なソフトウェアにするようにUUNET Communications Services Inc.と契約しました。 ホストFTP.UU.NETに接続する"ftp"コマンドを使用することによって、あなたはこれらのフィックスにアクセスできます。 「太陽-dist/セキュリティ」がその時、ディレクトリに変化して、ディレクトリリストを入手してください。 「リード・ミー」というファイルはこのディレクトリの各ファイルが何を含んでいるか、そして、何がフィックスをインストールするのに必要であるかに関する簡単な説明を含んでいます。
3.9.9.4.2 Berkeley Fixes
3.9.9.4.2 バークレーフィックス
The University of California at Berkeley also makes fixes
available via anonymous FTP; these fixes pertain primarily
to the current release of BSD UNIX (currently, release 4.3).
However, even if you are not running their software, these
fixes are still important, since many vendors (Sun, DEC,
Sequent, etc.) base their software on the Berkeley releases.
また、カリフォルニア大学バークレイ校はフィックスを公開FTPで利用可能にします。 これらのフィックスは主としてBSD UNIXの現在のリリースに関係します(現在、4.3をリリースしてください)。 しかしながら、あなたがそれらのソフトウェアを動かさないでも、これらのフィックスはまだ重要です、多くのベンダー(Sun、12月、Sequentなど)がそれらのソフトウェアをバークレーのリリースに基礎づけるので。
The Berkeley fixes are available for anonymous FTP from the
host UCBARPA.BERKELEY.EDU in the directory "4.3/ucb-fixes".
The file "INDEX" in this directory describes what each file
contains. They are also available from UUNET (see section
3.9.9.4.3).
バークレーフィックスは「4.3/ucb-フィックス」というディレクトリのホストUCBARPA.BERKELEY.EDUからの公開FTPに利用可能です。 このディレクトリの「インデックス」というファイルは各自分が含むことについて説明します。 セクション3.9を見てください。また、それらもUUNETから利用可能である、(.9 .4 .3)。
Berkeley also distributes new versions of "sendmail" and
"named" from this machine. New versions of these commands
are stored in the "4.3" directory, usually in the files
"sendmail.tar.Z" and "bind.tar.Z", respectively.
また、バークレーは"sendmail"でこのマシンから「命名されること」の新しいバージョンを分配します。 これらのコマンドの新しいバージョンが保存される、「通常ファイル"sendmail.tar.Z"と"bind.tar.Z"の4.3インチのディレクトリ、それぞれ」
Site Security Policy Handbook Working Group [Page 54] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[54ページ]RFC1244サイトセキュリティハンドブック1991年7月
3.9.9.4.3 Simtel-20 and UUNET
3.9.9.4.3 Simtel-20とUUNET
The two largest general-purpose software repositories on the
Internet are the hosts WSMR-SIMTEL20.ARMY.MIL and
FTP.UU.NET.
2つのインターネットで最も大きい汎用ソフトウェア倉庫が、ホストのWSMR-SIMTEL20.ARMY.MILとFTP.UU.NETです。
WSMR-SIMTEL20.ARMY.MIL is a TOPS-20 machine operated by the
U.S. Army at White Sands Missile Range (WSMR), New Mexico.
The directory "pd2:<unix-c>" contains a large amount of UNIX
software, primarily taken from the "comp.sources"
newsgroups. The directories "pd1:<msdos>" and
"pd2:<msdos2>" contains software for IBM PC systems, and
"pd3:<macintosh>" contains software for the Apple Macintosh.
WSMR-SIMTEL20.ARMY.MILはホワイトサンズミサイル発射場(WSMR)、ニューメキシコの米軍によって運用されたTOPS-20マシンです。 ディレクトリ「pd2: <unix-c>」は"comp.sources"ニュースグループから主として取られた多量のUNIXソフトウェアを含んでいます。 ディレクトリの「pd1: <msdos>」と「pd2: <msdos2>」はIBM PCシステムのためのソフトウェアを含んでいます、そして、「pd3: <防水布>」はアップルマッキントッシュのためのソフトウェアを含んでいます。
FTP.UU.NET is operated by UUNET Communications Services,
Inc. in Falls Church, Virginia. This company sells Internet
and USENET access to sites all over the country (and
internationally). The software posted to the following
USENET source newsgroups is stored here, in directories of
the same name:
FTP.UU.NETはFalls教会、ヴァージニアでUUNET Communications Services Inc.によって運用されます。 同社は国(国際的である)全体にわたるサイトへのアクセスをインターネットとUSENETに販売します。 以下のUSENETソースニュースグループに掲示されたソフトウェアは同じ名前のディレクトリにここに保存されます:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
comp.sources.games comp.sources.misc comp.sources.sun comp.sources.unix comp.sources.x
Numerous other distributions, such as all the freely
distributable Berkeley UNIX source code, Internet Request
for Comments (RFCs), and so on are also stored on this
system.
また、すべての自由に配置可能なバークレーUNIXソースコード、Comments(RFCs)のためのインターネットRequestなどなどの他の頻繁な配はこのシステムの上に保存されます。
3.9.9.4.4 Vendors
3.9.9.4.4 ベンダー
Many vendors make fixes for bugs in their software available
electronically, either via mailing lists or via anonymous
FTP. You should contact your vendor to find out if they
offer this service, and if so, how to access it. Some
vendors that offer these services include Sun Microsystems
(see above), Digital Equipment Corporation (DEC), the
University of California at Berkeley (see above), and Apple
Computer [5, CURRY].
多くのベンダーがそれらの電子的かメーリングリストか公開FTPを通して利用可能なソフトウェアでバグのためのフィックスを作ります。 あなたは、彼らがこのサービスを提供するかどうかと、そうだとすれば、どのようにそれにアクセスするかを見つけるためにベンダーに連絡するべきです。 これらのサービスを提供するベンダーの中にはサン・マイクロシステムズ(上を見る)、ディジタルイクイップメント社(12月)、カリフォルニア大学バークレイ校(上を見る)、およびアップル・コンピューター[5、CURRY]を含めるものもあります。
Site Security Policy Handbook Working Group [Page 55] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[55ページ]RFC1244サイトセキュリティハンドブック1991年7月
4. Types of Security Procedures
4. セキュリティ手順のタイプ
4.1 System Security Audits
4.1 システムセキュリティ監査
Most businesses undergo some sort of annual financial auditing as a regular part of their business life. Security audits are an important part of running any computing environment. Part of the security audit should be a review of any policies that concern system security, as well as the mechanisms that are put in place to enforce them.
ほとんどのビジネスが彼らの経済活動の通常の部分としてのある種の年に一度の財政的な監査を受けます。 セキュリティ監査はどんなコンピューティング環境も実行する重要な部分です。 セキュリティ監査の一部がシステムセキュリティに関するどんな方針のレビューであるべきです、それらを実施するために適所に置かれるメカニズムと同様に。
4.1.1 Organize Scheduled Drills
4.1.1 予定されているドリルを組織化してください。
Although not something that would be done each day or week,
scheduled drills may be conducted to determine if the procedures
defined are adequate for the threat to be countered. If your
major threat is one of natural disaster, then a drill would be
conducted to verify your backup and recovery mechanisms. On the
other hand, if your greatest threat is from external intruders
attempting to penetrate your system, a drill might be conducted to
actually try a penetration to observe the effect of the policies.
毎日されることでない週ではありませんが、予定されているドリルが、打ち返されるべき脅威に、定義された手順が適切であるかどうか決定するために行われるかもしれません。 あなたの大きな脅威であるなら、1つは天災のものです、次に、ドリルが、あなたのバックアップと回収機構について確かめるために行われるでしょう。他方では、あなたの最大の脅威があなたのシステムを理解するのを試みる外部の侵入者から来ているなら、ドリルが、方針の効果を観測するために実際に侵入を試みるために行われるかもしれません。
Drills are a valuable way to test that your policies and
procedures are effective. On the other hand, drills can be time-
consuming and disruptive to normal operations. It is important to
weigh the benefits of the drills against the possible time loss
which may be associated with them.
ドリルはテストへのあなたの方針と手順が効果的である有益な方法です。 他方では、ドリルは通常操作に消費していて破壊的な時間であるかもしれません。 それらに関連するかもしれない可能な時間の損失にドリルの恩恵について比較考量するのは重要です。
4.1.2 Test Procedures
4.1.2 テスト手順
If the choice is made to not to use scheduled drills to examine
your entire security procedure at one time, it is important to
test individual procedures frequently. Examine your backup
procedure to make sure you can recover data from the tapes. Check
log files to be sure that information which is supposed to be
logged to them is being logged to them, etc..
選択を使用に予定されないようにします。ひところあなたの全体のセキュリティ手順を調べるドリル、頻繁に独特の手順をテストするのは重要です。 バックアップ手順を調べて、データをテープから取り戻すことができるのを確実にしてください。 それらに登録されるべきである情報がそれらなどに登録されているのを確信しているようにログファイルをチェックしてください。
When a security audit is mandated, great care should be used in
devising tests of the security policy. It is important to clearly
identify what is being tested, how the test will be conducted, and
results expected from the test. This should all be documented and
included in or as an adjunct to the security policy document
itself.
セキュリティ監査が強制されるとき、高度の注意は安全保障政策のテストについて工夫する際に使用されるべきです。 何がテストされて、テストがどう行われるだろうか、そして、テストから予想された結果であるかを明確に特定するのは重要です。 これは、安全保障政策ドキュメント自体にすべて記録されて、付属物か付属物として含められるべきです。
It is important to test all aspects of the security policy, both
procedural and automated, with a particular emphasis on the
automated mechanisms used to enforce the policy. Tests should be
defined to ensure a comprehensive examination of policy features,
それは、安全保障政策の全面をテストするために重要で、かつ手続き上で、かつ自動化されています、方針を実施するのに使用される自動化されたメカニズムへの特別の強調で。 テストは、方針機能の包括的な試験を確実にするために定義されるべきです。
Site Security Policy Handbook Working Group [Page 56] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[56ページ]RFC1244サイトセキュリティハンドブック1991年7月
that is, if a test is defined to examine the user logon process,
it should be explicitly stated that both valid and invalid user
names and passwords will be used to demonstrate proper operation
of the logon program.
すなわち、テストがユーザログオンプロセスを調べるために定義されるなら、有効で無効のユーザ名とパスワードの両方がログオンプログラムの適切な操作を示すのに使用されると明らかに述べられるべきです。
Keep in mind that there is a limit to the reasonableness of tests.
The purpose of testing is to ensure confidence that the security
policy is being correctly enforced, and not to "prove" the
absoluteness of the system or policy. The goal should be to
obtain some assurance that the reasonable and credible controls
imposed by your security policy are adequate.
テストの順正への限界があるのを覚えておいてください。 「テストする目的は、安全保障政策が正しく実施することにされるのであるという信用を確実にして、システムか方針の絶対性を立証しない」ことです。 目標はあなたの安全保障政策によって設けられる妥当で確かな規制が適切であるという何らかの保証を得ることであるべきです。
4.2 Account Management Procedures
4.2 アカウント管理手順
Procedures to manage accounts are important in preventing unauthorized access to your system. It is necessary to decide several things: Who may have an account on the system? How long may someone have an account without renewing his or her request? How do old accounts get removed from the system? The answers to all these questions should be explicitly set out in the policy.
アカウントを管理する手順はあなたのシステムへの不正アクセスを防ぐのにおいて重要です。 数個のものについて決めるのが必要です: だれがシステムの上にアカウントを持っているかもしれませんか? どれくらい長い間、だれかには、その人の要求を更新しないで、アカウントがあるかもしれませんか? システムから古いアカウントをどのように取り除きますか? これらのすべての質問の答えは方針で明らかに出されるべきです。
In addition to deciding who may use a system, it may be important to determine what each user may use the system for (is personal use allowed, for example). If you are connected to an outside network, your site or the network management may have rules about what the network may be used for. Therefore, it is important for any security policy to define an adequate account management procedure for both administrators and users. Typically, the system administrator would be responsible for creating and deleting user accounts and generally maintaining overall control of system use. To some degree, account management is also the responsibility of each system user in the sense that the user should observe any system messages and events that may be indicative of a policy violation. For example, a message at logon that indicates the date and time of the last logon should be reported by the user if it indicates an unreasonable time of last logon.
だれがある方法を使うかもしれないかを決めることに加えて、各ユーザが何にシステムを使用するかもしれないかを(例えば許された個人的な使用です)決定するのは重要であるかもしれません。 あなたが外のネットワークに接続されるなら、あなたのサイトかネットワークマネージメントには、ネットワークが何に使用されるかもしれないかに関する規則があるかもしれません。 したがって、どんな安全保障政策も管理者とユーザの両方のために適切なアカウント管理手順を定義するのは、重要です。 一般に、システム管理者は、通常、ユーザアカウントを作成して、削除するのに責任があってシステム使用の総括経営を維持するでしょう。 アカウント管理は、ある程度、ユーザがどんなシステムメッセージも観測するべきであるという意味におけるそれぞれのシステムユーザの責任とも方針違反の暗示するかもしれないイベントです。 例えば、最後のログオンの無理な時間を示すなら、最後のログオンの日時を示すログオンにおけるメッセージはユーザによって報告されるべきです。
4.3 Password Management Procedures
4.3 パスワード管理手順
A policy on password management may be important if your site wishes to enforce secure passwords. These procedures may range from asking or forcing users to change their passwords occasionally to actively attempting to break users' passwords and then informing the user of how easy it was to do. Another part of password management policy covers who may distribute passwords - can users give their passwords to other users?
あなたのサイトが安全なパスワードを実施したいなら、パスワード管理に関する方針は重要であるかもしれません。 ユーザのパスワードを知らせるのを試みて、次に、するのがどれくらい簡単であるかについてユーザに知らせながら尋ねるか、またはユーザに彼らのパスワードに時折活発に変わらせるので、これらの手順は及ぶかもしれません。 パスワードを分配するかもしれないパスワード経営政策カバーの別の部分--ユーザは彼らのパスワードを他のユーザに与えることができますか?
Section 2.3 discusses some of the policy issues that need to be
セクション2.3は、必要がある政策問題であることのいくつかと論じます。
Site Security Policy Handbook Working Group [Page 57] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[57ページ]RFC1244サイトセキュリティハンドブック1991年7月
decided for proper password management. Regardless of the policies, password management procedures need to be carefully setup to avoid disclosing passwords. The choice of initial passwords for accounts is critical. In some cases, users may never login to activate an account; thus, the choice of the initial password should not be easily guessed. Default passwords should never be assigned to accounts: always create new passwords for each user. If there are any printed lists of passwords, these should be kept off-line in secure locations; better yet, don't list passwords.
適切なパスワード管理の有利な判決を下しました。 方針にかかわらず、手順が必要があるパスワード管理はパスワードを明らかにするのを避けるのを慎重にセットアップされます。 アカウントのための初期のパスワードの選択は重要です。 いくつかの場合、ユーザはアカウントを活性化するために決してログインしないかもしれません。 したがって、容易に初期のパスワードの選択を推測するべきではありません。 デフォルトパスワードはアカウントに決して割り当てられるべきではありません: 各ユーザのためにいつも新しいパスワードを作成してください。 何かパスワードの印刷されたリストがあれば、これらは安全な位置でオフラインに保たれるべきです。 さらに良く、パスワードをリストアップしないでください。
4.3.1 Password Selection
4.3.1 パスワード選択
Perhaps the most vulnerable part of any computer system is the
account password. Any computer system, no matter how secure it is
from network or dial-up attack, Trojan horse programs, and so on,
can be fully exploited by an intruder if he or she can gain access
via a poorly chosen password. It is important to define a good
set of rules for password selection, and distribute these rules to
all users. If possible, the software which sets user passwords
should be modified to enforce as many of the rules as possible.
どんなコンピュータ・システムの最も被害を受け易い部分もアカウントパスワードです。 それがネットワークかダイヤルアップ攻撃、トロイの木馬プログラムなどからどんなに安全であっても、その人が不十分に選ばれたパスワードでアクセスを得ることができるなら、侵入者はどんなコンピュータ・システムも完全に利用できます。 パスワード選択のために良いセットの規則を定義して、すべてのユーザにこれらの規則を分配するのは重要です。 できれば、ユーザパスワードを設定するソフトウェアは、できるだけ多くの規則を実施するように変更されるべきです。
A sample set of guidelines for password selection is shown below:
パスワード選択のための1人のサンプル集合のガイドラインは以下に示されます:
- DON'T use your login name in any form (as-is,
reversed, capitalized, doubled, etc.).
- どんなフォーム(そのままで、逆にされて、大文字で書かれて、倍増しているなど)でもログイン名を使用しないでください。
- DON'T use your first, middle, or last name in any form.
- どんなフォームでも1番目、中央、または姓を使用しないでください。
- DON'T use your spouse's or child's name.
- 配偶者か子供の名前を使用しないでください。
- DON'T use other information easily obtained about you.
This includes license plate numbers, telephone numbers,
social security numbers, the make of your automobile,
the name of the street you live on, etc..
- あなたに関して容易に得られた他の情報を使用しないでください。 これはプレートナンバー、電話番号、社会保険番号、あなたの自動車の造、あなたが生活する通りの名前などを含んでいます。
- DON'T use a password of all digits, or all the same
letter.
- すべてのケタ、またはちょうど同じ手紙に関するパスワードを使用しないでください。
- DON'T use a word contained in English or foreign
language dictionaries, spelling lists, or other
lists of words.
- 単語の英語、外国語辞書、スペルリスト、または他のリストに含まれた単語を使用しないでください。
- DON'T use a password shorter than six characters.
- 6つのキャラクタより短いパスワードを使用しないでください。
- DO use a password with mixed-case alphabetics.
- 複雑なケースalphabeticsで使用にパスワードをしてください。
- DO use a password with non-alphabetic characters (digits
or punctuation).
- 非英字(ケタか句読)で使用にパスワードをしてください。
Site Security Policy Handbook Working Group [Page 58] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[58ページ]RFC1244サイトセキュリティハンドブック1991年7月
- DO use a password that is easy to remember, so you don't
have to write it down.
- 覚えていやすいパスワードを使用にして、それを書き留める必要はなくなってください。
- DO use a password that you can type quickly, without
having to look at the keyboard.
- あなたがすばやくキーボードを見る必要はなくてタイプできるパスワードを使用にしてください。
Methods of selecting a password which adheres to these guidelines
include:
これらのガイドラインを固く守るパスワードを選択するメソッドは:
- Choose a line or two from a song or poem, and use the
first letter of each word.
- 歌か詩から1か2つの系列を選んでください、そして、それぞれの単語の最初の手紙を使用してください。
- Alternate between one consonant and one or two vowels, up
to seven or eight characters. This provides nonsense
words which are usually pronounceable, and thus easily
remembered.
- 1つの子音の母音と1か2つの母音の7か8つのキャラクタまで間を行き来してください。 これは通常発音可能で、このようにして容易に覚えていられた無意味語を提供します。
- Choose two short words and concatenate them together with
a punctuation character between them.
- 2つのショートワードを選んでください、そして、それらの間の句読文字と共にそれらを連結してください。
Users should also be told to change their password periodically,
usually every three to six months. This makes sure that an
intruder who has guessed a password will eventually lose access,
as well as invalidating any list of passwords he/she may have
obtained. Many systems enable the system administrator to force
users to change their passwords after an expiration period; this
software should be enabled if your system supports it [5, CURRY].
また、ユーザが定期的、通常3〜6カ月毎に彼らのパスワードを変えるように言われるべきです。 これは、パスワードを推測した侵入者が結局その人が得たかもしれないパスワードのどんなリストも無効にすることと同様にアクセスを失うのを確実にします。 多くのシステムが、システム管理者がユーザに満了の期間の後に彼らのパスワードを強制的に変えさせるのを可能にします。 あなたのシステムが、それが[5、CURRY]であるとサポートするなら、このソフトウェアは可能にされるべきです。
Some systems provide software which forces users to change their
passwords on a regular basis. Many of these systems also include
password generators which provide the user with a set of passwords
to choose from. The user is not permitted to make up his or her
own password. There are arguments both for and against systems
such as these. On the one hand, by using generated passwords,
users are prevented from selecting insecure passwords. On the
other hand, unless the generator is good at making up easy to
remember passwords, users will begin writing them down in order to
remember them.
いくつかのシステムがユーザが定期的にやむを得ず彼らのパスワードを変えるソフトウェアを提供します。 また、これらのシステムの多くが1セットのパスワードをユーザに提供する選ぶパスワードジェネレータを含んでいます。 ユーザがその人の自己のパスワードを作ることが許可されていません。 システムを支持したこれらなどのシステムに対する議論があります。 一方では、発生しているパスワードを使用することによって、ユーザは不安定なパスワードを選択するのが防がれます。 他方では、ジェネレータはパスワードを覚えているためにたやすく仲直りするのが上手でない場合、ユーザが、彼らを覚えているために彼らを書き留め始めるでしょう。
4.3.2 Procedures for Changing Passwords
4.3.2 パスワードを変えるための手順
How password changes are handled is important to keeping passwords
secure. Ideally, users should be able to change their own
passwords on-line. (Note that password changing programs are a
favorite target of intruders. See section 4.4 on configuration
management for further information.)
パスワード変化がどう扱われるかは、パスワードを安全に保つのに重要です。 理想的に、ユーザはオンラインでそれら自身のパスワードを変えることができるべきです。 (パスワード変化プログラムが侵入者のお気に入りの目標であることに注意してください。 詳細に関して構成管理のセクション4.4を見てください。)
However, there are exception cases which must be handled
しかしながら、扱わなければならない例外ケースがあります。
Site Security Policy Handbook Working Group [Page 59] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[59ページ]RFC1244サイトセキュリティハンドブック1991年7月
carefully. Users may forget passwords and not be able to get onto
the system. The standard procedure is to assign the user a new
password. Care should be taken to make sure that the real person
is requesting the change and gets the new password. One common
trick used by intruders is to call or message to a system
administrator and request a new password. Some external form of
verification should be used before the password is assigned. At
some sites, users are required to show up in person with ID.
慎重に。 ユーザは、パスワードを忘れて、システムに乗ることができないかもしれません。 標準手続きは新しいパスワードをユーザに割り当てることです。 実在の人物が変化を要求していて、新しいパスワードを得るのを確実にするために注意するべきです。 侵入者によって使用された1つの一般的なトリックが呼ぶことであるかシステム管理者と要求へのメッセージは新しいパスワードです。 パスワードが割り当てられる前に何らかの外部の形式の検証は使用されるべきです。 いくつかのサイトでは、ユーザはIDと共に自分で現れなければなりません。
There may also be times when many passwords need to be changed.
If a system is compromised by an intruder, the intruder may be
able to steal a password file and take it off the system. Under
these circumstances, one course of action is to change all
passwords on the system. Your site should have procedures for how
this can be done quickly and efficiently. What course you choose
may depend on the urgency of the problem. In the case of a known
attack with damage, you may choose to forcibly disable all
accounts and assign users new passwords before they come back onto
the system. In some places, users are sent a message telling them
that they should change their passwords, perhaps within a certain
time period. If the password isn't changed before the time period
expires, the account is locked.
また、多くのパスワードが変えられる必要がある回があるかもしれません。 システムが侵入者によって感染されるなら、侵入者は、パスワードファイルを横取りして、システムからそれを取ることができるかもしれません。 こういう事情ですから、1つの行動はシステムに関するすべてのパスワードを変えることです。 あなたのサイトには、どうすぐに、効率的にこれができるか手順があるべきです。 あなたがどんなコースを選ぶかは問題の緊急によるかもしれません。 損害に伴う知られている攻撃の場合では、あなたは、彼らがシステムに戻る前に、強制的にすべてのアカウントを無効にして、新しいパスワードをユーザに割り当てるのを選ぶことができます。 所々、彼らが自分達のパスワードを変えるべきであると彼らに言うメッセージをユーザに送ります、恐らくある期間以内に。 期間が期限が切れる前にパスワードが変えられないなら、アカウントはロックされます。
Users should be aware of what the standard procedure is for
passwords when a security event has occurred. One well-known
spoof reported by the Computer Emergency Response Team (CERT)
involved messages sent to users, supposedly from local system
administrators, requesting them to immediately change their
password to a new value provided in the message [24]. These
messages were not from the administrators, but from intruders
trying to steal accounts. Users should be warned to immediately
report any suspicious requests such as this to site
administrators.
セキュリティイベントが起こったとき、ユーザは標準手続きがパスワードのための何であるかを意識しているべきです。 1つのよく知られるパロディーが、(CERT)がかかわったコンピュータ緊急対応チームでメッセージがユーザに発信したと報告しました、推定上ローカルシステム管理者から、至急彼らのパスワードをメッセージ[24]に提供された新しい値に変えるよう彼らに要求して。 これらのメッセージは管理者からあったのではなく、アカウントを横取りしようとする侵入者から来ていました。 ユーザは至急サイトの管理者へのこれなどの疑わしげなあらゆる要求を報告するように注意されるべきです。
4.4 Configuration Management Procedures
4.4 構成管理手順
Configuration management is generally applied to the software development process. However, it is certainly applicable in a operational sense as well. Consider that the since many of the system level programs are intended to enforce the security policy, it is important that these be "known" as correct. That is, one should not allow system level programs (such as the operating system, etc.) to be changed arbitrarily. At very least, the procedures should state who is authorized to make changes to systems, under what circumstances, and how the changes should be documented.
一般に、構成管理はソフトウェア開発プロセスに適用されます。 しかしながら、確かに、それはまた、操作上の意味で適切です。 それを考えてください、システムレベルプログラムの多くが安全保障政策を実施することを意図するので、これらが同じくらい正しい状態で「知られていること」は、重要です。 すなわち、もので、システムレベルプログラム(オペレーティングシステムなどの)は任意に変化するはずがありません。 少なくとも、手順は、だれがシステムへの変更を行うのに権限を与えられるかを述べるべきです、どんな事情と変化がどのように記録されるべきであるかの下で。
In some environments, configuration management is also desirable as applied to physical configuration of equipment. Maintaining valid
また、いくつかの環境で、構成管理も設備の物理的な構成に適用されるように望ましいです。 維持有効です。
Site Security Policy Handbook Working Group [Page 60] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[60ページ]RFC1244サイトセキュリティハンドブック1991年7月
and authorized hardware configuration should be given due consideration in your security policy.
そして、あなたの安全保障政策で当然の考慮を認可されたハードウェア・コンフィギュレーションに対して払うべきです。
4.4.1 Non-Standard Configurations
4.4.1 標準的でない構成
Occasionally, it may be beneficial to have a slightly non-standard
configuration in order to thwart the "standard" attacks used by
some intruders. The non-standard parts of the configuration might
include different password encryption algorithms, different
configuration file locations, and rewritten or functionally
limited system commands.
時折、わずかに標準的でない構成を持っているのは、何人かの侵入者によって使用された「標準」の攻撃を阻むのに有益であるかもしれません。 構成の標準的でない一部分が異なったパスワードの暗号化アルゴリズム、異なった構成ファイル位置、および書き直されたか、または機能上限られたシステム・コマンドを含むかもしれません。
Non-standard configurations, however, also have their drawbacks.
By changing the "standard" system, these modifications make
software maintenance more difficult by requiring extra
documentation to be written, software modification after operating
system upgrades, and, usually, someone with special knowledge of
the changes.
しかしながら、標準的でない構成には、また、それらの欠点があります。 「標準」のシステムを変えることによって、これらの変更は付加的なドキュメンテーションが書かれているのを必要とすることによって、より難しいソフトウェア・メンテナンス、オペレーティングシステムアップグレードの後のソフトウェア変更、および通常変化に関する特別な知識をもっているだれかを作ります。
Because of the drawbacks of non-standard configurations, they are
often only used in environments with a "firewall" machine (see
section 3.9.1). The firewall machine is modified in non-standard
ways since it is susceptible to attack, while internal systems
behind the firewall are left in their standard configurations.
標準的でない構成の欠点のために、それらは「ファイアウォール」マシンで環境でしばしば使用されるだけです(セクション3.9.1を見てください)。 攻撃するのが影響されやすいので、ファイアウォールマシンは標準的でない方法で変更されます、ファイアウォールの後ろの内部のシステムがそれらの標準的な構成で残されますが。
5. Incident Handling
5. 付随している取り扱い
5.1 Overview
5.1 概要
This section of the document will supply some guidance to be applied when a computer security event is in progress on a machine, network, site, or multi-site environment. The operative philosophy in the event of a breach of computer security, whether it be an external intruder attack or a disgruntled employee, is to plan for adverse events in advance. There is no substitute for creating contingency plans for the types of events described above.
コンピュータセキュリティイベントがマシン(ネットワーク、サイト、またはマルチサイト環境)で進行しているとき、ドキュメントのこのセクションは、適用されるために何らかの指導を供給するでしょう。 影響を及ぼしている哲学はコンピュータセキュリティの不履行の場合、あらかじめそれが外部の侵入者攻撃か不満を抱いた従業員であることにかかわらず有害事象の計画を立てることです。 上で説明されたイベントのタイプのために緊急時対策を作成する代用品が全くありません。
Traditional computer security, while quite important in the overall site security plan, usually falls heavily on protecting systems from attack, and perhaps monitoring systems to detect attacks. Little attention is usually paid for how to actually handle the attack when it 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.
総合的なサイト警備計画でかなり重要ですが、通常、伝統的なコンピュータセキュリティは、攻撃を検出するために保護システムの上で攻撃、および恐らく監視システムからどしんと落ちます。 起こるとき、ほとんど、通常、注意は、実際にどう攻撃を扱うかために向けられません。 結果は、攻撃が進行しているとき、急いで多くの決定をするということであり、インシデントの源を捜し出すのにダメージが大きい場合があります、起訴取り組みに使用されるために証拠固めて、システムの回復の用意をして、システムの上に含まれた貴重な資料を保護して。
Site Security Policy Handbook Working Group [Page 61] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[61ページ]RFC1244サイトセキュリティハンドブック1991年7月
5.1.1 Have a Plan to Follow in Case of an Incident
5.1.1 インシデントの場合に続く計画を持ってください。
Part of handling an incident is being prepared to respond before
the incident occurs. This includes establishing a suitable level
of protections, so that if the incident becomes severe, the damage
which can occur is limited. Protection includes preparing
incident handling guidelines or a contingency response 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. Second, part of
protection is preparing a method of notification, so you will know
who to call and the relevant phone numbers. It is important, for
example, to conduct "dry runs," in which your computer security
personnel, system administrators, and managers simulate handling
an incident.
インシデントを扱う一部がインシデントが起こる前に応じるように準備されています。 これは、適当なレベルの保護を確立するのを含んでいます、インシデントが厳しくなるなら、発生できる損害は限られます。 保護は、あなたの組織かサイトのために付随している取り扱いガイドラインか偶然性応答プランを準備するのを含んでいます。 企画書を持っているのは、インシデントの間に起こるあいまいさの多くを排除して、より適切で徹底的な応答に通じるでしょう。 2番目に、保護の一部が通知のメソッドを準備しているので、あなたはだれを呼ぶか、そして、関連電話番号を知るでしょう。 例えば、「模擬試験」を行うのは、インシデントを扱いながら、あなたのコンピュータセキュリティ人員、システム管理者、およびマネージャがシミュレートするもので重要です。
Learning to respond efficiently to an incident is important for
numerous reasons. The most important benefit is directly to human
beings--preventing loss of human life. Some computing systems are
life critical systems, systems on which human life depends (e.g.,
by controlling some aspect of life-support in a hospital or
assisting air traffic controllers).
効率的にインシデントに応じることを学ぶのは多数の理由で重要です。 人間の寿命の損失を防いで、直接人間には最も重要な利益があります。 いくつかのコンピューティング・システムが寿命クリティカル・システム(人間の寿命がよる(例えば、病院で生命維持の何らかの局面を制御するか、または管制官を補助することによって)システム)です。
An important but often overlooked benefit is an economic one.
Having both technical and managerial personnel respond to an
incident requires considerable resources, resources which could be
utilized more profitably if an incident did not require their
services. If these personnel are trained to handle an incident
efficiently, less of their time is required to deal with that
incident.
重要な、しかし、しばしば見落とされた利益は経済ものです。 技術的で経営者の両方の人員にインシデントに応じさせるのがかなりのリソース(インシデントが彼らのサービスを必要としないなら、より有益に利用できるリソース)を必要とします。 これらの人員が効率的にインシデントを扱うよう訓練されるなら、彼らの時間の以下が、そのインシデントに対処するのに必要です。
A third benefit is protecting classified, sensitive, or
proprietary information. One of the major dangers of a computer
security incident is that information may be irrecoverable.
Efficient incident handling minimizes this danger. When
classified information is involved, other government regulations
may apply and must be integrated into any plan for incident
handling.
3番目の利益は分類されたか、敏感であるか、独占である情報を保護しています。 コンピュータセキュリティインシデントの主要な危険の1つは情報が回復しがたいかもしれないということです。 効率的な付随している取り扱いはこの危険を最小にします。 機密情報がかかわるとき、他の政府規制は適用するかもしれなくて、付随している取り扱いのためのどんなプランとも統合しなければなりません。
A fourth 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.
4番目の利益は広報に関連します。 コンピュータセキュリティインシデントに関するニュースは、現在の、または、潜在的のクライアントの中で組織の身長にダメージが大きい傾向があります。 効率的な付随している取り扱いは否定的暴露の可能性を最小にします。
A final benefit of efficient incident handling is related to legal
issues. It is possible that in the near future organizations may
be sued because one of their nodes was used to launch a network
効率的な付随している取り扱いの最終的な恩恵は法律問題に関連します。 彼らのノードの1つがネットワークを始めるのに使用されたので近い将来の組織におけるそれが訴えられるのは、可能です。
Site Security Policy Handbook Working Group [Page 62] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[62ページ]RFC1244サイトセキュリティハンドブック1991年7月
attack. In a similar vein, people who develop patches or
workarounds may be sued if the patches or workarounds are
ineffective, resulting in damage to systems, or if the patches or
workarounds themselves damage systems. Knowing about operating
system vulnerabilities and patterns of attacks and then taking
appropriate measures is critical to circumventing possible legal
problems.
攻撃してください。 似たような仕方で、システムへの損傷をもたらして、パッチか回避策が効力がないか、またはパッチか回避策自体がシステムを破損するなら、パッチか回避策を開発する人々は訴えられるかもしれません。攻撃と次に、適宜の処置を取るオペレーティングシステム脆弱性とパターンに関して知っているのは可能な法律問題を回避するのに重要です。
5.1.2 Order of Discussion in this Session Suggests an Order for
a Plan
5.1.2、a PlanのためにこのSession SuggestsのDiscussionについてOrderを注文します。
This chapter is arranged such that a list may be generated from
the Table of Contents to provide a starting point for creating a
policy for handling ongoing incidents. The main points to be
included in a policy for handling incidents are:
本章は、取り扱いのための方針を作成するための出発点に進行中のインシデントを提供するために目次からリストを生成することができるように整っています。 取り扱いインシデントのための方針に含まれるべき要点は以下の通りです。
o Overview (what are the goals and objectives in handling the
incident).
o Evaluation (how serious is the incident).
o Notification (who should be notified about the incident).
o Response (what should the response to the incident be).
o Legal/Investigative (what are the legal and prosecutorial
implications of the incident).
o Documentation Logs (what records should be kept from before,
during, and after the incident).
o 概要(中でインシデントを扱う目標と目的であること)o Evaluation(どれくらい重大であるかは、インシデントである)o Notification(インシデントに関して通知されるべきである)o Response、(インシデントへの応答が何であるべきであるか、)、○Legal/調査、(インシデントの法的で検察官の含意であること) . o Documentation Logs(記録がインシデントの前、およびインシデントとインシデントの後に妨げられるべきである何)。
Each of these points is important in an overall plan for handling
incidents. The remainder of this chapter will detail the issues
involved in each of these topics, and provide some guidance as to
what should be included in a site policy for handling incidents.
それぞれのこれらのポイントは取り扱いインシデントのための全体計画で重要です。 本章の残りは、それぞれのこれらの話題にかかわる問題を詳しく述べて、取り扱いインシデントのためのサイト方針に含まれるべきであることに関して何らかの指導を提供するでしょう。
5.1.3 Possible Goals and Incentives for Efficient Incident
Handling
5.1.3 効率的な付随している取り扱いのための可能な目標と誘因
As in any set of pre-planned procedures, attention must be placed
on a set of goals to be obtained in handling an incident. These
goals will be placed in order of importance depending on the site,
but one such set of goals might be:
どんなセットのあらかじめ計画された手順のようにも、インシデントを扱う際に得るために目標のセットに注意を置かなければなりません。 重要度の順にサイトによって、これらの目標は置かれるでしょうが、そのようなセットの1つの目標は以下の通りです。
Assure integrity of (life) critical systems.
Maintain and restore data.
Maintain and restore service.
Figure out how it happened.
Avoid escalation and further incidents.
Avoid negative publicity.
Find out who did it.
Punish the attackers.
(寿命)クリティカル・システムを保全に保証してください。データを保守して、回復してください。 サービスを維持して、復元してください。 それがどのように起こったか理解してください。 増大と一層のインシデントを避けてください。 マイナスの評判を避けてください。 だれがそれをしたか調べてください。 攻撃者を罰してください。
Site Security Policy Handbook Working Group [Page 63] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[63ページ]RFC1244サイトセキュリティハンドブック1991年7月
It is important to prioritize 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 serve as a starting point for
defining an organization's response:
インシデントが起こる時代のよく前にインシデントの間、取るために動作を最優先させるのは重要です。 時々、インシデントが非常に複雑であるかもしれないので、すぐにそれに応じるためにすべてをするのは不可能です。 プライオリティは不可欠です。 団体によってプライオリティは異なるでしょうが、以下は、プライオリティが組織の応答を定義するための出発点として機能するのを示しました:
o Priority one -- protect human life and people's
safety; human life always has precedence over all
other considerations.
o 優先権1--人間の寿命と人々の安全を保護してください。 人間の寿命には、他のすべての問題の上の先行がいつもあります。
o Priority two -- protect classified and/or sensitive
data (as regulated by your site or by government
regulations).
o 優先権two--分類されたそして/または、機密のデータを保護してください(あなたのサイトか政府規制によって規制されるように)。
o Priority three -- protect other data, including
proprietary, scientific, managerial and other data,
because loss of data is costly in terms of resources.
o 優先権three--他のデータを保護してください、独占で、科学的で、経営者の、そして、他のデータを含んでいて、データの喪失がリソースで高価であるので。
o 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.
o 優先権four--システム(例えば、損失やシステムファイルの変更、ディスクドライブへの損傷など)への損傷を防いでください。 システムへの損傷は高価な休止時間と回復をもたらすことができます。
o Priority five -- minimize disruption of computing
resources; it is better in many cases to shut a system
down or disconnect from a network than to risk damage
to data or systems.
o 優先権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; the
loss or compromise of data (especially classified data), however,
is usually not an acceptable outcome under any circumstances.
プライオリティを定義するための重要な含意は人間の寿命と国家安全保障問題がいったん扱われると、一般に、データを保存するのがシステムソフトとハードウェアより重要であるということです。 インシデントの間、どんな損害や損失も持っているのが望ましくないのですが、システムを取り替えることができます。 しかしながら、通常、データ(データを特に分類する)の損失か感染がどうあっても許容できる結果ではありません。
Part of handling an incident is being prepared to respond before
the incident occurs. This includes establishing a suitable level
of protections so that if the incident becomes severe, the damage
which can occur is limited. Protection includes preparing
incident handling guidelines or a contingency response plan for
your organization or site. Written plans eliminate much of the
ambiguity which occurs during an incident, and will lead to a more
appropriate and thorough set of responses. Second, part of
protection is preparing a method of notification so you will know
who to call and how to contact them. For example, every member of
インシデントを扱う一部がインシデントが起こる前に応じるように準備されています。 これが、適当なレベルの保護を確立するのを含んでいるので、インシデントが厳しくなるなら、発生できる損害は限られます。 保護は、あなたの組織かサイトのために付随している取り扱いガイドラインか偶然性応答プランを準備するのを含んでいます。 企画書は、インシデントの間に起こるあいまいさの多くを排除して、より適切で徹底的な応答につながるでしょう。 2番目に、保護の一部が通知のメソッドを準備しているので、あなたはだれを呼ぶか、そして、どのようにそれらに連絡するかを知るでしょう。 例えば、すべてのメンバー
Site Security Policy Handbook Working Group [Page 64] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[64ページ]RFC1244サイトセキュリティハンドブック1991年7月
the Department of Energy's CIAC Team carries a card with every
other team member's work and home phone numbers, as well as pager
numbers. Third, your organization or site should establish backup
procedures for every machine and system. Having backups
eliminates much of the threat of even a severe incident, since
backups preclude serious data loss. Fourth, you should set up
secure systems. This involves eliminating vulnerabilities,
establishing an effective password policy, and other procedures,
all of which will be explained later in this document. Finally,
conducting training activities is part of protection. It is
important, for example, to conduct "dry runs," in which your
computer security personnel, system administrators, and managers
simulate handling an incident.
エネルギー省のCIAC Teamはすべての他のチームメンバーの仕事と自宅電話番号でカードを運びます、ポケットベル番号と同様に。 3番目に、あなたの組織かサイトがあらゆるマシンとシステムのためにバックアップ手順を確立するべきです。 バックアップがあると、バックアップが重大なデータの損失を排除するので、厳しいインシデントさえの脅威の多くが排除されます。 4番目に、あなたは安全なシステムをセットアップするべきです。これは、脆弱性を排除することを伴います、効果的なパスワード方針、および他の手順(それのすべてが後で本書では説明される)を確立して。 最終的に、トレーニング活動を行うのは、保護の一部です。 例えば、「模擬試験」を行うのは、インシデントを扱いながら、あなたのコンピュータセキュリティ人員、システム管理者、およびマネージャがシミュレートするもので重要です。
5.1.4 Local Policies and Regulations Providing Guidance
5.1.4 ローカルの方針と指導を提供する規則
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.
セキュリティインシデントに応じるためのどんなプランもローカルの方針と規則によって誘導されるべきです。 機密事項に対処する政府と個人的なサイトが続かなければならないという特定の規則を持っています。
The policies your site makes about how it responds to incidents
(as discussed in sections 2.4 and 2.5) 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.
あなたのサイトがどうインシデントに応じるかに関して(セクション2.4と2.5で議論するように)作る方針はあなたの応答を形成するでしょう。 例えば、彼らが引っかかるならあなたのサイトが、侵入者にとって行動を起こすのを計画していないなら、それはモニターするメカニズムを作成する小さい意味と跡に侵入者になるかもしれません。 他の組織には、あなたのプランに影響する方針があるかもしれません。 電話会社はしばしば電話跡の情報を警察機関だけに発表します。
Section 5.5 also notes that if any legal action is planned, there
are specific guidelines that must be followed to make sure that
any information collected can be used as evidence.
また、セクション5.5は、何か訴訟が計画されているなら、証拠として集められたどんな情報も使用できるのを確実にするために従わなければならない特別な基準があることに注意します。
5.2 Evaluation
5.2 評価
5.2.1 Is It Real?
5.2.1 それは本当ですか?
This stage involves determining the exact problem. Of course
many, if not most, signs often associated with virus infections,
system intrusions, etc., are simply anomalies such as hardware
failures. 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. For example, widely available
software packages can greatly assist someone who thinks there may
be a virus in a Macintosh computer. Audit information is also
extremely useful, especially in determining whether there is a
network attack. It is extremely important to obtain a system
このステージは、正確な問題を決定することを伴います。 もちろん、多くです、まして、大部分(しばしばウイルス感染力、システム侵入などに関連しているサイン)は単にハードウェアの故障などの例外です。 インシデントが本当にあるかどうか特定するのを助けるために、通常、どんな利用可能であるかもしれない検出ソフトウェアも入手して、使用するのは役立っています。 例えば、広く利用可能なソフトウェアパッケージはウイルスがマッキントッシュのコンピュータにあるかもしれないと考えるだれかを大いに補助できます。 また、ネットワーク攻撃があるかどうか特に決定する際に監査情報も非常に役に立ちます。 システムを入手するのは非常に重要です。
Site Security Policy Handbook Working Group [Page 65] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[65ページ]RFC1244サイトセキュリティハンドブック1991年7月
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 do more good in identifying the problem and
any source of attack than most other actions which can be taken at
this stage. 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 which
deserve special attention:
特別な注意に値するインシデントのある指摘か「兆候」があります:
o System crashes.
o New user accounts (e.g., the account RUMPLESTILTSKIN
has unexplainedly been created), or high activity on
an account that has had virtually no activity for
months.
o New files (usually with novel or strange file names,
such as data.xx or k).
o Accounting discrepancies (e.g., in a UNIX system you
might notice that the accounting file called
/usr/admin/lastlog has shrunk, something that should
make you very suspicious that there may be an
intruder).
o Changes in file lengths or dates (e.g., a user should
be suspicious if he/she observes that the .EXE files in
an MS DOS computer have unexplainedly grown
by over 1800 bytes).
o Attempts to write to system (e.g., a system manager
notices that a privileged user in a VMS system is
attempting to alter RIGHTSLIST.DAT).
o Data modification or deletion (e.g., files start to
disappear).
o Denial of service (e.g., a system manager and all
other users become locked out of a UNIX system, which
has been changed to single user mode).
o Unexplained, poor system performance (e.g., system
response time becomes unusually slow).
o Anomalies (e.g., "GOTCHA" is displayed on a display
terminal or there are frequent unexplained "beeps").
o Suspicious probes (e.g., there are numerous
unsuccessful login attempts from another node).
o Suspicious browsing (e.g., someone becomes a root user
on a UNIX system and accesses file after file in one
user's account, then another's).
o システムクラッシュo Newユーザアカウント(例えば、アカウントRUMPLESTILTSKINはunexplainedlyに作成された)、または何カ月もo Newファイル(通常、data.xxかkなどの目新しいか奇妙なファイル名がある)o Accounting食い違い(例えば、UNIXシステムでは、あなたは、/usr/admin/lastlogと呼ばれる課金ファイルが縮まったのに気付くかもしれません、あなたを侵入者がいるかもしれないのが非常に疑わしげにするべきである何か)のための実際には活動を全く持っていないアカウントにおける高い活動; ファイルの長さにおけるo Changesかシステム(例えば、システム・マネージャは、VMSシステムの特権ユーザが、RIGHTSLIST.DATを変更するのを試みているのに気付く)に書く日付(その人が、MS-DOSコンピュータの.EXEファイルがunexplainedlyに1800バイト以上成長したのを観測するなら、例えば、ユーザは不審に思っているべきである)o Attempts; o Data変更か削除(例えば、ファイルは見えなくなり始める)サービス(例えば、システム・マネージャと他のすべてのユーザがシングルユーザーモードに変わったUNIXシステムからロックされるようになる)o Unexplained、貧しいsysteのo Denialm性能(例えばシステム応答時間は異常に遅くなる)○Anomalies(ディスプレー装置の上に例えば、"GOTCHA"を表示するか、または頻繁な説明されなかった「ビープ音」がある)o疑わしげな徹底的調査(例えば、別のノードからの頻繁な失敗のログイン試みがある)o疑わしげなブラウジング(例えば、だれかが、UNIXシステムの上で根のユーザになって、あるユーザのアカウントにおける後ファイルのファイルにアクセスして、その時はほかのもののものです)。
None of these indications is absolute "proof" that an incident is
これらの指摘のいずれはインシデントがそうであるという絶対「証拠」ではありません。
Site Security Policy Handbook Working Group [Page 66] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[66ページ]RFC1244サイトセキュリティハンドブック1991年7月
occurring, nor are all of these indications normally observed when
an incident occurs. If you observe any of these indications,
however, it is important to suspect that an incident might be
occurring, and act accordingly. There is no formula for
determining with 100 percent accuracy that an incident is
occurring (possible exception: when a virus detection package
indicates that your machine has the nVIR virus and you confirm
this by examining contents of the nVIR resource in your Macintosh
computer, you can be very certain that your machine is infected).
It is best at this point to collaborate with other technical and
computer security personnel to make a decision as a group about
whether an incident is occurring.
起こって、通常、これらの指摘のすべてが、インシデントがいつ起こるかを観測したということです。 しかしながら、あなたがこれらの指摘のどれかを観測するなら、インシデントが起こっているかもしれないと疑って、善処するのは重要です。 100パーセントの精度でインシデントが起こっていることを(可能な例外: ウイルス検出パッケージが、いつあなたのマシンがnVIRウイルスにかかっているのを示すか、そして、あなたはあなたのマッキントッシュのコンピュータでnVIRリソースのコンテンツを調べることによって、これを確認して、あなたのマシンが感染しているのを非常に確信している場合があります)決定するための公式が全くありません。 ここに、インシデントが起こるかどうかに関するグループとして決定するために他の技術的、そして、コンピュータセキュリティ人員と協力するのは最も良いです。
5.2.2 Scope
5.2.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. In addition, the impact of an incident will
determine its priority in allocating resources to deal with the
event. Without an indication of the scope and impact of the
event, it is difficult to determine a correct response.
インシデントの識別と共に、問題の範囲と影響の評価はそうですか? 正しくインシデントの境界を特定するのは、事実上、それに対処するために重要です。 さらに、インシデントの影響は、リソースを割り当てることにおける優先権がイベントに対処することを決定するでしょう。 イベントの範囲と影響のしるしがなければ、正しい応答を決定するのは難しいです。
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 are:
範囲と影響を特定するために、1セットの評価基準は定義されるべきです(サイトと接続の手があいているタイプに、適切です)。 問題のいくつかは以下の通りです。
o Is this a multi-site incident?
o Are many computers at your site effected by this
incident?
o Is sensitive information involved?
o What is the entry point of the incident (network,
phone line, local terminal, etc.)?
o Is the press involved?
o What is the potential damage of the incident?
o What is the estimated time to close out the incident?
o What resources could be required
to handle the incident?
o これはマルチサイトインシデントですか?oこのインシデントで作用するあなたのサイトのAre多くのコンピュータ--機密情報がかかわったo Is--o Whatはインシデント(ネットワーク、電話回線、ローカル・ターミナルなど)のエントリー・ポイントです--プレスがかかわったo Is--o Whatはインシデントの可能性のあるダメージです--o Whatはインシデントを見切り売りするおよそ時間です--インシデントを扱うためにo Whatリソースは必要とすることができました--
5.3 Possible Types of Notification
5.3 可能なタイプに関する通知
When you have confirmed that an incident is occurring, the appropriate personnel must be notified. Who and how this notification is achieved is very important in keeping the event under control both from a technical and emotional standpoint.
あなたが、インシデントが起こっていると確認したとき、適切な要員に通知しなければなりません。 だれ、そして、この通知はどう達成されているのが、技術的で感情的な見地から両方の、イベントを抑える非常に重要なコネであるということであるか。
Site Security Policy Handbook Working Group [Page 67] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[67ページ]RFC1244サイトセキュリティハンドブック1991年7月
5.3.1 Explicit
5.3.1 明白です。
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, or fax) provides
information about the incident that is clear, concise, and fully
qualified. When you are notifying others that will help you to
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 section 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 other information that would help
them resolve a part of the incident.
まず、地方かオフサイト人員へのどんな通知も明白でなければなりません。 これは、どんな声明(電子メールメッセージ、電話、またはファックスであることにかかわらず)も明確で、簡潔で、完全に適切なインシデントの情報を提供するのを必要とします。 あなたがあなたがイベントを扱うのを助ける他のものに通知しているとき、「煙幕」は、取り組みを分割するだけであり、混乱を作成するでしょう。 分業が示されるなら、他の取り組みで達成されていることに関する各セクションに情報を供給するのは役立っています。 これで、問題の部分に取り組んでいる人々は、取り組みの複製を抑えるだけではなく、どこで彼らがインシデントの一部を決議するのを助ける他の情報を得るかを知ることができるでしょう。
5.3.2 Factual
5.3.2 事実上です。
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. This is especially true when the press is
involved. When an incident severe enough to gain press attention
is ongoing, it is likely that any false information you provide
will not be substantiated by other sources. This will reflect
badly on the site and may create enough ill-will between the site
and the press to damage the site's public relations.
別の重要な考慮すべき事柄はインシデントについて話し合うとき、事実上ことです。 誤ったか不完全な情報を提供することによってインシデントの局面を隠すのを試みるのが、うまくいっている解決をインシデントに防ぐだけではありませんが、状況を悪化させさえするかもしれません。 プレスがかかわるとき、これは特に本当です。 プレス注目を集めるほど厳しいインシデントが進行中であるときに、あなたが提供する少しの偽情報も他のソースによって実体化されそうにないでしょう。 これは、ひどくサイトをよく考えて、サイトとプレスの間のサイトの広報を破損できるくらいの悪意を作成するかもしれません。
5.3.3 Choice of Language
5.3.3 言語の選択
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 expectations of damage and negative outcomes of the incident.
It is important to remain calm both in written and spoken
notifications.
インシデントに関して人々に通知するとき使用される言語の選択は情報が受信されている方法で効果を持つことができます。 感情的であるか扇動的の用語を使用すると、あなたは損害への期待とインシデントの否定的結果を提起します。 ともに書かれて話された通知で穏やかなままであることは重要です。
Another issue associated with the choice of language is the
notification to non-technical or off-site personnel. It is
important to accurately describe the incident without undue alarm
or confusing messages. 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 notifications cannot be underestimated and may
make the difference between handling the incident properly and
escalating to some higher level of damage.
言語の選択に関連している別の問題は非技術系かオフサイト人員への通知書です。 過度のアラームも紛らわしいメッセージなしで事件について正確に説明するのは重要です。 非技術系の聴衆に事件を説明するのが、より難しいのですが、それはしばしばより重要です。 非技術系の記述が経営上層部、プレス、または法施行連絡に必要であるかもしれません。 これらの通知の重要性は、過小評価できないで、適切に事件を扱って、何らかのより高いレベルの損害に徐々に拡大するところの違いを作るかもしれません。
Site Security Policy Handbook Working Group [Page 68] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[68ページ]RFC1244サイトセキュリティハンドブック1991年7月
5.3.4 Notification of Individuals
5.3.4 個人の通知
o Point of Contact (POC) people (Technical, Administrative,
Response Teams, Investigative, Legal, Vendors, Service
providers), and which POCs are visible to whom.
o Wider community (users).
o Other sites that might be affected.
o だれにとって、どのPOCsが目に見えるか。Contact(POC)の人々のポイント、(技術的である、Administrative、Response Teams、Investigative、Legal、Vendors、Serviceプロバイダー). o Wider共同体(ユーザ)影響を受けるかもしれないo Otherサイト。
Finally, there is the question of who should be notified during
and after the incident. There are several classes of individuals
that need to be considered for notification. These are the
technical personnel, administration, appropriate response teams
(such as CERT or CIAC), law enforcement, vendors, and other
service providers. These issues are important for the central
point of contact, since that is the person responsible for the
actual notification of others (see section 5.3.6 for further
information). A list of people in each of these categories is an
important time saver for the POC during an incident. It is much
more difficult to find an appropriate person during an incident
when many urgent events are ongoing.
最終的に、だれが事件と事件の後に通知されるべきであるかに関する質問があります。 通知のために考えられる必要がある数人のクラスの個人がいます。 これらは、技術者と、管理と、適切な応答チーム(CERTかCIACなどの)と、法施行と、業者と、他のサービスプロバイダーです。 中央の連絡先に、これらの問題は重要です、それが他のものの実際の通知に責任がある人(詳細に関してセクション5.3.6を見る)であるので。 それぞれのこれらのカテゴリにおける人々のリストは事件の間のPOCのための重要な時間貯蓄家です。 多くの緊急の出来事が進行中であることの事件の間、適切な人を見つけるのははるかに難しいです。
In addition to the people responsible for handling part of the
incident, there may be other sites affected by the incident (or
perhaps simply at risk from the incident). A wider community of
users may also benefit from knowledge of the incident. Often, a
report of the incident once it is closed out is appropriate for
publication to the wider user community.
事件の取り扱い部分に責任がある人々に加えて、事件(または危険な状態に単に恐らく事件から)で影響を受ける他のサイトがあるかもしれません。 また、ユーザの、より広い共同体は事件に関する知識の利益を得るかもしれません。 いったんそれを見切り売りすると、公表に、しばしば、事件のレポートは、より広いユーザーコミュニティに適切です。
5.3.5 Public Relations - Press Releases
5.3.5 広報--プレスリリース
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
広報課が利用可能でないなら、慎重にプレスに発表された情報を考えなければなりません。 情報が機密であるなら、最小量だけか概観情報をプレスに提供するのは有利であるかもしれません。 プレスに提供されたどんな情報もそうになるのは、かなり可能です。
Site Security Policy Handbook Working Group [Page 69] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[69ページ]RFC1244サイトセキュリティハンドブック1991年7月
quickly reviewed by the perpetrator of the incident. As a
contrast to this consideration, it was discussed above 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:
あらかじめどんなレベルの詳細をプレスに明らかにするかを決定するのが難しいのですが、覚えておくいくつかのガイドラインは以下の通りです。
o Keep the technical level of detail low. Detailed
information about the incident may provide enough
information for copy-cat events or even damage the
site's ability to prosecute once the event is over.
o 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.
o 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.
o Try not to be forced into a press interview before you are
prepared. The popular press is famous for the "2am"
interview, where the hope is to catch the interviewee off
guard and obtain information otherwise not available.
o 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.
o 詳細の技術水準を低く保ってください。 . o Keepの上に出来事がいったんあると、事件の詳細な情報は、模倣者出来事のための情報を十分に提供するか、または起訴するサイトの能力を破損さえするかもしれません。記者声明からの思惑。 だれが事件を引き起こすかに関する思惑か動機が、間違っているのが非常にありそうであり、事件の炎症を起こしている視点を引き起こすかもしれません。その証拠を保証する法施行専門家がいるo Workは保護されます。 起訴がかかわるなら、集められた証拠がプレスに明かされないと安心してください。あなたが用意ができている前にプレスに強制されるべきでないo Tryはインタビューします。 ポピュラーなプレスは「午前2時」インタビューで有名です、会見相手が油断しているのを捕らえて、そうでなければ、利用可能でない情報を得るところで望みがことである。o Doは、出来事の取り扱いがプレス注意で損なわれるのを許容しません。 いつも事件のうまくいっている閉鎖が第一に重要であることを覚えていてください。
5.3.6 Who Needs to Get Involved?
5.3.6 だれが、かかわる必要がありますか?
There now exists a number of incident response teams (IRTs) such
as the CERT and the CIAC. (See sections 3.9.7.3.1 and 3.9.7.3.4.)
Teams exists for many major government agencies and large
corporations. If such a team is available for your site, the
notification of this team should be of primary importance 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
to a single site, it is possible that the information available
through a response team could help in closing out the incident.
CERTやCIACなどの多くのインシデントレスポンスチーム(IRTs)が現在、存在します。 そして、(セクション3.9.7を見てください、.3、.1、3.9 .7 .3 .4) チームは多くの主要な政府機関と大企業のために存在します。 そのようなチームがあなたのサイトに利用可能であるなら、このチームの通知は事件の初期段階の間、第一に重要であるべきです。 これらのチームはさまざまなサイトと、より大きい実体の上のコンピュータセキュリティインシデントを調整するのに責任があります。 事件によってただ一つのサイトに含まれると信じられても、最後になりましたが、応答チームを通して利用可能な情報が事件を助けるかもしれないのは、可能です。
In setting up a site policy for incident handling, it may be
desirable to create an incident handling team (IHT), 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 IHTs.
Once an incident is under way, it is difficult to open a trusted
付随している取り扱いのためのサイト方針をセットアップするのにおいて、既に存在するそれらのチームのようにチーム(IHT)を扱うサイト(または、組織)において取り扱いコンピュータセキュリティインシデントに原因となるようになる事件を引き起こすのは望ましいかもしれません。 そのようなチームが創設されるなら、通信回線がこのチームと他のIHTsの間で開けられるのは、不可欠です。 事件がいったん進行中になると、信じられたaを開くのは難しいです。
Site Security Policy Handbook Working Group [Page 70] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[70ページ]RFC1244サイトセキュリティハンドブック1991年7月
dialogue between other IHTs if none has existed before.
他のIHTsの間の対話はなにもであるなら以前、存在したことがあります。
5.4 Response
5.4 応答
A major topic still untouched here is how to actually respond to an event. The response to an event will fall into the general categories of containment, eradication, recovery, and follow-up.
ここでまだ触れない主要な話題は実際にどのように出来事に応じるかということです。 出来事への応答は封じ込め、根絶、回復、およびフォローアップの一般的なカテゴリになるでしょう。
Containment
封じ込め
The purpose of containment is to limit the extent of an attack.
For example, it is important to limit the spread of a worm attack
on a network as quickly as possible. An essential part of
containment is decision making (i.e., determining whether to shut
a system down, to disconnect from a network, to monitor system or
network activity, to set traps, to disable functions such as
remote file transfer on a UNIX system, etc.). Sometimes this
decision is trivial; shut the system down if the system is
classified or sensitive, or if proprietary information is at risk!
In other cases, it is worthwhile to risk having some damage to the
system if keeping the system up might enable you to identify an
intruder.
封じ込めの目的は攻撃の範囲を制限することです。 例えば、ネットワークでできるだけはやくワーム攻撃の普及を制限するのは重要です。 封じ込めの不可欠の部分は意志決定(すなわち、ネットワークからモニタシステムまで連絡を断つためにシステムダウンを閉じるか、またはUNIXシステムなどにおける遠隔ファイル転送などの機能を無効にするためにセット罠に活動をネットワークでつなぐかを決定する)です。 時々、この決定は些細です。 システムが分類されているか、敏感である、または知的財産情報が危険であるなら、システムダウンを閉じてください! 他の場合では、侵入者を特定するシステムを手入れするならいくらかの損傷をシステムに持っているとあなたが可能にされるかもしれないというリスクに価値があります。
The third stage, containment, 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.
Finally, notification of cognizant authorities should occur during
this stage.
3番目のステージ(封じ込め)は、予定された手順を行うことを伴うはずです。 あなたの組織かサイトが、例えば、事件に対処する際に許容できる危険を定義するべきであり、それに従って、特定の動作と戦略を定めるべきです。 最終的に、認識力がある当局の通知はこのステージの間、現れるべきです。
Eradication
根絶
Once an incident has been detected, it is important to first think
about containing the incident. Once the incident has been
contained, it is now time to eradicate the cause. Software may be
available to help you in this effort. For example, eradication
software is available to eliminate most viruses which infect small
systems. If any bogus files have been created, it is time to
delete them at this point. In the case of virus infections, it is
important to clean and reformat any disks containing infected
files. Finally, ensure that all backups are clean. Many systems
infected with viruses become periodically reinfected simply
because people do not systematically eradicate the virus from
backups.
事件がいったん検出されると、最初に事件を含むと考えるのは重要です。 事件がいったん含まれると、現在もう原因を根絶するべき時間です。 ソフトウェアは、この努力であなたを助けるために利用可能であるかもしれません。 例えば、根絶ソフトウェアは. どんなにせのファイルも持っている小さいシステムIfを感染させるほとんどのウイルスを排除するために利用可能であるのが、作成されています、ここにもうそれらを削除するべき時間であるということであるということです。 ウイルス感染力の場合では、掃除するのが重要であり、どんなディスク含有も感染させた再フォーマットはファイルされます。 最終的に、すべてのバックアップが確実に清潔になるようにしてください。 ウイルスに感染している多くのシステムが単に人々が系統的にバックアップからのウイルスを根絶しないので定期的に再感染するようになります。
Recovery
回復
Once the cause of an incident has been eradicated, the recovery
一度、事件の原因が根絶されたことがある、回復
Site Security Policy Handbook Working Group [Page 71] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[71ページ]RFC1244サイトセキュリティハンドブック1991年7月
phase defines the next stage of action. The goal of recovery is
to return the system to normal. In the case of a network-based
attack, it is important to install patches for any operating
system vulnerability which was exploited.
フェーズは動作の次のステージを定義します。 回復の目標はシステムを標準に返すことです。 ネットワークベースの攻撃の場合では、利用されたどんなオペレーティングシステム脆弱性のためのパッチもインストールするのは重要です。
Follow-up
フォローアップ
One of the most important stages of responding to incidents is
also the most often omitted---the follow-up stage. This stage is
important because it helps those involved in handling the incident
develop a set of "lessons learned" (see section 6.3) to improve
future performance in such situations. This stage also provides
information which justifies an organization's computer security
effort to management, and yields information which may be
essential in legal proceedings.
また、事件に応じる最も重要なステージの1つは最もしばしば省略されます。---追跡しているステージ。 事件を扱うことにおける関係者がそのような状況における将来の性能を向上させるために「レッスンは学んだ」(セクション6.3を見ます)セットを発展させるのを助けるので、このステージは重要です。 このステージは、また、組織のコンピュータセキュリティの努力を管理に正当化する情報を提供して、合法的な処置で不可欠であるかもしれない情報をもたらします。
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? A follow-up report is valuable
because it provides a reference to be used in case of other
similar incidents. Creating a formal chronology of events
(including time stamps) is also important for legal reasons.
Similarly, it is also important to as quickly obtain a monetary
estimate of the amount of damage the incident caused in terms of
any loss of software and files, 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 by the FBI, the U.S. Attorney General's
Office, etc..
追跡しているステージの最も重要な要素は死後分析を実行しています。 まさに何が、起こって、どんな時にそうしましたか? 事件にかかわるスタッフはどれくらいよく働きましたか? スタッフはすぐにどういう情報を必要としたか、そして、彼らはできるだけ早く、どうしたらその情報を得ることができましたか? スタッフは次回、異なって何をするでしょうか? 他の同様の事件の場合に使用されるために参照を提供するので、追跡調査報告は貴重です。 また、出来事(タイムスタンプを含んでいる)の正式な年表を作成するのも法律上の理由によって重要です。 ファイル(変えられたファイルを復旧するハードウェア損傷、および労働力コスト)は、また、同様に、同じくらいすぐに事件がソフトウェアのどんな損失でも引き起こした損害額の通貨の見積りを得るのも重要であり、影響を受けるシステムなどを再構成します。 この見積りはFBI、米国の検事総長のオフィスなどでその後の起訴活動の基礎になるかもしれません。
5.4.1 What Will You Do?
5.4.1 あなたは何をするでしょうか?
o Restore control.
o Relation to policy.
o Which level of service is needed?
o Monitor activity.
o Constrain or shut down system.
o コントロールを復元してください。方針サービスのo Whichレベルへのo Relationが必要です--o Monitor活動o Constrainか閉鎖システム。
5.4.2 Consider Designating a "Single Point of Contact"
5.4.2 「単一の連絡先」を指定すると考えてください。
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 "points of
contact" (POC) that are not pulling their efforts together. This
will only add to the confusion of the event, and will probably
事件が進行中とき、主要な問題は、だれがプレーヤーの多数の活動を調整するのを担当しているかを決めています。 することができる主要な誤りは彼らの努力を引き合わせていない多くの「連絡先」(POC)を持つことです。 これは、出来事の混乱の一助となるだけであり、たぶん一助となるでしょう。
Site Security Policy Handbook Working Group [Page 72] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[72ページ]RFC1244サイトセキュリティハンドブック1991年7月
lead to additional confusion and wasted or ineffective effort.
追加混乱と無駄であるか効果がない努力に通じてください。
The single point of contact may or may not be the person "in
charge" of the incident. There are two distinct rolls to fill
when deciding who shall be the point of contact and the person in
charge of the incident. The person in charge will make decisions
as to the interpretation of policy applied to the event. The
responsibility for the handling of the event falls onto this
person. In contrast, the point of contact must coordinate the
effort of all the parties involved with handling the event.
単一の連絡先は事件で「担当している」人であるかもしれません。 だれが事件を担当して連絡先と人になるかを決めるときいっぱいにする2個の異なったロールがあります。 担当している人は出来事に適用された方針の解釈に関して決定をするでしょう。 出来事の取り扱いへの責任はこの人に落下します。 対照的に、連絡先は出来事を扱うのにかかわるすべてのパーティーの努力を調整しなければなりません。
The point of contact must be a person with the technical expertise
to successfully coordinate the effort of the system managers and
users involved in monitoring and reacting to the attack. Often
the management structure of a site is such that the administrator
of a set of resources is not a technically competent person with
regard to handling the details of the operations of the computers,
but is ultimately responsible for the use of these resources.
連絡先は、首尾よく攻撃にモニターして、反応するのにかかわるシステム・マネージャとユーザの努力を調整するためには技術的専門知識をもっている人でなければなりません。 しばしば、サイトの経営組織がそのようなものであるので、1セットのリソースの管理者は、コンピュータの操作の詳細を扱うことに関する技術的に有能な人ではありませんが、結局、これらのリソースの使用に責任があります。
Another important function of the POC is to maintain contact with
law enforcement and other external agencies (such as the CIA, DoD,
U.S. Army, or others) to assure that multi-agency involvement
occurs.
POCの別の重要な機能は複数機関かかわり合いが起こることを保証するために、法施行との接触と他の外部の政府機関(CIA、DoD、米軍、または他のものなどの)を維持することです。
Finally, if legal action in the form of prosecution is involved,
the POC may be able to speak for the site in court. The
alternative is to have multiple witnesses that will be hard to
coordinate in a legal sense, and will weaken any case against the
attackers. A single POC may also be the single person in charge
of evidence collected, which will keep the number of people
accounting for evidence to a minimum. 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. The
section below (Legal/Investigative) will provide more details for
consideration on this topic.
最終的に、起訴の形における訴訟がかかわるなら、POCは法廷のサイトを代弁できるかもしれません。 代替手段は法的な意味で調整しにくくて、攻撃者に対してどんなケースも弱める複数の目撃者がいることです。 また、独身のPOCはを担当して独身の人であるかもしれません。証拠は証拠のための人々会計の数を最小限に保つでしょう。 原則として、親指では、潜在的証拠に触れる人々が多ければ多いほど、法廷で承認しがたくなる可能性は、より大きいです。 下(法的であるか調査の)のセクションはこの話題に関して考慮のためのその他の詳細を提供するでしょう。
5.5 Legal/Investigative
5.5、法的であるか調査
5.5.1 Establishing Contacts with Investigative Agencies
5.5.1 調査の政府機関と共に接触すること。
It is important to establish contacts with personnel from
investigative agencies such as the FBI and Secret Service as soon
as possible, for several reasons. Local law enforcement and local
security offices or campus police organizations should also be
informed when appropriate. A primary reason is that once a major
attack is in progress, there is little time to call various
personnel in these agencies to determine exactly who the correct
point of contact is. Another reason is that it is important to
できるだけ早く人員と共にFBIや財務省検察局などの調査の政府機関から接触するのは重要です、いくつかの理由で。 また、適切であるときに、地方の法施行と地方の警察施設かキャンパスポリス組織も知識があるべきです。 第一の理由は大規模な攻撃がいったん進行していると、正しい連絡先がちょうどだれであるかを決定するためにこれらの政府機関で様々な人員に電話をする時間がほとんどないということです。 それが重要である別の理由はあります。
Site Security Policy Handbook Working Group [Page 73] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[73ページ]RFC1244サイトセキュリティハンドブック1991年7月
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 a court of
law. If you don't know in advance how to gather admissible
evidence, your efforts to collect evidence during an incident are
likely to be of no value to the investigative agency with which
you deal. 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 will make
responding to an incident go considerably more smoothly.
良い仕事上のお付き合いを伸ばして、これらの政府機関の働く手順によると、ある方法でこれらの政府機関と協力してください。 あらかじめ、働く手順を知って、あなたの連絡先への期待はこの方向への大きいステップです。 例えば、裁判所で容認できる証拠を集めるのは重要です。 あなたがあらかじめ法廷が採用する証拠を集める方法を知らないなら、調査の政府機関には事件の間に証拠固めるためのあなたの努力があなたが取扱うものをもって価値が全くありそうにはありません。 できるだけ早く接触する最終的な理由はどんな与えられた事件でも管轄を仮定する特定の政府機関を知るのが不可能であるということです。 事件に応じる接触と早く正規のルートを見つけるとする作成はかなりスムーズに行きます。
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
残念ながら、まだ調査の努力を支持するのにセキュリティインシデントにかかわった組織かそれともだれがかかわるかもしれないかに関する負債か責任に関するどんな明確な先例もありません。 捜査官は、しばしば組織が跡を助けて、侵入者をモニターするよう奨励するでしょう--本当に、大部分
Site Security Policy Handbook Working Group [Page 74] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[74ページ]RFC1244サイトセキュリティハンドブック1991年7月
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 lots of effort.
捜査官は組織からの大規模な支持のない押しつけがかかわったコンピュータを追求できません。 しかしながら、捜査官が責任クレームから保護を提供できないで、これらの種類の努力は、何カ月もだらだらと続いて、多くの努力を取るかもしれません。
On the other side, 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 anyone.
反対側の上では、組織の法的な協議会は、極端な警告を教えて、追跡活動が止められるのを示すかもしれません、そして、侵入者はシステムから閉じました。 これによって、捜査官は、本来責任から保護を前提としないで、だれをも特定できないかもしれません。
The balance between supporting investigative activity and limiting
liability is tricky; you'll need to consider the advice of your
council and the damage the intruder is causing (if any) in making
your decision about what to do during any particular incident.
調査の活動を支持して、責任を限定することの間のバランスは扱いにくいです。 あなたは、どんな特定の事件の間にもするべきことに関するあなたの決定をする際にあなたの協議会のアドバイスと侵入者がもたらしている(もしあれば)損害を考える必要があるでしょう。
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.
最終的に、あなたの弁護士は事件に応じるためのあなたのサイトの書かれた手順を評価するべきです。 あなたが実際にこれらの手順を行う前に法的な見解から「健康証明書」を得るのは不可欠です。
5.5.2 Formal and Informal Legal Procedures
5.5.2 正式で非公式の法的手続き
One of the most important considerations in dealing with
investigative agencies is verifying 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 information about incidents,
allowed unauthorized people into their systems, etc., because a
caller has masqueraded as an FBI or Secret Service agent. A
similar consideration is using a secure means of communication.
Because many network attackers can easily reroute 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 (e.g., the phones normally used in the business world)
are also frequent targets for tapping by network intruders, so be
careful!
調査の政府機関と取り引きするのにおいて最も重要な問題のひとりは、電話をする照会する人が問題の政府機関からの正統の代表であることを確かめています。 残念ながら、多くのよく意図を持った人々が事件に関する機密情報を知らずに漏らしました、と権限のない人々は彼らのシステムなどに許しました、訪問者がFBIかシークレットサービス捜査員のふりをしたので。 同様の考慮はコミュニケーションの安全な手段を使用しています。 多くのネットワーク攻撃者が容易に電子メールを別ルートで送ることができるので、他の政府機関(手元の事件に対処する他のものと同様に)とコミュニケートするのに電子メールを使用するのを避けてください。 また、非安全にされた電話回線(例えば通常、企業の動きを見ると使用される電話)がネットワークで侵入者を叩くための頻繁な目標であるので、注意してください!
Site Security Policy Handbook Working Group [Page 75] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[75ページ]RFC1244サイトセキュリティハンドブック1991年7月
There is no established set of rules for responding to an incident
when the U.S. Federal Government becomes involved. Except by
court order, no agency can force you to monitor, to disconnect
from the network, to avoid telephone contact with the suspected
attackers, etc.. As discussed in section 5.5.1, you should
consult the matter with your legal counsel, especially before
taking an action that your organization has never taken. The
particular agency involved may ask you to leave an attacked
machine on and to monitor activity on this machine, for example.
Your complying with this request will ensure continued cooperation
of the agency--usually the best route towards finding the source
of the network attacks and, ultimately, terminating these attacks.
Additionally, you may need some information or a favor from the
agency involved in the incident. You are likely to get what you
need only if you have been cooperative. Of particular importance
is avoiding unnecessary or unauthorized disclosure of information
about the incident, including any information furnished by the
agency involved. The trust between your site and the agency
hinges upon your ability to avoid compromising the case the agency
will build; keeping "tight lipped" is imperative.
米国連邦政府がかかわるようになると事件に応じるための規則のどんな設立されたセットもありません。 モニターして、ネットワークから外して、避ける注文、どんな政府機関もあなたを強制できない法廷を除いて、疑われた攻撃者との接触などに電話をしてください。 セクション5.5.1で議論するように、あなたはあなたの弁護士の問題に相談するべきです、あなたの組織が一度も取ったことがない行動を取る特に前に。 かかわった特定の政府機関は、攻撃されたマシンをオンなままにし、例えば、このマシンの上で活動を監視するようにあなたに頼むかもしれません。 この要求へのあなたの応じるのは政府機関の継続的な協力を確実にするでしょう--通常ネットワーク攻撃の源を見つけて、結局これらの攻撃を終えることに向かった最も良いルート。 さらに、あなたは事件にかかわる政府機関から何らかの情報か好意を必要とするかもしれません。 協力的であった場合にだけ、あなたは必要とするものを得そうです。 特別の重要性は事件の情報の不要であるか権限のない公開を避けます、かかわった政府機関によって提供されたどんな情報も含んでいて。 あなたのサイトと政府機関の間の信用は政府機関が造るケースで妥協するのを避けるあなたの能力によります。 キープ、「きつさ、唇、」 命令はそうですか?
Sometimes your needs and the needs of an investigative agency will
differ. Your site may want to get back to normal business by
closing an attack route, but the investigative agency may want you
to keep this route open. Similarly, your site may want to close a
compromised system down to avoid the possibility of negative
publicity, but again the investigative agency may want you to
continue monitoring. When there is such a conflict, there may be
a complex set of tradeoffs (e.g., interests of your site's
management, amount of resources you can devote to the problem,
jurisdictional boundaries, etc.). An important guiding principle
is related to what might be called "Internet citizenship" [22,
IAB89, 23] and its responsibilities. Your site can shut a system
down, and this will relieve you of the stress, resource demands,
and danger of negative exposure. The attacker, however, is likely
to simply move on to another system, temporarily leaving others
blind to the attacker's intention and actions until another path
of attack can be detected. Providing that there is no damage to
your systems and others, the most responsible course of action is
to cooperate with the participating agency by leaving your
compromised system on. This will allow monitoring (and,
ultimately, the possibility of terminating the source of the
threat to systems just like yours). On the other hand, if there
is damage to computers illegally accessed through your system, the
choice is more complicated: shutting down the intruder may prevent
further damage to systems, but might make it impossible to track
down the intruder. If there has been damage, the decision about
whether it is important to leave systems up to catch the intruder
時々、あなたの必要性と調査の政府機関の必要性は異なるでしょう。 攻撃ルートを閉じることによって、あなたのサイトは正常な業務に戻りたがっているかもしれませんが、調査の政府機関は、このルートを開くように保って欲しいかもしれません。 同様に、あなたのサイトはマイナスの評判の可能性を避けるために妥協しているシステムダウンを閉じたがっているかもしれませんが、一方、調査の政府機関は、モニターし続けて欲しいかもしれません。 そのような闘争があるとき、複雑なセットの見返り(例えば、あなたのサイトの管理の関心、あなたが問題、司法権の境界などに注ぐことができるリソースの量)があるかもしれません。 重要な指導原理は「インターネット市民権」と呼ばれるかもしれないものに関係づけられます。[22、IAB89、23、]およびその責任。 あなたのサイトはシステムダウンを閉じることができます、そして、これは圧力、リソース要求、および否定的露出という危険をあなたに取り除くでしょう。 しかしながら、攻撃者は単に別のシステムに動きそうです、攻撃の別の経路を検出できるまで一時他のものを攻撃者の意志と動作に盲目でおいて。 あなたのシステムと他のものへの損傷が全くなければ、最も原因となる行動はあなたの妥協しているシステムをオンなままにすることによって協同代理店と協力することです。 これは、モニターするのを(結局まさしくあなたのもののようなシステムへの脅威の源を終える可能性)許容するでしょう。 他方では、あなたのシステムを通して不法にアクセスされたコンピュータへの損傷があれば、選択は、より複雑です: 侵入者を止めるのに、システムへのさらなる損傷を防ぎますが、侵入者を捜し出すのは不可能になるかもしれません。 損害、決定が侵入者を捕らえるためにシステムを掲げるのが重要であるかどうかあったなら
Site Security Policy Handbook Working Group [Page 76] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[76ページ]RFC1244サイトセキュリティハンドブック1991年7月
should involve all the organizations effected. Further
complicating the issue of network responsibility is the
consideration that if you do not cooperate with the agency
involved, you will be less likely to receive help from that agency
in the future.
組織が作用したすべてにかかわるべきです。 さらにネットワーク責任の問題を複雑にして、協力するかかわる政府機関に協力しないなら、あなたがなることである考慮は将来その政府機関から助けをおそらく受ける以下ですか?
5.6 Documentation Logs
5.6 ドキュメンテーションログ
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 good portion of information you obtain, requiring you to contact the source of information once again. This wastes yours and others' time, something you can ill afford. At the same time, recording details will provide evidence for prosecution efforts, providing the case moves in this direction. Documenting an incident also will 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 a follow-up analysis in which you can engage in a valuable "lessons learned" exercise.
インシデントに応じるときには、インシデントに関連するすべての詳細を記録してください。 あなたがすう勢を解こうとするとき、これは自分と他のものに貴重な情報を提供するでしょう。 すべての詳細を記録すると、時間は結局、あなたに節約するでしょう。 あらゆる関連電話を記録するというわけではないなら、例えば、あなたはあなたが得る情報の良い部分を忘れそうです、あなたがもう一度情報源に連絡するのが必要であることで。 これはあなたのものと他のものの時間、あなたがほとんど都合することができない何かを浪費します。 同時に、詳細を記録すると、この件がこの方向に入って来ると、起訴取り組みに関する証拠は提供されるでしょう。 インシデントをまた記録するのも、あなたが損害(法施行役員と同様にあなたの経営者側が知りたくなること)の最終的な判断を実行するのを助けて、あなたが「レッスンは学んだ」という貴重な運動に従事できる追跡している分析の基礎を前提とするでしょう。
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:
インシデントの初期の間、あなたが裁判事件に関する集会証拠であるかのように記録するべきであって、起訴が実行可能であるかどうか決定するのはしばしば実行不可能です。 最小限では、あなたは記録するべきです:
o All system events (audit records).
o All actions you take (time tagged).
o All phone conversations (including the person with whom
you talked, the date and time, and the content of the
conversation).
o 記録) . あなたが取るo All行動(タグ付けをされた時間)を監査してください。すべてのシステムイベント、(o Allは会話に電話をします(あなたが話した人、日時、および会話の内容を含んでいて)。
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 you initially suspect that an incident will result in prosecution or when an investigative agency becomes involved, you need to 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 who can store these copied pages in a secure place (e.g., a safe). When you submit information for storage, you should in return receive a signed, dated receipt from the document custodian. Failure to observe these procedures can result in invalidation of any evidence you obtain in a court of law.
ドキュメンテーションを維持する最も簡単な方法は航海日誌を保管することです。 これで、あなたはあなたがいつそれを必要とするかという情報の集結されて、年代順の源に行くことができます、紙の個々のシートを通してページにあなたを必要とすることの代わりに。 この情報の多くが裁判所の潜在的証拠です。 したがって、あなたが、初めは、インシデントが起訴をもたらすと疑うか、または調査の政府機関がかかわるようになると、あなたは、定期的にあなたの航海日誌(あなたがシステムイベントを記録するのに使用するメディアと同様に)の写真複写されて、署名しているコピーを安全な場所(例えば、金庫)にこれらのコピーされたページを保存できるドキュメント管理人に渡す(例えば毎日)必要があります。 ストレージのための情報を提出するとき、あなたは代わりにドキュメント管理人から署名していて、時代遅れの領収書を受け取ることができます。 これらの手順を観測しない場合、あなたが裁判所で得るどんな証拠についても無効にするのをもたらすことができます。
Site Security Policy Handbook Working Group [Page 77] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[77ページ]RFC1244サイトセキュリティハンドブック1991年7月
6. Establishing Post-Incident Procedures
6. ポストインシデント手順を確立します。
6.1 Overview
6.1 概要
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. システムの資産について在庫を取るべきです、すなわち、慎重な調査はシステムがインシデントでどのように影響を受けたかを決定するべきです。
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. インシデントの結果、学習されたレッスンはインシデントが再発するのを防ぐ改訂された警備計画に含まれるべきです。
3. A new risk analysis should be developed in light of the
incident,
3. 新しい危険分析はインシデントの観点から開発されるべきです。
4. An investigation and prosecution of the individuals
who caused the incident should commence, if it is
deemed desirable.
4. それが望ましいと考えられるなら、インシデントを引き起こした個人の調査と起訴は始まるべきです。
All four steps should provide feedback to the site security policy committee, leading to prompt re-evaluation and amendment of the current policy.
すべての4ステップがサイト安全保障政策委員会にフィードバックを提供するべきです、通貨政策の迅速な再評価と改正に通じて。
6.2 Removing Vulnerabilities
6.2 脆弱性を取り除くこと。
Removing all vulnerabilities once an incident has occurred is difficult. The key to removing vulnerabilities is knowledge and understanding of the breach. In some cases, it is prudent to remove all access or functionality as soon as possible, and then restore normal operation in limited stages. Bear in mind that removing all access while an incident is in progress will obviously notify all users, including the alleged problem users, that the administrators are aware of a problem; this may have a deleterious effect on an investigation. However, allowing an incident to continue may also open the likelihood of greater damage, loss, aggravation, or liability (civil or criminal).
インシデントがいったん起こるとすべての脆弱性を取り除くのは難しいです。 脆弱性を取り除くキーは、不履行の知識と理解です。 いくつかの場合、できるだけ早くすべてのアクセスか機能性を取り除いて、次に、限局期で通常の操作を復元するのは慎重です。 インシデントが進行している間、すべてのアクセスを取り除くのが、管理者が問題を意識しているように明らかに申し立てられた問題ユーザを含むすべてのユーザに通知するのを覚えておいてください。 これは有害な影響を調査に与えるかもしれません。 しかしながら、また、インシデントが続くのを許容するのが、より重大な損害、損失、深刻化、または責任(民間であるか刑事上の)の見込みを開くかもしれません。
If it is determined that the breach occurred due to a flaw in the systems' hardware or software, the vendor (or supplier) and the CERT should be notified as soon as possible. Including relevant telephone numbers (also electronic mail addresses and fax numbers) in the site security policy is strongly recommended. To aid prompt acknowledgment and understanding of the problem, the flaw should be described in as much detail as possible, including details about how to exploit the flaw.
不履行がシステムのハードウェアかソフトウェアの欠点のため起こったのが、決定しているなら、ベンダー(または、供給者)とCERTはできるだけ早く、通知されるべきです。 サイト安全保障政策に関連電話番号(電子メールアドレスともファックス番号)を含んでいるのは強く推薦されます。 問題の迅速な承認と理解を支援するために、欠点はできるだけ多くの詳細に説明されるべきです、どう欠点を利用するかに関する詳細を含んでいて。
Site Security Policy Handbook Working Group [Page 78] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[78ページ]RFC1244サイトセキュリティハンドブック1991年7月
As soon as the breach has occurred, the entire system and all its components should be considered suspect. System software is the most probable target. Preparation is key to recovering from a possibly tainted system. This includes checksumming all tapes from the vendor using a checksum algorithm which (hopefully) is resistant to tampering [10]. (See sections 3.9.4.1, 3.9.4.2.) Assuming original vendor distribution tapes 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 backup tapes to recover from; consider that the incident may have continued for months or years before discovery, and that 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. At worst-case, restoration from the original manufactures' media and a re-installation of the systems will be the most prudent solution.
不履行が起こるとすぐに、全体のシステムとそのすべてのコンポーネントが疑わしいと考えられるべきです。 システムソフトは最もありえそうな目標です。 準備はことによると汚れているシステムから回復するのに主要です。 これは、(希望をいだいて)抵抗力があるチェックサムアルゴリズムを使用するベンダーから改ざん[10]まですべてのテープをchecksummingするのを含んでいます。 (見る、セクション3.9 .4 .1 3.9 .4 .2) 元売業者ディストリビューションテープが利用可能であると仮定する場合、すべてのシステムファイルの分析が始まるべきであり、どんな不規則もインシデントを扱うのにかかわるすべてのパーティーを、注意されて、参照されるべきです。 いくつかの場合、どれが回復するテープのバックアップをとるかを決めるのは非常に難しい場合があります。 インシデントが何カ月もの発見の何年も前に続いたかもしれなくて、容疑者がサイトの従業員であるかもしれないと考えるか、またはさもなければ、詳細な知識かアクセスをシステムに持ってください。ケースであり全部で、プレインシデント準備は、どんな回復が可能であるかを決定するでしょう。 最悪の場合では、オリジナルの製作物のメディアからの回復とシステムの再インストールは最も慎重なソリューションになるでしょう。
Review the lessons learned from the incident and always update the policy and procedures to reflect changes necessitated by the incident.
インシデントから学習されたレッスンを見直してください、そして、いつも方針と手順をアップデートして、インシデントによって必要とされた変化を反映してください。
6.2.1 Assessing Damage
6.2.1 損害額を評価すること。
Before cleanup can begin, the actual system damage must be
discerned. This can be quite time consuming, but should lead into
some of the insight as to the nature of the incident, and aid
investigation and prosecution. It is best to compare previous
backups or original tapes when possible; advance preparation is
the key. 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.
クリーンアップが始めることができる前に、実際のシステム被害について明察しなければなりません。 インシデント、援助調査、および起訴の本質に関して洞察のいくつかに導くべきであるのを除いて、これはかなり時間がかかっている場合があります。 可能であるときに、前のバックアップかオリジナルのテープを比較するのは最も良いです。 前売りの準備はキーです。 システム支援が伐採を集結したなら(大部分はそうします)、ログの上で戻ってください、そして、異常を探してください。 プロセス会計学と接続時間の会計が可能にされるなら、システム使用のパターンを探してください。 ある程度、ディスクの使用状況はインシデントを解明するかもしれません。 会計はインシデントとその後の起訴の分析に多くの役立つ情報を提供できます。
6.2.2 Cleanup
6.2.2 クリーンアップ
Once the damage has been assessed, it is necessary to develop a
plan for system cleanup. 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.
損害がいったん査定されると、システム・クリーンアップのために計画を作り上げるのが必要です。 一般に、最小ユーザ不便であるのを許容するという要求の注文におけるサービスを持って来るのは、最も良い習慣です。 システムのための適切なリカバリ手順が非常に重要であり、サイトに特定であるべきであることを理解してください。
It may be necessary to go back to the original distributed tapes
and recustomize the system. To facilitate this worst case
オリジナルの分配されたテープに戻って、システムを再カスタム設計するのが必要であるかもしれません。 この最悪の場合を容易にするために
Site Security Policy Handbook Working Group [Page 79] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[79ページ]RFC1244サイトセキュリティハンドブック1991年7月
scenario, a record of the original systems setup and each
customization change should be kept current with each change to
the system.
シナリオ、オリジナルのシステムセットアップとそれぞれの改造変化に関する記録はシステムへの各変化で現在につけられるべきです。
6.2.3 Follow up
6.2.3 追求してください。
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. 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 section 3.9.8.2 (e.g., COPS) as a start. Remember,
these tools don't replace continual system monitoring and good
systems administration procedures.
穴と罠さえシステムに潜むことができたのは、一度、あなたが、システムが「安全な」状態に復旧されたと信じているのがまだ可能です。 追跡している段階では、システムはクリーンアップ時期の間になくなっているかもしれない項目のためにモニターされるべきです。 aとしての.2(例えば、COPS)が始めるセクション3.9.8で言及したツールのいくつかを利用するのは慎重でしょう。 覚えていてください、そして、これらのツールは絶え間ないシステムの監視と良いシステム管理手順を置き換えません。
6.2.4 Keep a Security Log
6.2.4 セキュリティログを保ってください。
As discussed in section 5.6, a security log can be most valuable
during this phase of removing vulnerabilities. There are two
considerations here; the first is to keep logs of the procedures
that have been used to make the system secure again. This should
include command procedures (e.g., shell scripts) that can be run
on a periodic basis to recheck the security. Second, keep logs of
important system events. These can be referenced when trying to
determine the extent of the damage of a given incident.
セクション5.6で議論するように、セキュリティログは取り外し脆弱性のこの段階の間、最も貴重である場合があります。 2つの問題がここにあります。 1番目は再びシステムを安全にするのに用いられた手順に関するログを保つことです。 これはセキュリティを再確認する周期的ベースで実行できるコマンドプロシジャ(例えば、シェルスクリプト)を含むべきです。 2番目に、重要なシステムイベントに関するログを保ってください。 与えられたインシデントの損害の程度を測定しようとするとき、これらに参照をつけることができます。
6.3 Capturing Lessons Learned
6.3 レッスンを得るのは学びました。
6.3.1 Understand the Lesson
6.3.1 レッスンを理解してください。
After an incident, it is prudent to write a report describing the
incident, method of discovery, correction procedure, monitoring
procedure, and a summary of lesson learned. This will aid in the
clear understanding of the problem. Remember, it is difficult to
learn from an incident if you don't understand the source.
インシデントの後に、インシデントについて説明するレポートを書くのは慎重です、とレッスンの発見のメソッド、修正手順、モニターしている手順、および概要は学びました。 これは問題の明確な理解で支援されるでしょう。 覚えていてください、そして、インシデントからあなたがソースを理解していないかどうか学ぶのは難しいです。
6.3.2 Resources
6.3.2 リソース
6.3.2.1 Other Security Devices, Methods
6.3.2.1 他のセキュリティデバイス、メソッド
Security is a dynamic, not static process. Sites are dependent
on the nature of security available at each site, and the array
of devices and methods that will help promote security.
Keeping up with the security area of the computer industry and
their methods will assure a security manager of taking
advantage of the latest technology.
セキュリティは静的なプロセスではなく、動力です。 サイトは各サイトで利用可能なセキュリティの本質、およびセキュリティを促進するのを助けるデバイスとメソッドの勢ぞろいに依存しています。 コンピュータ産業とそれらのメソッドのセキュリティ領域について行くと、最新の技術を利用するのはセキュリティマネージャに保証されるでしょう。
Site Security Policy Handbook Working Group [Page 80] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[80ページ]RFC1244サイトセキュリティハンドブック1991年7月
6.3.2.2 Repository of Books, Lists, Information Sources
6.3.2.2 本、リスト、情報源の倉庫
Keep an on site collection of books, lists, information
sources, etc., as guides and references for securing the
system. Keep this collection up to date. Remember, as systems
change, so do security methods and problems.
システムを固定するガイドと参照として本、リスト、情報源などの現場の収集を保管してください。 この収集が時代について行かせてください。 システムが変化するとき覚えていてくださいので、セキュリティメソッドと問題をしてください。
6.3.2.3 Form a Subgroup
6.3.2.3 サブグループを形成してください。
Form a subgroup of system administration personnel that will be
the core security staff. This will allow discussions of
security problems and multiple views of the site's security
issues. This subgroup can also act to develop the site
security policy and make suggested changes as necessary to
ensure site security.
コア保安要員になるシステム管理の人員のサブグループを形成してください。 これは警備上の問題の議論とサイトの安全保障問題の複数の視点を許容するでしょう。 また、このサブグループは、サイトセキュリティを確実にするためにサイト安全保障政策を開発して、必要に応じて提案された変更を行うために行動できます。
6.4 Upgrading Policies and Procedures
6.4 方針と手順をアップグレードさせること。
6.4.1 Establish Mechanisms for Updating Policies, Procedures,
and Tools
6.4.1 方針、手順、およびツールをアップデートするためにメカニズムを確立してください。
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.
そして、インシデントが拙策に基づいていて、方針が変えられない場合、1つが過去を繰り返すのが運命づけられます。 かつてのサイトが回復して、インシデント、サイト方針、および手順が防ぐために変化を取り囲むのが見直されるべきである、同様のインシデント。 インシデントがなくても、定期的に方針と手順を見直すのは慎重でしょう。 今日がコンピューティング環境を変えるので、レビューは必須です。
6.4.2 Problem Reporting Procedures
6.4.2 手順を報告することにおける問題
A problem reporting procedure should be implemented to describe,
in detail, the incident and the solutions to the incident. Each
incident should be reviewed by the site security subgroup to allow
understanding of the incident with possible suggestions to the
site policy and procedures.
手順を報告することにおける問題は、詳細にインシデントとソリューションについてインシデントに説明するために実装されるべきです。 各インシデントは、可能な提案によるインシデントの理解をサイト方針と手順に許容するためにサイトセキュリティサブグループによって見直されるべきです。
7. References
7. 参照
[1] Quarterman, J., "The Matrix: Computer Networks and Conferencing
Systems Worldwide", Pg. 278, Digital Press, Bedford, MA, 1990.
[1]Quarterman、J.、「マトリクス:」 「世界中のコンピュータネットワークと会議システム」、Pg。 278 デジタルプレス、ベッドフォード、MA、1990。
[2] Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery", R. Brand,
available on-line from: cert.sei.cmu.edu:/pub/info/primer, 8 June
1990.
[2] ブランド、R.、「コンピュータセキュリティインシデントの脅威に対処します:」 「PreventionからRecoveryのPrimer」、利用可能なオンラインR.Brand、: cert.sei.cmu.edu: /pub/info/primer、1990年6月8日。
[3] Fites, M., Kratz, P. and A. Brebner, "Control and Security of
[3] ファイツ、M.、クラッツ、P.、およびA.Brebner、「コントロールとセキュリティ、」
Site Security Policy Handbook Working Group [Page 81] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[81ページ]RFC1244サイトセキュリティハンドブック1991年7月
Computer Information Systems", Computer Science Press, 1989.
「コンピュータ情報システム、」、科学が押すコンピュータ、1989
[4] Johnson, D., and J. Podesta, "Formulating a Company Policy on
Access to and Use and Disclosure of Electronic Mail on Company
Computer Systems", Available from: The Electronic Mail
Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington VA
22209, (703) 522-7111, 22 October 1990.
[4] ジョンソン、D.、および以下からのJ.ポデスタ、「会社コンピュータシステムズの電子メールのアクセスと使用と公開のときに企業目的を定式化します」、Available 電子メール協会(EMA)1555ウィルソンBlvd、スイート555、アーリントンヴァージニア 22209、(703)522-7111、1990年10月22日。
[5] Curry, D., "Improving the Security of Your UNIX System", SRI
International Report ITSTD-721-FR-90-21, April 1990.
[5] D. カレー、「あなたのUNIXシステムのセキュリティを向上すること」でのSRIインターナショナルはITSTD-721-FR-90-21、1990年4月を報告します。
[6] Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA, June
1990.
[6]チェスウィック、B.、「安全なインターネットゲートウェイのデザイン」、夏のUsenixコンファレンスの議事、アナハイム(カリフォルニア)1990年6月。
[7] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I -- Message Encipherment and Authentication Procedures", RFC
1113, IAB Privacy Task Force, August 1989.
[7] リン、J.、「インターネット電子メールのためのプライバシー増進:」 「Iを分けてください--暗号文と認証手順を通信させてください」、RFC1113、IABプライバシー特別委員会、1989年8月。
[8] Kent, S., and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II -- Certificate-Based Key Management",
RFC 1114, IAB Privacy Task Force, August 1989.
[8] ケント、S.、およびJ.リン、「インターネット電子メールのためのプライバシー増進:」 「IIを分けてください--証明書ベースのKey Management」、RFC1114、IABプライバシー特別委員会、8月1989
[9] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
Task Force, August 1989.
[9] リン、J.、「インターネット電子メールのためのプライバシー増進:」 「IIIを分けてください--アルゴリズム、モード、および識別子」、RFC1115、IABプライバシー特別委員会、8月1989
[10] Merkle, R., "A Fast Software One Way Hash Function", Journal of
Cryptology, Vol. 3, No. 1.
[10]Merkle、R.、「速いソフトウェア一方通行のハッシュ関数」、暗号理論、Vol.3、No.1のジャーナル。
[11] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", RFC 791, DARPA, September 1981.
[11] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、DARPA、1981年9月。
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[12] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
[13] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, 28 August 1980.
[13] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が設けるUSC/情報、1980年8月28日。
[14] Mogul, J., "Simple and Flexible Datagram Access Controls for
UNIX-based Gateways", Digital Western Research Laboratory
Research Report 89/4, March 1989.
[14] ムガール人、J.、「簡単でフレキシブルなデータグラムアクセスはUNIXベースのゲートウェイに制御します」、デジタル西洋の研究所研究レポート89/4、1989年3月。
[15] Bellovin, S., and M. Merritt, "Limitations of the Kerberos
Authentication System", Computer Communications Review, October
1990.
[15] Bellovin、S.とM.メリット、「ケルベロス認証システムの限界」コンピュータコミュニケーションは1990年10月に再検討されます。
[16] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood
[16]Pfleeger、C.、「コンピューティングにおけるセキュリティ」、新米のホール、イングルウッド
Site Security Policy Handbook Working Group [Page 82] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[82ページ]RFC1244サイトセキュリティハンドブック1991年7月
Cliffs, N.J., 1989.
がけ、ニュージャージー州、1989。
[17] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business", QED
Information Sciences, Inc., Wellesley, MA.
[17] パーカー、D.、スウォープ、S.、およびB.ベイカー、「倫理的な闘争:」 「情報、コンピュータサイエンス、技術、およびビジネス」、QED情報科学Inc.、ウェルズリー、MA。
[18] Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[18]森林学者、T.、およびP.モリソン、「コンピュータ倫理:」 MITは、「コンピューティングにおける物語と倫理的ジレンマ」と押して、ケンブリッジ(MA)は1990です。
[19] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[19] RFC854、科学が設けるUSC/情報がそうするポステル、J.とJ.レイノルズ、「telnetプロトコル仕様」1983。
[20] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.
[20] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル」、RFC959、科学が1985年10月に設けるUSC/情報。
[21] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1200,
IAB, April 1991.
[21] ポステル、J.、エディタ、「IABの公式のプロトコル標準」、RFC1200、IAB、1991年4月。
[22] Internet Activities Board, "Ethics and the Internet", RFC 1087,
Internet Activities Board, January 1989.
[22] インターネット、活動ボードと、「倫理学とインターネット」、RFC1087インターネット活動ボード、1月1989日
[23] Pethia, R., Crocker, S., and B. Fraser, "Policy Guidelines for
the Secure Operation of the Internet", CERT, TIS, CERT, RFC in
preparation.
[23]Pethia、R.、クロッカー、S.、およびB.フレーザ、「インターネットの安全な操作のための政策文書」、CERT、TIS、CERT(準備におけるRFC)。
[24] Computer Emergency Response Team (CERT/CC), "Unauthorized
Password Change Requests", CERT Advisory CA-91:03, April 1991.
[24]コンピュータ緊急対応チーム(CERT/CC)、「権限のないパスワード変更要求」、CERT勧告カリフォルニア-91: 03 1991年4月。
[25] Computer Emergency Response Team (CERT/CC), "TELNET Breakin
Warning", CERT Advisory CA-89:03, August 1989.
[25]コンピュータ緊急対応チーム(CERT/CC)、「telnetブレイクダンス警告」、CERT勧告カリフォルニア-89: 03 1989年8月。
[26] CCITT, Recommendation X.509, "The Directory: Authentication
Framework", Annex C.
[26]CCITT、推薦X.509、「ディレクトリ:」 「認証フレームワーク」、別館C。
[27] Farmer, D., and E. Spafford, "The COPS Security Checker System",
Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA,
Pgs. 165-170, June 1990.
[27] ファーマー、D.、およびE.Spafford、「巡査セキュリティ数奇のシステム」、1990年夏のUSENIXコンファレンス(アナハイム(カリフォルニア)Pgs)の議事。 165-170と、1990年6月。
8. Annotated Bibliography
8. 注釈付きの書誌
The intent of this annotated bibliography is to offer a representative collection of resources of information that will help the user of this handbook. It is meant provide a starting point for further research in the security area. Included are references to other sources of information for those who wish to pursue issues of the computer security environment.
この注釈付きの書誌の意図はこのハンドブックのユーザを助ける情報に関するリソースの代表している収集を提供することです。 それは意味されます。セキュリティ領域でのさらなる調査のための出発点を提供してください。 含まれているのは、他の情報筋のコンピュータセキュリティ環境の問題を追求したがっている人の参照です。
Site Security Policy Handbook Working Group [Page 83] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[83ページ]RFC1244サイトセキュリティハンドブック1991年7月
8.1 Computer Law
8.1 コンピュータ法
[ABA89]
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.
[ABA89]アメリカ法曹協会、科学技術のセクション、「コンピュータ犯罪法令の使用による電気通信詐欺の起訴へのガイド」、アメリカ法曹協会、1989。
[BENDER]
Bender, D., "Computer Law: Evidence and Procedure",
M. Bender, New York, NY, 1978-present.
[ベンダー]ベンダー、D.、「コンピュータ法:」 「証拠と手順」、M.ベンダー、現在のニューヨーク(ニューヨーク)1978。
Kept up to date with supplements.
Years covering 1978-1984 focuses on: Computer law,
evidence and procedures. The years 1984 to the current
focus on general computer law. Bibliographical
references and index included.
補足で、時代について行きます。 年間1978-1984をカバーするのは以下に集中します。 コンピュータ法、証拠、および手順。 電流への1984数年は汎用コンピュータ法に焦点を合わせます。 参照とインデックスを含んでいます。
[BLOOMBECKER]
Bloombecker, B., "Spectacular Computer Crimes", Dow Jones-
Irwin, Homewood, IL. 1990.
[BLOOMBECKER] Bloombecker、B.、「壮観なコンピュータ犯罪」、ダウ・ジョーンズのアーウィン、ホームウッド、IL。 1990.
[CCH]
Commerce Clearing House, "Guide to Computer Law", (Topical
Law Reports), Chicago, IL., 1989.
[CCH]商業クリアリングハウス、「コンピュータ法へのガイド」、(時事問題の判例集)、シカゴ、IL、1989
Court cases and decisions rendered by federal and state
courts throughout the United States on federal and state
computer law. Includes Case Table and Topical Index.
連邦と州のコンピュータ法に合衆国中の連邦と州の法廷によって表されたケースと決定を求めてください。 ケーステーブルと時事問題のインデックスを含んでいます。
[CONLY]
Conly, C., "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]Conly、C.、「コンピュータ犯罪調査と起訴のために結団する」最高裁判所判事の米国部、司法のオフィスは契約番号OJP86C002の下で国立司法研究所(ワシントン(DC)1989年7月)をプログラムします。
[FENWICK]
Fenwick, W., 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:」 「トライアルTacticsとTechniques」、Litigation Course Handbook Series No.280、コンピュータLitigation、1985での分配のためのPrepared: 指揮法が1985年2月-3月にプログラムするトライアル。
[GEMIGNANI]
Gemignani, M., "Viruses and Criminal Law", Communications
of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[GEMIGNANI] Gemignaniと、M.と、「ウイルスと刑法」、ACMに関するコミュニケーション、Vol.32、No.6、Pgs。 669-671と、1989年6月。
Site Security Policy Handbook Working Group [Page 84] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[84ページ]RFC1244サイトセキュリティハンドブック1991年7月
[HUBAND]
Huband, F., 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]のHuband、F.とR.シェルトン、エディターズ、「コンピュータ・システムとソフトウェアの保護:」 Papersは、国立科学財団、1986年までに後援されたワークショップに「SoftwareとUnauthorized IntrusionのCombating Theftのための新しいApproaches」と提示しました。
[MCEWEN]
McEwen, J., "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.
貢献者は、[MCEWEN]マキューエン(J.)が「コンピュータ犯罪ユニットを捧げた」と報告します: D。 化膿とH.ニュージェント、国立司法研究所、法のためのInstituteとOJP85C006、ワシントン、契約番号DCの下の司法のInc.による米国司法省1989年のPrepared。
[PARKER]
Parker, D., "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.
[パーカー]パーカー、D.、「コンピュータ犯罪:」 「刑事裁判リソースマニュアル」、最高裁判所判事の米国部、国立司法研究所、司法のオフィスは契約番号OJP86C002の下でワシントンDC(1989年8月)をプログラムします。
[SHAW]
Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986,
Congressional Record (3 June 1986), Washington, D.C.,
3 June 1986.
[ショー]ショー、E.、Jr.、「1986年のコンピューター詐欺濫用防止法、連邦議会議事録(1986年6月3日)、ワシントンDC、1986年6月3日。」
[TRIBLE]
Trible, P., "The Computer Fraud and Abuse Act of 1986",
U.S. Senate Committee on the Judiciary, 1986.
司法部、1986年の[TRIBLE]Trible、P.、「1986年のコンピューター詐欺濫用防止法」米国上院委員会。
8.2 Computer Security
8.2コンピュータセキュリティ
[CAELLI]
Caelli, W., Editor, "Computer Security in the Age of
Information", Proceedings of the Fifth IFIP International
Conference on Computer Security, IFIP/Sec '88.
[CAELLI] Caelli、W.、エディタ、「情報時代のコンピュータセキュリティ」、コンピュータセキュリティ(IFIP/秒の88年)における第5IFIP国際会議の議事。
[CARROLL]
Carroll, J., "Computer Security", 2nd Edition, Butterworth
Publishers, Stoneham, MA, 1987.
[キャロル]キャロル、J.、「コンピュータセキュリティ」、第2版、バターワース出版社、ストーナム(MA)1987。
[COOPER]
Cooper, J., "Computer and Communications Security:
Strategies for the 1990s", McGraw-Hill, 1989.
[クーパー]クーパー、J.、「コンピュータと通信秘密保全:」 「1990年代のための戦略」、マグロウヒル、1989。
[BRAND]
Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery",
[ブランド]ブランド、R.、「コンピュータセキュリティインシデントの脅威に対処します:」 「防止から回復による入門書」
Site Security Policy Handbook Working Group [Page 85] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[85ページ]RFC1244サイトセキュリティハンドブック1991年7月
R. Brand, 8 June 1990.
R.ブランド、1990年6月8日。
As computer security becomes a more important issue in
modern society, it begins to warrant a systematic approach.
The vast majority of the computer security problems and the
costs associated with them can be prevented with simple
inexpensive measures. The most important and cost
effective of these measures are available in the prevention
and planning phases. These methods are presented in this
paper, followed by a simplified guide to incident
handling and recovery. Available on-line from:
cert.sei.cmu.edu:/pub/info/primer.
コンピュータセキュリティが近代社会で、より重要な問題になるのに従って、それはシステム・アプローチを保証し始めます。 簡単な安価な程度でコンピュータセキュリティ問題のかなりの大部分、それらに関連しているコストを防ぐことができます。 これらの測定における最も重要であるのと費用効率がよさは防止と計画フェーズで利用可能です。 これらのメソッドは簡易型のガイドによって付随している取り扱いと回復に後をつけられたこの論文に提示されます。 利用可能である、以下からのオンライン cert.sei.cmu.edu: /pub/info/primer。
[CHESWICK]
Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA,
June 1990.
[チェスウィック]チェスウィック、B.、「安全なインターネットゲートウェイのデザイン」、夏のUsenixコンファレンスの議事、アナハイム(カリフォルニア)1990年6月。
Brief abstract (slight paraphrase from the original
abstract): AT&T maintains a large internal Internet that
needs to be protected from outside attacks, while
providing useful services between the two.
This paper describes AT&T's Internet gateway. This
gateway passes mail and many of the common Internet
services between AT&T internal machines and the Internet.
This is accomplished without IP connectivity using a pair
of machines: a trusted internal machine and an untrusted
external gateway. These are connected by a private link.
The internal machine provides a few carefully-guarded
services to the external gateway. This configuration
helps protect the internal internet even if the external
machine is fully compromised.
要約(オリジナルの要約からのわずかな言い換え)に事情を知らせてください: AT&Tは役に立つサービスを2つの間に提供する間に攻撃の外から保護される必要がある大きい内部のインターネットを維持します。 この論文はAT&Tのインターネット・ゲートウェイについて説明します。 このゲートウェイはAT&Tの内部のマシンとインターネットの間に一般的なインターネットのサービスのメールと多くを向かわせます。 これはIPの接続性なしで1組のマシンを使用することで達成されます: 信じられた内部のマシンと信頼されていない外部のゲートウェイ。 これらは個人的なリンクによって接続されます。 内部のマシンは外部のゲートウェイに対するいくつかの慎重に用心深いサービスを提供します。 この構成は、外部のマシンが完全に感染されても内部のインターネットを保護するのを助けます。
This is a very useful and interesting design. Most
firewall gateway systems rely on a system that, if
compromised, could allow access to the machines behind
the firewall. Also, most firewall systems require users
who want access to Internet services to have accounts on
the firewall machine. AT&T's design allows AT&T internal
internet users access to the standard services of TELNET and
FTP from their own workstations without accounts on
the firewall machine. A very useful paper that shows
how to maintain some of the benefits of Internet
connectivity while still maintaining strong
security.
これは非常に役に立っておもしろいデザインです。 ほとんどのファイアウォールゲートウェイシステムが感染されるならファイアウォールの後ろのマシンへのアクセスを許すかもしれないシステムを当てにします。 また、ほとんどのファイアウォールシステムがインターネットのサービスへのアクセスにファイアウォールマシンの上にアカウントを持って欲しいユーザを必要とします。 AT&Tのデザインはファイアウォールマシンの上でそれら自身のワークステーションからアカウントなしでTELNETとFTPの標準のサービスへのAT&Tの内部のインターネットユーザアクセスを許します。 まだ強いセキュリティを維持している間、どのようにインターネットの接続性の利益のいくつかを維持するかを示す非常に役に立つ紙。
Site Security Policy Handbook Working Group [Page 86] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[86ページ]RFC1244サイトセキュリティハンドブック1991年7月
[CURRY]
Curry, D., "Improving the Security of Your UNIX System",
SRI International Report ITSTD-721-FR-90-21, April 1990.
D. [カレー]カレー、「あなたのUNIXシステムのセキュリティを向上すること」でのSRIインターナショナルはITSTD-721-FR-90-21、1990年4月を報告します。
This paper describes measures that you, as a system
administrator can take to make your UNIX system(s) more
secure. Oriented primarily at SunOS 4.x, most of the
information covered applies equally well to any Berkeley
UNIX system with or without NFS and/or Yellow Pages (NIS).
Some of the information can also be applied to System V,
although this is not a primary focus of the paper. A very
useful reference, this is also available on the Internet in
various locations, including the directory
cert.sei.cmu.edu:/pub/info.
この論文が測定について説明する、それ、システム管理者があなたのUNIXシステムをより安全にするように取ることができるのであなた。 主としてSunOS 4.xで指向していて、カバーされた情報の大部分はNFS、そして/または、イエローページ(NIS)のあるなしにかかわらず等しくどんなバークレーUNIXシステムにも井戸を当てはまります。 また、何らかの情報をSystem Vに適用できます、これは紙の焦点ではありませんが。 非常に役に立つ参照であり、また、ディレクトリcert.sei.cmu.eduを含んでいて、これもインターネットで各地で利用可能です: /pub/info。
[FITES]
Fites, M., Kratz, P. and A. Brebner, "Control and
Security of Computer Information Systems", Computer Science
Press, 1989.
[ファイツ]ファイツ、M.、クラッツ、P.、およびA.Brebner、コンピュータサイエンスは「コンピュータ情報システムのコントロールとセキュリティ」と1989に押します。
This book serves as a good guide to the issues encountered
in forming computer security policies and procedures. The
book is designed as a textbook for an introductory course
in information systems security.
この本は良いガイドとしてコンピュータセキュリティ方針と手順を形成する際に遭遇する問題に勤めます。 本は情報システムセキュリティにおける初級コースへの教科書として設計されています。
The book is divided into five sections: Risk Management (I),
Safeguards: security and control measures, organizational
and administrative (II), Safeguards: Security and Control
Measures, Technical (III), Legal Environment and
Professionalism (IV), and CICA Computer Control Guidelines
(V).
本は5つのセクションに分割されます: リスク管理(I)、安全装置: セキュリティと制御測定、組織的で管理の(II)、Safeguards: セキュリティ、制御測定、技術的な(III)、法的環境、プロフェッショナリズム(IV)、およびCICAコンピュータはガイドライン(V)を制御します。
The book is particularly notable for its straight-forward
approach to security, emphasizing that common sense is the
first consideration in designing a security program. The
authors note that there is a tendency to look to more
technical solutions to security problems while overlooking
organizational controls which are often cheaper and much
more effective. 298 pages, including references and index.
セキュリティへの簡単なアプローチにおいて、本は特に注目に値します、常識がセキュリティプログラムを設計することにおいて第1要件であると強調して。 作者は、しばしばより安くて、はるかに効果的な組織的なコントロールを見落としている間に、より技術的なソリューションを警備上の問題を当てにする傾向があることに注意します。 指示するものとインデックスを含む298ページ。
[GARFINKEL]
Garfinkel, S, and E. Spafford, "Practical Unix Security",
O'Reilly & Associates, ISBN 0-937175-72-2, May 1991.
[ガーフィンケル] ガーフィンケル、SとE.Spaffordと「実用的なunixセキュリティ」とオライリーと仲間、ISBN0-937175-72-2、1991年5月。
Approx 450 pages, $29.95. Orders: 1-800-338-6887
(US & Canada), 1-707-829-0515 (Europe), email: nuts@ora.com
約450ページと、29.95ドル。 命令: 1-800-338-6887(米国とカナダ)、1-707-829-0515(ヨーロッパ)はメールされます: nuts@ora.com
This is one of the most useful books available on Unix
これはUnixで利用可能な最も役に立つ本の1つです。
Site Security Policy Handbook Working Group [Page 87] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[87ページ]RFC1244サイトセキュリティハンドブック1991年7月
security. The first part of the book covers standard Unix
and Unix security basics, with particular emphasis on
passwords. The second section covers enforcing security on
the system. Of particular interest to the Internet user are
the sections on network security, which address many
of the common security problems that afflict Internet Unix
users. Four chapters deal with handling security incidents,
and the book concludes with discussions of encryption,
physical security, and useful checklists and lists of
resources. The book lives up to its name; it is filled with
specific references to possible security holes, files to
check, and things to do to improve security. This
book is an excellent complement to this handbook.
セキュリティ。 本の最初の部分はパスワードへの特別の強調で標準のUnixとUnixセキュリティ基礎を含んでいます。 第2セクションは実施セキュリティをシステムにカバーします。 インターネットユーザへの特別の関心はネットワークセキュリティのセクションです。(それは、インターネットUnixユーザを苦しめる共通の安全保障問題の多くを扱います)。 4つの章は取り扱いセキュリティインシデントに対処します、そして、本は暗号化、物理的なセキュリティ、および役に立つチェックリストの議論とリソースのリストで締めくくります。 本は名前を満たします。 それは可能なセキュリティーホール、チェックするファイル、およびセキュリティを向上させるためにすることの特定指示で満たされます。 この本は、素晴らしくて、このハンドブックに理想的です。
[GREENIA90]
Greenia, M., "Computer Security Information Sourcebook",
Lexikon Services, Sacramento, CA, 1989.
[GREENIA90] Greenia、M.、「コンピュータセキュリティ情報底本」、Lexikonサービス、サクラメント、カリフォルニア、1989。
A manager's guide to computer security. Contains a
sourcebook of key reference materials including
access control and computer crimes bibliographies.
コンピュータセキュリティへのマネージャのガイド。 アクセスコントロールとコンピュータ犯罪図書目録を含む主要な参照の材料の底本を含んでいます。
[HOFFMAN]
Hoffman, L., "Rogue Programs: Viruses, Worms, and
Trojan Horses", Van Nostrand Reinhold, NY, 1990.
(384 pages, includes bibliographical references and index.)
[ホフマン]ホフマン、L.、「悪党は以下にプログラムを作ります」。 「ウイルス、ワーム、およびトロイの木馬」はNostrandラインホルト、ニューヨーク、1990をバンに積みます。 (384のページ、インクルード参照、およびインデックス。)
[JOHNSON]
Johnson, D., and J. Podesta, "Formulating A Company Policy
on Access to and Use and Disclosure of Electronic Mail on
Company Computer Systems".
「会社コンピュータシステムズの電子メールのアクセスと使用と公開のときに企業目的を定式化する」[ジョンソン]ジョンソン、D.、およびJ.ポデスタ。
A white paper prepared for the EMA, written by two experts
in privacy law. Gives background on the issues, and presents
some policy options.
白書はプライバシー法の2人の専門家によって書かれたEMAの用意をしました。 問題でバックグラウンドを与えて、いくつかの政策選択を提示します。
Available from: The Electronic Mail Association (EMA)
1555 Wilson Blvd, Suite 555, Arlington, VA, 22209.
(703) 522-7111.
利用可能: スイート555、アーリントン、ヴァージニア 電子メール協会(EMA)1555ウィルソンBlvd、22209。 (703) 522-7111.
[KENT]
Kent, Stephen, "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.
[ケント] ケント、スティーブン、「インターネットにプライバシーをメールしてください」 「新しいSoftwareとStrict Registration ProceduresはImplementedがこのYearであったならそうするでしょう」、Business Communications Review、Vol.20、No.1、Pg。 55 1990年1月1日。
Site Security Policy Handbook Working Group [Page 88] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[88ページ]RFC1244サイトセキュリティハンドブック1991年7月
[LU]
Lu, W., and M. Sundareshan, "Secure Communication in
Internet Environments: A Hierachical Key Management Scheme
for End-to-End Encryption", IEEE Transactions on
Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[Lu]のLu、W.、およびM.Sundareshan、「インターネット環境におけるコミュニケーションを保証してください」 「終端間暗号化のHierachical Key Management体系」、コミュニケーション、Vol.37、No.10、Pgの上のIEEEトランザクション。 1014、1989年10月1日。
[LU1]
Lu, W., 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.
[LU1] Lu、W.、およびM.Sundareshan、「多レベルセキュリティのためのコンピュータネットワークのモデル」、ソフトウェア工学、Vol.16、No.6、647ページ(1990年6月1日)のIEEEトランザクション。
[NSA]
National Security Agency, "Information Systems Security
Products and Services Catalog", NSA, Quarterly Publication.
[NSA]国家安全保障局、「情報システムセキュリティ製品とサービスはカタログに載る」NSA、季刊刊行物。
NSA's catalogue contains chapter on: Endorsed Cryptographic
Products List; NSA Endorsed Data Encryption Standard (DES)
Products List; Protected Services List; Evaluated Products
List; Preferred Products List; and Endorsed Tools List.
NSAのカタログは以下に章を含んでいます。 是認された暗号の製品は記載します。 NSAはデータ暗号化規格(DES)製品リストについて宣伝しました。 保護されたサービスは記載します。 評価の製品は記載します。 都合のよい製品は記載します。 そして、是認されたツールは記載します。
The catalogue is available from the Superintendent of
Documents, U.S. Government Printing Office, Washington,
D.C. One may place telephone orders by calling:
(202) 783-3238.
カタログが文書監督官から利用可能である、米国政府印刷局、ワシントンDC Oneは呼ぶことによって、電話注文をするかもしれません: (202) 783-3238.
[OTA]
United States Congress, Office of Technology Assessment,
"Defending Secrets, Sharing Data: New Locks and Keys for
Electronic Information", OTA-CIT-310, October 1987.
[OTA]合衆国議会、技術評価局、「防御しているシークレット、データを共有します:」 「電子情報のための新しい錠とキー」、OTA-CIT-310、10月1987日
This report, prepared for congressional committee considering
Federal policy on the protection of electronic information, is
interesting because of the issues it raises regarding the
impact of technology used to protect information. It also
serves as a reasonable introduction to the various encryption
and information protection mechanisms. 185 pages. Available
from the U.S. Government Printing Office.
この電子情報の保護に関する連邦政府の方針を考える議会委員会のために準備されたレポートはそれが情報を保護するのに使用される技術の影響に関して提起する問題のためにおもしろいです。 また、それは合理的な序論として様々に暗号化と情報保護メカニズム185ページ機能します。 米国政府印刷局から、利用可能です。
[PALMER]
Palmer, I., and G. Potter, "Computer Security Risk
Management", Van Nostrand Reinhold, NY, 1989.
[パーマー] パーマー、I.とG.ポッター、「コンピュータセキュリティリスク管理」、バンNostrandラインホルト、ニューヨーク、1989
[PFLEEGER]
Pfleeger, C., "Security in Computing", Prentice-Hall,
Englewood Cliffs, NJ, 1989.
[PFLEEGER] Pfleeger、C.、「コンピューティングにおけるセキュリティ」、新米のホール、イングルウッドがけ、ニュージャージー、1989。
A general textbook in computer security, this book provides an
excellent and very readable introduction to classic computer
コンピュータセキュリティによる一般的な教科書であり、この本は素晴らしくて非常に読み込み可能な序論を古典的なコンピュータに供給します。
Site Security Policy Handbook Working Group [Page 89] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[89ページ]RFC1244サイトセキュリティハンドブック1991年7月
security problems and solutions, with a particular emphasis on
encryption. The encryption coverage serves as a good
introduction to the subject. Other topics covered include
building secure programs and systems, security of database,
personal computer security, network and communications
security, physical security, risk analysis and security
planning, and legal and ethical issues. 538 pages including
index and bibliography.
暗号化への特別の強調がある警備上の問題とソリューション。 暗号化適用範囲は良い序論として対象に機能します。 カバーされた他の話題は、安全なプログラム、システム、データベースのセキュリティ、パーソナルコンピュータセキュリティ、ネットワーク、通信秘密保全、物理的なセキュリティ、危険分析、セキュリティ計画、および法的で倫理的な問題を構築するのを含んでいます。 インデックスと図書目録を含む538ページ。
[SHIREY]
Shirey, R., "Defense Data Network Security Architecture",
Computer Communication Review, Vol. 20, No. 2, Page 66,
1 April 1990.
[SHIREY] Shirey、R.、「ディフェンスデータ網セキュリティー体系」、コンピュータコミュニケーションレビュー、Vol.20、No.2、66ページ、1990年4月1日。
[SPAFFORD]
Spafford, E., Heaphy, K., and D. Ferbrache, "Computer
Viruses: Dealing with Electronic Vandalism and Programmed
Threats", ADAPSO, 1989. (109 pages.)
[SPAFFORD] Spafford、E.、ヒーフィー、K.、およびD.Ferbrache、「コンピュータウイルス:」 「電子破壊とプログラムされた脅威に対処します」、ADAPSO、1989。 (109ページ。)
This is a good general reference on computer viruses and
related concerns. In addition to describing viruses in
some detail, it also covers more general security issues,
legal recourse in case of security problems, and includes
lists of laws, journals focused on computers security,
and other security-related resources.
これはコンピュータウイルスと関連する関心に関する良い一般参照です。 何らかの詳細にウイルスについて説明することに加えて、それは、また、より一般的な安全保障問題、警備上の問題の場合の法的な償還請求をカバーしていて、法(コンピュータセキュリティ、および他のセキュリティ関連のリソースに集中しているジャーナル)のリストを含んでいます。
Available from: ADAPSO, 1300 N. 17th St, Suite 300,
Arlington VA 22209. (703) 522-5055.
利用可能: スイート300、アーリントンヴァージニア ADAPSO、N.の第17通り、1300 22209。 (703) 522-5055.
[STOLL88]
Stoll, C., "Stalking the Wily Hacker", Communications
of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM,
New York, NY, May 1988.
C. [STOLL88]ストール、ACMに関するコミュニケーション、Vol.31、No.5、「陰険なハッカーに忍び寄る」Pgs。 484-497 ACM、ニューヨーク(ニューヨーク)は1988がそうするかもしれません。
This article describes some of the technical means used
to trace the intruder that was later chronicled in
"Cuckoo's Egg" (see below).
この記事は後で「カッコウの卵」に記録にとどめられた侵入者をつけるのに使用される技術手段のいくつかについて説明します(以下を見てください)。
[STOLL89]
Stoll, C., "The Cuckoo's Egg", ISBN 00385-24946-2,
Doubleday, 1989.
[STOLL89] ストール、C.、「カッコウの卵」、ISBN00385-24946-2、ダブルデー、1989。
Clifford Stoll, an astronomer turned UNIX System
Administrator, recounts an exciting, true story of how he
tracked a computer intruder through the maze of American
military and research networks. This book is easy to
understand and can serve as an interesting introduction to
the world of networking. Jon Postel says in a book review,
クリフォード・ストール(天文学者のターンされたUNIX System Administrator)は彼がアメリカの軍と研究ネットワークの迷宮を通ってどうコンピュータ侵入者を追跡したかに関するおもしろい実話について詳しく話します。 この本は、分かり易く、おもしろい序論としてネットワークの世界に機能できます。 ジョン・ポステルは書評で言います。
Site Security Policy Handbook Working Group [Page 90] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[90ページ]RFC1244サイトセキュリティハンドブック1991年7月
"[this book] ... is absolutely essential reading for anyone
that uses or operates any computer connected to the Internet
or any other computer network."
「[この本]…はどんなインターネットに接続しているコンピュータかいかなる他のコンピュータネットワークも使用するか、または操作するだれでもめざして勉強するのにおいて絶対に不可欠です。」
[VALLA]
Vallabhaneni, S., "Auditing Computer Security: A Manual with
Case Studies", Wiley, New York, NY, 1989.
[ウァラ]バラバンネーニ、S.、「監査のコンピュータセキュリティ:」 「ケーススタディがあるマニュアル」、ワイリー、ニューヨーク(ニューヨーク)1989。
8.3 Ethics
8.3 倫理学
[CPSR89]
Computer Professionals for Social Responsibility, "CPSR
Statement on the Computer Virus", CPSR, Communications of the
ACM, Vol. 32, No. 6, Pg. 699, June 1989.
社会的責任のための[CPSR89]コンピュータの専門家、「コンピュータウィルスに関するCPSR声明」、CPSR、ACMに関するコミュニケーション、Vol.32、No.6(Pg)。 699 1989年6月。
This memo is a statement on the Internet Computer Virus
by the Computer Professionals for Social Responsibility
(CPSR).
このメモはSocial Responsibility(CPSR)のためのコンピュータProfessionalsによるインターネットコンピュータVirusに関する声明です。
[DENNING]
Denning, Peter J., Editor, "Computers Under Attack:
Intruders, Worms, and Viruses", ACM Press, 1990.
[デニング]デニング、ピーターJ.、エディタ、「コンピュータ下は攻撃します」。 ACMは、「侵入者、ワーム、およびウイルス」と1990に押します。
A collection of 40 pieces divided into six sections: the
emergence of worldwide computer networks, electronic breakins,
worms, viruses, counterculture (articles examining the world
of the "hacker"), and finally a section discussing social,
legal, and ethical considerations.
40つの収集は6つのセクションに分割されました: 世界規模のコンピュータ・ネットワーク、電子breakins、ワーム、ウイルス、反体制文化(「ハッカー」の世界を調べる記事)、および最終的に社会的で、法的で、倫理的な問題について論ずるセクションの出現。
A thoughtful collection that addresses the phenomenon of
attacks on computers. This includes a number of previously
published articles and some new ones. The previously
published ones are well chosen, and include some references
that might be otherwise hard to obtain. This book is a key
reference to computer security threats that have generated
much of the concern over computer security in recent years.
コンピュータにおける攻撃の現象を扱う考え深い収集。 これは多くの以前に発行された記事といくつかの新しいものを含んでいます。 以前に発行されたものは、適切であり、いくつかのそうでなければ得るのが困難であるかもしれない指示するものを含んでいます。 この本は近年コンピュータセキュリティに関する心配の多くを生成したコンピュータセキュリティの脅威の主要な参照です。
[ERMANN]
Ermann, D., Williams, M., and C. Gutierrez, Editors,
"Computers, Ethics, and Society", Oxford University Press,
NY, 1990. (376 pages, includes bibliographical references).
[ERMANN]Ermann、D.とウィリアムズ、M.とC.グティエレス、エディターズ「コンピュータ、倫理、および社会」オックスフォード大学出版局、ニューヨーク、1990 (376ページ、インクルード参照。)
[FORESTER]
Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA,
1990. (192 pages including index.)
[森林学者]森林学者、T.、およびP.モリソン、「コンピュータ倫理:」 MITは、「コンピューティングにおける物語と倫理的ジレンマ」と押して、ケンブリッジ(MA)は1990です。 (インデックスを含む192ページ。)
Site Security Policy Handbook Working Group [Page 91] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[91ページ]RFC1244サイトセキュリティハンドブック1991年7月
From the preface: "The aim of this book is two-fold: (1) to
describe some of the problems created by society by computers,
and (2) to show how these problems present ethical dilemmas
for computers professionals and computer users.
序文から: 「この本の目的は二面です」 (1) 社会はコンピュータ、および(2)によって生じさせられた、これらの問題がコンピュータ専門家とコンピュータユーザのためにどう倫理的ジレンマを提示するかを示していた問題のいくつかについて説明するために。
The problems created by computers arise, in turn, from two
main sources: from hardware and software malfunctions and
from misuse by human beings. We argue that computer systems
by their very nature are insecure, unreliable, and
unpredictable -- and that society has yet to come to terms
with the consequences. We also seek to show how society
has become newly vulnerable to human misuse of computers in
the form of computer crime, software theft, hacking, the
creation of viruses, invasions of privacy, and so on."
コンピュータによって生じさせられた問題は2つの主なソースから順番に起こります: ハードウェアとソフトウェア不調と人間による誤用から。 私たちは、彼らのまさしくその本質によるコンピュータ・システムは、不安定で、頼り無く、予測できません--社会がまだ結果と折り合っていないと主張します。 「また、私たちは社会がどう新たにコンピュータ犯罪、ソフトウェア窃盗、ハッキング、ウイルスの作成、プライバシーの侵入などの形における、コンピュータの人間の誤用に被害を受け易くなったかを示そうとします。」
The eight chapters include "Computer Crime", "Software
Theft", "Hacking and Viruses", "Unreliable Computers",
"The Invasion of Privacy", "AI and Expert Systems",
and "Computerizing the Workplace." Includes extensive
notes on sources and an index.
8つの章インクルード「コンピュータ犯罪」と、「ソフトウェア窃盗」と、「ハッキングとウイルス」、「頼り無いコンピュータ」、「プライバシー侵害」「AIとエキスパートシステム」、そして、「仕事場をコンピューター化します。」 ソースとインデックスに関する大規模な雰囲気を含んでいます。
[GOULD]
Gould, C., Editor, "The Information Web: Ethical and Social
Implications of Computer Networking", Westview Press,
Boulder, CO, 1989.
[グールド]グールド、C.、エディタ、「情報ウェブ:」 「コンピュータのネットワーク化の倫理的で社会的な含意」、Westviewプレス、ボウルダー、CO、1989。
[IAB89]
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.
[IAB89]インターネット、活動ボードと、「倫理学とインターネット」、RFC1087、IAB、1月1989日 また、ACMのCommunications、Vol.32、No.6、Pgでは、現れます。 710 1989年6月。
This memo is a statement of policy by the Internet
Activities Board (IAB) concerning the proper use of
the resources of the Internet. Available on-line on
host ftp.nisc.sri.com, directory rfc, filename rfc1087.txt.
Also available on host nis.nsf.net, directory RFC,
filename RFC1087.TXT-1.
このメモはインターネットに関するリソースの適切な使用に関するインターネットActivities Board(IAB)による方針の声明です。 利用可能なホストftp.nisc.sri.comのオンラインの、そして、ディレクトリrfcなファイル名rfc1087.txt。 また、ホストnis.nsf.net、ディレクトリRFC、ファイル名RFC1087.TXT-1では、利用可能です。
[MARTIN]
Martin, M., and R. Schinzinger, "Ethics in Engineering",
McGraw Hill, 2nd Edition, 1989.
[マーチン]マーチン、M.とR.シンチンゲル、「工学の倫理学」マクグロー・ヒル、第2版、1989。
[MIT89]
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.
[MIT89]マサチューセッツ工科大学、「コンピュータの責任ある利用に関して学生に教えます」、MIT、1985-1986。 また、ACMのCommunications、Vol.32、No.6、Pgでは、増刷されています。 704 アティナプロジェクト、MIT、1989年6月。
Site Security Policy Handbook Working Group [Page 92] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[92ページ]RFC1244サイトセキュリティハンドブック1991年7月
This memo is a statement of policy by the Massachusetts
Institute of Technology (MIT) on the responsible use
of computers.
このメモはコンピュータの責任ある利用でのマサチューセッツ工科大学(MIT)による方針の声明です。
[NIST]
National Institute of Standards and Technology, "Computer
Viruses and Related Threats: A Management Guide", NIST
Special Publication 500-166, August 1989.
[NIST]米国商務省標準技術局、「コンピュータウイルスと関連脅威:」 「マネジメント・ガイド」、NISTの特別な公表500-166、1989年8月。
[NSF88]
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.
[NSF88]科学基金、「NSFはネットワーク倫理の規範を引き起こす」ACMに関するコミュニケーション、Vol.32、No.6、Pg。 688 1989年6月。 また、事業部Advisory Panelの例会の議事録の間、1988年11月29日〜30日にNetworkingとCommunications ResearchとInfrastructure、デーヴ・ファーバー、議長に見えます。
This memo is a statement of policy by the National Science
Foundation (NSF) concerning the ethical use of the Internet.
このメモはインターネットの倫理的な使用に関する国立科学財団(NSF)による方針の声明です。
[PARKER90]
Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business",
QED Information Sciences, Inc., Wellesley, MA. (245 pages).
[PARKER90] パーカー、D.、スウォープ、S.、およびB.ベイカー、「倫理的な闘争:」 「情報、コンピュータサイエンス、技術、およびビジネス」、QED情報科学Inc.、ウェルズリー、MA。 (245ページ。)
Additional publications on Ethics:
Ethicsに関する追加刊行物:
The University of New Mexico (UNM)
ニューメキシコ大学(UNM)
The UNM has a collection of ethics documents. Included are
legislation from several states and policies from many
institutions.
UNMには、倫理ドキュメントの収集があります。 含まれているのは、多くの団体からのいくつかの州と方針からの法律です。
Access is via FTP, IP address ariel.umn.edu. Look in the
directory /ethics.
FTP、IPアドレスariel.umn.eduを通してアクセスがあります。 ディレクトリ/倫理の中を見てください。
8.4 The Internet Worm
8.4 インターネットワーム
[BROCK]
Brock, J., "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.
[ブロック]ブロック、J.、「1988年11月にインターネットコンピュータウィルスと国家のテレコミュニケーションの脆弱性はウイルスをコンピュータにネットワークでつなぎます」、カオ/T-IMTEC-89-10、ワシントン(DC)1989年7月20日。
Testimonial statement of Jack L. Brock, Director, U. S.
Government Information before the Subcommittee on
Telecommunications and Finance, Committee on Energy and
そしてジャック・L.ブロック、Energyの上のディレクター(Subcommitteeの前のTelecommunicationsに関するU.S.政府情報とFinance)Committeeの証明書声明。
Site Security Policy Handbook Working Group [Page 93] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[93ページ]RFC1244サイトセキュリティハンドブック1991年7月
Commerce, House of Representatives.
商業、下院。
[EICHIN89]
Eichin, M., and J. Rochlis, "With Microscope and Tweezers:
An Analysis of the Internet Virus of November 1988",
Massachusetts Institute of Technology, February 1989.
[EICHIN89] Eichin、M.、およびJ.Rochlis、「顕微鏡座とピンセットで:、」 「1988年11月のインターネットウイルスの分析」、マサチューセッツ工科大学、1989年2月。
Provides a detailed dissection of the worm program. The
paper discusses the major points of the worm program then
reviews strategies, chronology, lessons and open issues,
Acknowledgments; also included are a detailed appendix
on the worm program subroutine by subroutine, an
appendix on the cast of characters, and a reference section.
ワームプログラムの詳細な解剖を提供します。 論文はワームプログラムの次に、レビューの戦略と年表とレッスンと未解決の問題、Acknowledgmentsの主旨について議論します。 また、含まれているのは、ワームプログラムサブルーチンのサブルーチンによる詳細な付録と、キャラクタのキャストの上の付録と、参照部です。
[EISENBERG89]
Eisenberg, T., D. Gries, J. Hartmanis, D. Holcomb,
M. Lynn, and T. Santoro, "The Computer Worm", Cornell
University, 6 February 1989.
[EISENBERG89]エイゼンバーグとT.とD.グリースとJ.HartmanisとD.ホルコム、M.リンとT.サントーロ、「コンピュータワーム」コーネル大学(1989年2月6日)。
A Cornell University Report presented to the Provost of the
University on 6 February 1989 on the Internet Worm.
コーネル大学Reportはインターネットの1989年2月6日の大学事務長にWormを寄贈しました。
[GAO]
U.S. General Accounting Office, "Computer Security - Virus
Highlights Need for Improved Internet Management", United
States General Accounting Office, Washington, DC, 1989.
[GAO]米国会計検査院、「コンピュータセキュリティ--ウイルスハイライトは改良されたインターネットに管理を必要とします」、合衆国米国会計検査院、ワシントン、DC1989
This 36 page report (GAO/IMTEC-89-57), by the U.S.
Government Accounting Office, describes the Internet worm
and its effects. It gives a good overview of the various
U.S. agencies involved in the Internet today and their
concerns vis-a-vis computer security and networking.
米国政府会計局で、この36ページのレポート(カオ/IMTEC-89-57)はインターネットワームとその効果について説明します。 それはコンピュータセキュリティとネットワークと向かいあって今日インターネットにかかわっている様々な米国代理店と彼らの関心の良い概要を与えます。
Available on-line on host nnsc.nsf.net, directory
pub, filename GAO_RPT; and on nis.nsf.net, directory nsfnet,
filename GAO_RPT.TXT.
利用可能である、ホストnnsc.nsf.net、ディレクトリパブ、ファイル名GAO_RPTのオンライン。 ディレクトリnsfnet、nis.nsf.netの上のファイル名GAO_RPT.TXT。
[REYNOLDS89]
The Helminthiasis of the Internet, RFC 1135,
USC/Information Sciences Institute, Marina del Rey,
CA, December 1989.
[REYNOLDS89]インターネット、RFC1135、USC/情報Sciences Institute、マリナデルレイのHelminthiasis、カリフォルニア1989年12月。
This report looks back at the helminthiasis (infestation
with, or disease caused by parasitic worms) of the
Internet that was unleashed the evening of 2 November 1988.
This document provides a glimpse at the infection,its
festering, and cure. The impact of the worm on the Internet
community, ethics statements, the role of the news media,
このレポートが蠕虫病を見返す、(出没、寄生虫によって引き起こされた病気) インターネットでは、それは1988年11月2日の晩に解き放たれました。 このドキュメントはその感染、化膿、および療法で一瞥を提供します。 インターネットコミュニティのワームの影響、倫理声明、ニュースメディアの役割
Site Security Policy Handbook Working Group [Page 94] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[94ページ]RFC1244サイトセキュリティハンドブック1991年7月
crime in the computer world, and future prevention is
discussed. A documentation review presents four publications
that describe in detail this particular parasitic computer
program. Reference and bibliography sections are also
included. Available on-line on host ftp.nisc.sri.com
directory rfc, filename rfc1135.txt. Also available on
host nis.nsf.net, directory RFC, filename RFC1135.TXT-1.
防止について議論するコンピュータ世界、および未来の犯罪。 ドキュメンテーションレビューは詳細にこの特定の寄生的なコンピュータ・プログラムについて説明する4つの刊行物を提示します。 また、指示するものと図書目録部は含まれています。 利用可能である、ホストftp.nisc.sri.comディレクトリrfc、ファイル名rfc1135.txtでは、オンラインです。 また、ホストnis.nsf.net、ディレクトリRFC、ファイル名RFC1135.TXT-1では、利用可能です。
[SEELEY89]
Seeley, D., "A Tour of the Worm", Proceedings of 1989
Winter USENIX Conference, Usenix Association, San Diego, CA,
February 1989.
[SEELEY89] セーレー、D.、「ワームのツアー」、1989年の冬のUSENIXコンファレンスの議事、Usenix協会(サンディエゴ(カリフォルニア)1989年2月)。
Details are presented as a "walk thru" of this particular
worm program. The paper opened with an abstract,
introduction, detailed chronology of events upon the
discovery of the worm, an overview, the internals of the
worm, personal opinions, and conclusion.
aがこの特定のワームプログラムを「徹底的に歩かせる」とき、詳細は提示されます。 要約で開かれた論文(序論)はワーム、概要、ワーム、個人的な見解、および結論のインターナルの発見のときにイベントの年表を詳しく述べました。
[SPAFFORD88]
Spafford, E., "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.
[SPAFFORD88] Spafford、E.、「インターネットワームは以下にプログラムを作ります」。 「分析」、コンピュータコミュニケーションレビュー、Vol.19、No.1、ACM SIGCOM、1989年1月。 また、パドゥーCS Technical Report CSD-TR-823、1988年11月28日として、発行されています。
Describes the infection of the Internet as a worm
program that exploited flaws in utility programs in
UNIX based systems. The report gives a detailed
description of the components of the worm program:
data and functions. Spafford focuses his study on two
completely independent reverse-compilations of the
worm and a version disassembled to VAX assembly language.
. レポートがワームプログラムの部品の詳述を与えるUNIXのベースのシステムのユティリティプログラムの欠点を利用したワームプログラムとしてインターネットの感染を記述します: データと機能。 SpaffordはVAXアセンブリ言語に分解されたワームとバージョンの2つの完全に独立している逆編集に関する彼の研究の焦点を合わせます。
[SPAFFORD89]
Spafford, G., "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.
[SPAFFORD89] Spafford、G.、「インターネットワームの分析」、ヨーロッパのソフトウェア工学コンファレンス1989、ウォリックイギリス(1989年9月)の議事。 議事は以下としてSpringer-Verlagによって発行されました。 コンピュータ科学#387で注意について講義してください。 また、パドゥーTechnical Report#CSD-TR-933として、発行されています。
8.5 National Computer Security Center (NCSC)
8.5 国家のコンピュータセキュリティセンター(NCSC)
All NCSC publications, approved for public release, are available from the NCSC Superintendent of Documents.
すべての公共のリリースのために承認されたNCSC刊行物がNCSC文書監督官から利用可能です。
NCSC = National Computer Security Center
NCSCは国家のコンピュータセキュリティセンターと等しいです。
Site Security Policy Handbook Working Group [Page 95] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[95ページ]RFC1244サイトセキュリティハンドブック1991年7月
9800 Savage Road
Ft Meade, MD 20755-6000
ミード、9800サヴェージ道路Ft MD20755-6000
CSC = Computer Security Center:
an older name for the NCSC
CSCはコンピュータセキュリティセンターと等しいです: NCSCのための、より古い名前
NTISS = National Telecommunications and
Information Systems Security
NTISS Committee, National Security Agency
Ft Meade, MD 20755-6000
NTISSは国家のテレコミュニケーションと情報システムセキュリティNTISS委員会と等しく、国家安全保障局フィートはミード、MD20755-6000です。
[CSC]
Department of Defense, "Password Management Guideline",
CSC-STD-002-85, 12 April 1985, 31 pages.
[CSC]国防総省、「パスワード管理ガイドライン」、CSC-STD-002-85、1985年4月12日、31ページ。
The security provided by a password system depends on
the passwords being kept secret at all times. Thus, a
password is vulnerable to compromise whenever it is used,
stored, or even known. In a password-based authentication
mechanism implemented on an ADP system, passwords are
vulnerable to compromise due to five essential aspects
of the password system: 1) a password must be initially
assigned to a user when enrolled on the ADP system;
2) a user's password must be changed periodically;
3) the ADP system must maintain a 'password
database'; 4) users must remember their passwords; and
5) users must enter their passwords into the ADP system at
authentication time. This guideline prescribes steps to be
taken to minimize the vulnerability of passwords in each of
these circumstances.
パスワードシステムによって提供されたセキュリティはいつも秘密にされるパスワードによります。 したがって、パスワードは、それが使用されるか、保存されるか、または知られるときはいつもさえ、妥協するために被害を受け易いです。 ADPシステムの上で実装されたパスワードベースの認証機構では、パスワードはパスワードシステムの5つの不可欠の局面のため妥協するために被害を受け易いです: 1) ADPシステムの上に登録されると、初めは、パスワードをユーザに割り当てなければなりません。 2) 定期的にユーザのパスワードを変えなければなりません。 3) ADPシステムは'パスワードデータベース'を維持しなければなりません。 4) ユーザは彼らのパスワードを覚えていなければなりません。 そして、5人の)ユーザが認証時に彼らのパスワードをADPシステムに入力しなければなりません。 このガイドラインは、それぞれのこれらの事情のパスワードの脆弱性を最小にするために取るためにステップを定めます。
[NCSC1]
NCSC, "A Guide to Understanding AUDIT in Trusted Systems",
NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
[NCSC1]NCSC、「信じられたシステムにおける監査を理解していることへのガイド」、NCSC-TG-001、1988年6月1日、25ページのバージョン-2。
Audit trails are used to detect and deter penetration of
a computer system and to reveal usage that identifies
misuse. At the discretion of the auditor, audit trails
may be limited to specific events or may encompass all of
the activities on a system. Although not required by
the criteria, it should be possible for the target of the
audit mechanism to be either a subject or an object. That
is to say, the audit mechanism should be capable of
monitoring every time John accessed the system as well as
every time the nuclear reactor file was accessed; and
likewise every time John accessed the nuclear reactor
file.
監査証跡は、コンピュータ・システムの侵入を検出して、思いとどまらせて、誤用を特定する用法を明らかにするのに使用されます。 監査役の裁量では、監査証跡は、特定のイベントに制限されるか、または活動のすべてをシステムに取り囲むかもしれません。 評価基準は必要ではありませんが、監査機構の目標が対象かオブジェクトのどちらかであることが可能であるべきです。 すなわち、ジョンが原子炉ファイルがアクセスされた毎回と同様にシステムにアクセスしたときはいつも、監査機構はモニターできるべきです。 そして、同様に毎回のジョンは原子炉ファイルにアクセスしました。
Site Security Policy Handbook Working Group [Page 96] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[96ページ]RFC1244サイトセキュリティハンドブック1991年7月
[NCSC2]
NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL
in Trusted Systems", NCSC-TG-003, Version-1, 30 September
1987, 29 pages.
[NCSC2]NCSC、「信じられたシステムにおける任意のアクセスコントロールを理解していることへのガイド」、NCSC-TG-003、1987年9月30日、29ページのバージョン-1。
Discretionary control is the most common type of access
control mechanism implemented in computer systems today.
The basis of this kind of security is that an individual
user, or program operating on the user's behalf, is
allowed to specify explicitly the types of access other
users (or programs executing on their behalf) may have to
information under the user's control. [...] Discretionary
controls are not a replacement for mandatory controls. In
any environment in which information is protected,
discretionary security provides for a finer granularity of
control within the overall constraints of the mandatory
policy.
自由裁量的統制は今日コンピュータ・システムで実装されている最も一般的なタイプのアクセス管理機構です。 この種類のセキュリティの基礎は個々のユーザ、またはユーザに代わったプログラム操作が明らかに他のユーザ(または、彼らに代わった実行をプログラムします)がユーザのコントロールの下で情報に持っているかもしれないアクセスのタイプを指定できるということです。 [...] 自由裁量的統制は法的規制へのリプレースメントではありません。 情報が保護されるどんな環境でも、任意のセキュリティは義務的な方針の総合的な規制の中にコントロールの、よりすばらしい粒状に備えます。
[NCSC3]
NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT
in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988,
31 pages.
[NCSC3]NCSC、「信じられたシステムの構成管理を理解していることへのガイド」、NCSC-TG-006、1988年3月28日、31ページのバージョン-1。
Configuration management consists of four separate tasks:
identification, control, status accounting, and auditing.
For every change that is made to an automated data
processing (ADP) system, the design and requirements of the
changed version of the system should be identified. The
control task of configuration management is performed
by subjecting every change to documentation, hardware, and
software/firmware to review and approval by an authorized
authority. Configuration status accounting is responsible
for recording and reporting on the configuration of the
product throughout the change. Finally, though the process
of a configuration audit, the completed change can be
verified to be functionally correct, and for trusted
systems, consistent with the security policy of the system.
構成管理は4つの別々のタスクから成ります: 識別、コントロール、状態会計、および監査。 自動データ処置(ADP)システムにされるあらゆる変更に関しては、システムの変えられたバージョンのデザインと要件は特定されるべきです。 構成管理に関するコントロールタスクは、認可された権威でドキュメンテーションへのあらゆる変化、ハードウェア、およびソフトウェア/ファームウェアをレビューと承認にかけることによって、実行されます。 構成状態会計は変化の間中製品の構成に関して記録して、報告するのに原因となります。 最終的に、構成監査のプロセスですが、完成した変化は機能上正しくなるように確かめられる、および信じられたシステムのためのものであることができます、システムの安全保障政策と一致しています。
[NTISS]
NTISS, "Advisory Memorandum on Office Automation Security
Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987,
58 pages.
[NTISS]NTISS、「オフィス・オートメーション安全ガイドラインの顧問メモ」、NTISSAM CONPUSEC/1-87、1987年1月16日、58ページ。
This document provides guidance to users, managers, security
officers, and procurement officers of Office Automation
Systems. Areas addressed include: physical security,
personnel security, procedural security, hardware/software
security, emanations security (TEMPEST), and communications
このドキュメントは指導をユーザに提供して、オフィスAutomation Systems領域の役員が演説したマネージャ、セキュリティ担当責任者、および調達は: 物理的なセキュリティ、人的安全保護、手続き上のセキュリティ、ハードウェア/ソフトウェアセキュリティ、エマナチオンセキュリティ(TEMPEST)、およびコミュニケーション
Site Security Policy Handbook Working Group [Page 97] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[97ページ]RFC1244サイトセキュリティハンドブック1991年7月
security for stand-alone OA Systems, OA Systems
used as terminals connected to mainframe computer systems,
and OA Systems used as hosts in a Local Area Network (LAN).
Differentiation is made between those Office Automation
Systems equipped with removable storage media only (e.g.,
floppy disks, cassette tapes, removable hard disks) and
those Office Automation Systems equipped with fixed media
(e.g., Winchester disks).
スタンドアロンのOA Systemsのためのセキュリティ、端末として使用されるOA Systemsはメインフレームコンピュータ・システム、およびホストとしてローカル・エリア・ネットワーク(LAN)に使用されるOA Systemsに接続しました。 リムーバブルストレージメディアだけを備えていたそれらのオフィスAutomation Systemsの間で分化をしました、そして、(例えば、フロッピーディスク、カセットはテープで貼ります、リムーバブルハードディスク)それらのオフィスAutomation Systemsは固定メディア(例えば、ウィンチェスタディスク)を備えていました。
Additional NCSC Publications:
追加NCSC刊行物:
[NCSC4]
National Computer Security Center, "Glossary of Computer
Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
[NCSC4]国家のコンピュータセキュリティセンター、「コンピュータセキュリティ用語の用語集」、NCSC-TG-004、NCSC、1988年10月21日。
[NCSC5]
National Computer Security Center, "Trusted
Computer System Evaluation Criteria", DoD 5200.28-STD,
CSC-STD-001-83, NCSC, December 1985.
[NCSC5]国家のコンピュータセキュリティセンター、「信じられたコンピュータシステム評価」、DoD 5200.28-STD、CSC-STD-001-83、NCSC、1985年12月。
[NCSC7]
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.
[NCSC7]国家のコンピュータセキュリティセンター、「国防総省を適用するための指導は特定の環境におけるコンピュータシステム評価を信じました」、CSC-STD-003-85、NCSC、1985年6月25日。
[NCSC8]
National Computer Security Center, "Technical Rationale
Behind CSC-STD-003-85: Computer Security Requirements",
CSC-STD-004-85, NCSC, 25 June 85.
[NCSC8]国家のコンピュータセキュリティセンター、「CSC-STD-003-85の後ろの技術的な原理:」 「コンピュータセキュリティ要件」、CSC-STD-004-85、NCSC、1985年6月25日。
[NCSC9]
National Computer Security Center, "Magnetic Remanence
Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985.
[NCSC9]国家のコンピュータセキュリティセンター、「磁気残留分極安全ガイドライン」、CSC-STD-005-85、NCSC、1985年11月15日。
This guideline is tagged as a "For Official Use Only"
exemption under Section 6, Public Law 86-36 (50 U.S. Code
402). Distribution authorized of U.S. Government agencies
and their contractors to protect unclassified technical,
operational, or administrative data relating to operations
of the National Security Agency.
このガイドラインは「公式の使用専用」としてタグ付けをされます。セクション6、Public法86-36(50米国Code402)の下における控除。 米国政府機関と保護する彼らの契約者に認可された分配は国家安全保障局の操作に関連する技術的であるか、操作上の、または、管理のデータを非分類しました。
[NCSC10]
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.
[NCSC10]国家のコンピュータSecurityセンター、「正式な検証制度のためのガイドライン」、送料リストノー: 89-660P、センター、とりでジョージG.ミード(MD)1990年4月1日。
Site Security Policy Handbook Working Group [Page 98] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[98ページ]RFC1244サイトセキュリティハンドブック1991年7月
[NCSC11]
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.
[NCSC11]国家のコンピュータSecurityセンター、「コンピュータセキュリティ用語の用語集」、送料リストノー: 89-254P、センター、とりでジョージG.ミード(MD)1988年10月21日。
[NCSC12]
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.
[NCSC12]国家のコンピュータSecurityセンター、「UNIXシステムのためのアクセスコントロールリスト機能を選択するための信じられたUNIX作業部会(TRUSIX)原理」、送料リストノー: 90-076P、センター、とりでジョージ・G.ミード(MD)1990。
[NCSC13]
National Computer Security Center, "Trusted Network
Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
[NCSC13]国家のコンピュータセキュリティセンター、「信じられたネットワーク解釈」、NCSC-TG-005、NCSC、1987年7月31日。
[NCSC14]
Tinto, M., "Computer Viruses: Prevention, Detection, and
Treatment", National Computer Security Center C1
Technical Report C1-001-89, June 1989.
[NCSC14]ティント、M.、「コンピュータウイルス:」 国家のコンピュータセキュリティは、「防止、検出、および処理」と中心に置きます。1989年6月のC1技術報告書C1-001-89。
[NCSC15]
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.
[NCSC15]国家のコンピュータセキュリティコンファレンス、「第12国家のコンピュータセキュリティコンファレンス:」 ボルチモアコンベンションセンター、1989年ボルチモア(MD)10-13 10月: 「情報システムセキュリティ、今日のソリューション--、明日の概念、」、規格の国家の研究所と国家のコンピュータセキュリティセンター、1989
8.6 Security Checklists
8.6 セキュリティチェックリスト
[AUCOIN]
Aucoin, R., "Computer Viruses: Checklist for Recovery",
Computers in Libraries, Vol. 9, No. 2, Pg. 4,
1 February 1989.
[オークイン]オークイン、R.、「コンピュータウイルス:」 「回復のためのチェックリスト」、図書館のコンピュータ、Vol.9、No.2、Pg。 4 1989年2月1日。
[WOOD]
Wood, C., Banks, W., Guarro, S., Garcia, A., Hampel, V.,
and H. Sartorio, "Computer Security: A Comprehensive Controls
Checklist", John Wiley and Sons, Interscience Publication,
1987.
[植林します] 木、C.、銀行、W.、Guarro、S.、ガルシア、A.、ハンペル、V.、およびH.Sartorio、「コンピュータセキュリティ:」 「包括的なコントロールチェックリスト」とジョン・ワイリーと息子、Interscience公表、1987
8.7 Additional Publications
8.7 追加刊行物
Defense Data Network's Network Information Center (DDN NIC)
ディフェンスデータ網のネットワークインフォメーション・センター(DDN NIC)
The DDN NIC maintains DDN Security bulletins and DDN Management
DDN NICはDDN Security報告とDDN Managementを維持します。
Site Security Policy Handbook Working Group [Page 99] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[99ページ]RFC1244サイトセキュリティハンドブック1991年7月
bulletins online on the machine: NIC.DDN.MIL. They are available
via anonymous FTP. The DDN Security bulletins are in the
directory: SCC, and the DDN Management bulletins are in the
directory: DDN-NEWS.
マシンのオンラインの報告: NIC.DDN.MIL。 それらは公開FTPで利用可能です。 DDN Security報告がディレクトリにあります: SCC、DDN Management報告がディレクトリにある、: DDN-ニュース。
For additional information, you may send a message to:
NIC@NIC.DDN.MIL, or call the DDN NIC at: 1-800-235-3155.
追加情報に関しては、あなたはメッセージを以下に送ることができます。 NIC@NIC.DDN.MIL 、以下でDDN NICに電話をしてください。 1-800-235-3155.
[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]ディフェンスデータ網、「BSD4.2と4.3ソフトウェアの問題解決」、DDN MGT報告#43、DDNはインフォメーション・センター(1988年11月3日)をネットワークでつなぎます。
A Defense Data Network Management Bulletin announcement
on the 4.2bsd and 4.3bsd software fixes to the Internet
worm.
4.2bsdと4.3bsdソフトウェアにおけるDefense Data Network Management Bulletin発表はインターネットワームに固定されます。
[DDN89]
DCA DDN Defense Communications System, "DDN Security
Bulletin 03", DDN Security Coordination Center,
17 October 1989.
[DDN89]DCA DDNディフェンス通信網、「DDN、セキュリティ報告3インチ、DDNセキュリティコーディネートセンター、1989年10月17日、」
IEEE Proceedings
IEEE議事
[IEEE]
"Proceedings of the IEEE Symposium on Security
and Privacy", published annually.
[IEEE] 「セキュリティとプライバシーにおけるIEEEシンポジウムの議事」は毎年発行されました。
IEEE Proceedings are available from:
IEEE Proceedingsは以下から利用可能です。
Computer Society of the IEEE
P.O. Box 80452
Worldway Postal Center
Los Angeles, CA 90080
IEEE私書箱80452のWorldwayの郵便のセンターロサンゼルス、カリフォルニア 90080人のコンピュータ社会
Other Publications:
他の刊行物:
Computer Law and Tax Report
Computers and Security
Security Management Magazine
Journal of Information Systems Management
Data Processing & Communications Security
SIG Security, Audit & Control Review
情報システム管理データと通信秘密保全SIGセキュリティ、監査、およびコントロールレビューのコンピュータ法、税金レポートコンピュータ、およびセキュリティセキュリティ管理雑誌ジャーナル
Site Security Policy Handbook Working Group [Page 100] RFC 1244 Site Security Handbook July 1991
サイト安全保障政策ハンドブックワーキンググループ[100ページ]RFC1244サイトセキュリティハンドブック1991年7月
9. Acknowledgments
9. 承認
Thanks to the SSPHWG's illustrious "Outline Squad", who assembled at USC/Information Sciences Institute on 12-June-90: Ray Bates (ISI), Frank Byrum (DEC), Michael A. Contino (PSU), Dave Dalva (Trusted Information Systems, Inc.), Jim Duncan (Penn State Math Department), Bruce Hamilton (Xerox), Sean Kirkpatrick (Unisys), Tom Longstaff (CIAC/LLNL), Fred Ostapik (SRI/NIC), Keith Pilotti (SAIC), and Bjorn Satdeva (/sys/admin, inc.).
1990年6月12日にUSC/情報Sciences Instituteで集合したSSPHWGの有名な「アウトライン分隊」への感謝: レイ・ベイツ(ISI)、フランク・バイラム(12月)、マイケルA.Contino(PSU)、デーヴDalva(情報システムInc.を信じる)、ジム・ダンカン(ペンシルバニア州立大Math部)、ブルース・ハミルトン(ゼロックス)、ショーン・カークパトリック(ユニシス)、トム・ロングスタッフ(CIAC/LLNL)、フレッドOstapik(SRI/NIC)、キースPilotti(SAIC)、およびビヨンSatdeva(/sys/admin(inc))。
Many thanks to Rich Pethia and the Computer Emergency Response Team (CERT); much of the work by Paul Holbrook was done while he was working for CERT. Rich also provided a very thorough review of this document. Thanks also to Jon Postel and USC/Information Sciences Institute for contributing facilities and moral support to this effort.
リッシュPethiaとコンピュータ緊急対応チーム(CERT)をありがとうございます。 彼がCERTに勤めていた間、ポールHolbrookによる仕事の多くのことをしました。 また、リッシュはこのドキュメントの非常に徹底的なレビューを提供しました。 また、ジョン・ポステルとUSC/情報Sciences Instituteに施設と精神的なサポートをこの取り組みに寄付してくださってありがとうございます。
Last, but NOT least, we would like to thank members of the SSPHWG and Friends for their additional contributions: Vint Cerf (CNRI), Dave Grisham (UNM), Nancy Lee Kirkpatrick (Typist Extraordinaire), Chris McDonald (WSMR), H. Craig McKee (Mitre), Gene Spafford (Purdue), and Aileen Yuan (Mitre).
最も最少でないのにもかかわらず、最後に、彼らの追加貢献についてSSPHWGとFriendsのメンバーに感謝申し上げます: Vintサーフ(CNRI)、デーヴGrisham(UNM)、ナンシー・リー・カークパトリック(並はずれたタイピスト)、クリス・マクドナルド(WSMR)、H.クレイグ・マッキー(斜め継ぎ)、遺伝子Spafford(パドゥー)、およびアイリーンYuan(斜め継ぎ)。
10. Security Considerations
10. セキュリティ問題
If security considerations had not been so widely ignored in the Internet, this memo would not have been possible.
セキュリティ問題がインターネットでそれほど広く無視されなかったなら、このメモは可能ではありませんでした。
11. Authors' Addresses
11. 作者のアドレス
J. Paul Holbrook CICNet, Inc. 2901 Hubbard Ann Arbor, MI 48105
ハバードアナーバー、J.ポールホルブルックCICNet Inc.2901MI 48105
Phone: (313) 998-7680 EMail: holbrook@cic.net
以下に電話をしてください。 (313) 998-7680 メールしてください: holbrook@cic.net
Joyce K. Reynolds University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ジョイスK.レイノルズ南カリフォルニア情報Sciences Institute大学4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (213) 822-1511 EMail: JKREY@ISI.EDU
以下に電話をしてください。 (213) 822-1511 メールしてください: JKREY@ISI.EDU
Site Security Policy Handbook Working Group [Page 101]
サイト安全保障政策ハンドブックワーキンググループ[101ページ]
一覧
スポンサーリンク
