RFC2350 日本語訳
2350 Expectations for Computer Security Incident Response. N.Brownlee, E. Guttman. June 1998. (Format: TXT=86545 bytes) (Also BCP0021) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Brownlee
Request for Comments: 2350 The University of Auckland
BCP: 21 E. Guttman
Category: Best Current Practice Sun Microsystems
June 1998
コメントを求めるワーキンググループN.ブラウンリーの要求をネットワークでつないでください: 2350 オークランド大学BCP: 21E.Guttmanカテゴリ: 最も良い現在の練習サン・マイクロシステムズ1998年6月
Expectations for Computer Security Incident Response
コンピュータセキュリティインシデント応答への期待
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities.
このドキュメントの目的はコンピュータセキュリティ事件対応チーム(CSIRTs)への一般的なインターネットコミュニティの期待を言い表すことです。 1セットのすべてのチームに、適切な要件を定義するのが可能ではありませんが、話題、重要な問題、および一般的な関心を構成している共同体に記載して、説明するのは、可能であって、役立っています。
CSIRT constituents have a legitimate need and right to fully understand the policies and procedures of 'their' Computer Security Incident Response Team. One way to support this understanding is to supply detailed information which users may consider, in the form of a formal template completed by the CSIRT. An outline of such a template and a filled in example are provided.
CSIRT成分には、正統な必要性と'their'のコンピュータSecurity Incident Response Teamの方針と手順を完全に理解する権利があります。 この理解をサポートする1つの方法はどのユーザが考えるかもしれないかという詳細な情報を提供することです、CSIRTによって完成した正式なテンプレートの形で。 そのようなテンプレートのアウトラインと記入された例を提供します。
Table of Contents
目次
1 Introduction ....................................................2
2 Scope............................................................4
2.1 Publishing CSIRT Policies and Procedures ....................4
2.2 Relationships between different CSIRTs ......................5
2.3 Establishing Secure Communications ..........................6
3 Information, Policies and Procedures.............................7
3.1 Obtaining the Document.......................................8
3.2 Contact Information .........................................9
3.3 Charter ....................................................10
3.3.1 Mission Statement.....................................10
3.3.2 Constituency..........................................10
1つの序論…2 2範囲…4 2.1 CSIRT方針と手順を発行します…4 異なったCSIRTsの間の2.2の関係…5 2.3 安全なコミュニケーションを確立します…6 3の情報、方針、および手順…7 3.1 ドキュメントを入手します…8 3.2問い合わせ先…9 3.3 チャーターします。10 3.3 .1 任務声明…10 3.3 .2選挙民…10
Brownlee & Guttman Best Current Practice [Page 1] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[1ページ]。
3.3.3 Sponsoring Organization / Affiliation.................11
3.3.4 Authority.............................................11
3.4 Policies ...................................................11
3.4.1 Types of Incidents and Level of Support...............11
3.4.2 Co-operation, Interaction and Disclosure of
Information...........................................12
3.4.3 Communication and Authentication......................14
3.5 Services ...................................................15
3.5.1 Incident Response ....................................15
3.5.1.1 Incident Triage ..............................15
3.5.1.2 Incident Coordination ........................15
3.5.1.3 Incident Resolution...........................16
3.5.2 Proactive Activities .................................16
3.6 Incident Reporting Forms ...................................16
3.7 Disclaimers ................................................17
Appendix A: Glossary of Terms ....................................18
Appendix B: Related Material .....................................20
Appendix C: Known Computer Security Incident Response Teams ......21
Appendix D: Outline for CSIRT Template ...........................22
Appendix E: Example - 'filled-in' Template for a CSIRT ...........23
4 Acknowlegements ................................................36
5 References .....................................................36
6 Security Considerations ........................................36
7 Authors' Addresses .............................................37
8 Full Copyright Statement .......................................38
3.3.3 組織/提携を後援します…11 3.3 .4権威…11 3.4の方針…11 3.4 .1のタイプのインシデントとサポート水準…11 3.4 情報の.2の協力、相互作用、および公開…12 3.4 .3のコミュニケーションと認証…14 3.5 修理します。15 3.5 .1インシデントレスポンス…15 3.5 .1 .1 付随している選別…15 3.5 .1 .2 付随しているコーディネート…15 3.5 .1 .3の付随している解決…16 3.5 .2 活動を予測してください…16 3.6 付随している報告は形成されます…16 3.7の注意書き…17 付録A: 用語の用語集…18 付録B: 材料を関係づけます…20 付録C: 知られているコンピュータセキュリティインシデント応答は組になります…21 付録D: CSIRTテンプレートのために、概説します。22 付録E: 例--CSIRTのためにテンプレートに'記入します'…23 4Acknowlegements…36 5つの参照箇所…36 6 セキュリティ問題…36 7人の作者のアドレス…37 8 完全な著作権宣言文…38
1 Introduction
1つの序論
The GRIP Working Group was formed to create a document that describes the community's expectations of computer security incident response teams (CSIRTs). Although the need for such a document originated in the general Internet community, the expectations expressed should also closely match those of more restricted communities.
GRIP作業部会は、コンピュータセキュリティインシデント応答チーム(CSIRTs)に共同体の期待を説明するドキュメントを作成するために形成されました。 そのようなドキュメントの必要性は一般的なインターネットコミュニティで起こりましたが、また、言い表された期待は密接にさらに制限された共同体のものに合うべきです。
In the past there have been misunderstandings regarding what to expect from CSIRTs. The goal of this document is to provide a framework for presenting the important subjects (related to incident response) that are of concern to the community.
そこの過去に、CSIRTsから予想するべきことに関する誤解がありました。 このドキュメントの目標は共同体に重要な重大な題目(インシデントレスポンスに関連する)を提示するのにフレームワークを提供することです。
Before continuing, it is important to clearly understand what is meant by the term "Computer Security Incident Response Team." For the purposes of this document, a CSIRT is a team that performs, coordinates, and supports the response to security incidents that involve sites within a defined constituency (see Appendix A for a more complete definition). Any group calling itself a CSIRT for a specific constituency must therefore react to reported security incidents, and to threats to "their" constituency in ways which the specific community agrees to be in its general interest.
続く前に、何が「コンピュータセキュリティインシデント応答チーム」という用語によって意味されるかを明確に理解しているのは重要です。 このドキュメントの目的のために、CSIRTは定義された選挙民の中でサイトにかかわるセキュリティインシデントへの応答を実行して、調整して、サポートするチーム(より完全な定義に関してAppendix Aを見る)です。 したがって、それ自体を特定の有権者にCSIRTと呼ぶどんなグループも、セキュリティインシデントを報告して、一般的興味には特定の共同体が同意する方法で「their」の選挙民への脅威にはあるように反応しなければなりません。
Brownlee & Guttman Best Current Practice [Page 2] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[2ページ]。
Since it is vital that each member of a constituent community be able to understand what is reasonable to expect of their team, a CSIRT should make it clear who belongs to their constituency and define the services the team offers to the community. Additionally, each CSIRT should publish its policies and operating procedures. Similarly, these same constituents need to know what is expected of them in order for them to receive the services of their team. This requires that the team also publish how and where to report incidents.
構成している共同体のそれぞれのメンバーが、何はそれらのチームに予想するのが妥当であるかを理解できるのが、重大であるので、CSIRTはだれが彼らの選挙民のものであるかを断言して、チームが共同体に提供するサービスを定義するはずです。 さらに、各CSIRTは方針と操作手順を発行するはずです。 同様に、これらの同じ成分は、何がそれらのチームのサービスを受けるためにそれらに予想されるかを知る必要があります。 これは、また、チームがインシデントを報告するためにどのように、どこを発行するかを必要とします。
This document details a template which will be used by CSIRTs to communicate this information to their constituents. The constituents should certainly expect a CSIRT to provide the services they describe in the completed template.
このドキュメントはこの情報を彼らの成分に伝えるのにCSIRTsによって使用されるテンプレートについて詳述します。 確かに、成分は、CSIRTがそれらが完成したテンプレートで説明するサービスを提供すると予想するはずです。
It must be emphasized that without active participation from users, the effectiveness of the CSIRT's services can be greatly diminished. This is particularly the case with reporting. At a minimum, users need to know that they should report security incidents, and know how and to where they should report them.
ユーザからの積極的な参加がなければ、CSIRTのサービスの有効性が大いに減少できると強調しなければなりません。 これは特に報告があるそうです。 最小限では、ユーザは、彼らがセキュリティインシデントを報告するべきであるのを知って、どのように、彼らがそれらを報告するべきであるところに知る必要があります。
Many computer security incidents originate outside local community boundaries and affect inside sites, others originate inside the local community and affect hosts or users on the outside. Often, therefore, the handling of security incidents will involve multiple sites and potentially multiple CSIRTs. Resolving these incidents will require cooperation between individual sites and CSIRTs, and between CSIRTs.
多くのコンピュータセキュリティインシデントがローカルの共同体境界の外で起因して、内面のサイトに影響して、他のものは、地方の共同体の中で起因して、外部でホストかユーザに影響します。 したがって、しばしば、セキュリティインシデントの取り扱いは複数のサイトと潜在的に複数のCSIRTsにかかわるでしょう。 これらのインシデントを決議するのは個々のサイトとCSIRTsと、CSIRTsとの協力を必要とするでしょう。
Constituent communities need to know exactly how their CSIRT will be working with other CSIRTs and organizations outside their constituency, and what information will be shared.
構成している共同体は、それらのCSIRTが他のCSIRTsと組織と共に彼らの選挙民の外でちょうどどのように働くだろうか、そして、どんな情報が共有されるかを知る必要があります。
The rest of this document describes the set of topics and issues that CSIRTs need to elaborate for their constituents. However, there is no attempt to specify the "correct" answer to any one topic area. Rather, each topic is discussed in terms of what that topic means.
このドキュメントの残りは話題とCSIRTsが彼らの成分のために詳しく説明する必要がある問題のセットについて説明します。 しかしながら、どんな話題領域の「正しい」答えも指定する試みが全くありません。 むしろ、その自分が意味することで各話題について議論します。
Chapter two provides an overview of three major areas: the publishing of information by a response team, the definition of the response team's relationship to other response teams, and the need for secure communications. Chapter three describes in detail all the types of information that the community needs to know about their response team.
第2章は3つの主要な領域の概要を提供します: 応答チームによる情報の出版、他の応答チームとの応答チームの関係の定義、および安全なコミュニケーションの必要性。 第3章は詳細に、共同体が、彼らの応答チームに関して知る必要があるというすべてのタイプの情報について説明します。
For ease of use by the community, these topics are condensed into an outline template found in Appendix D. This template can be used by constituents to elicit information from their CSIRT.
共同体による使いやすさにおいて、これらの話題はAppendix D.で見つけられたアウトラインテンプレートに凝縮します。Thisテンプレートは成分によって使用されて、それらのCSIRTから情報を引き出すことができます。
Brownlee & Guttman Best Current Practice [Page 3] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[3ページ]。
It is the working group's sincere hope that through clarification of the topics in this document, understanding between the community and its CSIRTs will be increased.
このドキュメントにおける、話題の明確化で、共同体とそのCSIRTsの間で分かるのが増強されるのは、ワーキンググループの心からの望みです。
2 Scope
2 範囲
The interactions between an incident response team and its constituent community response team require first that the community understand the policies and procedures of the response team. Second, since many response teams collaborate to handle incidents, the community must also understand the relationship between their response team and other teams. Finally, many interactions will take advantage of existing public infrastructures, so the community needs to know how those communications will be protected. Each of these subjects will be described in more detail in the following three sections.
インシデントレスポンスチームとその構成している共同体応答チームとの相互作用は、最初に、共同体が応答チームの方針と手順を理解しているのを必要とします。 2番目に、また、多くの応答チームがインシデントを扱うために共同して、共同体はそれらの応答チームと他のチームとの関係を理解しなければなりません。最終的に、多くの相互作用が既存の公共のインフラストラクチャを利用するでしょう、したがって、共同体はそれらのコミュニケーションがどのように保護されるかを知る必要があります。 それぞれのこれらの対象はさらに詳細に以下の3つのセクションで説明されるでしょう。
2.1 Publishing CSIRT Policies and Procedures
2.1 CSIRT方針と手順を発行すること。
Each user who has access to a Computer Security Incident Response Team should know as much as possible about the services of and interactions with this team long before he or she actually needs them.
その人が実際にそれらを必要とするずっと前にこれとのSecurity Incident Response Teamがサービスに関してできるだけ知っているはずであるアクセスをコンピュータに持っている各ユーザと相互作用は組になります。
A clear statement of the policies and procedures of a CSIRT helps the constituent understand how best to report incidents and what support to expect afterwards. Will the CSIRT assist in resolving the incident? Will it provide help in avoiding incidents in the future? Clear expectations, particularly of the limitations of the services provided by a CSIRT, will make interaction with it more efficient and effective.
CSIRTの方針と手順の明確な声明は、成分がどのようにインシデントを最もよく報告するか、そして、その後どんなサポートを予想したらよいかを理解しているのを助けます。 CSIRTは、インシデントを決議するのを助けるでしょうか? それは将来インシデントを避けるのに助けを提供するでしょうか? それが、より効率的であって、効果的な状態で明確な期待は特にCSIRTによって提供されたサービスの制限で相互作用を作るでしょう。
There are different kinds of response teams: some have very broad constituencies (e.g., CERT Coordination Center and the Internet), others have more bounded constituencies (e.g., DFN-CERT, CIAC), and still others have very restricted constituencies (e.g., commercial response teams, corporate response teams). Regardless of the type of response team, the constituency supported by it must be knowledgeable about the team's policies and procedures. Therefore, it is mandatory that response teams publish such information to their constituency.
異種の応答チームがあります: 或るものには、非常に広い選挙民(例えば、CERTコーディネートセンターとインターネット)がいます、そして、他のものには、より境界がある選挙民(例えば、DFN-CERT、CIAC)がいます、そして、それでも、他のものには、非常に制限された選挙民(例えば商業応答は組になります、法人の応答チーム)がいます。 応答チームのタイプにかかわらず、それによってサポートされた選挙民はチームの方針と手順に関して博識であるに違いありません。 したがって、応答チームがそのような情報を彼らの選挙民に発表するのは、義務的です。
A CSIRT should communicate all necessary information about its policies and services in a form suitable to the needs of its constituency. It is important to understand that not all policies and procedures need be publicly available. For example, it is not necessary to understand the internal operation of a team in order to interact with it, as when reporting an incident or receiving guidance on how to analyze or secure one's systems.
CSIRTは選挙民の必要性に適したフォームでその方針とサービスに関するすべての必要事項を伝えるはずです。 方針と手順が必要とするというわけではないすべてが公的に利用可能であることを理解しているのは重要です。 例えば、チームの内部の操作を理解するのはそれと対話するのに必要ではありません、人のシステムを分析するか、またはどう固定するかに関してインシデントを報告するか、または指導を受けながらいつとして。
Brownlee & Guttman Best Current Practice [Page 4] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[4ページ]。
In the past, some teams supplied a kind of Operational Framework, others provided a Frequently Asked Questions list (FAQ), while still others wrote papers for distribution at user conferences or sent newsletters.
過去に、いくつかのチームが一種のOperational Frameworkを供給しました、と他のものはよく出る質問リスト(FAQ)を前提としました、それでも、他のものが、分配のためにユーザ会議に論文を書いたか、またはニュースレターを送りましたが。
We recommend that each CSIRT publish its guidelines and procedures on its own information server (e.g. a World Wide Web server). This would allow constituents to easily access it, though the problem remains of how a constituent can find his or her team; people within the constituency have to discover that there is a CSIRT "at their disposal."
私たちは、各CSIRTがそれ自身の情報サーバ(例えば、WWWサーバ)のそのガイドラインと手順を発表することを勧めます。 これで、成分は容易にそれにアクセスできるでしょう、成分がどうその人のチームを見つけることができるかに関する問題の残りですが。 選挙民の中の人々は、「彼らの自由」にはCSIRTがあると発見しなければなりません。
It is foreseen that completed CSIRT templates will soon become searchable by modern search engines, which will aid in distributing information about the existence of CSIRTs and basic information required to approach them.
完成したCSIRTテンプレートがすぐCSIRTsの存在に関する情報伝達で支援される現代のサーチエンジンで探せるようになるのを見通されて、基本情報が彼らにアプローチするのが必要です。
It would be very useful to have a central repository containing all the completed CSIRT templates. No such repository exists at the time of writing, though this might change in the future.
すべての完成したCSIRTテンプレートを含む中央倉庫を持っているのは非常に役に立つでしょう。 どんなそのような倉庫もこれが将来、変化するかもしれませんが、書く時点で、存在しません。
Regardless of the source from which the information is retrieved, the user of the template must check its authenticity. It is highly recommended that such vital documents be protected by digital signatures. These will allow the user to verify that the template was indeed published by the CSIRT and that it has not been tampered with. This document assumes the reader is familiar with the proper use of digital signatures to determine whether a document is authentic.
情報が検索されるソースにかかわらず、テンプレートのユーザは信憑性をチェックしなければなりません。 そのような重大なドキュメントがデジタル署名で保護されるのは、非常にお勧めです。 これらで、ユーザは、本当に、テンプレートがCSIRTによって発行されて、それがいじられていないことを確かめることができるでしょう。 このドキュメントは、ドキュメントが正統であるかどうか決定するために読者がデジタル署名の適切な使用に詳しいと仮定します。
2.2 Relationships between different CSIRTs
2.2 異なったCSIRTsの間の関係
In some cases a CSIRT may be able to operate effectively on its own and in close cooperation with its constituency. But with today's international networks it is much more likely that most of the incidents handled by a CSIRT will involve parties external to its constituency. Therefore the team will need to interact with other CSIRTs and sites outside its constituency.
いくつかの場合、CSIRTはそれ自身と緊密に提携してその選挙民と共に有効に作動できるかもしれません。 しかし、今日の国際ネットワークと共に、CSIRTによって扱われたインシデントの大部分は選挙民にとっての、外部のパーティーにはるかにかかわりそうでしょう。 したがって、チームは、選挙民の外で他のCSIRTsとサイトと対話する必要があるでしょう。
The constituent community should understand the nature and extent of this collaboration, as very sensitive information about individual constituents may be disclosed in the process.
構成している共同体はこの共同の自然と範囲を理解するべきです、個々の成分の非常に機密の情報がプロセスで明らかにされるかもしれないように。
Inter-CSIRT interactions could include asking other teams for advice, disseminating knowledge of problems, and working cooperatively to resolve a security incident affecting one or more of the CSIRTs' constituencies.
相互CSIRT相互作用は、他のチームにアドバイスを求めるのを含むかもしれません、CSIRTsの選挙民のより多くのひとりに影響するセキュリティインシデントを決議するために問題に関する知識を広めて、協力して働いていて。
Brownlee & Guttman Best Current Practice [Page 5] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[5ページ]。
In establishing relationships to support such interactions, CSIRTs must decide what kinds of agreements can exist between them so as to share yet safeguard information, whether this relationship can be disclosed, and if so to whom.
そのような相互作用をサポートするために関係を確立する際に、CSIRTsは、どんな種類の協定が情報を共有しますが、保護するためにそれらの間に存在できるかを決めなければなりません、この関係が明らかにされて、そうだとすれば、だれにそうすることができるかか否かに関係なく。
Note that there is a difference between a peering agreement, where the CSIRTs involved agree to work together and share information, and simple co-operation, where a CSIRT (or any other organization) simply contacts another CSIRT and asks for help or advice.
じっと見る協定と、簡単な協力の違いがあることに注意してください。そこでは、かかわったCSIRTsが情報を一緒に扱って、共有するのに同意します。(そこでは、CSIRT(または、いかなる他の組織)は単に別のCSIRTに連絡して、助けかアドバイスを求めます)。
Although the establishment of such relationships is very important and affects the ability of a CSIRT to support its constituency, it is up to the teams involved to decide about the details. It is beyond the scope of this document to make recommendations for this process. However, the same set of information used to set expectations for a user community regarding sharing of information will help other parties to understand the objectives and services of a specific CSIRT, supporting a first contact.
そのような関係の設立は、非常に重要であり、CSIRTが選挙民をサポートする能力に影響しますが、それは詳細に関して決めるためにかかわるチーム次第です。 それは、このプロセスのための推薦状をするようにこのドキュメントの範囲を超えています。 しかしながら、情報の共有に関してユーザーコミュニティへの期待を設定するのに使用される同じセットの情報は、相手が特定のCSIRTの目的とサービスを理解しているのを助けるでしょう、最初の接触をサポートして。
2.3 Establishing Secure Communications
2.3 安全なコミュニケーションを確立すること。
Once one party has decided to share information with another party, or two parties have agreed to share information or work together - as required for the coordination of computer security incident response - all parties involved need secure communications channels. (In this context, "secure" refers to the protected transmission of information shared between different parties, and not to the appropriate use of the information by the parties.)
一度..パーティー..決める..共有..情報..パーティー..パーティー..同意..共有..情報..働く..一緒に..必要に応じて..コーディネート..コンピュータセキュリティインシデント..応答..パーティー..かかわる..必要..安全..コミュニケーション..チャンネル (このような関係においては、「安全」はパーティーによる情報の適切な使用ではなく、異なったパーティーの間で共有された情報の保護された伝達を示します。)
The goals of secure communication are:
安全なコミュニケーションの目標は以下の通りです。
- Confidentiality:
Can somebody else access the content of the communication?
- 秘密性: 他の誰かがコミュニケーションの内容にアクセスできますか?
- Integrity:
Can somebody else manipulate the content of the communication?
- 保全: 他の誰かがコミュニケーションの内容を操ることができますか?
- Authenticity:
Am I communicating with the "right" person?
- 信憑性: 私は「正しい」人とコミュニケートしていますか?
It is very easy to send forged e-mail, and not hard to establish a (false) identity by telephone. Cryptographic techniques, for example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) can provide effective ways of securing e-mail. With the correct equipment it is also possible to secure telephone communication. But before using such mechanisms, both parties need the "right" infrastructure, which is to say preparation in advance. The most important preparation is ensuring the authenticity of the
電話で(誤っている)のアイデンティティを確立するのは、偽造メールを非常に送りやすくて、困難ではありません。 暗号のテクニックであり、例えば、プリティ・グッド・プライバシ(PGP)かPrivacy Enhancedメール(PEM)がメールを保証する効果的な方法を提供できます。 また、正しい設備では、電話コミュニケーションを保証するのも可能です。 しかし、そのようなメカニズムを使用する前に、双方はあらかじめ準備を言うことである「正しい」インフラストラクチャを必要とします。 最も重要な準備は信憑性を確実にしています。
Brownlee & Guttman Best Current Practice [Page 6] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[6ページ]。
cryptographic keys used in secure communication:
安全なコミュニケーションで使用される暗号化キー:
- Public keys (for techniques like PGP and PEM):
Because they are accessible through the Internet, public keys must
be authenticated before use. While PGP relies on a "Web of Trust"
(where users sign the keys of other users), PEM relies on a
hierarchy (where certification authorities sign the keys of users).
- 公開鍵(PGPとPEMのようなテクニックのための): それらがインターネットを通してアクセスしやすいので、使用の前に公開鍵を認証しなければなりません。 PGPは「信用のウェブ」(ユーザが他のユーザのキーにサインするところ)を当てにしますが、PEMは階層構造(証明当局がユーザのキーにサインするところ)を当てにします。
- Secret keys (for techniques like DES and PGP/conventional
encryption): Because these must be known to both sender and
receiver, secret keys must be exchanged before the communication
via a secure channel.
- 秘密鍵(DESとPGP/従来の暗号化のようなテクニックのための): 送付者と受信機の両方にこれらを知っていなければならないので、コミュニケーションの前に安全なチャンネルで秘密鍵を交換しなければなりません。
Communication is critical to all aspects of incident response. A team can best support the use of the above-mentioned techniques by gathering all relevant information, in a consistent way. Specific requirements (such as calling a specific number to check the authenticity of keys) should be clear from the start. CSIRT templates provide a standardized vehicle for delivering this information.
コミュニケーションはインシデントレスポンスの全面に重要です。 チームは、一貫した方法ですべての関連情報を集めることによって、上記のテクニックの使用を最もよく支持できます。 決められた一定の要求(キーの信憑性をチェックするために特定の数に電話をすることなどの)は始めによって明確であるはずです。 CSIRTテンプレートはこの情報を送るための標準化された乗り物を提供します。
It is beyond the scope of this document to address the technical and administrative problems of secure communications. The point is that response teams must support and use a method to secure the communications between themselves and their constituents (or other response teams). Whatever the mechanism is, the level of protection it provides must be acceptable to the constituent community.
それは、安全なコミュニケーションのその技術的で管理の問題を訴えるためにこのドキュメントの範囲を超えています。 ポイントは応答チームが自分たちのコミュニケーションを保証する方法とそれらの成分(または、他の応答チーム)を支持して、使用しなければならないということです。 メカニズムが何であっても、それが提供する保護のレベルは構成している共同体に許容しているに違いありません。
3 Information, Policies and Procedures
3 情報、方針、および手順
In chapter 2 it was mentioned that the policies and procedures of a response team need to be published to their constituent community. In this chapter we will list all the types of information that the community needs to receive from its response team. How this information is communicated to a community will differ from team to team, as will the specific information content. The intent here is to clearly describe the various kinds of information that a constituent community expects from its response team.
第2章では、応答チームの方針と手順が、それらの構成している共同体に発行される必要であると言及されました。 本章では、私たちは共同体が、応答チームから受信する必要があるというすべてのタイプの情報をリストアップするつもりです。 この情報がどう共同体に伝えられるかが特殊情報内容のように組にするチームと異なるでしょう。 ここの意図は明確に、構成している共同体が応答チームから予想する様々な種類の情報について説明することです。
To make it easier to understand the issues and topics relevant to the interaction of constituents with "their" CSIRT, we suggest that a CSIRT publish all information, policies, and procedures addressing its constituency as a document, following the template given in Appendix D. The template structure arranges items, making it easy to supply specific information; in Appendix E we provide an example of a filled-out template for the fictitious XYZ University. While no recommendations are made as to what a CSIRT should adopt for its policy or procedures, different possibilities are outlined to give
「their」のCSIRTとの成分の相互作用に関連している問題と話題を理解しているのをより簡単にするように、私たちは、CSIRTがドキュメントとして選挙民に演説するすべての情報、方針、および手順を発表することを提案して、Appendix D.で与えられたテンプレートに続いて、テンプレート構造は項目を手配します、特殊情報を提供するのを簡単にして。 Appendix Eでは、私たちは書き込んでいるテンプレートに関する例を架空のXYZ大学に提供します。 何に、CSIRTがその方針か手順のために採用するはずであり、異なった可能性があるかとして与えるために概説されていた状態で推薦状を全くしませんが
Brownlee & Guttman Best Current Practice [Page 7] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[7ページ]。
some examples. The most important thing is that a CSIRT have a policy and that those who interact with the CSIRT be able to obtain and understand it.
いくつかの例。 最も重要なものはCSIRTには方針があって、CSIRTと対話する人がそれを得て、理解できるということです。
As always, not every aspect for every environment and/or team can be covered. This outline should be seen as a suggestion. Each team should feel free to include whatever they think is necessary to support its constituency.
いつものように、あらゆる環境、そして/または、チームのためのあらゆる局面をカバーできるというわけではありません。 このアウトラインは提案と考えられるべきです。 各チームは遠慮なく、彼らが選挙民を支持するのに必要であると考えることなら何でも含むべきです。
3.1 Obtaining the Document
3.1 ドキュメントを入手すること。
Details of a CSIRT change with time, so the completed template must indicate when it was last changed. Additionally, information should be provided concerning how to find out about future updates. Without this, it is inevitable that misunderstandings and misconceptions will arise over time; outdated documents can do more harm than good.
CSIRTの細部が時間を交換するので、完成したテンプレートは、それが最後にいつ変えられたかを示さなければなりません。 さらに、どう将来のアップデートを見つけるかに関して情報を提供するべきです。 これがなければ、誤解と誤解が時間がたつにつれて起こるのは、必然です。 時代遅れのドキュメントに利益より危害を加えることができます。
- Date of last update This should be sufficient to allow
anyone interested to evaluate the
currency of the template.
- アップデートThisの期日は、テンプレートの通貨を評価したがっていただれでも許容するために十分であるべきです。
- Distribution list Mailing lists are a convenient
mechanism to distribute up-to-date
information to a large number of
users. A team can decide to use its
own or an already existing list to
notify users whenever the document
changes. The list might normally be
groups the CSIRT has frequent
interactions with.
- 発送先リストMailingリストは多くのユーザに最新情報を分配する便利なメカニズムです。 チームは、ドキュメントが変化するときはいつも、ユーザに通知するのにそれ自身か既に既存のリストを使用すると決めることができます。 通常、リストはCSIRTには頻繁な相互作用があるグループであるかもしれません。
Digital signatures should be used
for update messages sent by a CSIRT.
デジタル署名はCSIRTによって送られたアップデートメッセージに使用されるべきです。
- Location of the document The location where a current version
of the document is accessible through
a team's online information services.
Constituents can then easily learn
more about the team and check for
recent updates. This online version
should also be accompanied by a
digital signature.
- 位置、ドキュメントの最新版がチームのオンライン情報サービスでアクセスしやすい位置を記録してください。 成分は、次に、チームに関して容易にもう少し学んで、最近のアップデートがないかどうかチェックできます。 また、デジタル署名でこのオンラインバージョンは伴われるべきです。
Brownlee & Guttman Best Current Practice [Page 8] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[8ページ]。
3.2 Contact Information
3.2 問い合わせ先
Full details of how to contact the CSIRT should be listed here, although this might be very different for different teams; for example, some might choose not to publicize the names of their team members. No further clarification is given when the meaning of the item can be assumed.
どうCSIRTに連絡するかに関する一部始終はここに記載されているべきです、異なったチームにおいて、これが非常に異なるかもしれませんが。 例えば、或るものは、彼らのチームメンバーの名前についてピーアールしないのを選ぶかもしれません。 項目の意味を想定できるとき、さらなる明確化を全く与えません。
- Name of the CSIRT
- CSIRTという名前
- Mailing Address
- 郵送先住所
- Time zone This is useful for coordinating
incidents which cross time zones.
- 時間帯のThisは時間帯に交差する事件を調整することの役に立ちます。
- Telephone number
- 電話番号
- Facsimile number
- ファクシミリ番号
- Other telecommunication Some teams might provide secure
voice communication (e.g. STU III).
- 他の電気通信Someチームは秘密音声コミュニケーション(例えば、STU III)を提供するかもしれません。
- Electronic mail address
- 電子メールアドレス
- Public keys and encryption The use of specific techniques
depends on the ability of the
communication partners to have
access to programs, keys and so on.
Relevant information should be
given to enable users to determine
if and how they can make use of
encrypted communication while
interacting with the CSIRT.
- Team members
- 特定のテクニックの使用がコミュニケーションパートナーがプログラム、キー、およびそうに近づく手段を持つ能力に依存する公開鍵と暗号化。 CSIRTと対話している間、確認するユーザと彼らがどう暗号化通信を利用できるかを可能にするために関連情報を与えるべきです。 - チームメンバー
- Operating Hours The operating hours and holiday
schedule should be provided here.
Is there a 24 hour hotline?
- 営業時間と休日が計画をする操作Hoursをここに提供するべきです。 24時間のホットラインがありますか?
- Additional Contact Info Is there any specific customer
contact info?
- 追加Contact Info Is、そこに、何か特定の顧客がインフォメーションに連絡しますか?
More detailed contact information can be provided. This might include different contacts for different services, or might be a list of online information services. If specific procedures for access to some services exist (for example addresses for mailing list requests), these should be explained here.
より詳細な問い合わせ先を提供できます。 これは、異なったサービスのために異なった接触を含むかもしれないか、またはオンライン情報サービスのリストであるかもしれません。 いくつかのサービスへのアクセスのための特定の手順が存在しているなら(例えば、メーリングリスト要求のためのアドレス)、これらはここで説明されるべきです。
Brownlee & Guttman Best Current Practice [Page 9] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[9ページ]。
3.3 Charter
3.3 憲章
Every CSIRT must have a charter which specifies what it is to do, and the authority under which it will do it. The charter should include at least the following items:
あらゆるCSIRTには、それが何をすることになっているかを指定する特許、およびそれがそれをする権威がなければなりません。 特許は少なくとも以下の項目を含むべきです:
- Mission statement - Constituency - Sponsorship / affiliation - Authority
- 使命記述書--選挙民--スポンサーシップ/提携--権威
3.3.1 Mission Statement
3.3.1 使命記述書
The mission statement should focus on the team's core activities, already stated in the definition of a CSIRT. In order to be considered a Computer Security Incident Response Team, the team must support the reporting of incidents and support its constituency by dealing with incidents.
使命記述書はCSIRTの定義で既に述べられたチームの中心的活動に焦点を合わせるべきです。 コンピュータSecurity Incident Response Teamであると考えられるために、チームは、事件の報告を支持して、事件に対処することによって、選挙民を支持しなければなりません。
The goals and purposes of a team are especially important, and require clear, unambiguous definition.
チームの目標と目的は、特に重要であり、明確で、明白な定義を必要とします。
3.3.2 Constituency
3.3.2 選挙民
A CSIRT's constituency can be determined in any of several ways. For example it could be a company's employees or its paid subscribers, or it could be defined in terms of a technological focus, such as the users of a particular operating system.
CSIRTの選挙民はいくつかの方法について少しも決定できます。 例えば、それは、会社の従業員かその支払われた加入者であるかもしれませんか技術的な焦点に関してそれを定義できました、特定のオペレーティングシステムのユーザなどのように。
The definition of the constituency should create a perimeter around the group to whom the team will provide service. The policy section of the document (see below) should explain how requests from outside this perimeter will be handled.
選挙民の定義はチームがサービスを提供するグループの周りの周辺を作成するべきです。 ドキュメント(以下を見る)の方針部はこの周辺の外からの要求がどう扱われるかを説明するべきです。
If a CSIRT decides not to disclose its constituency, it should explain the reasoning behind this decision. For example, for-fee CSIRTs will not list their clients but will declare that they provide a service to a large group of customers that are kept confidential because of the clients' contracts.
CSIRTが、選挙民を明らかにしないと決めるなら、それで、この決定の後ろで推理がわかるべきです。 例えば、料金のためのCSIRTsは、彼らのクライアントを記載しませんが、彼らがクライアントの契約のために秘密にされる顧客の大きいグループに対するサービスを提供すると宣言するでしょう。
Constituencies might overlap, as when an ISP provides a CSIRT which delivers services to customer sites that also have CSIRTs. The Authority section of the CSIRT's description (see below) should make such relationships clear.
選挙民はISPがまた、CSIRTsを持っている顧客サイトに対するサービスを提供するCSIRTを提供する時として重なるかもしれません。 CSIRTの記述(以下を見る)のAuthority部はそのような関係を明らかにするべきです。
Brownlee & Guttman Best Current Practice [Page 10] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[10ページ]。
3.3.3 Sponsoring Organization / Affiliation
3.3.3 組織/提携を後援すること。
The sponsoring organization, which authorizes the actions of the CSIRT, should be given next. Knowing this will help the users to understand the background and set-up of the CSIRT, and it is vital information for building trust between a constituent and a CSIRT.
次に、後援組織(CSIRTの機能を認可する)を与えるべきです。 これを知っているのは、ユーザがCSIRTのバックグラウンドとセットアップを理解しているのを助けるでしょう、そして、それは、成分とCSIRTの間で信頼を築き上げるための極めて重要な情報です。
3.3.4 Authority
3.3.4 権威
This section will vary greatly from one CSIRT to another, based on the relationship between the team and its constituency. While an organizational CSIRT will be given its authority by the management of the organization, a community CSIRT will be supported and chosen by the community, usually in a advisory role.
このセクションはチームとその選挙民との関係に基づいて1CSIRTから別のものに大いに異なるでしょう。 組織的なCSIRTがそうになる間、組織、共同体の管理による権威を考えて、CSIRTは共同体によって支持されて、選ばれるでしょう、通常、顧問役割で。
A CSIRT may or may not have the authority to intervene in the operation of all of the systems within its perimeter. It should identify the scope of its control as distinct from the perimeter of its constituency. If other CSIRTs operate hierarchically within its perimeter, this should be mentioned here, and the related CSIRTs identified.
CSIRTには、周辺の中でシステムのすべての操作を干渉する権威があるかもしれません。 それは、コントロールの範囲が選挙民の周辺と異なっていると認識するべきです。 他のCSIRTsが周辺の中で階層的で作動するなら、これは、ここで言及されていて特定された関連するCSIRTsであるべきです。
Disclosure of a team's authority may expose it to claims of liability. Every team should seek legal advice on these matters. (See section 3.7 for more on liability.)
チームの権威の公開は責任のクレームにそれを露出するかもしれません。 あらゆるチームがこれらの件で弁護士の意見を求めるべきです。 (詳しい情報については、責任でセクション3.7を見てください。)
3.4 Policies
3.4の方針
It is critical that Incident Response Teams define their policies. The following sections discuss communication of these policies to the constituent community.
Incident Response Teamsが彼らの方針を定義するのは、批判的です。 以下のセクションはこれらの方針に関するコミュニケーションについて構成している共同体に論じます。
3.4.1 Types of Incidents and Level of Support
3.4.1 事件とサポート水準のタイプ
The types of incident which the team is able to address, and the level of support which the team will offer when responding to each type of incident, should be summarized here in list form. The Services section (see below) provides the opportunity to give more detailed descriptions, and to address non-incident-related topics.
チームが演説できる事件のタイプ、および応じるときチームがそれぞれタイプすると申し出る事件のサポート水準はここ、リスト形式でまとめられるべきです。 Services部(以下を見る)は、より詳細な記述を与えて、非事件関連の話題を記述する機会を提供します。
The level of support may change depending on factors such as the team's workload and the completeness of the information available. Such factors should be outlined and their impact should be explained. As a list of known types of incidents will be incomplete with regard to possible or future incidents, a CSIRT should also give some background on the "default" support for incident types not otherwise mentioned.
チームのワークロードや利用可能な情報の完全性などの要素によって、サポート水準は変化するかもしれません。 そのような要素は概説されているべきです、そして、それらの衝撃は説明されるべきです。 また、知られているタイプの事件のリストが可能であるか将来の事件に関して不完全になるとき、CSIRTは別の方法で言及されなかった付随しているタイプの「デフォルト」サポートのときに何らかのバックグラウンドを与えるはずです。
Brownlee & Guttman Best Current Practice [Page 11] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[11ページ]。
The team should state whether it will act on information it receives about vulnerabilities which create opportunities for future incidents. A commitment to act on such information on behalf of its constituency is regarded as an optional proactive service policy rather than a core service requirement for a CSIRT.
チームは、それが将来の事件の機会を作成する脆弱性に関して受け取る情報に影響するかどうかと述べるべきです。 選挙民を代表してそのような情報に影響する委任はCSIRTのためのコアサービス要件よりむしろ任意の先を見越すサービス方策と見なされます。
3.4.2 Co-operation, Interaction and Disclosure of Information
3.4.2 情報の協力、相互作用、および公開
This section should make explicit which related groups the CSIRT routinely interacts with. Such interactions are not necessarily related to the computer security incident response provided, but are used to facilitate better cooperation on technical topics or services. By no means need details about cooperation agreements be given out; the main objective of this section is to give the constituency a basic understanding of what kind of interactions are established and what their purpose is.
このセクションはCSIRTがきまりきって対話するどの関係団体を明白にするべきであるか。 そのような相互作用は、必ず提供されたコンピュータセキュリティインシデント応答に関連されるというわけではありませんが、技術的な話題かサービスのときに、より良い協力を容易にするのに使用されます。 協力協定に関する詳細を決して、発表する必要はありません。 このセクションの主な目標はどういう相互作用が設立されるか、そして、それらの目的が何であるかに関する基本的了解事項を選挙民に与えることです。
Cooperation between CSIRTs can be facilitated by the use of unique ticket number assignment combined with explicit handoff procedures. This reduces the chance of misunderstandings, duplications of effort, assists in incident tracking and prevents 'loops' in communication.
明白な移管手順に結合されたユニークなチケット数の課題の使用でCSIRTsの間の協力を容易にすることができます。 これは、コミュニケーションで誤解の機会、努力の複製を抑えて、付随している追跡を助けて、'輪'を防ぎます。
The reporting and disclosure policy should make clear who will be the recipients of a CSIRT's report in each circumstance. It should also note whether the team will expect to operate through another CSIRT or directly with a member of another constituency over matters specifically concerning that member.
だれが各状況におけるCSIRTのレポートの受取人になるかが明確に報告と公開方針は作るべきです。 また、それは、チームが、別のCSIRTか直接別の選挙民のメンバーと共に件の上で特にそのメンバーに関して作動すると予想するかどうかに注意するべきです。
Related groups a CSIRT will interact with are listed below:
CSIRTが対話する関係団体は以下に記載されています:
Incident Response Teams:
A CSIRT will often need to interact with other CSIRTs. For
example a CSIRT within a large company may need to report
incidents to a national CSIRT, and a national CSIRT may need to
report incidents to national CSIRTs in other countries to deal
with all sites involved in a large-scale attack.
インシデントレスポンスチーム: CSIRTは、しばしば他のCSIRTsと対話する必要があるでしょう。 例えば、大企業の中のCSIRTは、国家のCSIRTにインシデントを報告する必要があるかもしれません、そして、国家のCSIRTは大規模な攻撃にかかわるすべてのサイトに対処するために他国で国家のCSIRTsにインシデントを報告する必要があるかもしれません。
Collaboration between CSIRTs may lead to disclosure of
information. The following are examples of such disclosure, but
are not intended to be an exhaustive list:
CSIRTsの間の共同は情報の公開につながるかもしれません。 以下は、そのような公開に関する例ですが、完全なりストであることを意図しません:
- Reporting incidents within the constituency to other teams.
If this is done, site-related information may become public
knowledge, accessible to everyone, in particular the press.
- 選挙民の中でインシデントを他に報告するのは組になります。これが完了しているなら、サイト関連の情報は世間一般に知れ渡るかもしれません、皆、特にプレスに、アクセスしやすいです。
- Handling incidents occurring within the constituency, but
reported from outside it (which implies that some information
has already been disclosed off-site).
- それ(何らかの情報が既に明らかにされたオフサイトであることを含意する)の外から選挙民の中に起こりますが、報告されたインシデントを扱います。
Brownlee & Guttman Best Current Practice [Page 12] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[12ページ]。
- Reporting observations from within the constituency indicating
suspected or confirmed incidents outside it.
- 選挙民からの観測が示していると報告するのが、それの外でインシデントを疑ったか、または確認しました。
- Acting on reports of incidents from outside the constituency.
- 選挙民の外からインシデントのレポートに影響します。
- Passing information about vulnerabilities to vendors, to
partner CSIRTs or directly to affected sites lying within or
outside the constituency.
- CSIRTsを組ませるために脆弱性の情報をベンダーに通過するか、または選挙民以内か選挙民の外に直接関係部位に横たわっています。
- Feedback to parties reporting incidents or vulnerabilities.
- インシデントか脆弱性を報告するパーティーへのフィードバック。
- The provision of contact information relating to members of
the constituency, members of other constituencies, other
CSIRTs, or law-enforcement agencies.
- 選挙民のメンバー、他の選挙民のメンバー、他のCSIRTsに関連する問い合わせ先か警察機関の設備。
Vendors:
Some vendors have their own CSIRTs, but some vendors may not. In
such cases a CSIRT will need to work directly with a vendor to
suggest improvements or modifications, to analyze the technical
problem or to test provided solutions. Vendors play a special
role in handling an incident if their products' vulnerabilities
are involved in the incident.
ベンダー: いくつかのベンダーにはそれら自身のCSIRTsがありますが、持っているというわけではないベンダーもあるかもしれません。 そのような場合CSIRTは、改良か変更を示すか、技術的問題を分析するか、または提供されたソリューションをテストするために直接ベンダーと共に働く必要があるでしょう。 ベンダーはそれらの製品の脆弱性がインシデントにかかわるならインシデントを扱うことにおける特別な役割を果たします。
Law-enforcement agencies:
These include the police and other investigative agencies. CSIRTs
and users of the template should be sensitive to local laws and
regulations, which may vary considerably in different countries.
A CSIRT might advise on technical details of attacks or seek
advice on the legal implications of an incident. Local laws and
regulations may include specific reporting and confidentiality
requirements.
警察機関: これらは警察と他の調査の政府機関を含んでいます。 テンプレートのCSIRTsとユーザは地域法と規則に敏感であるべきです。(規則は異なった国でかなり異なるかもしれません)。 CSIRTは攻撃に関する技術的詳細について助言を与えるか、またはインシデントの法的な含意で助言を求めるかもしれません。 地域法と規則は特定の報告と機密保持の要求事項を含むかもしれません。
Press:
A CSIRT may be approached by the press for information and comment
from time to time.
以下を押してください。 CSIRTには、プレスからの接触が情報とコメントのために時々あるかもしれません。
An explicit policy concerning disclosure to the press can be
helpful, particularly in clarifying the expectations of a CSIRT's
constituency. The press policy will have to clarify the same
topics as above more specifically, as the constituency will
usually be very sensitive to press contacts.
プレスへの公開に関する明白な方針は特にCSIRTの選挙民への期待をはっきりさせる際に役立っている場合があります。 プレス方針は、より明確に上の同じ話題をはっきりさせなければならないでしょう、選挙民が接触を押すために通常非常に敏感になるとき。
Other:
This might include research activities or the relation to the
sponsoring organization.
他: これは後援組織との研究活動か関係を含むかもしれません。
Brownlee & Guttman Best Current Practice [Page 13] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[13ページ]。
The default status of any and all security-related information which a team receives will usually be 'confidential,' but rigid adherence to this makes the team to appear to be an informational 'black hole,' which may reduce the likelihood of the team's obtaining cooperation from clients and from other organizations. The CSIRT's template should define what information it will report or disclose, to whom, and when.
チームが受け取るありとあらゆるセキュリティ関連の情報のデフォルト状態は通常'秘密でしょう'が、これへの堅い固守は、クライアントと他の組織からのチームが協力を得るという見込みを減少させるかもしれない情報の'ブラックホール'であるように見えるためにチームを作ります。 CSIRTのテンプレートはそれがどんな情報をだれに報告するか、または明らかにするだろうか、そして、いつかを定義するはずです。
Different teams are likely to be subject to different legal restraints requiring or limiting disclosure, especially if they work in different jurisdictions. In addition, they may have reporting requirements imposed by their sponsoring organization. Each team's template should specify any such constraints, both to clarify users' expectations and to inform other teams.
異なったチームは公開を必要である、または制限する異なった法的な抑制を受けることがある傾向があります、特に異なった管内で働いているなら。 さらに、組織を後援することによって、彼らは報告要件を課させるかもしれません。 各チームのテンプレートは、ともにユーザの期待をはっきりさせて、他のチームに知らせるためにどんなそのような規制も指定するはずです。
Conflicts of interest, particularly in commercial matters, may also restrain disclosure by a team; this document does not recommend on how such conflicts should be addressed.
また、特に商業件に関して、利害対立はチームによる公開を抑制するかもしれません。 そのようなものがどう闘争するかに関してドキュメントが推薦しないこれは扱われるべきです。
A team will normally collect statistics. If statistical information is distributed, the template's reporting and disclosure policy should say so, and should describe how to obtain such statistics.
通常、チームは統計を集めるでしょう。 統計情報が分配されているなら、テンプレートの報告と公開方針は、そのように言うべきであり、そのような統計を得る方法を説明するべきです。
3.4.3 Communication and Authentication
3.4.3 コミュニケーションと認証
You must have a policy which describes methods of secure and verifiable communication that you will use. This is necessary for communication between CSIRTs and between a CSIRT and its constituents. The template should include public keys or pointers to them, including key fingerprints, together with guidelines on how to use this information to check authenticity and how to deal with corrupted information (for example where to report this fact).
あなたには、あなたが使用する安全で証明可能なコミュニケーションのメソッドを説明する方針がなければなりません。 これがCSIRTsとCSIRTとその成分とのコミュニケーションに必要です。 テンプレートは公開鍵か指針をそれらに含めるはずです、主要な指紋を含んでいて、信憑性をチェックするのにどのようにこの情報を使用するか、そして、どのように崩壊した情報に対処するかに関する(例えば、どこで、この事実を報告しますか)ガイドラインと共に。
At the moment it is recommended that as a minimum every CSIRT have (if possible), a PGP key available. A team may also make other mechanisms available (for example PEM, MOSS, S/MIME), according to its needs and the needs of its constituents. Note however, that CSIRTs and users should be sensitive to local laws and regulations. Some countries do not allow strong encryption, or enforce specific policies on the use of encryption technology. In addition to encrypting sensitive information whenever possible, correspondence should include digital signatures. (Please note that in most countries, the protection of authenticity by using digital signatures is not affected by existing encryption regulations.)
現在、それは最小限としてあらゆるCSIRTには(できれば)利用可能なPGPキーがあることが勧められます。 また、チームは他のメカニズムを利用可能に(例えば、PEM、モス、S/MIME)するかもしれません、必要性と成分の必要性に従って。 しかしながら、そのCSIRTsとユーザが地域法と規則に敏感であるべきであることに注意してください。 国の中には強い暗号化を許容しないか、または特定保険証券に暗号技術の使用に押しつけないものもあります。 可能であるときはいつも、機密情報を暗号化することに加えて、通信はデジタル署名を含むべきです。 (ほとんどの国では、デジタル署名を使用するのによる信憑性の保護が既存の暗号化規則で影響を受けません。)
For communication via telephone or facsimile a CSIRT may keep secret authentication data for parties with whom they may deal, such as an agreed password or phrase. Obviously, such secret keys must not be
電話かファクシミリを通したコミュニケーションに関しては、彼らがだれを取扱うかもしれないかと共にCSIRTはパーティーのために秘密の認証データを保つかもしれません、同意されたパスワードや句のように。 明らかに、そのような秘密鍵はそうであるはずがありません。
Brownlee & Guttman Best Current Practice [Page 14] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[14ページ]。
published, though their existence may be.
それらの存在は発行されますが、発行されます。
3.5 Services
3.5 サービス
Services provided by a CSIRT can be roughly divided into two categories: real-time activities directly related to the main task of incident response, and non-real-time proactive activities, supportive of the incident response task. The second category and part of the first category consist of services which are optional in the sense that not all CSIRTs will offer them.
およそCSIRTによって提供されたサービスは2つのカテゴリに分割できます: リアルタイムの活動は直接インシデントレスポンスの主なタスク、および非リアルタイムの先を見越す活動に関連しました、インシデントレスポンスタスクを支持しています。 最初のカテゴリの2番目のカテゴリと部分はすべてのCSIRTsが彼らを提供するというわけではないという意味で任意のサービスから成ります。
3.5.1 Incident Response
3.5.1 インシデントレスポンス
Incident response usually includes assessing incoming reports about
incidents ("Incident Triage") and following up on these with other
CSIRTs, ISPs and sites ("Incident Coordination"). A third range of
services, helping a local site to recover from an incident ("Incident
Resolution"), is comprised of typically optional services, which not
all CSIRTs will offer.
通常、インシデントレスポンスは、インシデント(「付随している選別」)に関して入って来るレポートを評価して、他のCSIRTs、ISP、およびサイト(「付随しているコーディネート」)がこれらで追求されるのを含んでいます。 3番目の1つの範囲のサービス、ローカル・サイトを助けて、インシデントから回復するために、(「付随している解決」)は通常任意のサービス(すべてのCSIRTsが提供するというわけではないもの)から成ります。
3.5.1.1 Incident Triage
3.5.1.1 付随している選別
Incident triage usually includes:
通常付随している選別は:
- Report assessment Interpretion of incoming incident
reports, prioritizing them, and
relating them to ongoing incidents
and trends.
- それらを最優先させて、進行中のインシデントと傾向にそれらに関連して、入って来る事故報告の査定Interpretionを報告してください。
- Verification Help in determining whether an
incident has really occurred, and
its scope.
- インシデントが本当に起こったかどうか決定するのにおいて検証ヘルプ、およびその範囲。
3.5.1.2 Incident Coordination
3.5.1.2 付随しているコーディネート
Incident Coordination normally includes:
通常付随しているCoordinationは:
- Information categorization Categorization of the incident related
information (logfiles, contact
information, etc.) with respect to
the information disclosure policy.
- インシデントの情報分類Categorizationは情報公開方針に関して情報(ログファイル、問い合わせ先など)について話しました。
- Coordination Notification of other involved
parties on a need-to-know basis, as
per the information disclosure
policy.
- 関係者のみに知らせる原則で情報公開方針に従って他の関係者のコーディネートNotification。
Brownlee & Guttman Best Current Practice [Page 15] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[15ページ]。
3.5.1.3 Incident Resolution
3.5.1.3 付随している解決
Usually additional or optional, incident resolution services include:
付随している解決サービスは:通常、追加しているか、または任意であることで、
- Technical Assistance This may include analysis of
compromised systems.
- 技術的なAssistance Thisは感染されたシステムの分析を含むかもしれません。
- Eradication Elimination of the cause of a
security incident (the vulnerability
exploited), and its effects (for
example, continuing access to the
system by an intruder).
- セキュリティインシデント(利用された脆弱性)の原因の根絶Elimination、およびその効果(例えば、侵入者によるシステムへの継続するアクセス)。
- Recovery Aid in restoring affected systems
and services to their status before
the security incident.
- 回復における回復Aidはセキュリティインシデントの前にシステムとそれらの状態に対するサービスに影響しました。
3.5.2. Proactive Activities
3.5.2. 先を見越す活動
Usually additional or optional, proactive services might include:
通常、追加しているか、または任意であることで、先を見越すサービスは以下を含むかもしれません。
- Information provision This might include an archive of
known vulnerabilities, patches or
resolutions of past problems, or
advisory mailing lists.
- 情報支給Thisは過去の問題、または顧問メーリングリストの知られている脆弱性のアーカイブ、パッチまたは解決を含むかもしれません。
- Security Tools This may include tools for auditing
a Site's security.
- セキュリティTools ThisはSiteのセキュリティを監査するためのツールを含むかもしれません。
- Education and training
- 教育訓練
- Product evaluation
- 製品評価
- Site security auditing and consulting
- サイトセキュリティー監査とコンサルティング
3.6 Incident Reporting Forms
3.6 付随している報告様式
The use of reporting forms makes it simpler for both users and teams to deal with incidents. The constituent can prepare answers to various important questions before he or she actually contacts the team, and can therefore come well prepared. The team gets all the necessary information at once with the first report and can proceed efficiently.
報告様式の使用で、ユーザとチームの両方がインシデントに対処するのが、より簡単になります。 したがって、その人が実際にチームに連絡して、よく準備されていた状態で来ることができる前に成分は様々な重要な質問の答えを準備できます。 チームは、すぐに、最初のレポートですべての必要事項を得て、効率的に続くことができます。
Depending on the objectives and services of a particular CSIRT, multiple forms may be used, for example a reporting form for a new vulnerability may be very different from the form used for reporting
特定のCSIRTの目的とサービスによって、複数のフォームは使用されるかもしれません、例えば、新しい脆弱性のための報告様式が報告するのに使用されるフォームと非常に異なっているかもしれません。
Brownlee & Guttman Best Current Practice [Page 16] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[16ページ]。
incidents.
インシデント。
It is most efficient to provide forms through the online information services of the team. The exact pointers to them should be given in the CSIRT description document, together with statements about appropriate use, and guidelines for when and how to use the forms. If separate e-mail addresses are supported for form-based reporting, they should be listed here again.
チームのオンライン情報サービスでフォームを提供するのは最も効率的です。 CSIRT記述ドキュメントでそれらへの正確な指針を与えるべきです、いつ、どうフォームを使用するかためには適切な使用に関する声明、およびガイドラインと共に。別々のEメールアドレスがフォームベースの報告のためにサポートされるなら、それらは再びここに記載されるべきです。
One example of such a form is the Incident Reporting Form provided by the CERT Coordination Center:
そのようなフォームに関する1つの例がCERTコーディネートセンターによって提供されたIncident Reporting Formです:
- ftp://info.cert.org/incident_reporting_form
- ftp://info.cert.org/incident_reporting_form
3.7 Disclaimers
3.7 注意書き
Although the CSIRT description document does not constitute a contract, liability may conceivably result from its descriptions of services and purposes. The inclusion of a disclaimer at the end of the template is therefore recommended and should warn the user about possible limitations.
CSIRT記述ドキュメントは契約を成立させませんが、責任は多分サービスと目的の記述から生じるかもしれません。 テンプレートの端の注意書きの包含は、したがって、お勧めであり、可能な制限に関してユーザに警告するべきです。
In situations where the original version of a document must be translated into another language, the translation should carry a disclaimer and a pointer to the original. For example:
ドキュメントのオリジナルバージョンを別の言語に翻訳しなければならない状況で、翻訳は注意書きと指針をオリジナルまで運ぶべきです。 例えば:
Although we tried to carefully translate the original document
from German into English, we can not be certain that both
documents express the same thoughts in the same level of detail
and correctness. In all cases, where there is a difference
between both versions, the German version will prevail.
正本をドイツ語から英語に慎重に翻訳しようとしましたが、私たちは両方のドキュメントが同じレベルの詳細と正当性における同じ考えを言い表すのを確信しているはずがありません。 すべての場合では、ドイツ語版は広がるでしょう。そこに、両方のバージョンの間には、違いがあります。
The use of and protection by disclaimers is affected by local laws and regulations, of which each CSIRT should be aware. If in doubt the CSIRT should check the disclaimer with a lawyer.
注意書きによる使用と保護は地域法と規則で影響を受けます。(そこをそれぞれのCSIRTは意識しているべきです)。 疑問でCSIRTは弁護士に注意書きについて問い合わせるはずです。
Brownlee & Guttman Best Current Practice [Page 17] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[17ページ]。
Appendix A: Glossary of Terms
付録A: 用語の用語集
This glossary defines terms used in describing security incidents and Computer Security Incident Response Teams. Only a limited list is included. For more definitions please refer to other sources, for example to the Internet User's Glossary [RFC 1983].
この用語集はセキュリティインシデントについて説明する際に使用される用語とコンピュータセキュリティ事件対応チームを定義します。限られたリストだけが含まれています。 より多くの定義について、例えば、インターネットUserのGlossary[RFC1983]を他のソースを参照してください。
Constituency:
Implicit in the purpose of a Computer Security Incident Response
Team is the existence of a constituency. This is the group of
users, sites, networks or organizations served by the team. The
team must be recognized by its constituency in order to be
effective.
選挙民: コンピュータSecurity Incident Response Teamの目的で暗黙であることは、選挙民の存在です。 これは、チームによって役立たれたユーザー層、サイト、ネットワークまたは組織です。 選挙民は、有効になるようにチームを認識しなければなりません。
Security Incident:
For the purpose of this document, this term is a synonym of
Computer Security Incident: any adverse event which compromises
some aspect of computer or network security.
セキュリティインシデント: このドキュメントの目的のために、今期はコンピュータSecurity Incidentの同義語です: コンピュータかネットワークセキュリティの何らかの局面に感染するどんな有害事象。
The definition of an incident may vary between organizations, but
at least the following categories are generally applicable:
インシデントの定義は組織の間で異なるかもしれませんが、一般に、少なくとも以下のカテゴリは適切です:
- Loss of confidentiality of information.
- Compromise of integrity of information.
- Denial of service.
- Misuse of service, systems or information.
- Damage to systems.
- 守秘義務の損失。 - 情報の保全の感染。 - サービスの否定。 - サービス、システムまたは情報の誤用。 - システムに損傷します。
These are very general categories. For instance the replacement
of a system utility program by a Trojan Horse is an example of '
compromise of integrity,' and a successful password attack is an
example of 'loss of confidentiality.' Attacks, even if they
failed because of proper protection, can be regarded as Incidents.
これらは非常に一般的なカテゴリです。 例えば、トロイの木馬によるシステム・ユーティリティ・プログラムの交換は'保全の感染'に関する例です、そして、うまくいっているパスワード攻撃は'秘密性の損失'に関する例です。彼らが適切な保護で失敗したとしても、AttacksをIncidentsと見なすことができます。
Within the definition of an incident the word 'compromised' is
used. Sometimes an administrator may only 'suspect' an incident.
During the response it must be established whether or not an
incident has really occurred.
中では、単語が'感染した'インシデントの定義が使用されています。 時々、管理者はインシデントを'疑うだけであるかもしれません'。 応答の間、インシデントが本当に起こったかどうか設立しなければなりません。
Computer Security Incident Response Team:
Based on two of the definitions given above, a CSIRT is a team
that coordinates and supports the response to security incidents
that involve sites within a defined constituency.
コンピュータセキュリティインシデント応答チーム: 上に与えられた2つの定義に基づいて、CSIRTは定義された選挙民の中でサイトにかかわるセキュリティインシデントへの応答を調整して、サポートするチームです。
In order to be considered a CSIRT, a team must:
CSIRTであると考えられるために、チームは考えられなければなりません:
- Provide a (secure) channel for receiving reports about
suspected incidents.
- (安全)のチャンネルを疑われたインシデントに関する受信報告書に提供してください。
Brownlee & Guttman Best Current Practice [Page 18] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[18ページ]。
- Provide assistance to members of its constituency in
handling these incidents.
- Disseminate incident-related information to its
constituency and to other involved parties.
- 取り扱いにおける選挙民のメンバーに対する支援にこれらのインシデントを提供してください。 - 選挙民と、そして、他の関係者にインシデント関連の情報を広めてください。
Note that we are not referring here to police or other law
enforcement bodies which may investigate computer-related crime.
CSIRT members, indeed, need not have any powers beyond those of
ordinary citizens.
私たちがここで警察かコンピュータ関連の犯罪を調査するかもしれない他の法施行本体を参照していないことに注意してください。 本当に、CSIRTメンバーには、一般市民のものを超えて少しの強国もある必要はありません。
Vendor:
A 'vendor' is any entity that produces networking or computing
technology, and is responsible for the technical content of that
technology. Examples of 'technology' include hardware (desktop
computers, routers, switches, etc.), and software (operating
systems, mail forwarding systems, etc.).
ベンダー: 'ベンダー'は、技術をネットワークでつなぐか、または計算しながら生産されるどんな実体でありも、その技術の技術的な内容に責任があります。 '技術'に関する例はハードウェア(デスクトップコンピュータ、ルータ、スイッチなど)、およびソフトウェア(オペレーティングシステム、メール転送システムなど)を含んでいます。
Note that the supplier of a technology is not necessarily the '
vendor' of that technology. As an example, an Internet Service
Provider (ISP) might supply routers to each of its customers, but
the 'vendor' is the manufacturer, since the manufacturer, rather
than the ISP, is the entity responsible for the technical content
of the router.
技術の供給者が必ずその技術の'ベンダー'であるというわけではないことに注意してください。 例として、インターネットサービスプロバイダ(ISP)は顧客各人にルータを供給するかもしれませんが、'ベンダー'はメーカーです、メーカーがISPよりむしろルータの技術的な内容に原因となる実体であるので。
Vulnerability:
A 'vulnerability' is a characteristic of a piece of technology
which can be exploited to perpetrate a security incident. For
example, if a program unintentionally allowed ordinary users to
execute arbitrary operating system commands in privileged mode,
this "feature" would be a vulnerability.
脆弱性: '脆弱性'はセキュリティインシデントを犯すのに利用できる1つの技術の特性です。 例えば、一般ユーザがプログラムで特権があるモードにおける任意のオペレーティングシステムコマンドを何気なく実行できるなら、この「特徴」は脆弱性でしょうに。
Brownlee & Guttman Best Current Practice [Page 19] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[19ページ]。
Appendix B: Related Material
付録B: 関連材料
Important issues in responding to security incidents on a site level are contained in [RFC 2196], the Site Security Handbook, produced by the Site Security Handbook Working Group (SSH). This document will be updated by the SSH working group and will give recommendations for local policies and procedures, mainly related to the avoidance of security incidents.
サイトレベルでセキュリティインシデントに応じることにおける切迫した課題は[RFC2196]、Site Security Handbook作業部会(SSH)によって生産されたSite Security Handbookに含まれています。 このドキュメントは、SSHワーキンググループによってアップデートされて、セキュリティインシデントの回避に主に関連するローカルの方針と手順のために推薦を与えるでしょう。
Other documents of interest for the discussion of CSIRTs and their tasks are available by anonymous FTP. A collection can be found on:
CSIRTsの議論と彼らのタスクのための興味深い他のドキュメントは公開FTPで利用可能です。 以下で収集を見つけることができます。
- ftp://ftp.cert.dfn.de/pub/docs/csir/
Please refer to file 01-README for further information about
the content of this directory.
- ftp://ftp.cert.dfn.de/pub/docs/csir/ はこのディレクトリの中身に関する詳細についてファイル01-READMEについて言及してください。
Some especially interesting documents in relation to this document are as follows:
このドキュメントと関連したいくつかの特におもしろいドキュメントは以下の通りです:
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/
reports/R-92-01
This report contains the Operational Framework of CERT-NL, the
CSIRT of SURFnet (network provider in the Netherlands).
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ レポート/R-92-01 ThisレポートはCERT-NLのOperational Framework、SURFnetのCSIRT(オランダのネットワーク内の提供者)を含んでいます。
- For readers interested in the operation of FIRST (Forum of
Incident Response and Security Teams) more information is
collected in Appendix C.
- FIRST(Incident ResponseとSecurity Teamsのフォーラム)の操作に興味を持っている読者に関しては、詳しい情報はAppendix Cに集められます。
- http://hightop.nrl.navy.mil/news/incident.html
This document leads to the NRL Incident Response Manual.
- このドキュメントがNRL Incident Response Manualに導く http://hightop.nrl.navy.mil/news/incident.html 。
- http://www.cert.dfn.de/eng/team/kpk/certbib.html
This document contains an annotated bibliography of available
material, documents and files about the operation of CSIRTs
with links to many of the referenced items.
- これが記録する http://www.cert.dfn.de/eng/team/kpk/certbib.html は参照をつけられた項目の多くへのリンクによるCSIRTsの操作に関する利用可能な材料、ドキュメント、およびファイルに関する注釈付きの書誌を含んでいます。
- ftp://info.cert.org/incident_reporting_form
This Incident Reporting Form is provided by the CERT
Coordination Center to gather incident information and to avoid
additional delays caused by the need to request more detailed
information from the reporting site.
- このIncident Reporting Formが付随している情報を集めて、報告サイトから、より詳細な情報を要求する必要性によって引き起こされた追加遅れを避けるためにCERTコーディネートセンターによって提供される ftp://info.cert.org/incident_reporting_form 。
- http://www.cert.org/cert.faqintro.html
A collection of frequently asked questions from the CERT
Coordination Center.
- 頻繁の収集が尋ねた http://www.cert.org/cert.faqintro.html はCERTコーディネートセンターから質問されます。
Brownlee & Guttman Best Current Practice [Page 20] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[20ページ]。
Appendix C: Known Computer Security Incident Response Teams
付録C: 知られているコンピュータセキュリティ事件対応チーム
Today, there are many different CSIRTs but no single source lists every team. Most of the major and long established teams (the first CSIRT was founded in 1988) are nowadays members of FIRST, the worldwide Forum of Incident Response and Security Teams. At the time of writing, more than 55 teams are members (1 in Australia, 13 in Europe, all others in North America). Information about FIRST can be found:
今日、多くの異なったCSIRTsがありますが、どんな単独の情報筋もあらゆるチームを記載するというわけではありません。 主要で長い設立されたチーム(最初のCSIRTは1988年に設立された)の大部分によるこの頃はSecurity Teams FIRSTのメンバーとIncident Responseの世界的なForumとこれを書いている時点で55以上のチームがメンバー(オーストラリアの1、ヨーロッパの13、北アメリカのすべての他のもの)であるということです。 FIRSTに関する情報を見つけることができます:
- http://www.first.org/
- http://www.first.org/
The current list of members is available also, with the relevant contact information and some additional information provided by the particular teams:
また、現在の会員名簿も利用可能です、関連問い合わせ先と何らかの追加情報が特定のチームによって提供されている状態で:
- http://www.first.org/team-info/
- http://www.first.org/team-info/
For CSIRTs which want to become members of this forum (please note that a team needs a sponsor - a team which is already a full member of FIRST - to be introduced), the following files contain more information:
このフォーラム(チームが、スポンサー(既にFIRSTの正会員であるチーム)が紹介される必要に注意する)のメンバーになりたがっているCSIRTsに関しては、以下のファイルは詳しい情報を含んでいます:
- http://www.first.org/about/op_frame.html
The Operational Framework of FIRST.
- http://www.first.org/about/op_frame.html 、最初にの操作上のフレームワーク。
- http://www.first.org/docs/newmem.html
Guidelines for teams which want to become members of FIRST.
- FIRSTのメンバーになりたがっているチームのための http://www.first.org/docs/newmem.html ガイドライン。
Many of the European teams, regardless of whether they are members of FIRST or not, are listed by countries on a page maintained by the German CSIRT:
彼らがFIRSTのメンバーであるかどうかにかかわらず、ヨーロッパのチームの多くが国によってドイツのCSIRTによって維持された1ページに記載されています:
- http://www.cert.dfn.de/eng/csir/europe/certs.html
- http://www.cert.dfn.de/eng/csir/europe/certs.html
To learn about existing teams suitable to one's needs it is often helpful to ask either known teams or an Internet Service Provider for the "right" contact.
人の必要性に適した既存のチームに関して学ぶために、「正しい」接触に知られているチームかインターネットサービスプロバイダのどちらかを尋ねるのはしばしば役立っています。
Brownlee & Guttman Best Current Practice [Page 21] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[21ページ]。
Appendix D: Outline for CSIRT Template
付録D: CSIRTテンプレートのためのアウトライン
This outline summarizes in point form the issues addressed in this document, and is the recommended template for a CSIRT description document. Its structure is designed to facilitate the communication of a CSIRT's policies, procedures, and other relevant information to its constituency and to outside organizations such as other CSIRTs. A 'filled-in' example of this template is given as Appendix E.
このアウトラインは、ポイントフォームに本書では扱われた問題をまとめて、CSIRT記述ドキュメントのためのお勧めのテンプレートです。 構造は、CSIRTの方針、手順、および他の関連情報に関するコミュニケーションを選挙民と、そして、他のCSIRTsなどの組織の外に容易にするように設計されています。 '記入されて'このテンプレートに関する例はAppendix Eとして出されます。
1. Document Information
1.1 Date of Last Update
1.2 Distribution List for Notifications
1.3 Locations where this Document May Be Found
1. Notifications1.3LocationsのためにLast Update1.2Distribution Listの情報1.1Dateを記録してください、どこ、このDocument5月のBe Found
2. Contact Information
2.1 Name of the Team
2.2 Address
2.3 Time Zone
2.4 Telephone Number
2.5 Facsimile Number
2.6 Other Telecommunication
2.7 Electronic Mail Address
2.8 Public Keys and Encryption Information
2.9 Team Members
2.10 Other Information
2.11 Points of Customer Contact
2. Contact Information 2.1 Name of the Team 2.2 Address 2.3 Time Zone 2.4 Telephone Number 2.5 Facsimile Number 2.6 Other Telecommunication 2.7 Electronic Mail Address 2.8 Public Keys and Encryption Information 2.9 Team Members 2.10 Other Information 2.11 Points of Customer Contact
3. Charter
3.1 Mission Statement
3.2 Constituency
3.3 Sponsorship and/or Affiliation
3.4 Authority
3. 憲章3.1使命記述書3.2選挙民3.3スポンサーシップ、そして/または、提携3.4権威
4. Policies
4.1 Types of Incidents and Level of Support
4.2 Co-operation, Interaction and Disclosure of Information
4.3 Communication and Authentication
4. 情報4.3コミュニケーションと認証のインシデントとサポート水準4.2協力の方針4.1タイプ、相互作用、および公開
5. Services
5.1 Incident Response
5.1.1. Incident Triage
5.1.2. Incident Coordination
5.1.3. Incident Resolution
5.2 Proactive Activities
5. サービス5.1インシデントレスポンス5.1.1。 付随している選別5.1.2。 付随しているコーディネート5.1.3。 付随している決議5.2は活動を予測します。
6. Incident Reporting Forms
6. 付随している報告様式
7. Disclaimers
7. 注意書き
Brownlee & Guttman Best Current Practice [Page 22] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[22ページ]。
Appendix E: Example - 'filled-in' Template for a CSIRT
付録E: 例--CSIRTのためにテンプレートに'記入します'。
Below is an example of a filled-in template for a fictitious CSIRT called XYZ-CSIRT. This text is for example purposes only, and does not constitute endorsement by the working group or the IETF of any particular set of procedures or policies. While CSIRTs are welcome to use any or all of this text if they wish, such use is of course not mandatory, or even appropriate in most cases.
以下に、XYZ-CSIRTと呼ばれる架空のCSIRTのための記入しているテンプレートに関する例があります。 本稿は、例えば、目的専用であり、どんな特定のセットの手順か方針のワーキンググループかIETFによる裏書きも構成しません。 彼らが願うなら、本稿のいずれかすべてを使用するのにおいてCSIRTsを歓迎しますが、多くの場合、そのような使用は、もちろん義務的でないか、または適切でさえあります。
CSIRT Description for XYZ-CERT -----------------------------
XYZ-本命のためのCSIRT記述-----------------------------
1. About this document
1. このドキュメントに関して
1.1 Date of Last Update
1.1 アップデートの日付
This is version 1.01, published 1997/03/31.
これは1997/03/31に発行されたバージョン1.01です。
1.2 Distribution List for Notifications
1.2 通知のための発送先リスト
Notifications of updates are submitted to our mailing list
<xyz-cert-info@xyz-univ.ca>. Subscription requests for this
list should be sent to the Majordomo at
<xyz-cert-info-request@xyz-univ.ca>; the body of the message
should consist of the word "subscribe". Send the word "help"
instead if you don't know how to use a Majordomo list manager.
This mailing list is moderated.
私たちが list <xyz-cert-info@xyz-univ.ca に郵送するのにアップデートの通知を提出する、gt。 このリストに関する購読要求をMajordomo at <xyz-cert-info-request@xyz-univ.ca に送るべきである、gt;、。 メッセージ欄は「申し込んでください」という単語から成るべきです。 Majordomoリストマネージャを使用する方法を知らないなら、代わりに、「助けてください」という知らせを送ってください。 このメーリングリストは加減されます。
1.3 Locations where this Document May Be Found
1.3の位置、どこ、このDocument5月のBe Found
The current version of this CSIRT description document is
available from the XYZ-CERT WWW site; its URL is
http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt
Une version francaise de ce document est igalement disponible:
http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt
Please make sure you are using the latest version.
このCSIRT記述ドキュメントの最新版はXYZ-CERT WWWサイトから利用可能です。 URLは http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt Uneバージョンfrancaise de Ceドキュメントest igalement disponibleです: http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt は、あなたが最新版を使用しているのを確実にしてください。
1.4 Authenticating this Document
1.4 このDocumentを認証すること。
Both the English and French versions of this document have
been signed with the XYZ-CERT's PGP key. The signatures are
also on our Web site, under:
http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc
http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc
このドキュメントの両方のイギリスの、そして、フランスのバージョンにXYZ-CERTのPGPキーで署名してあります。 署名が私たちのウェブサイトにも以下の下にあります。 http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc
Brownlee & Guttman Best Current Practice [Page 23] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[23ページ]。
2. Contact Information
2. 問い合わせ先
2.1 Name of the Team
2.1 チームの名前
"XYZ-CERT": the XYZ University Computer Emergency Response
Team.
「XYZ-本命」: XYZ大学コンピュータ緊急対応チーム。
2.2 Address
2.2 アドレス
XYZ-CERT
XYZ University, Computing Services Department
12345 Rue Principale
UniversityTown, Quebec
Canada H0H 0H0
XYZ-本命XYZ大学、部の12345悔悟Principale UniversityTown、コンピューターサービスケベックカナダH0H 0H0
2.3 Time Zone
2.3 時間帯
Canada/Eastern (GMT-0500, and GMT-0400 from April to October)
カナダ/イースタン(グリニッジ標準時の0500、およびグリニッジ標準時の4月から10月までの0400)
2.4 Telephone Number
2.4 電話番号
+1 234 567 7890 (ask for the XYZ-CERT)
+1 234 567 7890 (XYZ-本命を求めます)
2.5 Facsimile Number
2.5 ファクシミリ番号
+1 234 567 7899 (this is *not* a secure fax)
+1 234 567 7899 (これは*a安定したファックスではなく、*です)
2.6 Other Telecommunication
2.6 他の電気通信
None available.
利用可能でないなにも。
2.7 Electronic Mail Address
2.7 電子メールアドレス
<xyz-cert@xyz-univ.ca> This is a mail alias that relays mail
to the human(s) on duty for the XYZ-CERT.
本命@xyz-univ.caをxyzしている<>ThisはXYZ-CERTにおける、勤務中の人間にメールをリレーするメール別名です。
2.8 Public Keys and Other Encryption Information
2.8 公開鍵と他の暗号化情報
The XYZ-CERT has a PGP key, whose KeyID is 12345678 and
whose fingerprint is
11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11.
The key and its signatures can be found at the usual large
public keyservers.
XYZ-CERTはKeyIDが12345678であり、指紋が11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11であるPGPキーを持っています。 普通の大きい公共のkeyserversでキーとその署名を見つけることができます。
Because PGP is still a relatively new technology at XYZ
University, this key still has relatively few signatures;
efforts are underway to increase the number of links to this
key in the PGP "web of trust". In the meantime, since most
それでも、PGPがXYZ大学の比較的新しい技術であるので、このキーには、比較的わずかな署名しかまだありません。 取り組みは、数を増やすためにPGPのこのキーへのリンクで進行中です。「信頼のウェブ。」 差し当たり、大部分
Brownlee & Guttman Best Current Practice [Page 24] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[24ページ]。
fellow universities in Quebec have at least one staff member
who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has
signed the XYZ-CERT key, and will be happy to confirm its
fingerprint and that of her own key to those people who know
her, by telephone or in person.
ケベックの仲間大学には、XYZ-CERTコーディネータのZoeドウを知っている少なくとも1人の職員がいます、そして、ZoeドウはXYZ-CERTキーに署名しました、そして、彼女自身の電話で自分で彼女を知っている人々のキーの指紋とものを確認するので、幸福でしょう。
2.9 Team Members
2.9 チームのメンバー
Zoe Doe of Computing Services is the XYZ-CERT coordinator.
Backup coordinators and other team members, along with their
areas of expertise and contact information, are listed in the
XYZ-CERT web pages, at
http://www.xyz-univ.ca/xyz-cert/teamlist.html
コンピューターサービスのZoeドウはXYZ-CERTコーディネータです。 バックアップコーディネータと他のチームメンバーは彼らの専門的技術と問い合わせ先の領域と共にXYZ-CERTウェブページに記載されています、 http://www.xyz-univ.ca/xyz-cert/teamlist.html で
Management, liaison and supervision are provided by Steve Tree,
Assistant Director (Technical Services), Computing Services.
スティーブTree、Assistantディレクター(技術的なServices)、コンピューターサービスで管理、連絡、および指揮を提供します。
2.10 Other Information
2.10 他の情報
General information about the XYZ-CERT, as well as links to
various recommended security resources, can be found at
http://www.xyz-univ.ca/xyz-cert/index.html
http://www.xyz-univ.ca/xyz-cert/index.html でXYZ-CERTに関する一般情報、および様々なお勧めのセキュリティリソースへのリンクを見つけることができます。
2.11 Points of Customer Contact
2.11 ポイントの顧客との接触
The preferred method for contacting the XYZ-CERT is via
e-mail at <xyz-cert@xyz-univ.ca>; e-mail sent to this address
will "biff" the responsible human, or be automatically
forwarded to the appropriate backup person, immediately. If
you require urgent assistance, put "urgent" in your subject
line.
メール at <xyz-cert@xyz-univ.ca を通してXYZ-CERTに連絡するための適した方法がある、gt;、。 このアドレスに送られたメールを、責任がある人間を「ぶつ」か、またはすぐに、自動的に適切なバックアップ人に転送するでしょう。 あなたの件名で「緊急」の状態で置かれた緊急の支援が必要でしたら。
If it is not possible (or not advisable for security reasons)
to use e-mail, the XYZ-CERT can be reached by telephone during
regular office hours. Telephone messages are checked less
often than e-mail.
メールを使用するのが可能でなくて(セキュリティ理由で賢明でない)であるなら、XYZ-CERTに通常の営業時間の間、電話で達することができます。 通話はメールするより、よりしばしばチェックされます。
The XYZ-CERT's hours of operation are generally restricted to
regular business hours (09:00-17:00 Monday to Friday except
holidays).
一般に、XYZ-CERTの数時間の操作は通常取引(月曜日から休日以外の金曜日への9時0分から17時0分)時間に制限されます。
If possible, when submitting your report, use the form
mentioned in section 6.
できれば、あなたのレポートを提出するときには、セクション6で参照された書式を使用してください。
Brownlee & Guttman Best Current Practice [Page 25] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[25ページ]。
3. Charter
3. 憲章
3.1 Mission Statement
3.1 使命記述書
The purpose of the XYZ-CERT is, first, to assist members of XYZ
University community in implementing proactive measures to
reduce the risks of computer security incidents, and second, to
assist XYZ community in responding to such incidents when they
occur.
起こるとそのようなインシデントに応じるのにXYZ共同体を助けるために、最初に、XYZ大学共同体のアシストメンバーにはXYZ-CERTの目的がコンピュータセキュリティインシデントの危険を減少させるために先を見越した措置を実装して、2番目に、あります。
3.2 Constituency
3.2 選挙民
The XYZ-CERT's constituency is the XYZ University community,
as defined in the context of the "XYZ University Policy on
Computing Facilities". This policy is available at
http://www-compserv.xyz-univ.ca/policies/pcf.html
XYZ-CERTの選挙民はXYZ大学共同体です、「コンピュータ設備に関するXYZ大学方針」の文脈で定義されるように。 この方針は http://www-compserv.xyz-univ.ca/policies/pcf.html で利用可能です。
However, please note that, notwithtanding the above, XYZ-CERT
services will be provided for on-site systems only.
しかしながら、上記をnotwithtandingして、XYZ-CERTサービスを現場のシステムだけに提供するでしょう。
3.3 Sponsorship and/or Affiliation
3.3 スポンサーシップ、そして/または、提携
The XYZ-CERT is sponsored by the ACME Canadian Research
Network. It maintains affiliations with various University
CSIRTs throughout Canada and the USA on an as needed basis.
XYZ-CERTはACMEのカナダのResearch Networkによって後援されます。 カナダと米国中に様々な大学CSIRTsがある提携をオンに維持する、必要な基礎として。
3.4 Authority
3.4 権威
The XYZ-CERT operates under the auspices of, and with authority
delegated by, the Department of Computing Services of XYZ
University. For further information on the mandate and
authority of the Department of Computing Services, please
refer to the XYZ University "Policy on Computing Facilities",
available at
http://www-compserv.xyz-univ.ca/policies/pcf.html
XYZ-CERTは部と代表として派遣された権威、XYZ大学のコンピューターサービスの部との前兆で作動します。 コンピューターサービスの部の命令と権威に関する詳細について、XYZ大学「コンピュータ設備に関する方針」を参照してください、 http://www-compserv.xyz-univ.ca/policies/pcf.html では、利用可能です。
The XYZ-CERT expects to work cooperatively with system
administrators and users at XYZ University, and, insofar as
possible, to avoid authoritarian relationships. However,
should circumstances warrant it, the XYZ-CERT will appeal to
Computing Services to exert its authority, direct or indirect,
as necessary. All members of the XYZ-CERT are members of the
CCSA (Committee of Computer Systems Administrators), and have
all of the powers and responsibilities assigned to Systems
Administrators by the Policy on Computing Facilities, or are
members of University management.
XYZ-CERTはそして、可能である限り、システム管理者とユーザと共にXYZ大学で協力して働いて、権威主義的な関係を避けると予想します。 しかしながら、事情がそれを保証すると、XYZ-CERTは、直接の、または、間接的な権威を出すようにコンピューターサービスに求めるでしょう、必要に応じて。 XYZ-CERTのすべてのメンバーが、CCSA(コンピュータシステムズAdministrators委員会)のメンバーであり、PolicyにComputing Facilitiesで強国と責任のすべてを初級システムアドミニストレータに割り当てさせるか、または大学管理のメンバーです。
Brownlee & Guttman Best Current Practice [Page 26] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[26ページ]。
Members of the XYZ University community who wish to appeal the
actions of the XYZ-CERT should contact the Assistant Director
(Technical Services), Computing Services. If this recourse is
not satisfactory, the matter may be referred to the Director
of Computing Services (in the case of perceived
problems with existing policy), or to the XYZ University
Office of Rights and Responsibilities (in the case of perceived
errors in the application of existing policy).
XYZ-CERTの機能を上告したがっているXYZ大学共同体のメンバーはAssistantディレクター(技術的なServices)(コンピューターサービス)に連絡するべきです。 この償還請求が満足できないなら、その件はコンピューターサービス(既存の方針に関する知覚された問題の場合における)のディレクター、またはRightsとResponsibilities(既存の方針の適用における、知覚された誤りの場合における)のXYZ大学オフィスを参照されるかもしれません。
4. Policies
4. 方針
4.1 Types of Incidents and Level of Support
インシデントとサポート水準の4.1のタイプ
The XYZ-CERT is authorized to address all types of computer
security incidents which occur, or threaten to occur, at
XYZ University.
XYZ-CERTは起こるすべてのタイプのコンピュータセキュリティインシデントを扱うか、または起こると脅かすのが認可されます、XYZ大学で。
The level of support given by XYZ-CERT will vary depending on
the type and severity of the incident or issue, the type of
constituent, the size of the user community affected, and the
XYZ-CERT's resources at the time, though in all cases some
response will be made within one working day. Resources will
be assigned according to the following priorities, listed in
decreasing order:
インシデントか問題のタイプと厳しさ、成分のタイプ、影響を受けるユーザーコミュニティのサイズ、および当時XYZ-CERTのリソースに頼っていて、XYZ-CERTによって与えられたサポート水準は異なるでしょう、1営業日以内にすべての場合では、何らかの応答をするでしょうが。 多いほうから少ないほうへ順に並べると記載された以下のプライオリティに従って、リソースは割り当てられるでしょう:
- Threats to the physical safety of human beings.
- Root or system-level attacks on any Management Information
System, or any part of the backbone network infrastructure.
- Root or system-level attacks on any large public service
machine, either multi-user or dedicated-purpose.
- Compromise of restricted confidential service accounts or
software installations, in particular those used for MIS
applications containing confidential data, or those used
for system administration.
- Denial of service attacks on any of the above three items.
- Any of the above at other sites, originating from XYZ
University.
- Large-scale attacks of any kind, e.g. sniffing attacks,
IRC "social engineering" attacks, password cracking
attacks.
- Threats, harassment, and other criminal offenses
involving individual user accounts.
- Compromise of individual user accounts on multi-user
systems.
- Compromise of desktop systems.
- Forgery and misrepresentation, and other security-related
violations of local rules and regulations, e.g. netnews
and e-mail forgery, unauthorized use of IRC bots.
- 人間の身体上の安全への脅威。 - 根かシステムレベルがどんなManagement情報システム、またはバックボーンネットワークインフラのどんな部分の上でも攻撃されます。 - 根かシステムレベルがどんな大きい社会奉仕マシン(マルチユーザかひたむきな目的のどちらか)の上でも攻撃されます。 - 制限された秘密のサービス勘定かソフトウェアインストールの感染、特にものはMISに秘密のデータを含むアプリケーション、またはシステム管理に使用されるものを使用しました。 - サービスの否定は上記のどれかで攻撃されます。3つの項目 --他のサイトの上記のいずれも、XYZ大学から発すること。 - どんな種類の大規模な攻撃、例えば、スニフィング攻撃、IRC「ソーシャルエンジニアリング」も攻撃されて、パスワード解析は攻撃されます。 - 脅威、ハラスメント、および個々のユーザアカウントにかかわる他の犯罪。 - デスクトップ型で妥協してください。個々のユーザの感染がマルチユーザーシステムの上で説明される、--. --偽造と誤伝とローカル・ルールと規則、例えば、ネットニュースの他のセキュリティ関連の違反とメール偽造(IRCウマバエの幼虫の無断使用)。
Brownlee & Guttman Best Current Practice [Page 27] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[27ページ]。
- Denial of service on individual user accounts, e.g.
mailbombing.
- 個々のユーザアカウント、例えば、mailbombingのサービスの否定。
Types of incidents other than those mentioned above will be
prioritized according to their apparent severity and extent.
それらの見かけの厳しさと範囲に従って、それら以外の前記のようにインシデントのタイプは最優先するでしょう。
Note that no direct support will be given to end users; they
are expected to contact their system administrator, network
administrator, or department head for assistance. The XYZ-CERT
will support the latter people.
どんなダイレクトサポートもエンドユーザに与えられないことに注意してください。 彼らが支援のために彼らのシステム管理者、ネットワーク管理者、または部のヘッドに連絡すると予想されます。 XYZ-CERTは後者の人々をサポートするでしょう。
While the XYZ-CERT understands that there exists great
variation in the level of system administrator expertise at XYZ
University, and while the XYZ-CERT will endeavor to present
information and assistance at a level appropriate to each
person, the XYZ-CERT cannot train system administrators on the
fly, and it cannot perform system maintenance on their behalf.
In most cases, the XYZ-CERT will provide pointers to the
information needed to implement appropriate measures.
XYZ-CERTが、XYZ大学のシステム管理者専門的技術のレベルのすばらしい変化が存在するのを理解して、XYZ-CERTが、各人にとって、適切なレベルで情報と支援を提示するよう努力している間、XYZ-CERTは急いでシステム管理者を訓練しないことができて、またそれはそれらの利益にシステム保守を実行しないことができます。 多くの場合、XYZ-CERTは穏当な処置を実装するのに必要である情報に指針を提供するでしょう。
The XYZ-CERT is committed to keeping the XYZ University system
administration community informed of potential vulnerabilities,
and where possible, will inform this community of such
vulnerabilities before they are actively exploited.
XYZ-CERTは潜在的脆弱性についてXYZ大学システム管理共同体に知らせ続けるよう心がけます、そして、それらが活発に利用される前に可能であるところでは、そのような脆弱性についてこの共同体に知らせるでしょう。
4.2 Co-operation, Interaction and Disclosure of Information
4.2 情報の協力、相互作用、および公開
While there are legal and ethical restrictions on the flow of
information from XYZ-CERT, many of which are also outlined in
the XYZ University Policy on Computing Facilities, and all of
which will be respected, the XYZ-CERT acknowledges its
indebtedness to, and declares its intention to contribute to,
the spirit of cooperation that created the Internet.
Therefore, while appropriate measures will be taken to protect
the identity of members of our constituency and members of
neighbouring sites where necessary, the XYZ-CERT will otherwise
share information freely when this will assist others in
resolving or preventing security incidents.
法的で倫理的な制限がXYZ-CERTからの情報の流れにある間、XYZ-CERTはインターネットを作成した共同の精神に、負債を承認して、貢献するという意志を宣言します。XYZ-CERTのためにまたそれの多くがComputing Facilitiesの上のXYZ大学Policyに概説されていて、それのすべてが尊敬されるでしょう。 したがって、必要であるところに私たちの選挙民のメンバーと隣接しているサイトのメンバーのアイデンティティを保護するために穏当な処置を取っている間、これがセキュリティインシデントを決議するか、防ぐのに他のものを助けるとき、XYZ-CERTは別の方法で自由に情報を共有するでしょう。
In the paragraphs below, "affected parties" refers to the
legitimate owners, operators, and users of the relevant
computing facilities. It does not refer to unauthorized
users, including otherwise authorized users making
unauthorized use of a facility; such intruders may have no
expectation of confidentiality from the XYZ-CERT. They may or
may not have legal rights to confidentiality; such rights will
of course be respected where they exist.
以下のパラグラフで、「影響を受けた当事者」は関連コンピュータ設備の正統の所有者、オペレータ、およびユーザを示します。 施設の無断使用をしているそうでなければ、認可されたユーザを含んでいて、それは権限のないユーザについて言及しません。 そのような侵入者には、XYZ-CERTからの秘密性への期待が全くないかもしれません。 彼らは秘密性に法的権利を持っているかもしれません。 そのような権利はもちろんそれらが存在するところで尊敬されるでしょう。
Brownlee & Guttman Best Current Practice [Page 28] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[28ページ]。
Information being considered for release will be classified as
follows:
リリースのために考えられる情報は以下の通り分類されるでしょう:
- Private user information is information about particular
users, or in some cases, particular applications, which
must be considered confidential for legal, contractual,
and/or ethical reasons.
- 個人的なユーザー情報は特定のユーザ、またはいくつかの場合特定用途の情報です。(法的で、契約的な、そして/または、倫理的な理由で秘密であると特定用途を考えなければなりません)。
Private user information will be not be released in
identifiable form outside the XYZ-CERT, except as provided
for below. If the identity of the user is disguised, then
the information can be released freely (for example to show
a sample .cshrc file as modified by an intruder, or to
demonstrate a particular social engineering attack).
以下に備えられるように個人的なユーザー情報はXYZ-CERTの外のリリースされたコネ身元保証可能なフォームでないためにことになって、除いてください。 ユーザのアイデンティティが変装するなら、自由(例えば変更されるとしての侵入者によるサンプル.cshrcファイルを見せているか、または特定のソーシャルエンジニアリング攻撃を示す)に情報を発表できます。
- Intruder information is similar to private user
information, but concerns intruders.
- 侵入者情報は、個人的なユーザー情報と同様ですが、侵入者に関係があります。
While intruder information, and in particular identifying
information, will not be released to the public (unless it
becomes a matter of public record, for example because
criminal charges have been laid), it will be exchanged
freely with system administrators and CSIRTs tracking an
incident.
侵入者情報と、特に身元が分かる情報を公衆に発表しない間(例えば、刑事責任が横たえられたのでそれが公記録の問題にならない場合)、自由にインシデントを追跡するシステム管理者とCSIRTsとそれを交換するでしょう。
- Private site information is technical information about
particular systems or sites.
- 個人的なサイト情報は特定のシステムかサイトに関する技術資料です。
It will not be released without the permission of the site
in question, except as provided for below.
以下に備えられる以外に、それはサイトのはっきりしていない許可なしでリリースされないでしょう。
- Vulnerability information is technical information about
vulnerabilities or attacks, including fixes and
workarounds.
- 脆弱性情報はフィックスと回避策を含む脆弱性か攻撃に関する技術資料です。
Vulnerability information will be released freely, though
every effort will be made to inform the relevant vendor
before the general public is informed.
脆弱性情報は自由に発表されるでしょう、一般が知識があるようになる前にあらゆる取り組みは関連ベンダーに知らせさせられるでしょうが。
- Embarrassing information includes the statement that an
incident has occurred, and information about its extent or
severity. Embarrassing information may concern a site or
a particular user or group of users.
- 恥ずかしい情報はインシデントが起こったという声明、およびその範囲か厳しさの情報を含んでいます。 恥ずかしい情報はサイト、特定のユーザまたはユーザー層に関係があるかもしれません。
Embarrassing information will not be released without the
permission of the site or users in question, except as
provided for below.
恥ずかしい情報はサイトかユーザのはっきりしていない許可なしで発表されないでしょう、以下に備えられるのを除いて。
Brownlee & Guttman Best Current Practice [Page 29] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[29ページ]。
- Statistical information is embarrassing information with
the identifying information stripped off.
- 統計情報は身元が分かる情報が全部はぎ取られている恥ずかしい情報です。
Statistical information will be released at the discretion
of the Computing Services Department.
統計情報はコンピューターサービス部の裁量で発表されるでしょう。
- Contact information explains how to reach system
administrators and CSIRTs.
- 問い合わせ先で、システム管理者とCSIRTsに届く方法がわかります。
Contact information will be released freely, except where
the contact person or entity has requested that this not
be the case, or where XYZ-CERT has reason to believe that
the dissemination of this information would not be
appreciated.
問い合わせ先は自由に発表されるでしょう、連絡窓口か実体が、どこでこれがそうでないよう要求したか、そして、またはXYZ-CERTがどこにこの情報の普及をよろしくお願いしますと信じる理由を持っているかを除いて。
Potential recipients of information from the XYZ-CERT will be
classified as follows:
XYZ-CERTからの情報の潜在的受取人は以下の通り分類されるでしょう:
- Because of the nature of their responsibilities and
consequent expectations of confidentiality, members of XYZ
University management are entitled to receive whatever
information is necessary to facilitate the handling of
computer security incidents which occur in their
jurisdictions.
- 秘密性へのそれらの責任と結果の期待の本質のために、XYZ大学管理のメンバーはどんな彼らの管内に起こるコンピュータセキュリティインシデントの取り扱いを容易にするのに必要な情報も受け取る権利を与えられます。
- Members of the Office of Rights and Responsibilities are
entitled to receive whatever information they request
concerning a computer security incident or related matter
which has been referred to them for resolution. The same is
true for the XYZ Security Department, when its assistance in
an investigation has been enlisted, or when the investigation
has been instigated at its request.
- RightsとResponsibilitiesのオフィスのメンバーは彼らがコンピュータセキュリティインシデントに関して要求するどんな情報か関連する彼らが解決について参照された物質も受ける権利を与えられます。 XYZ保安部に、同じくらいは本当です、調査における支援が得られたか、または調査が要求によって扇動されたとき。
- System administrators at XYZ University who are members of
the CCSA are also, by virtue of their responsibilities,
trusted with confidential information. However, unless such
people are also members of XYZ-CERT, they will be given only
that confidential information which they must have in order
to assist with an investigation, or in order to secure their
own systems.
- また、彼らの責任によって、XYZ大学のCCSAのメンバーであるシステム管理者は秘密情報で信じられます。 しかしながら、また、そのような人々がXYZ-CERTのメンバーでないなら、彼らが調査を助けるか、またはそれら自身のシステムを固定するために持ってはいけないその秘密情報しか彼らに与えるでしょう。
- Users at XYZ University are entitled to information which
pertains to the security of their own computer accounts,
even if this means revealing "intruder information", or
"embarrassing information" about another user. For
example, if account aaaa is cracked and the intruder attacks
account bbbb, user bbbb is entitled to know that aaaa was
cracked, and how the attack on the bbbb account was
- XYZ大学のユーザはそれら自身のコンピュータアカウントのセキュリティに関係する情報の権利を与えられます、これが顕な「侵入者情報」、または別のユーザに関する「恥ずかしい情報」を意味しても。 例えば、アカウントaaaaが割られて、侵入者攻撃がbbbbを説明するなら、ユーザbbbbはaaaaが割られたのを知っている権利を与えられて、bbbbアカウントに対する攻撃がどのようにあったかをそうされます。
Brownlee & Guttman Best Current Practice [Page 30] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[30ページ]。
executed. User bbbb is also entitled, if she or he requests
it, to information about account aaaa which might enable
bbbb to investigate the attack. For example, if bbbb was
attacked by someone remotely connected to aaaa, bbbb should
be told the provenance of the connections to aaaa, even
though this information would ordinarily be considered
private to aaaa. Users at XYZ University are entitled to be
notified if their account is believed to have been
compromised.
実行にされる。 また、ユーザbbbbは権利を与えられます、彼女か彼がそれを要求するなら、bbbbが攻撃を調査するのを可能にするかもしれないアカウントaaaaの情報に。 例えば、bbbbがaaaaに離れて接続されただれかによって攻撃されるなら、bbbbは接続の起源をaaaaに言われるでしょうに、この情報はaaaaに個人的であると通常考えられるでしょうが。 彼らのアカウントが感染されたと信じられているなら、XYZ大学のユーザは通知される権利を与えられます。
- The XYZ University community will receive no restricted
information, except where the affected parties have given
permission for the information to be disseminated.
Statistical information may be made available to the general
XYZ community. There is no obligation on the part of the
XYZ-CERT to report incidents to the community, though it may
choose to do so; in particular, it is likely that the
XYZ-CERT will inform all affected parties of the ways in
which they were affected, or will encourage the affected site
to do so.
- XYZ大学共同体は制限された情報を全く受け取らないでしょう、影響を受けた当事者が情報が広められる許可を与えたところを除いて。 一般的なXYZ共同体は統計情報を入手するかもしれません。 インシデントを共同体に報告するために、義務は全くXYZ-CERT側のありません、そうするのを選ぶかもしれませんが。 XYZ-CERTは、それらが影響を受けた方法についてすべての影響を受けた当事者に知らせそうであるか、または特に、関係部位がそうするよう奨励しそうでしょう。
- The public at large will receive no restricted information.
In fact, no particular effort will be made to communicate
with the public at large, though the XYZ-CERT recognizes
that, for all intents and purposes, information made
available to the XYZ University community is in effect made
available to the community at large, and will tailor the
information in consequence.
- 社会全般は制限された情報を全く受け取らないでしょう。 事実上、どんな特定の取り組みも社会全般とコミュニケートさせられないでしょう、XYZ-CERTは、XYZ大学共同体が入手した情報がすべての「不-テント」と目的のために事実上、一般社会に利用可能に作られていて、その結果、情報を合わせると認めますが。
- The computer security community will be treated the same way
the general public is treated. While members of XYZ-CERT may
participate in discussions within the computer security
community, such as newsgroups, mailing lists (including the
full-disclosure list "bugtraq"), and conferences, they will
treat such forums as though they were the public at large.
While technical issues (including vulnerabilities) may be
discussed to any level of detail, any examples taken from
XYZ-CERT experience will be disguised to avoid identifying
the affected parties.
- コンピュータセキュリティ共同体は一般が扱われる同じように扱われるでしょう。 XYZ-CERTのメンバーが参加しているかもしれない間、コンピュータセキュリティ共同体の中のニュースグループや、メーリングリスト("bugtraq"という完全な開示のリストを含んでいる)や、会議などの議論では、それらはまるで彼らが社会全般であるかのようにそのようなフォーラムを扱うでしょう。 専門的な問題(脆弱性を含んでいる)についてどんなレベルの詳細とも議論しているかもしれない間、XYZ-CERT経験から取られたどんな例も、影響を受けた当事者を特定するのを避けるために変装するでしょう。
- The press will also be considered as part of the general
public. The XYZ-CERT will not interact directly with the
Press concerning computer security incidents, except to point
them toward information already released to the general
public. If necessary, information will be provided to the
XYZ University Public Relations Department, and to the
Customer Relations group of the Computing Services
Department. All incident-related queries will be referred to
- また、プレスは一般の一部であるとみなされるでしょう。 XYZ-CERTはコンピュータセキュリティインシデントに関して直接Pressと対話しないでしょう、既に一般に発表された情報に向かってそれらを指すのを除いて。 必要なら、XYZ大学Public Relations部と、そして、コンピューターサービス部の苦情処理係グループに情報を提供するでしょう。 すべてのインシデント関連の質問が言及されるでしょう。
Brownlee & Guttman Best Current Practice [Page 31] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[31ページ]。
these two bodies. The above does not affect the ability of
members of XYZ-CERT to grant interviews on general computer
security topics; in fact, they are encouraged to do to, as a
public service to the community.
これらの2つのボディー。 上記はXYZ-CERTのメンバーが汎用コンピュータセキュリティ話題に関してインタビューを承諾する能力に影響しません。 事実上、それらはそうです。社会奉仕として共同体にするために、奨励されています。
- Other sites and CSIRTs, when they are partners in the
investigation of a computer security incident, will in some
cases be trusted with confidential information. This will
happen only if the foreign site's bona fide can be verified,
and the information transmitted will be limited to that which
is likely to be helpful in resolving the incident. Such
information sharing is most likely to happen in the case of
sites well known to XYZ-CERT (for example, several other
Quebec universities have informal but well-established
working relationships with XYZ University in such matters).
- 彼らがコンピュータセキュリティインシデントの調査でパートナーであるときに、いくつかの場合、他のサイトとCSIRTsは秘密情報で信じられるでしょう。 海外サイトが誠実である場合にだけ、これは起こるでしょう。確かめることができて、伝えられた情報はインシデントを決議する際に役立っている傾向があるそれに制限されるでしょう。 XYZ-CERTによく知られているサイトの場合でそのような情報共有は最も起こりそうです(例えば、他のいくつかのケベック大学には、そのような件に関してXYZ大学との非公式の、しかし、安定している仕事上のお付き合いがあります)。
For the purposes of resolving a security incident, otherwise
semi-private but relatively harmless user information such as
the provenance of connections to user accounts will not be
considered highly sensitive, and can be transmitted to a
foreign site without excessive precautions. "Intruder
information" will be transmitted freely to other system
administrators and CSIRTs. "Embarrassing information" can be
transmitted when there is reasonable assurance that it will
remain confidential, and when it is necessary to resolve an
incident.
セキュリティインシデントを決議する目的のために、ユーザアカウントとの接続の起源などのそうでなければ、準個人的な、しかし、比較的無害なユーザー情報を非常に敏感であると考えないで、過度の注意なしで海外サイトに伝えることができます。 「侵入者情報」は自由に他のシステム管理者とCSIRTsに伝えられるでしょう。 いつ、秘密のままで残るという手頃な保証があるか、そして、インシデントを決議するのがいつ必要であるかという「恥ずかしい情報」を伝えることができます。
- Vendors will be considered as foreign CSIRTs for most intents
and purposes. The XYZ-CERT wishes to encourage vendors of
all kinds of networking and computer equipment, software, and
services to improve the security of their products. In aid
of this, a vulnerability discovered in such a product will be
reported to its vendor, along with all technical details
needed to identify and fix the problem. Identifying details
will not be given to the vendor without the permission of the
affected parties.
- ベンダーはほとんどの「不-テント」と目的のための外国CSIRTsであるとみなされるでしょう。 XYZ-CERTは、すべての種類のネットワークの、そして、コンピュータ機器の、そして、ソフトウェアの、そして、サービスのベンダーがそれらの製品のセキュリティを向上させるよう奨励したがっています。 この援助では、そのような製品の中に発見された脆弱性はベンダーに報告されるでしょう、問題を特定して、修正するのに必要であるすべての技術的詳細と共に。 詳細を特定するのは影響を受けた当事者の許可なしでベンダーに与えられないでしょう。
- Law enforcement officers will receive full cooperation from
the XYZ-CERT, including any information they require to
pursue an investigation, in accordance with the Policy on
Computing Facilities.
- 法施行役員はXYZ-CERTから全力をあげての協力を受けるでしょう、彼らが調査を追求するのを必要とする情報を含んでいて、Computing Facilitiesの上のPolicyによると。
4.3 Communication and Authentication
4.3 コミュニケーションと認証
In view of the types of information that the XYZ-CERT will
likely be dealing with, telephones will be considered
sufficiently secure to be used even unencrypted. Unencrypted
e-mail will not be considered particularly secure, but will be
XYZ-CERTがおそらく対処する情報のタイプから見て、電話は、非暗号化されてさえいた状態で使用されるために十分安全であると考えられるでしょう。 暗号化されていない電子メールは、特に安全であることは考えられませんが、あるでしょう。
Brownlee & Guttman Best Current Practice [Page 32] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[32ページ]。
sufficient for the transmission of low-sensitivity data. If
it is necessary to send highly sensitive data by e-mail, PGP
will be used. Network file transfers will be considered to
be similar to e-mail for these purposes: sensitive data should
be encrypted for transmission.
低感度データの伝達では、十分です。 メールで非常に機密のデータを送るのが必要であるなら、PGPは使用されるでしょう。 ネットワークファイル転送がこれらの目的のためにメールするために同様であると考えられるでしょう: 極秘データはトランスミッションのために暗号化されるべきです。
Where it is necessary to establish trust, for example before
relying on information given to the XYZ-CERT, or before
disclosing confidential information, the identity and bona
fide of the other party will be ascertained to a reasonable
degree of trust. Within XYZ University, and with known
neighbor sites, referrals from known trusted people will
suffice to identify someone. Otherwise, appropriate methods
will be used, such as a search of FIRST members, the use of
WHOIS and other Internet registration information, etc, along
with telephone call-back or e-mail mail-back to ensure that
the party is not an impostor. Incoming e-mail whose data must
be trusted will be checked with the originator personally, or
by means of digital signatures (PGP in particular is
supported).
それがどこでXYZ-CERTに与えられた情報を当てにする前、または例えば、秘密情報、アイデンティティを明らかにする前に信頼を証明するのに必要であって、相手で誠実であるかは妥当な度合いの信頼に確かめられるでしょう。 XYZ大学以内と知られている隣人サイトで、知られている信じられた人々からの紹介は、だれかを特定するために十分でしょう。 さもなければ、適切なメソッドは、パーティーが詐欺師でないことを保証するのに通話後部かメールメール後部と共にFIRSTメンバーの検索やWHOISの使用や他のインターネットレジスト情報などのように使用されるでしょう。 データを信じなければならない入ってくる電子メールは個人的、またはデジタル署名によって創始者に問い合わせられるでしょう(特にPGPはサポートされます)。
5. Services
5. サービス
5.1 Incident Response
5.1インシデントレスポンス
XYZ-CERT will assist system administrators in handling the
technical and organizational aspects of incidents. In
particular, it will provide assistance or advice with respect
to the following aspects of incident management:
XYZ-CERTはインシデントの技術的で組織的な局面を扱うのにシステム管理者を助けるでしょう。 特に、付随している管理の以下の局面に関して支援かアドバイスを提供するでしょう:
5.1.1 Incident Triage
5.1.1 付随している選別
- Investigating whether indeed an incident occured.
- Determining the extent of the incident.
- 本当に、インシデントがoccuredされたかどうか調査します。 - インシデントの範囲を測定します。
5.1.2 Incident Coordination
5.1.2 付随しているコーディネート
- Determining the initial cause of the incident
(vulnerability exploited).
- Facilitating contact with other sites which may be
involved.
- Facilitating contact with XYZ University Security and/or
appropriate law enforcement officials, if necessary.
- Making reports to other CSIRTs.
- Composing announcements to users, if applicable.
- インシデント(利用された脆弱性)の初期の原因を決定します。 - かかわるかもしれない他のサイトとの接触を容易にします。 - 必要なら、XYZ大学Security、そして/または、適切な取締官との接触を容易にします。 - レポートを他のCSIRTsにします。 - 適切であるなら、発表をユーザに構成します。
Brownlee & Guttman Best Current Practice [Page 33] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[33ページ]。
5.1.3 Incident Resolution
5.1.3 付随している解決
- Removing the vulnerability.
- Securing the system from the effects of the incident.
- Evaluating whether certain actions are likely to reap
results in proportion to their cost and risk, in
particular those actions aimed at an eventual prosecution
or disciplinary action: collection of evidence after the
fact, observation of an incident in progress, setting
traps for intruders, etc.
- Collecting evidence where criminal prosecution, or
University disciplinary action, is contemplated.
- 脆弱性を取り除きます。 - インシデントの効果からシステムを固定します。 - ある動作が収穫しそうであるかどうか評価するのがそれらの費用とリスクか、特に最後の起訴が目的とされたそれらの動作か懲戒免職に比例して結果として生じます: 事実の後の証拠の収集、侵入者などに罠を設定する進行中のインシデントの観測 - 刑事訴追、または大学懲戒免職が熟考される証拠を集めます。
In addition, XYZ-CERT will collect statistics concerning
incidents which occur within or involve the XYZ University
community, and will notify the community as necessary to
assist it in protecting against known attacks.
さらに、XYZ-CERTは、XYZ大学共同体に中に起こるか、またはかかわるインシデントに関して統計を集めて、必要に応じて共同体が知られている攻撃から守るのにそれを助けるように通知するでしょう。
To make use of XYZ-CERT's incident response services, please
send e-mail as per section 2.11 above. Please remember that
the amount of assistance available will vary according to
the parameters described in section 4.1.
XYZ-CERTのインシデントレスポンスサービスを利用するには、上のセクション2.11に従ってメールを送ってください。 セクション4.1で説明されたパラメタによると、有効な支援している量が異なるつもりであったのを覚えていてください。
5.2 Proactive Activities
5.2 先を見越す活動
The XYZ-CERT coordinates and maintains the following
services to the extent possible depending on its resources:
- Information services
- List of departmental security contacts, administrative
and technical. These lists will be available to the
general public, via commonly-available channels such as
the World Wide Web and/or the Domain Name Service.
- Mailing lists to inform security contacts of new
information relevant to their computing environments.
These lists will be available only to XYZ University
system administrators.
- Repository of vendor-provided and other security-related
patches for various operating systems. This repository
will be available to the general public wherever
license restrictions allow it, and will be provided via
commonly-available channels such as the World Wide Web
and/or ftp.
- Repository of security tools and documentation for
use by sysadmins. Where possible, precompiled
ready-to-install versions will be supplied. These will
be supplied to the general public via www or ftp as
above.
XYZ-CERTは可能な範囲内でリソースによる以下のサービスを、調整して、維持します: - 情報サービス--部門のセキュリティ接触の管理的、そして、技術的なリスト。 これらのリストはWorld Wide Web、そして/または、Domain Name Serviceなどの一般的に利用可能なチャンネルで一般にとって利用可能になるでしょう。 - それらのコンピューティング環境に関連している新情報のセキュリティ接触を知らせるメーリングリスト。 これらのリストはXYZ大学のシステム管理者だけに利用可能になるでしょう。 - 様々なオペレーティングシステムこの倉庫のためのベンダーによって提供されて他のセキュリティ関連のパッチの倉庫をライセンス制限がどこにそれを許容しても一般にとって利用可能であり、World Wide Web、そして/または、ftpなどの一般的に利用可能なチャンネルで提供するでしょう。 - sysadminsによる使用のためにセキュリティツールとドキュメンテーションの倉庫。 可能で、前コンパイルされているところに、インストールするのにおいて準備ができるバージョンを供給するでしょう。 同じくらい上でwwwかftpを通してこれらを一般に提供するでしょう。
Brownlee & Guttman Best Current Practice [Page 34] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[34ページ]。
- "Clipping" service for various existing resources, such
as major mailing lists and newsgroups. The resulting
clippings will be made available either on the
restricted mailing list or on the web site, depending
on their sensitivity and urgency.
- Training services
- Members of the XYZ-CERT will give periodic seminars on
computer security related topics; these seminars will
be open to XYZ University system administrators.
- Auditing services
- Central file integrity checking service for Unix
machines, and for any other platforms capable of
running "tripwire".
- Security level assignments; machines and subnetworks
at XYZ University will be audited and assigned a
security level. This security level information will be
available to the XYZ University community, to facilitate
the setting of appropriate access privileges. However,
details of the security analyses will be confidential,
and available only to the concerned parties.
- Archiving services
- Central logging service for machines capable of
Unix-style remote logging. Incoming log entries will
be watched by an automated log analysis program, and
events or trends indicative of a potential security
problem will be reported to the affected system
administrators.
- Records of security incidents handled will be kept.
While the records will remain confidential, periodic
statistical reports will be made available to the XYZ
University community.
- 主要なメーリングリストやニュースグループなどの様々な既存のリソースのためのサービスを「切り取ります」。 結果として起こる切り取りを制限されたメーリングリストの上、または、ウェブサイトの上で利用可能にするでしょう、それらの感度と緊急によって。 - トレーニングサービス--XYZ-CERTのメンバーはコンピュータセキュリティ関連した話題で周期的なセミナーを与えるでしょう。 これらのセミナーはXYZ大学のシステム管理者にとって開くようになるでしょう。 - 監査のサービス--Unixマシン、および「仕掛け線」を実行できるいかなる他のプラットホームのためのサービスもチェックする中央のファイル保全。 - セキュリティは課題を平らにします。 XYZ大学のマシンとサブネットワークは監査されて、セキュリティー・レベルを割り当てられるでしょう。 このセキュリティー・レベル情報は、適切なアクセス権の設定を容易にするためにXYZ大学共同体に利用可能になるでしょう。 しかしながら、証券分析の詳細は、秘密であって、関係者だけに利用可能になるでしょう。 - サービスを格納します--Unix-スタイルのリモート伐採ができるマシンのための主要な伐採サービス。 入って来る航空日誌記入事項は自動化されたログ解析プログラムで見られるでしょう、そして、潜在的警備上の問題を暗示したイベントか傾向が影響を受けるシステム管理者に報告されるでしょう。 - 扱われたセキュリティインシデントに関する記録はつけられるでしょう。 記録が秘密のままで残る間、XYZ大学共同体は周期的な統計報告を入手するでしょう。
Detailed descriptions of the above services, along with
instructions for joining mailing lists, downloading
information, or participating in certain services such as the
central logging and file integrity checking services, are
available on the XYZ-CERT web site, as per section 2.10
above.
上のサービスの詳述は情報をダウンロードして、メーリングリストを接合するための指示、または主要な伐採やファイル保全などのあるサービスに参加すると共にサービスがチェックするXYZ-CERTウェブサイトで利用可能です、上のセクション2.10に従って。
6. Incident Reporting Forms
6. 付随している報告様式
There are no local forms developed yet for reporting incidents
to XYZ-CERT. If possible, please make use of the Incident
Reporting Form of the CERT Coordination Center (Pittsburgh,
PA). The current version is available from:
ftp://info.cert.org/incident_reporting_form
インシデントをXYZ-CERTに報告するためにまだ発生していたどんな地方のフォームもありません。 できれば、CERTコーディネートセンター(ピッツバーグ(PA))のIncident Reporting Formを利用してください。 最新版は以下から利用可能です。 ftp://info.cert.org/incident_reporting_form
Brownlee & Guttman Best Current Practice [Page 35] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[35ページ]。
7. Disclaimers
7. 注意書き
While every precaution will be taken in the preparation of
information, notifications and alerts, XYZ-CERT assumes no
responsibility for errors or omissions, or for damages
resulting from the use of the information contained within.
あらゆる注意が情報、通知、および警戒の準備で払われるでしょうが、XYZ-CERTは中に含まれた状態で誤りか省略、または情報の使用から生じる損害賠償への責任を全く負いません。
4 Acknowlegdements
4 Acknowlegdements
The editors gratefully acknowledge the contributed material and editorial scrutiny of Anne Bennett. Thanks also to Don Stikvoort for assistance reworking the description of Incident Response Team services.
エディタは感謝してアン・ベネットの寄付された材料と編集の精査を承諾します。 また、Incident Response Teamサービスの記述を作りなおす支援をドンStikvoortをありがとうございます。
5 References
5つの参照箇所
[RFC 2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[RFC1983] マルキン、G.、「インターネットユーザの用語集」、FYI18、RFC1983、1996年8月。
6 Security Considerations
6 セキュリティ問題
This document discusses the operation of Computer Security Incident Response Teams, and the teams' interactions with their constituencies and with other organizations. It is, therefore, not directly concerned with the security of protocols, applications, or network systems themselves. It is not even concerned with particular responses and reactions to security incidents, but only with the appropriate description of the responses provided by CSIRTs.
このドキュメントはコンピュータセキュリティ事件対応チームの操作、および彼らの選挙民と他の組織とのチームの相互作用について議論します。 したがって、それは直接プロトコル、アプリケーション、またはネットワーク・システム自体のセキュリティに関係がありません。 それはセキュリティインシデントへの特定の応答と反応にもかかわらず、CSIRTsによって提供される応答の適切な記述だけに関係がしてさえいません。
Nonetheless, it is vital that the CSIRTs themselves operate securely, which means that they must establish secure communication channels with other teams, and with members of their constituency. They must also secure their own systems and infrastructure, to protect the interests of their constituency and to maintain the confidentiality of the identity of victims and reporters of security incidents.
それにもかかわらず、CSIRTs自身がしっかりと作動するのは、重大です(彼らが他のチーム、および彼らの選挙民のメンバーと共に安全な通信チャネルを確立しなければならないことを意味します)。 また、彼らは、彼らの選挙民の関心を保護して、セキュリティインシデントの犠牲者とレポーターのアイデンティティの秘密性を維持するためにそれら自身のシステムとインフラストラクチャを固定しなければなりません。
Brownlee & Guttman Best Current Practice [Page 36] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[36ページ]。
7 Authors' Addresses
7人の作者のアドレス
Nevil Brownlee ITSS Technology Development The University of Auckland
ネヴィルブラウンリーのITSS技術開発オークランド大学
Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz
以下に電話をしてください。 +64 9 373 7599x8941 EMail: n.brownlee@auckland.ac.nz
Erik Guttman Sun Microsystems, Inc. Bahnstr. 2 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズ・インクBahnstr。 2 74915Waibstadtドイツ
Phone: +49 7263 911484 EMail: Erik.Guttman@sun.com
以下に電話をしてください。 +49 7263 911484はメールされます: Erik.Guttman@sun.com
Brownlee & Guttman Best Current Practice [Page 37] RFC 2350 Expectations for Computer Security Incident Response June 1998
ブラウンリーとGuttmanの最も良い海流は1998年6月にコンピュータセキュリティインシデント応答へのRFC2350期待を練習します[37ページ]。
8 Full Copyright Statement
8 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Brownlee & Guttman Best Current Practice [Page 38]
ブラウンリーとGuttmanの最も良い現在の習慣[38ページ]
一覧
スポンサーリンク
