セキュリティ対応組織(SOC/CSIRT)強化に向けた
サイバーセキュリティ情報共有の「5W1H」

第 1.0 版

2017 年 10 月 27 日

日本セキュリティオペレーション事業者協議会 （ISOG-J）© 2017 ISOG-J改版履歴2017/10/27

初版作成

免責事項


本資料の著作権は日本セキュリティオペレーション事業者協議会(以下、ISOG-J)に帰属します。



引用については、著作権法で引用の目的上正当な範囲内で行われることを認めます。
引用部分を明確にし、出典が明記されるなどです。



なお、引用の範囲を超えると思われる場合は ISOG-J へご相談ください(info (at)isog-j.org まで)。



本文書に登場する会社名、製品名、サービス名は、一般に各社の登録商標または商標です。本文中では®や TM、©マークは明記していません。

ISOG-J ならびに執筆関係者は、このガイド文書に関するいかなる責任も負うものではありません。全ては自己責任にてご活用ください。

© 2017 ISOG-J目次
1.

はじめに .......................................................................................................................... 11.1.背景 ............................................................................................................................... 1
1.2.課題認識と本書の目的 .................................................................................................. 1

2.

Why と When.................................................................................................................. 3

3.

What ............................................................................................................................... 5
3.1.脆弱性情報の What ...................................................................................................... 5
3.1.1.

初動対応要否判断................................................................................................. 5

3.1.2.

検知と分析 ........................................................................................................... 6

3.1.3.

封じ込め/根絶/復旧............................................................................................... 7

3.1.4.

準備 ...................................................................................................................... 7

3.1.5.

事件後の対応 ........................................................................................................ 7

3.2.攻撃関連情報の What .................................................................................................. 8
3.2.1.

初動対応要否判断................................................................................................. 83.2.2.

検知と分析 ........................................................................................................... 83.2.3.

封じ込め/根絶/復旧............................................................................................. 103.2.4.

事件後の対応 ...................................................................................................... 103.3.実際のセキュリティ対応事例の What ........................................................................114.

受信者側の Who と How ............................................................................................... 125.

発信者側の Who と How ............................................................................................... 13

6.

Where............................................................................................................................ 147.

情報共有が逃れられない根本的な制約 ......................................................................... 15

おわりに ............................................................................................................................... 17i© 2017 ISOG-J1. はじめに
1.1.

背景

サイバーセキュリティの対応における「情報共有」については、経済産業省の「サイバーセキュリティ経営ガイドライン」1や内閣サイバーセキュリティセンター（NISC）の平成 29 年第 12 回会合「サイバー攻撃に係る情報の収集・分析・共有について」2などで述べられているように、その重要性は広く理解され、実際の取り組みとして JPCERT/CC やIPA の J-CSIP、民間の ISAC や日本シーサート協議会(NCA)などで情報共有の場が整備されつつある。

1.2.

課題認識と本書の目的

ここで、「情報共有」の大きな流れをおさらいしたい。

発信側

情報生成

受信側

フィードバック

フィードバック

情報発信

情報共有の場

図 1

情報
受信

情報
活用

情報共有の流れ情報を発信したいと思った側が、情報を生成し、情報共有の「場」へ発信、そしてその情報を利用したいと思っている受信側において、情報をキャッチし、活用していくというのが基本的な流れである。
前述したとおり、様々なところで情報共有の「場」が設けられてきているものの、その前後における過程はまだまだ成熟している状況とは言えず、情報発信そのものが不足していたり、共有された情報をセキュリティ対応に生かし切れていなかったりという課題がある。

1
2

http://www.meti.go.jp/policy/netsecurity/mng_guide.html
http://www.nisc.go.jp/conference/cs/dai12/pdf/12sankou.pdf
1© 2017 ISOG-Jその一因は、次に示す「5W1H」の観点が整理されないまま「情報共有」というキーワードだけが先行している実態にあるのではないだろうか。
発信側

受信側

Why

何を目的に何を目的に

When

どのようなタイミングでどのようなタイミングでWhat

何の情報を何の情報をWhere

どの情報共有の場においてどの情報共有の場から得てWho

誰が誰がHow

どのようにどのように発信するのか活用するのか

表 1 サイバーセキュリティ情報共有における 5W1H

本書においては、この「サイバーセキュリティ情報共有における 5W1H」について、順を追ってその考え方をまとめる。様々なところで行われている「情報共有」において、「情報発信」と「情報活用」活発化の参考となれば幸いである。

2© 2017 ISOG-J

