「組織図」では説明できない ── RFC2350というCSIRTの自己紹介状【CySec復習ログ#10】

Last updated at 2026-08-19Posted at 2026-08-17

はじめに

少し前の私は、「うちの CSIRT って結局何をする組織なの?」と聞かれたとき、頭に浮かぶのが組織図の四角い箱だけでした。「ここにこの人がいて、その下にこの部署があって」と人と箱の配置は説明できます。けれど、肝心の「何を守って、何をして、何はしないのか」になると、一枚も言葉が出てこなかったのです。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログです。本シリーズの通し番号では #10 にあたります。想定読者は、少し前の私と同じく「CSIRT という言葉は知っているが、自分の組織の CSIRT が何をする組織なのかを一枚で説明できない」エンジニア・情シス・セキュリティ担当です。資格学習中の方や、社内で体制づくりに関わり始めた方を念頭に置いています。

この記事が扱うのは、「CSIRT とは何か。どう定義し、どう宣言するか」という、いわば平時に書いておく自己紹介状の話です。言い換えると、CSIRT を「何のために・何を守るために置くのか(WHAT / WHY)」に集中します。一方、「CSIRT は専門部署が必要か、それとも機能でよいのか」「アラートが鳴ったあとに誰が・どの順で・何を判断して動くか(OODA・トリアージ・机上演習)」という"動かし方"(HOW)の論点は、ペアになる #9 に譲ります。本記事はそこには踏み込まず、平時の宣言に徹します。

この記事の軸になる見方を、先に1行で書いておきます。

CSIRT は「組織図(箱)」ではなく、「何を守り・何をし・何をしないと宣言したか」で定義される。RFC2350 は、その宣言を書くための「自己紹介状」のテンプレートである。

結論を先に3点でまとめておきます(TL;DR)。本文はこれをほどいていく形です。

CSIRT は「箱」ではなく「宣言」で定義される。 誰がいるか(組織図)ではなく、守るべき対象(Constituency)を決め、そこへ何をすると宣言したかが CSIRT の正体です。組織図の形は目的さえ達成できれば自由です。
RFC2350 は CSIRT の「自己紹介状」のテンプレート。 外の人(社員・顧客)が「何を期待して・どこに・どこまで頼れるか」を読み取れるように、ミッション・権限・ポリシー・サービス・免責を宣言する文書です。
自己紹介状の肝は3つ。 ポリシーが最後の拠り所であること、サービスは「書いた範囲が約束」になること、そして CIA の "A" は文脈で意味が変わること(可用性なのか真正性なのか)です。

読み終えたとき、「うちの CSIRT は?」と聞かれて、箱ではなく「何を守り・何をし・何をしないと宣言しているか」で答え始められるようになっていれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

CSIRTを「組織図」で説明しようとして詰まった

最初に、私がどこで詰まったのかを正直に書きます。ここが、この記事の出発点です。

CSIRT(Computer Security Incident Response Team)は、組織内で起きたセキュリティインシデントに対応するチームです。この説明自体は、本やスライドで何度も見ました。だから「CSIRT を作りましょう」と言われれば、私はまず組織図を描こうとしました。経営の下にセキュリティ委員会を置いて、その下に対応チームの箱を足して、という具合です。

ところが、その箱を描き終えても、肝心の問いには何も答えられませんでした。「で、その CSIRT は何を守るの?」「インシデントが来たら、どこまでやってくれるの?」「逆に、やらないことは何?」。箱は「誰がいるか」を示しますが、「何をするか・しないか」は一文字も含んでいません。組織図を見せられた相手が本当に知りたいのは、まさにその中身のほうでした。

このつまずきは、私だけのものではないと思います。組織図は描きやすく、見た目も整います。だからつい、それで CSIRT を定義した気になってしまいます。けれど、箱をいくら精密に描いても、CSIRT が何者かは決まりません。次の節で、その理由をはっきりさせます。

CSIRTは「箱」ではなく「宣言」で定義される

ここがこの記事の核です。CSIRT は組織図ではなく、宣言の中身で定義されます。

