Transcript 警察政策学会
「サイバー攻撃源を逆探知する トレースバックシステム」 について 平成２２年２月１９日 日本電気株式会社 山形 昌也 人と地球にやさしい情報社会を イノベーションで実現する グローバルリーディングカンパニー NECグループビジョン2017 2 自己紹介 項目 1 氏名 山形 昌也（やまがた まさや） 2 所属 NEC 中央研究所 サービスプラットフォーム研究所 NICT（情報通信研究機構）インシデント対策Ｇ 3 タイトル NEC 主任 NICT 短期専攻研究員 4 電子メール [email protected] [email protected] 5 専門分野 ネットワークセキュリティ、マルウェア解析 システムセキュリティ 業務内容 ネットワークセキュリティ技術の研修開発 (1) ネットワークトラヒックの観測、分析 (2) トラヒック、ログ解析による不正アクセスの検出 (3) トレースバック技術の研究開発（ＮＰ） マルウェア解析（ネットワーク的な挙動解析を中心） 6 3 内容 目次 ０．はじめに １．委託研究概要 １） 委託研究全体概要 ①目的・背景 ②各社の分担 ③研究課題の概要 ２） トレースバックシステムの概念図と課題との関係 ３） 実証実験時のシステム構成（概要）と課題との関係 ２．実証実験にむけて １） 通信の秘密 ２） 導入シミュレーション ３） 事前実験 ３．実証実験の実施とその後 １） 実証実験 ２） 実証実験の動作、オペレーション概要 ３） 今後について 4 ０．はじめに ▐ 今回の説明の発端 ▐ 広報 ２００９年１１月２６日実施 タイトル 「サイバー攻撃源の逆探知システ ムの開発と実験に成功 ～世界初、 広域インターネット環境下での逆 探知を実証～」 で、関係各社のWebページに掲 載 5 参考① 広報文が掲載された新聞、Web 新聞掲載 • • • • 11月27日付 12月2日付け 12月4日付け 12月7日付 電波新聞 2面、日経産業新聞 3面 電波タイムズ 朝1面（Top) 電波タイムズ 朝1面（記者席） 日刊工業新聞 18面 Web掲載 • CNET Japan (http://japan.cnet.com/news/sec/story/0,2000056024,20404340,00.htm) • INTERNET Watch (http://internet.watch.impress.co.jp/docs/news/20091127_331937.html) • IT media エンラープライズ (http://www.itmedia.co.jp/enterprise/articles/0911/26/news058.html) • RBB TODAY (http://www.rbbtoday.com/news/20091126/64013.html) • atmark IT (http://www.atmarkit.co.jp/news/200911/27/traceback.html) • マイコミジャーナル (http://journal.mycom.co.jp/news/2009/11/26/050/index.html) • zdnet (http://japan.zdnet.com/news/sec/story/0,2000056194,20404340,00.htm) • ウイルス対策ニュース ・ドットネット (http://antivirus-news.net/2009/11/nec-1.html) 6 参考② 広報文が掲載された新聞の例 ▐ 新聞記事：例 配布厳禁 / 日 刊 工 業 新 聞 20 09 12 07 / 18 面 電波新聞2009/11/27朝刊2面 日経産業新聞 2009/11/27 3面 7 参考③ • 広報文が掲載されたWebニュースの例 Webニュース記事：例 ↑INTERNET WATCH 8 @IT→ 配布厳禁 参考④ • 9 広報文に関するWeb（CGM）の例１ Web（CGM）コメント：例 配布厳禁 参考⑤ 広報文に関するWeb（CGM）の例２ - http://tyoukoudou.blog95.fc2.com/blog-entry-22.html このトレースバック相互接続システムのソフトウェア（名 称：InterTrack） はオープンソースとして公開されている そうです。 参照記事⇒http://thinkit.jp/article/853/1/を参照にしながら、 試して使ってみるのも手ですね。 - http://blog.livedoor.jp/ashitagaaru74/archives/51284188.html (blog) 今日一番驚いたのが、サイバー攻撃の発生源を逆探知する システム、NECらが開発についてのニュースです。 自分が興味を持っているジャンルのニュースって、真っ先 に目に入ってくるものですよね。 (コメント) う～ん、この記事だけからでは何とも言えないのですが、 とにかくサイバー攻撃の発生源を逆探知するシステム、 NECらが開発に対する関心は、まだしばらく続くのかなぁ、 という気がします。 ほぉ～、そうなんですか。なかなか興味を引かれるニュー スではあります。 サイバー攻撃の発生源を逆探知するシステム、NECらが開 発の話は、受け取る人によって感じ方はさまざまなんで しょうが。 - http://blogs.yahoo.co.jp/need_takaaki/22421284.html との事です素晴らしいですね hackしてる方にとっては大変でしょうが^^ - http://blog.goo.ne.jp/asterisk-interceptor/e/3d6e6ec8de22d7577cf3c2bf37a5f9cc ハッカー（クラッカー）涙目ですね。この技術が完成した ら犯罪として立件できるので、頼もしい限りです。 10 配布厳禁 [CGM(blogでの感想/コメントなど)] - http://fgfege.exblog.jp/13076930/ 情報通信研究機構は、パケットに対してどのような関係 性を持っているのでしょうか。 だが、関連付について、Wikipediaでよく調べてみようと 思います。発生源についても調べてみたいですね。 しかし、システムはなんだかとても面白そうですね。 - http://jiro4.blog66.fc2.com/blog-entry-387.html そーだろうな。 がんばってんな。 - http://tweetbuzz.jp/entry/...（とても長いので省略） おお、実証事件成功したのか。実運用にはまだ壁がたく さんあるみたいだが。 おおお、ついに攻性防壁が？ ほほう、しかし抜け道はいくらでもありそう つまり、暗号化された疑似IPを各ISPに設置したバックド アを通じて問い合わせられるようにするもの？ これは期待 なるほど、諸々の ISP が連携して事に当たる仕組みを確 立するワケね。 - http://candylove.asukablog.net/Entry/178 「サイバー攻撃源の“逆探知”、産学連携で実証実験に成 功」というような話題が増えてくること自体は仕方がな いんでしょうね。 - http://katyusha.cgifile.net/blog/gerochan/archives/2009/11/g001458.phtml 踏み台にされても見つけられるのかねぇ トレースバックとは？ ▐ 直訳すれば「逆探知」 ドラマなどで“電話（交換網）”の世界では当たり前のように使われて いる 携帯電話、ナンバーディスプレイ対応電話では、受信時に発番がばっ ちり 電話の世界での発番は詐称できない（非常に困難） • 基本、最後まで繋がったことが確認できてはじめて通話が可能なため ▐ ＩＰは「送りっぱなし」 IPネットワークはバケツリレーを繰り返し、最終目的地に届きさえす ればＯＫ • • どこから？、どこを経由して？、などは二の次 行き返りの経路が違う、通信中に経路が変わる、もＯＫ 相手が繋がっていようがいまいがお構いなし IPネットワークの世界では、「逆探知」できないことが原因 IPの発番（始点IPアドレス）は詐称し放題 • 11 「ばれない」ということで、やりたい放題する者が発生 トレースバックの概要とイメージ ▐ 始点IPアドレス詐称問題 始点IPアドレスが詐称された通信について、発信源を突き止め、対処するに はどうすればよいか。 パケットの発信源追跡（トレースバック） 攻撃指示 攻撃パケット トレースバック 踏み台経由の発信源追跡 攻撃ノード 1 4 7 3 6 9 被害ノード 2 5 攻撃ノード 12 8 踏み台 １．委託研究概要 １） 委託研究全体概要 ①目的・背景 ②各社の分担 ③研究課題の概要 ２） トレースバックシステムの概念図と課題との関係 ３） 実証実験時のシステム構成（概要）と課題との関係 13 １－１．委託研究全体概要（①目的・背景） (独)情報通信研究機構（NICT）からの委託研究 委託研究テーマの目的 本研究では、インターネットにおけるトレースバック技術の実運用環境への 実装を目指した研究開発を行うことを目的とし、具体的には、以下を実施す るものである。 • • • • • • 基盤となる全体のアーキテクチャの設計 トレースバックアルゴリズムの開発 トレースバック用データ収集装置の開発 上記を統合したトレースバックプラットフォームの開発 当該プラットフォームの実装及び運用体制について検討 実運用環境への実装に向けた総合試験・検証 委託研究テーマの背景 インターネットの急速な拡大と重要性に伴い、インターネットに対する攻 撃・脅威により引き起こされうるインシデントの大きさについても年々増大 の一途を辿っている。大規模インシデントに対する早期警戒態勢の整備が急 務であることが強く認識されている。 14 １－１．委託研究全体概要（②各社の分担） 代表研究責任者 ：日本電気株式会社 課題 ア 「全体アーキテクチャの設計」 ア‐１ トレースバック機構を構築する上で考慮するべき事項 （国立大学法人奈良先端科学技術大学院大学） （株式会社KDDI研究所） ア‐２ 基本的なトレースバック方式の開発 ア‐３ トレースバックシステムの相互接続アーキテクチャの開発 （国立大学法人奈良先端科学技術大学院大学） 課題 イ 「トレースバック・アルゴリズムの開発」 （パナソニック電工株式会社） イ‐１ I Pパケットトレースバックアルゴリズムの開発 イ‐２ アプリケーショントレースバックアルゴリズムの開発 （株式会社クルウィット） イ‐３ 異なるレイヤ由来の情報からトレースバック能力を向上させるアルゴリズムの開発 （株式会社クルウィット） 課題 ウ 「トレースバック用データ収集装置（プローブ装置）の開発」 ウ‐１ IPトレースバック用データ収集装置の開発 （株式会社KDDI研究所） ウ‐２ アプリケーショントレースバック用データ収集装置の開発 （日本電気株式会社） 課題 エ 「トレースバックプラットフォームの実証実験」 エ‐１ 実装および運用体制の検討 （財団法人日本データ通信協会） エ‐２ 攻撃パターンの想定 （財団法人日本データ通信協会） エ‐３ 動作検証 （財団法人日本データ通信協会） 課題 オ 「テーマ全体管理」 15 （日本電気株式会社） １－１．委託研究全体概要（③研究課題の概要） ●課題ア：「全体アーキテクチャの設計」 トレースバックについての問題点を様々な観点で課題を明らかにし、基本的なト レー スバック方式の開発をする。 さらに、ドメイン間（ISP間）のトレースバックシステムが連携するためのアー キテク チャの開発を進める。 ●課題イ： 「トレースバック・アルゴリズムの開発」 実用的なトレースバックのアルゴリズムの提案および開発をすることを課題とし、 本プロジェクトでは、IPトレースバックのアルゴリズム、アプリケーショント レースバックのアルゴリズムの開発およびそれらが連携する方式の開発を目標と する。 ●課題ウ： 「トレースバック用データ収集装置（プローブ装置）の開発」 課題イで開発されたトレースバックのシステムに必要なデータを高速で収集する 機能と能力をもつデータ収集装置を開発することを課題とする。 ●課題エ： 「トレースバックプラットフォームの実証実験」 課題アからウにより開発されたトレースバックの動作検証、運用上の問題を検討 するために実証実験を実施し、トレースバックシステムの実用性および問題点を 明らかにする。 ●課題オ： 「テーマ全体管理」 課題アからエの進捗管理を実施する。 16 １－２．トレースバックシステムの概念図と課題との関係 トレースバックシステムの概念図と本プロジェクトの課題との関係 ア－１ オペレーター トレースバック機構構築上の 考慮事項網羅 ア－２ APトレース バック 基本的な トレースバック 方式開発 オペレーター イ－３ 異レイヤトレースバック連携 トレースバック システム相互接続 アーキテクチャ ア－３ IPトレース バック APトレース バック イ－２ APトレースバックアルゴリズム開発 IPトレース バック イ－１ IPトレースバックアルゴリズム開発 トレースバックプラットフォーム ウ－２ P1 プローブ P2 APトレースバック用データ収集 装置開発 P４ P3 ウ－１ IPトレースバック用データ収集 装置開発 攻撃 攻撃対象サー バ エ－１ 実装および運用体制検討 エ－２ 攻撃パターンの想定 エー３ ISP間の契約書、 公開ポリシ 動作検証（実証実験の実施） オ 全体とりまとめ 17 １－３．実証実験時のシステム構成（概要）と課題との関係 実証実験時のシステム構成（概要）と課題との関係 トレースバックシステム トレースバック 検索システム ア－２ トレースバック相互接続システム ア－３ イ－１ トレースバック イ－２ コントロールシステム イ－３ トレースバック管理センター 情報の集約 ウ－１ パケット収集システム ウ－２ インターネット 探索依頼 ISP-C 真の攻撃者 擬似攻撃PC エ－２ ISP-A ISP-B IPアドレスを偽装された 見せかけの攻撃者 ア－１ エ－１ エ－３ オ 18 対処依頼 インシデント 調査依頼 被害者 真の攻撃ルート 偽装された攻撃ルート ISP-Cオペレータ ISP-Aオペレータ 方式検討や体制、運用等のため、システムには見える形では現れない ２．実証実験にむけて １） ２） ３） 19 通信の秘密 導入シミュレーション 事前実験 ２－１．通信の秘密 ▐ 憲法第21条2項 検閲は、これをしてはならない。 通信の秘密は、これを侵してはならない。 ▐ 電気通信事業法第4条1項 電気通信事業者の取扱中に係る通信の秘密は、侵してはならない。 ▐ 個人情報保護ガイドライン第２３条（通信履歴） 1. 電気通信事業者は、通信履歴（利用者が電気通信を利用した日時、 当該通信の相手方その他の利用者の通信に係る情報であって通信内 容以外のものをいう。以下同じ。）については、課金、料金請求、 苦情対応、不正利用の防止その他の業務の遂行上必要な場合に限り 、記録することができる。 2. 電気通信事業者は、利用者の同意がある場合、裁判官の発付した令 状に従う場合、正当防衛又は緊急避難に該当する場合その他の違法 性阻却事由がある場合を除いては、通信履歴を他人に提供しないも のとする。 20 ２－１．通信の秘密 ▐ 目的の正当性 本トレースバック手法は、事業者の電気通信設備を守る目的で、事業者設備及び 利用者設備に対する発信元を詐称した攻撃等に対処するために利用されるもの ▐ 行為の必要性 本トレースバック手法は、送信元を詐称した攻撃を抑止するために、真の攻撃源 を特定し、それに対して対処を講じることのできる現時点で最も有効な手段を行 う行為 ▐ 手段の相当性 本トレースバック手法で用いる情報は、パケットのヘッダー情報に限られ、かつ ハッシュ値として一時的にメモリに保管されるにとどまり、かつ、その情報は探 査・対応のために限られた対象にのみ提供されるものであるから、目的達成のた めに必要な限度にとどまる ▐ 以上３点から、「正当業務行為」と認められる 当事者の同意があれば、 「通信の秘密」への侵害という、違法性が阻却されると考えることができる。 ※https://www.telecom-isac.jp/cgi-bin/download/dl.cgi/TB20090408：本トレースバック手法の導入に関する法的問題点の整理.pdf から抜粋 21 法律・技術・運用の3すくみ問題 Technical issue Operational issue Legal issue Privacy of Communications 22 適法要件と対応手段 過去に実施するための要件 要件を満たす手段 過去に実施するための要件 ②データ破損などがない タップまたは ミラーポートの使用 ①装置等の設置の同意 契約 ④直前/直後の アドレスのみ取得 該当せず （ICMP方式未適用） ③インシデント検出時に トレースバック実施 ポリシ TB実施基準 ⑦個人情報保護 ISMS ⑤ハッシュ値のみ伝送、 記録、保存 実 装 ⑥パケットのデータ部への 書き込み不可 23 Hash方式導入 契 ⑧インシデント発生以前 約 のアクセス不可 ・ ⑩探査者の守秘義務 基 該当せず 準 ⑪データの共同利用の （Marking方式未適用） 守秘義務 要件を満たす手段 ポリシ TB実施基準 契約 契約 ⑨探査者以外の者の アクセス不可 アクセス制御 ⑬セキュリティ/プライバシー ポリシー構築と適用 ISMS ⑫インシデント未検出時の 共同利用不可 インシデント発生後に TBデータ構築 ⑭適切な方法による 情報公開 ポリシ公開 トレースバック・プラットフォームのイメージ図 Management System Control Facility between ISPs ISP Network ISP Network ISP Network System Layer 24 Traceback Probes 3階層のトレースバック・システム概要 （2） 自動的に疑わしき攻撃の経路情報を保管. IDS等が探査すべき攻撃を認知したら自動的に、コントローラーは攻撃パケットのハッシュ値を他のTBコントロー ラーに問い合わせて該当攻撃パケットが通過した経路情報を作成し、TB管理センターのTB-DBに保管する。 TB管理センター TB-DB （3） オペレーターが真の攻撃者の所在 を 確定 攻撃元特定が認知された後、TBオペレー ターは、攻撃パケットのハッシュ値を元にTBDBを検索し、攻撃パケットの経路情報を確定 する。 コントローラー 真の攻撃者の所 在 (ASマップ) IDS プローブ Incident ISP(a) 真の攻撃者 ISP(c) ISP(b) IPアドレスを偽装した 見かけの攻撃者 （1） プローブは常時ハッシュ化したデータを取得. 各プローブは、自動的にパケットをハッシュ化し、自らのキャッシュに一時保管する。 25 ２－２．導入シミュレーション ▐ 導入シミュレーション（StarBEDで仮想トポロジーを構築） JPNIC登録の国内449-ASトポロジーデータ（CAIDA Project提供、2008年1 月） リーフAS（中小ISP）から順に導入したケースを想定 ▐ シミュレーション結果 下位13-AS（中小13-ISP）への導入で21.75% ＋コア1-AS（大手1-ISP）で 58.35% ＋リーフ17-AS、コア1-ASで 70.74% 国内ASトポロジー 26 ２－３．事前実験 ▐ 概要 平成20年8月～平成21年1月 参加ISP-5社 ▐ 実験内容 １．基本動作確認 ２．攻撃演習 新潟 • DDoS模擬攻撃 – 1対N、N対1 – シナリオのない攻撃 東京1 東京2 島根 神奈川 27 事前実験：シナリオ概要 管理センター 5 管理センター オペレータ 6 対処依頼 攻撃者側 ISPオペレータ ※ トレースバック 結果の閲覧 イベントDB 被害者側 ISP 1 模擬攻撃送信 攻撃者役 模擬攻撃・被害 サーバ 28 被害者側 ISPオペレータ インターネット 7 対処依頼 や 6 の連絡は オペレータ連携支援システム （Webシステム）を介して行われる 3 トレースバック 結果の検索 4 対処依頼 攻撃者側 ISP 4 - syn flood - 100pps - src IPアドレス偽装 （他のISPの模擬攻撃 サーバになりすまし） 2 対処依頼 被害者役 模擬攻撃・被害 サーバ 事前実験で判明した課題 ＜事前実験での課題＞ 作業プ ロ セスの流れ >同時多発に一部作業が混乱 誤判断・ 誤操作回避 >人手によ る 転記ミ ス シ ステ ムユーザビ リ テ ィ >メ ッ セージ が分かり づら い ISPへの支援の程度 >習熟には時間が必要 大規模実験への拡大 >同時多発時の統制の見直し が必要 機器障害対応 >品質・ 信頼性確保が必要 キャ プ チャ 漏れの影響 >確度向上策が必要 ＜実証実験での改良点＞ (1) シ ステ ムのバグ対応、 ISP環境における 事前動作確認の拡充 (2) 実験記録用紙な ど の改定 (3) ISP間連携を 補完する CHATサービ ス等 の導入 (4) 実験参加ISPへの事前ト レ ーニン グの拡充 (5) ト レ ース バッ ク ・ 管理セン タ ーの人員と 設備の増強 通信の秘密の関係で、 • 現地デバッグ不可 • 通信パケットに関するログ、再現データの取得/記録不可 であるため、障害の再現が困難。 29 障害対応は機材交換のみ 実質的に何もできない 製品並みに高い品質が必要 ３．実証実験の実施 １） ２） ３） 30 実証実験 実証実験の動作、オペレーション概要 今後について ３－１．実証実験 ▐ 概要 平成21年5月～9月 ISP-15社、および、研究機関-3組 織 北海道 ▐ 実験内容 １．基本性能測定 ２．攻撃演習 • DDoS模擬攻撃 – – – – – 1対N、N対1 （N対M）＊L回 シナリオのない攻撃 異なるTB間連携 障害発生対応 • DNSリフレクション模擬攻撃 • 実インシデント実験 31 新潟 宮城 群馬 東京1 東京2 東京3 神奈川 京都 大阪 島根 岡山 高知 鹿児島 沖縄 ３－２．実証実験の動作、オペレーション概要 トレースバック実証実験システム （３） （ニ） トレースバック 相互接続システム トレースバック コントロールシステム トレースバック 検索システム トレースバック管理センター パケット収集システム （１） インターネット （イ） 真の攻撃者役 ISP-A担当者 ISP-C ISP-A 模擬攻撃を 停止するよう 依頼 各役の使用するマシンは 実証実験のために用意したもの （ハ） 問題の解決 を要請 ISP-B 被害者役 IPアドレスを偽装された 見せかけの攻撃者役 対処依頼 （ホ） （ロ） 真の攻撃ルート 偽装された攻撃ルート ISP-C担当者 ※ト レ ースバッ ク 相互接続シ ステ ムと ト レ ースバッ ク コ ン ト ロ ールシ ステ ムについて シ ステ ムと いう のは論理的なも のであっ て、 実際のハード ウェ ア 構成と は一致し ません。 ▐ トレースバック実証実験の動作概要 システムの動作概要（実証実験の開始により以下の動作が開始さ れる） （１） パケット収集システムによるハッシュ値の算出と保 管を開始する。 （２） IDSが模擬攻撃パケットの検出を開始する。模擬攻撃 パケットを検出した場合、模擬攻撃パケットのハッシュ値 を算出し、トレースバック相互接続システムへ提供する。 （３） トレースバック相互接続システムは提供されたハッ シュ値をもとにトレースバック相互接続システム間で問い 合わせを行い、その結果得られた模擬攻撃パケットの経路 情報をトレースバック管理センターのトレースバック検索 システムへ登録する。 32 （２） IDSなど攻撃パケット 探索依頼 を検知する仕組み ▐ 実証実験参加者のオペレーション概要 （イ） ISP-Aの真の攻撃者役が発信元のIPアドレスをISP-Bの見せかけ の攻撃者役のIPアドレスに詐称して、ISP-Cの被害者役宛の模擬攻撃パケ ットの送出を開始する。 （ロ） 被害者役が模擬攻撃を検知し、ISP-Cの担当者に問題の解決を要 請する。 （ハ） ISP-Cの担当者は被害者役からの要請により、模擬攻撃パケット のハッシュ値を確認し、トレースバック管理センターに模擬攻撃パケッ トの探索を依頼する。 （ニ） 探索依頼を受けたトレースバック管理センターは、トレースバッ ク検索システムを利用して模擬攻撃元を探索し、ISP-Aであることを特定 する。 （ホ） 模擬攻撃元を特定したトレースバック管理センターは、模擬攻撃 元のISP-Aの担当者に模擬攻撃の停止の対処依頼をする。ISP-Aの担当者 が真の攻撃者役に対して模擬攻撃パケットの送出を停止するように依頼 模擬攻撃＆実インシデントの結果 検証項目 内容 1対13、14対1 N対M*L回 シナリオの無い攻撃 １ DDoS攻撃 異なるTB間連携 結果 ◎ 想定時間内に処理 ◎ 想定時間内に処理 X 双方の環境・システムの差異で追跡失敗 ◎ 障害発生対応（2種類） ２ DNSリフレク ション攻撃 攻撃N社から 中継1社経由で 被害1社 ISP・TB管理センターとの情報交換により、 誤った対応を回避し、正しい手続きを実行でき た。 ◎ ほぼ追跡できた、 攻撃（DNS-query）を検知できない場合あり X ３ 33 実インシデト 実験 研究機関からの調査依 頼から、実攻撃を追跡 研究機関の上位ISPで攻撃を検知していたが、 攻撃元まで追跡は失敗 実運用に向けた課題の整理（整理中） ▐ 運用モデルの前提条件 TB管理センターの詳細 コスト計算 インシデント判定基準 ▐ 実験の前提条件 被害者はHi-Skill＆特殊設備を運営 攻撃は見つかるまで継続される 必要な場所にTB機器が設置されている ▐ 実験で判明したこと 他のトレースバック・システム／グループとの連携方法 システム・パラメーターの最適値の決定方法 プローブの設置箇所、InterTrackのトポロジーの設計方法 ▐ その他 大規模導入時のシステム全体の性能の見積もり 大規模DDoS攻撃対応 システム・パラメーターの自動設定、または、ISPによる設定変更 34 実運用に向けた課題の整理：ISP調査結果（一部抜粋） ▐ トレースバックシステムの認知度が高 まっており、高い期待がある。 ▐ 捕捉率=70%以上の要求が多く、 標準化への要望も高く、 運用費の補助希望は７割近い。 ▐ 運用すべきが８割を超えている。 また、７割に参加意欲がみられる。 ▐ 実運用に期待しながらも、 さらなる向上を求める声があり、 実証実験の継続の期待感はある。 35 ３－３．今後について ▐ このプロジェクトにおける成果、資料を公開 各種論文や資料の掲載 ソースコードの一部をオープンソースとして公開 → 大学や企業によるトレースバック技術、 ネットワークセキュリティ技術の研究を推進 ▐ 多くの関連する技術の標準化活動を推進 トレースバック技術の標準化・共通化を目指す • ITU-T SG17 Q.4 (Cybersecurity) においてトレースバック技術に関する標 準化を開始 • IETFにトレースバック相互接続アーキテクチャと実証実験に関する個人草 案を提案（2010年3月末日予定） 36 資料、ソースコードの公開について ▐ 研究成果である各種論文、開発したソフトウェア、実証実験の成果等を 公開し、大学や企業、研究機関等によるネットワークセキュリティの研 究推進を支援 http://intertrack.naist.jp/ https://www.telecom-isac.jp/tb/ 37 38