2. Why と When
何を目的として情報共有するのかという「Why」と、その情報をどのようなタイミングで発信あるいは活用するのかという「When」は密接な関係にある。それは、セキュリテ
ィ対応の流れとリンクするからである。
NIST が発行する SP800 シリーズ（Special Publication）の SP800-61「コンピュータセキュリティ・インシデント対応ガイド」を参考にすると、インシデント対応は主に「準備」「検知と分析」「封じ込め/根絶/復旧」「事件後の対応」の 4 つのフェーズに分かれる。

準備

封じ込め/根絶/復旧

検知と分析

図 2

事件後の対応インシデント対応ライフサイクル

これはあくまで「インシデント対応」の流れであり、「情報共有」を起点として考えた場合、大きく変化する点が二つある。
一つ目は、「インシデント」は原則として対応しなければならないものであるが、共有された情報は対応が必要とは限らないという点である。例えば Apache Struts2 の脆弱性情報が共有されたとしても、そもそもそれを使用していなければ具体的な対応は不要である3。
つまり、共有された情報を元に何らかの初動対応を取るかどうかを判断するフェーズが追加される。
二つ目は、当然と言えば当然であるが、攻撃の情報が世の中に存在しているからと言って、自組織でインシデントが発生しているとは限らない点である。インシデントが発生していない場合、「封じ込め/根絶/復旧」というフェーズは存在しない。
これら二点を加味すると、情報共有を出発点としたセキュリティ対応は次のようなフローチャートとなる。
3「対応は不要と判断する」という対応をしていると捉えることもできるが、ここでは質の違いに着目して、異なる対応フェーズへの移行が伴うものと考える。
3© 2017 ISOG-J情報共有

対応不要

初動対応要否判断
対応が必要

検知なし

検知および分析準備（予防）

検知あり

事件
後の対応

封じ込め/根絶/復旧

図 3

情報共有を出発点としたセキュリティ対応このフローチャート上のどのフェーズ（「When（タイミング）」）で利用されるためのものなのかが、そのまま情報共有の「Why（目的）」となる。
情報共有の「Why（目的）」は、


初動対応要否判断



検知および分析

封じ込め/根絶/復旧準備（予防）



事件後の対応のいずれかを行うためのものであり、それぞれの「When（タイミング）」で使用する情報を収集すればよいということになる。上からその時期が早く訪れる順に記載しているが、上位のものほど、情報の網羅性よりも、判断に必要な最低限の情報をいかに早く発信/収集するかが重要になる。

4© 2017 ISOG-J3. What
では具体的に「What（何の情報）」を収集すればよいのか。前章でまとめた「Why（目的）」を意識すると整理しやすい。
ここでは情報共有で良く扱われる下記の三点について、具体的な事例を交え説明する。
脆弱性情報

攻撃関連情報

実際のセキュリティ対応事例

全ての情報が完全な状態で共有される必要はなく、「Why（目的）」「When（タイミング）」に合った情報を発信、収集できることが肝要である。

3.1.

脆弱性情報の What

脆弱性情報とは、悪意のある攻撃者が標的とするソフトウェアやハードウェアの不具合について、セキュリティ機関や関係者が公開した情報全般を指すものとする。共有された脆弱性情報はそれぞれの企業にとって脅威になるものと、そうではないものが存在するた
め、共有された内容を理解、把握する必要がある。

3.1.1. 初動対応要否判断
このフェーズでは何が必要となるだろうか。脆弱性の対応においては、具体的にどの脆弱性か明確にし、その対象となるシステムが存在するかどうかが対応要否の分岐となる。
よって、下記のような事項が必要である。
脆弱性識別子（CVE やパッチ番号など）



脆弱性の対象となる➢システム種別➢バージョン➢条件（システム構成、設定など）

各セキュリティ製品における対応状況
5© 2017 ISOG-J

条件が明らかになっていない、あるいは自システムの設定が不明といった場合は、バージョン情報までで対応要否を判断するのが一般的である。各セキュリティ製品の対応状況
によっても、その後の対応要否が変わる可能性があるため確認できる場合は情報を得ておくことが望ましい4。

3.1.2. 検知と分析対象となるシステムが存在し対応が必要と判断された場合、攻撃を検知する監視の実施と、被害の有無について分析する必要がある。その場合には下記の情報が役に立つ。


攻撃の特徴
➢

攻撃形態、関連する通信の内容➢核心となる攻撃コード

攻撃によって残る痕跡➢