組織図(箱)と宣言(RFC2350)とで、それぞれ何に答えられるかを並べてみます。

観点	組織図(箱)で答えると	宣言(RFC2350)で答えると
誰がいるか	部署・役職・人の配置がわかる	(宣言の役割ではない)
何を守るか	わからない	Constituency として明示
何をするか	わからない	サービスとして明示
何をしないか	わからない	免責として明示
どんな権限で	わからない	Authority として明示

この表が示すとおり、組織図は人の配置しか語れません。「何を守り・何をし・何をしないか」という守備範囲に答えられるのは、宣言のほうだけです。では、その宣言はどんな順番で組み立てるのか。出発点になるのが Constituency です。

CSIRT の定義をそぎ落とすと、「規定された Constituency(守るべき対象)のセキュリティインシデントへの対応を、コーディネートし支援するチーム」になります。この一文で決定的なのは、「Constituency(守るべき対象)」が先に来ている点です。守る相手が決まっていないチームは、何に対応すべきかも決められません。

順序を意識すると、CSIRT の組み立て方が見えてきます。

この図のとおり、Constituency が起点です。守る対象が決まってはじめて、「その対象にとって何がリスクか」を見積もれます。そして、そのリスクに対して「何をするか(サービス)」「どこまでやれるか(権限)」「何をしないか(免責)」が決まっていきます。組織図の箱は、この一連の宣言を実行するための手段にすぎません。手段を先に描いても、目的(何を守るか)は決まらないのです。

講義でも繰り返し出てきたのが、「すべては守れない」という前提でした。脅威は無限にあります。極端に言えば隕石も脅威です。だからこそ、自分たちの事業にとって「何を守るか」という価値観を先に決め、そこから守り方を逆算します。CSIRT はあくまで手段で、大事なのは「何のために守るのか」という目的のほうだ、という話です。

組織図が自由なのは「目的さえ達成できれば形は問わない」から

「箱で定義できない」ことの裏返しとして、組織図の形そのものには正解がありません。

講義では、CSIRT の組織上の置き方として、おおむね次の3パターンが示されました。経営の直下に置くパターン、リスク管理委員会の直下に置くパターン、そして複数の部門の配下に分散して置くパターンです。実在の企業でも、新設するところもあれば、既存の研究所などに機能を持たせるところもあり、置き方はさまざまです。

ここで大事なのは、「教科書に載っている組織図が唯一の正解ではない」ということです。目的(規定された対象を守るためにインシデント対応をコーディネートする)さえ達成できれば、形は自由でよいのです。逆に言えば、形がどうであれ、宣言の中身が定まっていなければ CSIRT として機能しません。だから、定義は箱ではなく宣言の側にある、というわけです。

RFC2350 ── CSIRTの「自己紹介状」のテンプレート

宣言の中身を、どんな順番で・何を書けばよいのか。その雛形を与えてくれるのが RFC2350 です。

RFC2350 は、IETF が定める文書の1つで、正式名称は "Expectations for Computer Security Incident Response"(コンピュータセキュリティインシデント対応への期待)です。1998年6月に発行され、ステータスは Best Current Practice(BCP 21)です(RFC 2350)。私自身、最初は Informational(情報提供)だと思い込んでいました。正しくは BCP(BCP 21、現時点で推奨されるベストプラクティス)なので、ここは念のため訂正しておきます。

RFC2350 を一言でいうと、「CSIRT に対して世間が一般的に抱く期待を、ベストプラクティスとして整理した文書」です。重要なのは、これが外の人に向けた文書だという点です。一般の社員や顧客が、その CSIRT について「何をしてくれるのか」「何を期待して通報すればよいのか」「どんな根拠で設置されているのか」「どこまで権限があるのか」を読み取れるように書きます。

だから私は、これを「CSIRT の自己紹介状」と呼ぶのがしっくりきました。初対面の相手に「私はこういう者で、こういうことをします。ただしこれはしません」と渡す、あの紙と同じ役割です。

何が書いてあるか(3.1〜3.7を一望する)