被害を受けた後の通信内容➢

サーバやクライアントに残るログ➢

サーバやクライアントに残るその他の特徴



各セキュリティ製品における検知名



上記が不明な場合、自身で調査するための PoC（Proof of Concept）5

これらがあれば、攻撃や被害の有無を確認することができる。なお、PoC は高いレベルのセキュリティ人材が必要となるため、必ずしも扱われるものではない6。

4

初動時点では、製品ベンダーやセキュリティサービス提供事業者もパターンファイルやシグネチャ作成の真最中で情報が出せない、あるいはユーザからの問合せが殺到して対応しきれないなどのケースは実際に発生する。よって、この情報がなければ次のアクションに移れない、というような対応フローは避けるのが賢明である。
5 脆弱性を実証するためのプログラムのこと。
6 さらに高度なセキュリティ人材がいる場合には、自ら脆弱性を見つけ出したり、ソフトウェア修正パッチの情報から自ら PoC を作り出せたりする場合もあるが、よりレアケースである。
6© 2017 ISOG-J

3.1.3. 封じ込め/根絶/復旧
攻撃や被害が発生していた場合は、その封じ込めと根絶、復旧が必要となる。そのために必要となるのは下記のような情報である。


攻撃行為をセキュリティ製品や関連するシステムで遮断するための設定要件



攻撃を無効化する方法（パッチの適用、設定変更など）



被害を受けたシステムの復旧方法

3.1.4. 準備
攻撃や被害が発生していない場合は、先んじて行うべき対応を見出す必要がある。これは「封じ込め/根絶/復旧」に準ずることとなる。

3.1.5. 事件後の対応「3.3 実際のセキュリティ対応事例の What」にてまとめる。

7© 2017 ISOG-J

3.2.

攻撃関連情報の What

「攻撃関連情報」とは、ここでは、例えば「WannaCry が流行っている」「標的型攻撃が発生している」「DDoS の予告が出ている」という情報や、セキュリティベンダーから出ている攻撃解析レポートなど、攻撃に関連する情報全般を指すものとする。しかし、どのような情報ソースであろうと「Why（目的）」は決まっているので、その目的を果たせる内容かどうか確かめて必要な情報を抜き出せばよい。

3.2.1. 初動対応要否判断
攻撃関連情報の場合、下記のような事項が判断に役立つ。
該当の攻撃情報を示す名称（攻撃名称、マルウェア名、事件名など）



攻撃のターゲット

攻撃ベクター7

脆弱性情報とは異なり一意に決まる識別子がない場合があるが、関係者が理解できる何らかの名称を設定する必要がある。
また、脆弱性のように対象の有無を明確に線引きできず、多くは「要対応」と判断することになるかもしれない。例えば「東欧諸国を狙った標的型攻撃」のように攻撃者のターゲットが明らかになっている場合、その情報から対応不要あるいは対応優先度を下げるなどの判断ができる。また、攻撃ベクターがはっきりすれば、「この攻撃はインターネットから来るが、このシステムはクローズドネットワーク内なので対応不要」というような判断をすることもできる。

3.2.2. 検知と分析
脆弱性情報の時と同様、攻撃を検知する監視の実施と、被害の有無について分析する必要がある。


7

攻撃の特徴
➢

攻撃の通信内容➢核心となる攻撃コード

攻撃がどこから進行してくるか。例えばマルウェアの感染経路など。
8© 2017 ISOG-J➢

攻撃に関わる HTTP 関連のインジケーターIP アドレス

ドメイン



FQDN



URL

攻撃に関わるメール関連のインジケーター
➢

メール件名

➢

メール本文

➢

メール本文に含まれる URL➢

添付ファイルの情報


ファイル名



拡張子



ハッシュ値



内容



その他のプロトコルにおける特徴、インジケーター



攻撃を受けた場合の痕跡➢攻撃を受けた後の通信内容➢

サーバやクライアントに残るログ➢

サーバやクライアントに残るその他の特徴➢

攻撃に関連する悪性コンテンツの情報


ファイル名



フォルダ・ディレクトリパス



プロセス名
9
© 2017 ISOG-J



ハッシュ値



レジストリ変更内容検体（悪性コンテンツそのもの）8

各セキュリティ製品における検知名

もちろん、これら以上に詳細な情報も存在するが、それらの情報を理解して活用できる体制が無ければ宝の持ち腐れとなる。
「自組織が活用できる情報は何か」をしっかり把握し、効率的に情報収集することが推奨される。

3.2.3. 封じ込め/根絶/復旧
攻撃や被害が発生していた場合は、その封じ込めと根絶が必要となる。そのために必要なのは脆弱性情報の時と同様に、下記のような情報である。


攻撃行為をセキュリティ製品や関連するシステムで遮断するための設定要件



攻撃を無効化する方法（パッチの適用、設定変更など）



被害を受けたシステムの復旧方法

3.2.4. 事件後の対応「3.3 実際のセキュリティ対応事例の What」にてまとめる。

8

検体の取り扱いは危険を伴うため、厳格なルールを定め、その役割を担う一定のスキルを持ったメンバーによって、厳重な管理のもとに活用する必要がある。
10© 2017 ISOG-J3.3.

実際のセキュリティ対応事例の What

実際のセキュリティ対応事例とは、組織や企業が自身に発生したセキュリティ事象やその対応方法を「事件後の対応」として取りまとめたものになる。
ここまで言及してきた脆弱性情報や攻撃関連情報に関して、一次情報源の発信者となるのは一般的な組織においては難しいかもしれない。しかし、組織としての実際の対応事例は下記の観点を意識することで、誰でも発信者となることができる。


初動対応要否判断➢

いつどこから情報を得たか➢

どのように対応要否を判断したか（プロセス、ルールなど含めたその時の状況）

検知と分析
➢

攻撃や被害の有無を確認した具体的な方法（どのログをどのような条件で探した、具体的にこんな痕跡があった、など）➢


攻撃や被害についての数値データ（攻撃発生数、被害端末数など）

封じ込め/根絶/復旧と準備（予防）➢実際に行った対応内容（システムにどんな設定を行ったか、どのセキュリティ製品にどんな設定を行ったか、など）➢


対応した結果の数値データ（対応数、対応完了率など）

対応全体通して➢うまくいった点➢

うまくいかなかった点

今後の具体的な改善ポイント

これらの情報は、次のセキュリティ対応事案に備えるために有用であるとともに、CISOなど重要関係者へインプットする基礎情報にもなる。すべての項目が埋まらないケースもあるだろうし、組織を越えて開示することは難しい内容も多いだろう。しかし、可能な範囲で内外の組織へ情報共有すれば、貴重な情報となるはずである。また、開示した内容に対して類似した経験をもつ組織からフィードバックをもらえることもあるだろう。
11© 2017 ISOG-J

4. 受信者側の Who と How共有された情報を有効に活用し、対応していくためには、「Who（誰が）」「How（どのように）」行動するのかは事前に取り決めておかなければならない。
ここでは「Why（目的）」ごとに、「セキュリティ対応組織の教科書」9で記述されているどの機能・役割にあたるかを列挙する。自組織に置き換え、具体的な「Who（誰が）」「How（どのように）」を考えてみてほしい。
初動対応要否判断➢「A-2. トリアージ基準管理」「A-3. アクション方針管理」に従い判断する。着手
後は「E-3. 脆弱性管理・対応」によって組織的に対応していく。

検知と分析
➢「B. リアルタイムアナリシス（即時分析）」を行い、より詳細な調査が必要な場
合は「C. ディープアナリシス（深掘分析）」へ進む。

封じ込め/根絶/復旧➢



実害があった場合はインシデントとなる。「D. インシデント対応」を実施する。

準備（予防）➢

今後被害が発生しないようにするため、「G. セキュリティ対応システム運用・開発」の機能が中心となり、具体的な対策を実装する。改めて「E. セキュリティ対応状況の診断と評価」を行うと、より万全な準備ができるだろう。



事件後の対応➢「F. 脅威情報の収集および分析と評価」において、実施した対応内容を客観的に評価し、改善を実施する。対応に問題が多かった場合には、「A. セキュリティ対応組織運営」の中で抜本的な運営体制の見直しが必要なのかもしれない。さらにもう一つ大切なのは、「I. 外部組織との積極的連携」を促進するために自身が発信者となっていくことである。成功談と失敗談、どちらも非常に価値のある情報である。

9

http://isog-j.org/output/2017/Textbook_soc-csirt_v2.html
12© 2017 ISOG-J