自己紹介状の中身は、RFC2350 のセクション3にまとまっています。節構成を一望できるように表にしました。

節	原文の見出し	何を書くか	読み手が読み取ること
3.1	Obtaining the Document	この文書自体の入手方法・版・更新日	今読んでいる情報が最新か
3.2	Contact Information	連絡先・対応時間・本人認証の手段	どこに、どうやって通報すればよいか
3.3	Charter(憲章)	ミッション / Constituency / 設置母体 / 権限(Authority)	誰のために、どんな後ろ盾で動くチームか
3.4	Policies(ポリシー)	扱うインシデントの種類とサポートレベル / 連携・情報開示 / 連絡と本人認証	どこまで頼ってよいか、情報はどう扱われるか
3.5	Services(サービス)	具体的に何をするか(インシデント対応 / 予防的活動)	何をしてくれて、何はしないか
3.6	Incident Reporting Forms	通報時に書いてほしい様式	何を伝えればスムーズか
3.7	Disclaimers(免責事項)	負う義務の範囲・責任の限界	どこまでが約束で、どこからは違うか

3.3 の Charter は、さらに 3.3.1 Mission Statement(ミッション)・3.3.2 Constituency(守るべき対象)・3.3.3 Sponsoring Organization / Affiliation(設置母体)・3.3.4 Authority(権限)に分かれます。前の節で見た「Constituency を起点に組み立てる」という構造が、そのまま文書の骨格になっているのがわかります。

なお、RFC2350 には別添(Appendix)も付いています。Appendix A は用語集、B は関連資料、C は既知の CSIRT 一覧、D は CSIRT テンプレートの概要(セクション3の要点)、E は架空の "XYZ-CERT" を使った記入例です。自分で書くときは、D で骨格をつかみ、E の記入例を真似ると進めやすい構成になっています。

自己紹介状の「肝」は3つ

ここからが、入門としていちばんつまずきやすく、いちばん持ち帰ってほしいところです。RFC2350 を読むうえで効いてくる勘どころを3つに絞ります。

肝1: 3.4 ポリシーが最後の拠り所

3.4 のポリシーは、自己紹介状の中でもとりわけ大事な節です。講義でも「ここが一番大事」と強調されました。

理由は、ここが何かあったときの最後の拠り所になるからです。CSIRT がある対応に踏み込んだとき、「なぜそれをやってよいのか」を問われる場面が必ず来ます。そのときに立ち返るのが、「存在理由」「経営層からの権限委譲(Authority)があること」「その根拠(社内規程や設置の経緯)」をセットで書いたポリシーです。組織からの要求を上流に置き、それを元に「CSIRT がやること」を下流で決める、という順番がここに表れます。逆に、権限委譲が書かれていないと、いざというときに「誰の承認でやっているのか」が宙に浮きます。

肝2: 3.5 サービスは「書いた範囲が約束」になる

3.5 のサービスには、「具体的に何をするか」を書きます。ここで初心者が見落としがちな機微があります。書いた範囲が、そのまま約束になるということです。

たとえば「脆弱性を分析する」と書いたとして、それは「脆弱性に対応する(直す)」とまでは約束していません。「分析する」と「対応する」は別の言葉で、書いた言葉の範囲だけが期待される、というのが RFC2350 の考え方です。だから、サービスは書きすぎても書かなすぎても困ります。書きすぎれば実態が追いつかず、書かなすぎれば「結局何をしてくれるの?」になります。

この濃淡を調整するのが、3.4 のポリシーに含まれる「サポートレベル」です。同じ「対応する」でも、どこまで深く面倒を見るのか、緊急度に応じてどう優先するのかを宣言しておきます。読み手が「ここまでは頼ってよい。ここからは自分でやる」と判断できるようにするのが目的です。

肝3: CIAの"A"は文脈で中身が変わる(可用性 vs 真正性)

3つめは、正確性のうえで取り違えやすい点です。セキュリティで頻出する「CIA」の "A" は、文脈によって指すものが変わります。ここを混同すると、文書を読み違えます。

	情報セキュリティ一般のトリアード	RFC2350 §2.3 の文脈