5. 発信者側の Who と How
情報発信する際に登場する「Who（誰が）」は、概ね下記にまとめられる。
1. 実際に情報発信を行う者
2. 発信内容を承認する者
3. 発信後の状況を観察する者
4. 発信した情報に責任を持つ者
セキュリティ対応組織からの情報発信を考えるにあたっては、必要以上の情報が出てしまうことや、発信した情報がもとでいわゆる「炎上」が起こることを避けなければならない。「1」と「3」、「2」と「4」は同一の人物（あるいは役職）でも構わないが、全てを一人が担うのは、管理統制の観点から推奨しない。情報発信に当たっては、プロセスやルールを設け、スムーズに運営できるよう事前にしっかり計画しておくことが重要である。そのルールには「How（どのように）」も組み込んでおく必要があり、特に下記の点を意識する必要がある。


どのような情報を

どのような開示範囲で

どのような伝達手段で

どのような形式でこれらは「Where（どの情報共有の場において）」に強く依存するため、情報発信先の「場」を想定し、情報発信のルールを定めておくとよい。特に組織外へ発信する情報（ Global Threat Intelligence ） と 、 組 織 内 で の み 流 通 さ せ る 情 報 （ Local ThreatIntelligence）を区別し、情報共有の場において、必要な情報が必要な範囲内で活用されるようにルール化することが大切である。そのためには、組織外での情報共有では TLP（Traffic Light Protocol）10の活用や、組織内であれば、ISMS で規定されているような情報ラベルの付与などの工夫も必要となる。

10

https://en.wikipedia.org/wiki/Traffic_Light_Protocol
参考：https://www.nisc.go.jp/conference/seisaku/kihon/dai9/pdf/9siryou_ref04.pdf
13© 2017 ISOG-J6. Where
情報共有の場（Where）は様々だが、一般的には下記のいずれかに分類されるのではないだろうか。


組織内
➢

所属部署内

➢

自組織内の関係部署

➢

上層部

組織外
➢

関連会社（親会社・子会社）、関連組織➢

アウトソーサー➢

各種団体（NCA、各種 ISAC など）➢一般公衆

この「Where」のうち、どの場を発信対象とするのか、あるいはどの場を受信元とするのか具体的にリストアップしておくことが大切である。初めから色々な場へ発信するのは難しいかもしれないが、関係の深い範囲で実績を作り、徐々に外へと共有範囲を広げていけるよう「Who」と「How」も整理しながら進めていくことが推奨される。また、「一般公衆」からの情報11については、適切な「場」に情報を集めるために組織としての受付窓口等を設け、その存在を対外的に明らかにしておく必要もある。
情報収集の際は「Where」に合わせ「How」を明確にしておく必要がある。目的を定めない情報収集は際限なく実施することができ、収集する行為ばかりに時間を費やしてしまうことになる。情報を集めすぎて取捨選択できなくなったり、情報に踊らされてしまったりしないよう、自組織が確実に活用できる範囲に集中するべきである。そして、被害の有無や大小に関係なく情報を積極的に発信することが重要であり、可能な限り広く情報共有が行われるような風土を作ることが、それぞれの「場」において求められる。

11

第三者からの申告、通報、通達あるいは報道など。
14© 2017 ISOG-J7. 情報共有が逃れられない根本的な制約
ここでは情報共有が持つ根本的な制約について書き記す。これは情報共有に携わる者すべてにとって逃れられない事項であるため、しっかりと認識しておく必要がある。
まずは、理想的な情報共有とはどのような性質を持つか考えてみよう。例えば、「早くて、正確で、抜け漏れがない」ものであればどうだろうか、誰しもが満足できるのではないだろうか。
しかし、本当にそれは実現可能であろうか。
答えは NO である。急いで情報を共有しようとすれば、その正確性は犠牲になる。網羅性を担保しようと思えば時間はかかってしまう。当たり前の話である。このジレンマは情報共有のトライアングルとして取り上げられている12,13。

早さ

正確性
図 4

網羅性

情報共有のトライアングル

要するに、早さと正確性、網羅性はいずれか 2 つしか満たせないというものであるが、改めて整理すると次のように言える。

27th Annual FIRST Conference (2015), Lightning Talk: "Four Easy Pieces", Tom
Millar (US-CERT, NIST)
1213

https://www.first.org/resources/papers/conf2015/first_2015-rasmussen-rod_cutting-thr
ough-cyberthreat-intelligence-noise_20150615.pdf
15© 2017 ISOG-J

早くて正確なものは網羅性に問題が出る➢

例：攻撃に関する情報として特定の IP アドレスが提示されたものの、他にも関連していた IP アドレスが多数あったことがあとから判明する



早くて網羅的なものは正確性に問題が出る➢

例：攻撃に関連する情報として多数のドメインが提示されていたものの、無害なドメインも含まれてしまっている

正確で網羅的なものは早さに問題が出る➢

例：攻撃に関連する情報として、IP アドレスもドメインも抜け漏れなく、正確に整理されたものが提示されるのは、しばらく時間がたってからである

事態が深刻であればあるほど、早さが求められてしまう現実があり、その「早さ」に応えようとすれば、正確性か網羅性が犠牲になってしまう。これは逃れようのない制約である。そのため、せっかく早く共有してもらった情報に対し「網羅性がない！」「正確ではない！」と責め立ててしまうのは悪手である。情報発信者を萎縮させ、情報が提示されにくい環境を生み出してしまう。誰が行うにしても、正確で網羅的な情報を作り上げるには時間がかかるのである。これは、情報に関する苦痛のピラミッド14 (the Pyramid of Pain)として言及されるところでもある。
文句を言わず情報を受け入れるべし、ということではない。フィードバックもまた重要である。共有された情報に不足を感じたのであれば、自身がそれを補う発信をすべきであるし、正確性に問題があるのであれば正しい情報を発信するべきである。
フィードバックが建設的であればあるほど、良い情報共有の場となるということは情報発信の立場であっても情報受信の立場であっても忘れないようにしたい。

14

http://detect-respond.blogspot.jp/2013/03/the-pyramid-of-pain.html
16© 2017 ISOG-J

おわりに
本書では「5W1H」を切り口に、サイバーセキュリティ情報共有の「いろは」を整理した。基本を押さえた先には大きな課題がある。例えば下記のような事項である。


発信者側と受信者側の「How」の標準化、自動化



情報の信頼度、有効性の可視化



発信者と受信者をつなぐ、フィードバックの機構
発信者側の「How」の標準化については STIX15、TAXII16や CybOX17といった仕様が策定されているものの、まだまだ一般的に普及した状態とは言えず、発信者側も受信者側も共通的な処理で情報を発信したり、活用したりすることができないという課題がある。また、共有された情報の信頼度をどのように可視化するかも真剣に考えなければならない。
情報は絶えず変化するものであり、時間経過により無効化するものもある。さらに、悪意に満ちた偽の情報が混入する可能性もあるなど、正確性、信頼性を担保するのは難しい。
その解決の糸口の一つとして受信者による「フィードバック」が考えられるが、そのフィードバック自体が「発信」であるため、情報共有の場をもっと活性化されなければならな
い。仮に活性化がうまくいったとしても、フィードバックが散在して参照しづらい状態では発信者側も他の受信者も拾うことができないため、共通の情報共有基盤が不可欠になる。
しかし、現状のように情報共有の「場」自体が散在している状態では、それは難しいと言わざるを得ない。
米国では、国土安全保障省（DHS）がサイバーセキュリティの情報共有の枠組みとして「Automated Indicator Sharing（AIS）18」を推進している。STIX をベースとした情報基盤を構築し、多くの組織がその情報を活用するなど先進的な事例も出てきた。自動化についても IETF において MILE19や I2NF20の議論が活発化している。ISOG-J も日本において、様々な課題に積極的に取り組んでいきたいと考えている。
読者の皆様におかれましても、情報共有の場で、活発な発信、適切な活用を行えるよう、本書でまとめた"サイバーセキュリティ情報共有の「5W1H」"で基本を押さえ、より一層のセキュリティ対応組織(SOC/CSIRT)強化へ繋げていただければ幸いである。

https://www.ipa.go.jp/security/vuln/STIX.html
https://www.ipa.go.jp/security/vuln/TAXII.html
17 https://www.ipa.go.jp/security/vuln/CybOX.html
18 https://www.dhs.gov/ais
19 https://datatracker.ietf.org/wg/mile/about/
20 https://datatracker.ietf.org/wg/i2nsf/about/
15
16

17
© 2017 ISOG-J

執筆
日本セキュリティオペレーション事業者協議会（ISOG-J）
セキュリティオペレーション連携 WG(WG6)亀田 勇歩

SCSK 株式会社

阿部 慎司

NTT セキュリティ・ジャパン株式会社/ISOG-J WG4 リーダー

武井 滋紀

NTT テクノクロス株式会社/ISOG-J WG6 リーダー

市川 隆義

ソフトバンク・テクノロジー株式会社

佐々木 将信株式会社富士通ソーシアルサイエンスラボラトリ（協力者）

ももい やすなり

株式会社インターネットイニシアティブ

河島 君知

NTT データ先端技術株式会社（執筆関係者、社名五十音順）

18© 2017 ISOG-J