C	機密性(Confidentiality)	守秘性(Confidentiality)
I	完全性(Integrity)	完全性(Integrity)
A	可用性(Availability)	真正性(Authenticity)

右の列は、RFC2350 のセクション2.3「セキュアな通信の確立(Establishing Secure Communications)」の文脈です。左の列は、よく知られた情報セキュリティの3要素です。"A" は 可用性(Availability) で、「必要なときに使えること」を指します。一方、RFC2350 のスコープ(2.3)で出てくる "A" は 真正性(Authenticity) で、「やり取りしている相手が本当に正しい相手か」を指します(RFC 2350 セクション 2.3)。連絡を受け付ける CSIRT にとって、「この通報は本物の本人からか」を確かめられることは重要なので、安全な連絡の文脈では真正性が前面に出てくるわけです。

同じ "A" でも、片や可用性、片や真正性です。略語だけ覚えていると、どちらの文脈の話かを取り違えます。「CIA の A は、いまどっちの意味で使われているか」を毎回確かめる癖をつけると、こうした文書を正確に読めます。

なお、講義では情報セキュリティの価値観の移り変わりにも触れられました。かつては機密性を最優先(C > I, A)に守る考え方が主流でしたが、情報を流通・共有して事業を回す現在は、止まらないこと、すなわち可用性を重視する(A > C, I)場面が増えています。これも「Availability としての A」を重く見る流れで、真正性の話とは別物です。混同しないようにしましょう。

X.1060 ── 自己紹介状の「外側」にある地図

RFC2350 が「1つの CSIRT の自己紹介状」だとすれば、その外側で「組織全体のセキュリティ機能をどう配置するか」を描く地図にあたるのが X.1060 です。深入りはしませんが、位置づけだけ押さえておきます。

X.1060 は ITU-T(国際電気通信連合の電気通信標準化部門)の勧告で、正式名称は "Framework for the creation and operation of a cyber defence centre"(サイバーディフェンスセンターの構築と運用のためのフレームワーク)です。2021年6月に承認されました(ITU-T X.1060)。日本の知見をもとに国際標準化された経緯があります。

X.1060 の中心にあるのが CDC(Cyber Defense Center) という考え方です。CDC は、組織のセキュリティサービス全体を束ねる上位の概念で、CSIRT はその中の1つとして位置づけられます。同じ傘の下には、監視・検知を担う SOC や、自社製品の脆弱性を扱う PSIRT なども並びます。

本記事の関心からすると重要なのは、ここで各チームの「守備範囲」が線引きされる、という点です。CSIRT が何を引き受け、何を SOC や PSIRT に任せるのか。その境目をはっきりさせることが、自己紹介状で「何をして、何はしないか」を宣言する前提になります。

ここで言いたいのは、「CSIRT を1つの島として孤立させない」という視点です。CDC という地図の上で各チームの守備範囲が定まり、その自分の守備範囲を「何をして、何はしないか」と対外的に宣言したものが RFC2350 の自己紹介状だ、と捉えると、2つの文書の関係がすっきりします。X.1060 が「組織として何を守る体制を敷くか」を描き、RFC2350 が「その中で自分のチームは何を引き受けると宣言するか」を書く、という分担です。なお、各チームが有事に実際どう連携して動くか、という運用の流れは #9に委ねます。

実際に「自己紹介状」を書いてみて気づいたこと

第9回の宿題は、RFC2350 に準拠したフォームを使って、自分の CSIRT が何をするかを記述書にまとめる、というものでした。ここでは、特定の組織の回答は載せず、書いてみて一般的に気づいたことだけを整理します。

いちばんの気づきは、書こうとして初めて、「自分たちが何を守るのか」を誰も言語化していなかったと気づくことでした。Constituency(守るべき対象)の欄でいきなり手が止まります。「社員? システム? 顧客の情報? どこまで?」と考え出すと、これまで暗黙の了解で済ませてきたことを、実は誰も明確に決めていなかったと思い知らされました。前半で見た「Constituency が起点」という話を、身をもって実感する瞬間でした。

次の気づきは、欄が連鎖しているということでした。Constituency が決まらないと、サービスにも免責にも何を書けばよいか決まりません。守る対象が宙ぶらりんのままだと、「何をするか」も「何をしないか」も書けません。逆に、対象さえ定めれば、芋づる式に他の欄が埋まり始めます。

3つめは、免責(3.7)が思った以上に効くということです。社内向けだけならまだしも、社外に向けて自己紹介状を出すなら、「ここまでは責任を持つが、ここからは負わない」という線引きを書いておかないと、際限なく期待を背負い込むことになります。免責は逃げの条項ではなく、約束の輪郭をはっきりさせるための条項だと理解できました。

最後に実務的な Tips を1つ。空欄のフォームをいきなり埋めようとすると、たいてい手が止まります。JPCERT/CC は CSIRT 構築を支援するマテリアルを公開しているので、まずはそうした雛形や記入例を真似て、自分たちの言葉に置き換えていくのが進めやすいやり方でした(JPCERT/CC CSIRTマテリアル)。RFC2350 自体にも Appendix E に記入例があります。ゼロから書くのではなく、形のあるものを下敷きにするのがコツです。

まとめ

この記事では、CySec 第9回「インシデントレスポンス演習」の内容を、「CSIRT は組織図(箱)ではなく、何を守り・何をし・何をしないと宣言したかで定義される。RFC2350 はその宣言を書くための自己紹介状のテンプレートである」という1本の軸で再構成しました。タイトルの「組織図では説明できない」とは、箱の配置ではなく宣言の中身が CSIRT の正体だ、という意味です。

この記事の幹は3つです。これだけ持ち帰れば十分です。

CSIRT は「箱」ではなく「宣言」で定義される。 起点は Constituency(守るべき対象)です。対象が決まるとリスクを見積もれ、サービス・権限・免責が決まります。組織図の形は、目的さえ達成できれば自由です。
RFC2350 は自己紹介状のテンプレート。 外の人が「何を期待して・どこに・どこまで頼れるか」を読み取れるように、3.1〜3.7 でミッション・権限・ポリシー・サービス・免責を宣言します(BCP 21、1998年)。
肝は3つ。 3.4 ポリシーは最後の拠り所、3.5 サービスは書いた範囲が約束、そして CIA の "A" は可用性(Availability)か真正性(Authenticity)か文脈で中身が変わります。

そして、これらは読むだけより、書いてみるほうが圧倒的に身につきます。実際に書こうとすると、「自分たちが何を守るのか」を誰も言語化していなかったと気づくからです。

最後に、手を動かしてほしいことを1つ。自分の組織の CSIRT について、「何を守り(Constituency)・何をして・何はしないか(免責)」を、自己紹介状として1枚書き出してみてください。 RFC2350 の Appendix E や JPCERT/CC のマテリアルを下敷きにすると進めやすいです。少し前の私は組織図の箱しか描けませんでしたが、いまは「うちの CSIRT は誰のために、何をして、何はしないと宣言しているか」で語り始められるようになりました。

そして、この自己紹介状(平時の宣言)を実際に動かす「有事の動き方」は、ペアになる #9 で扱います。平時に何を宣言したかと、有事にどう動くかは、表裏一体です。ここまで読んでいただき、ありがとうございました。冒頭にも書いたとおり、私自身まだ学習中の身です。間違いや、より正確な捉え方があれば、指摘していただけると助かります。

参考資料

本記事で挙げた文書・用語・年号は、次の一次情報・公的情報で確認できます。記事中の内容は学習・執筆時点(2026年6月現在)のもので、最新は各サイトで確認してください。

※ X.1060 は2021年6月承認の版を一次情報で確認しています。その後の改訂版や補足文書(Supplement)が発行されている可能性があるため、最新の版番号は ITU-T の該当ページで確認してください。
※ RFC2350 のセクション番号・Appendix・ステータス(BCP 21)は原文で確認しています。日本語で読みたい場合は、JPCERT/CC の CSIRT 関連マテリアルが参考になります。