Comments
Description
Transcript
「悪意あるサイトの識別情報 及び対策情報提供システム（TIPS） 第一次
Ⅲ．仕様書 「悪意あるサイトの識別情報 及び対策情報提供システム（TIPS） 第一次機能強化」 開発・構築作業内容（発注仕様書） 2011 年 1 月 31 日 i 目 次 1. はじめに................................................................................................................... 1 1.1. 本システムの目的 ...................................................................................................................... 1 1.1.1. 1.1.2. 本システムの概要 ..................................................................................................................... 1 機能強化の概要......................................................................................................................... 1 1.2. 用語の定義 ................................................................................................................................. 3 1.3. 対象業務の概要 ......................................................................................................................... 5 1.3.1. 1.3.2. 1.4. ウェブサイト調査依頼対応 ...................................................................................................... 5 ウェブサイト自動巡回 .............................................................................................................. 6 作業内容・納入物件 .................................................................................................................. 7 1.4.1. 1.4.2. 1.4.3. 1.4.4. 1.4.5. 1.4.6. 1.4.7. 1.4.8. 作業範囲 ................................................................................................................................... 7 作業内容 ................................................................................................................................... 7 プロジェクトの流れと作業分担 ............................................................................................... 8 ハードウェア及びソフトウェアに関する作業範囲 .................................................................. 9 納入期限 ................................................................................................................................. 10 納入場所 ................................................................................................................................. 10 納入物件 ................................................................................................................................. 10 検収条件 ................................................................................................................................. 10 2. システムの要件 ...................................................................................................... 11 2.1. システムの概要 ........................................................................................................................11 2.1.1. 2.1.2. 2.1.3. 2.2. 業務要件 .................................................................................................................................. 14 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7. 2.2.8. 2.2.9. 2.2.10. 2.2.11. 2.3. 業務要件一覧 .......................................................................................................................... 14 業務データ要件....................................................................................................................... 16 業務要件 1 ウェブサイト調査 ................................................................................................ 20 業務要件 2 ウェブサイト巡回調査 ........................................................................................ 22 業務要件 3 ゼロデイ攻撃調査 ................................................................................................ 24 業務要件 4 統計レポート参照 ................................................................................................ 27 業務要件 5 巡回調査スケジュール設定 ................................................................................. 29 業務要件 6 外部接続用ルータ電源操作 ................................................................................. 30 業務要件 7 ウイルス検体操作 ................................................................................................ 31 業務要件 8 システム監視 ....................................................................................................... 31 業務要件 9 システム運用管理 ................................................................................................ 32 情報システムの機能等に関する要件....................................................................................... 35 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. システムの概要と処理の流れ ..................................................................................................11 システムのユーザー ............................................................................................................... 13 運用形態 ................................................................................................................................. 13 機能要件 ................................................................................................................................. 35 画面要件 ................................................................................................................................. 47 情報・データ要件 ................................................................................................................... 47 外部インターフェース要件 .................................................................................................... 48 設計に係る要件 ....................................................................................................................... 48 2.4.1. 2.4.2. 設計方針 ................................................................................................................................. 48 基本設計及び詳細設計に係る要件.......................................................................................... 48 ii 2.4.3. 2.4.4. 2.4.5. 2.4.6. 2.4.7. 2.4.8. 2.4.9. 2.4.10. 構築作業及びシステム構築手順書に係る要件 ....................................................................... 48 信頼性要件 .............................................................................................................................. 48 拡張性要件 .............................................................................................................................. 48 上位互換性要件....................................................................................................................... 49 システム中立性要件 ............................................................................................................... 49 事業継続性要件....................................................................................................................... 49 権限管理要件 .......................................................................................................................... 49 情報セキュリティ対策 ............................................................................................................ 50 2.5. 稼働環境等要件 ....................................................................................................................... 50 2.6. 全体構成 .................................................................................................................................. 51 2.6.1. 2.6.2. 2.6.3. 2.7. ハードウェア構成 ................................................................................................................... 51 ソフトウェア構成 ................................................................................................................... 51 ネットワーク構成 ................................................................................................................... 52 規模・性能要件 ....................................................................................................................... 56 2.7.1. 2.7.2. 規模要件 ................................................................................................................................. 56 性能要件 ................................................................................................................................. 56 3. 作業及び作業環境等に係る要件 ............................................................................. 56 4. システム試験 ......................................................................................................... 56 5. 作業の体制及び方法 ............................................................................................... 57 5.1. プロジェクトの体制等 ............................................................................................................ 57 5.2. プロジェクト管理等 ................................................................................................................ 57 6. 保守要件................................................................................................................. 58 7. 条件等 .................................................................................................................... 58 7.1. スケジュール ........................................................................................................................... 58 iii 図 表 目 次 図 図 図 図 図 図 図 図 図 図 図 図 1-1 TIPS サービス説明図 ........................................................................................................ 1 1-2 TIPS の構成機能 ................................................................................................................ 2 1-3 ウェブサイト調査依頼対応 イメージ図 .......................................................................... 5 1-4 ウェブサイト自動巡回 イメージ図.................................................................................. 6 1-5 プロジェクトの流れ ......................................................................................................... 8 1-6 システム構成要素 ............................................................................................................. 9 2-1 システム概要図................................................................................................................11 2-2 機能構成図 ...................................................................................................................... 35 2-3 機能フロー図（ウェブサイト調査、ウェブサイト巡回調査）...................................... 45 2-4 機能フロー図（ゼロデイ攻撃調査） .............................................................................. 46 2-5 論理ネットワーク構成図（例） ..................................................................................... 55 7-1 想定スケジュール ........................................................................................................... 58 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 1-1 用語の定義 ........................................................................................................................ 3 1-2 ウェブサイト調査依頼対応業務のユーザー ..................................................................... 5 1-3 ウェブサイト自動巡回業務のユーザー ............................................................................ 6 1-4 作業範囲と作業内容 ......................................................................................................... 7 1-5 システム構成要素と作業範囲........................................................................................... 9 1-6 開発成果物一覧............................................................................................................... 10 2-1 システム概要図 処理の説明 .......................................................................................... 12 2-2 システム運用者の区分.................................................................................................... 13 2-3 業務要件一覧 .................................................................................................................. 14 2-4 調査対象エントリの構成情報......................................................................................... 16 2-5 調査対象エントリの設定のトレードオフ ...................................................................... 16 2-6 調査結果レポートの構成情報......................................................................................... 17 2-7 攻撃サイトリストの構成情報......................................................................................... 18 2-8 日次レポートの構成情報 ................................................................................................ 18 2-9 月次レポートの構成情報 ................................................................................................ 19 2-10 機能概要一覧 ................................................................................................................ 36 2-11 SPICA 管理 機能要件.................................................................................................... 36 2-12 URL リスト作成機能 機能要件 ..................................................................................... 38 2-13 巡回用クローラ 機能要件 ............................................................................................ 38 2-14 ゼロデイ攻撃判定用クローラ 機能要件 ...................................................................... 41 2-15 検証用クローラ 機能要件 ............................................................................................ 43 2-16 フォワードプロキシ 機能要件 ..................................................................................... 43 2-17 PPPoE ルータ 機能要件 ............................................................................................... 44 2-18 電源制御装置 機能要件 ................................................................................................ 44 2-19 バックアップサーバ 機能要件 ..................................................................................... 44 2-20 情報・データ要件 ......................................................................................................... 47 2-21 クローラ仮想マシン ソフトウェア構成（案） ........................................................... 52 2-22 機器構成一覧（例） ..................................................................................................... 53 iv 1. はじめに 1.1. 本システムの目的 1.1.1. 本システムの概要 IPA は、国内の一般利用者や企業によるインターネットの利用における安全性を確保するた めの活動を、中立的な立場で行っている。活動の内容としては、日々進化する攻撃手法やウイ ルスの情報の収集、脅威の分析、対策方法の検討、そして注意喚起の発信などがある。 近年、インターネットにおいて「ウェブの脅威」が増大している。最たる例は「ガンブラー」 の手口によるもので、「正規のウェブサイトの改ざん」、「ウェブ閲覧により感染するウイル ス」 、 「セキュリティソフトの検知回避技術」、「ゼロデイ攻撃」などが巧みに組み合わせられ、 問題となっている。 「ウェブの脅威」は、全てのインターネット利用者の安全性を脅かすものであり、ウイルス 感染における主要な経路の一つである。IPA では、この脅威への対策として、悪意あるサイト の検知・識別システムである「TIPS」を構築した。 TIPS は、一般利用者に代わってウェブサイトにアクセスし、脅威を検知するとともに、一 般利用者や関連協力団体に対して迅速かつ適切に情報を提供し、一般利用者にかかる被害の拡 大を防止することを目的とするシステムである（図 1-1） 。 図 1-1 TIPS サービス説明図 1.1.2. 機能強化の概要 現在運用中の TIPS では、例えば「ガンブラー」型攻撃で使われる、次のような巧妙化した 手口に対して、検知能力が不足している状況になっている。 （例） 複数の無害なサイトを経由させた上で、攻撃サイトへ誘導する手口 パターンマッチを逃れるため、毎回異なる改ざん内容を生成する手口 今回の機能強化では、今後も IPA が「ウェブの脅威」の検知、ウイルス検体の捕獲、及びそ れらを活用した注意喚起等のための情報収集を進めることを目的とし、TIPS の追加機能とし て、「高対話型ウェブクローラ」（Sacrificial Parallel high-Interaction web Crawling Analyzer、以下「SPICA」 ）を開発する（図 1-2） 。 1 図 1-2 TIPS の構成機能 本機能強化における目標とするポイントを次に示す。 （1） 「ウェブ感染型ウイルス」による攻撃の検知 最新の「ガンブラー」型攻撃で使われる手口など、検知が難しい攻撃に対応し、ウイル スのパターンやシグネチャに依存しないアーキテクチャを採用する。 可能な限り、攻撃により感染させられたウイルスの検体を捕獲する。 （2） ゼロデイ攻撃の検出 ウェブサイトからの攻撃がゼロデイ攻撃であっても検知できるアーキテクチャを採用 する。 検知した攻撃がゼロデイ攻撃か否かを簡易判定する機能を実装する。 （3） 自動巡回と情報蓄積 システム運用者が指定したウェブサイトを自動的に巡回する（繰り返し調査する）機能 を実装する。 巡回に使用するサーバについて、スケールアウト可能な設計とする。また、1 つの調査 用サーバ内で複数の調査処理を並列させるといった、効率化を意識した設計とする。 巡回した URL の情報や、攻撃を検知した URL について、管理者が参照できるよう、継続 的に情報を蓄積する。 （4） 他システムとの連携 本システムで捕獲した検体について、IPA 内の検体解析システムである ZHA へ投入し、 簡易解析を行い、ZHA の提供情報の充実に貢献する。 2 1.2. 用語の定義 表 1-1 用語の定義 項番 1 用語 高対話型ウェブク ローラ 2 クローラ 3 クローラサーバ 4 TIPS 5 悪質サイト判定 6 SPICA 7 ZHA 8 調査対象エントリ 9 11 処理済み調査対象 エントリ 次回巡回待ち調査 対象エントリ 調査結果レポート 12 攻撃サイト 13 攻撃対象アプリケ ーション 14 攻撃サイトリスト 15 16 17 日次レポート 月次レポート システムデータ 18 19 20 巡回調査実行時間 巡回調査停止時間 単体試験 21 結合試験 22 システム試験 10 定義 本書では、仮想マシン上の本物の OS やウェブブラウザを自動操作し、調査対象の ウェブサイトへアクセスを行い、仮想マシンに発生した異変を捉えて脅威（攻撃） を検知する機能を指す。高対話ウェブクライアント型ハニーポットとも呼ばれる。 本書では、ウェブサイトを機械処理により調査または巡回する機能と定義する（必 ずしも、ウェブサイトを常に巡回するとは限らず、一度だけの調査を行うものも含 む） 。 本書では、高対話型ウェブクローラの機能を実装するサーバ（巡回用クローラ、ゼ ロデイ攻撃判定用クローラ、検証用クローラ）を総称して、 「クローラサーバ」と 呼ぶ。共通する機能等の説明の際に、この呼び方を用いる。 IPA で運用している、 「悪意あるサイトの識別情報及び対策情報提供システム （TIPS：Trap-website Information Providing System） 」 。ウェブサイトからの脅 威の検知、調査に利用する。本件は、TIPS 内への機能追加となる。 http://www.ipa.go.jp/security/isg/tips.html TIPS 内に存在する既存機能。本件で追加する機能とは、現段階ではシステム上の直 接的な機能間連携はない。 本件にて TIPS 内に追加する機能。高対話型ウェブクローラと、それらを管理する ための諸機能で構成する機能（Sacrificial Parallel high-Interaction web Crawling Analyzer の略） 。 IPA で運用している、 「ウイルス等迅速解析支援ツール（Zero Hour Analysis）」 。ウ イルスの挙動解析を行うシステム。 システム運用者が SPICA でウェブサイトの調査を行う際の、具体的な調査指示を示 す一組のデータ。2.2.2.1を参照。 URL リスト作成機能での処理が完了した調査対象エントリ。2.2.2.1を参照。 ウェブサイト巡回調査において、次回の巡回のため待機している調査対象エント リ。2.2.2.1を参照。 調査対象エントリと一対一で対応する、SPICA が調査処理を行った結果レポート。 2.2.2.2を参照。 OS やアプリケーションの脆弱性の悪用といった手口により、利用者のパソコンにウ イルス等を感染させる仕掛けが施してあるウェブサイト。詐欺やフィッシングサイ トは含まない。 ウェブサイトの閲覧により、脆弱性を悪用され、ウイルス感染や侵入といった攻撃 を受ける可能性がある、もしくは過去に攻撃の対象となったアプリケーション。脆 弱性を悪用する攻撃を検知するため、仮想マシンへインストールする。 SPICA が巡回及び調査の過程において、過去 n 日（設定可能とする）において攻撃 サイトとして検出した URL のリスト。2.2.2.3を参照。 SPICA が巡回及び調査を実施した内容の一日ごとの集計情報。2.2.2.4を参照。 SPICA が巡回及び調査を実施した内容のひと月ごとの集計情報。2.2.2.5を参照。 各種設定ファイル、仮想マシンイメージ、データベースを使用する場合はデータベ ース上のデータなど、開発／構築時点から内容が変化するもので、サーバ障害から の復旧を迅速に行うために必要なデータ。 ウェブサイト巡回調査が実行されることを許可する時間帯。2.2.7.1を参照。 ウェブサイト巡回調査が実行されることを許可しない時間帯。2.2.7.1を参照。 開発したプログラム等について、最小単位（単体）で実施する試験。主に、詳細設 計で設計した内容の検証を目的とする。 開発したプログラム、OS の機能、オープンソースソフトウェアや商用製品など、隣 接する機能同士において、その結合処理が正しく行われることを確認する試験。主 に、基本設計及び詳細設計で設計した、機能間インターフェースの検証を目的とす る。 開発したプログラムやソフトウェアを実運用のためのサーバ上に構築し、また、ネ ットワーク機器等の設定を行い、ハードウェア、OS、ネットワーク等全ての要素を 組み合わせた状態で、機能要件が正しく実現されることや、目的とする業務が遂行 できることを確認する試験。 3 項番 23 用語 性能試験 24 請負者 25 機器等納入業者 26 Squid 定義 システム試験と同じ環境で、全ての要素を組み合わせた状態で、目的とする性能要 件が達成できることを確認する試験。併せて、当該性能を達成した時の各サーバの 負荷状況や、ディスク消費量、ネットワーク負荷等を確認し、将来の機器増設計画 の材料となる情報の収集や、継続運転時に問題が発生しないこと等を確認する。 本件（開発・構築作業）について、契約に基づき「1.4 作業内容・納入物件」に示 す開発・構築作業を行う者。 本件（開発・構築作業）について、その機能を稼動させるために必要なハードウェ アとソフトウェアの当機構からの発注を受け、納入、設置、配線等を行う者。 オープンソースのプロキシサーバソフトウェア。 http://www.squid-cache.org/ 4 1.3. 対象業務の概要 TIPS を利用して実施する 2 つの業務について、その概要を示す。 1.3.1. ウェブサイト調査依頼対応 利用者から電子メールにて不審なウェブサイトの情報を受け付け、本システムにて調査した 結果を回答する。 業務運用イメージを「図 1-3 ウェブサイト調査依頼対応 イメージ図」に示す。 図 1-3 ウェブサイト調査依頼対応 イメージ図 続いて、本業務に関わるユーザーについて、 「表 1-2 ウェブサイト調査依頼対応業務のユー ザー」に示す。 表 1-2 ウェブサイト調査依頼対応業務のユーザー 項番 1 2 ユーザー 調査依頼者 （一般利用者） システム運用者 （IPA） システムへの関わり方 不審な URL を IPA へメールで調査依頼する。 結果をメールで受け取る。 調査依頼を受けた URL を TIPS へ投入し、調査結果をメールで回答する。 現在は TIPS の「悪質サイト判定」機能のみで調査を行っているが、 「SPICA」の 運用開始後は、両方で調査を行う。 調査を通じて重要ウェブサイトが改ざんされ、攻撃サイトとなっていることが判 明した場合には、必要に応じて通報等を行う。 必要に応じて、攻撃サイトの URL を「SPICA」のゼロデイ攻撃判定機能へ投入し、 詳しい調査を行う。 なお、特に一般利用者からの依頼がなくとも、IPA が入手した不審な URL について、システ ム運用者が個別に調査を実施する場合もある。この時は、「図 1-3 ウェブサイト調査依頼対応 イメージ図」の①と④のフロー（依頼と回答）が無くなるのみであり、システムの機能として は特に違いはない。 5 1.3.2. ウェブサイト自動巡回 SPICA のウェブサイト自動巡回機能により、ウェブの脅威を検知し情報収集を行う。また、 必要に応じてシステム運用者が通報等を行う。 業務運用イメージを「図 1-4 ウェブサイト自動巡回 イメージ図」に示す。 図 1-4 ウェブサイト自動巡回 イメージ図 続いて、本業務に関わるユーザーについて、「表 1-3 ウェブサイト自動巡回業務のユーザ ー」に示す。 表 1-3 ウェブサイト自動巡回業務のユーザー 項番 1 ユーザー システム運用者 （IPA） システムへの関わり方 自動巡回先とするウェブサイトの URL を「SPICA」へ登録する。 日々巡回の結果を確認し、重要ウェブサイトが改ざん等により攻撃サイトとなっ ていることを発見した場合は、必要に応じて通報等を行う。 必要に応じて、攻撃サイトの URL を「SPICA」のゼロデイ攻撃判定機能へ投入し、 詳しい調査を行う。 なお、本業務のポリシーとして、巡回先のウェブサイトの安全性を常に保証するようなサー ビスを提供するものではない。また、特定のサイトを巡回対象にしてほしいといった外部から の依頼も、原則として受け付けない。 6 1.4. 作業内容・納入物件 本件は、 「悪意あるサイトの識別情報及び対策情報提供システム（TIPS） 第一次機能強化」の開 発・構築に係る作業を発注するものである。 本作業では、機能強化における設計・実装・構築・試験を行うこととする。 1.4.1. 作業範囲 （1） プロジェクト管理 （2） 課題管理 （3） 要件定義 （4） ハードウェア／ソフトウェア構成設計 （5） 基本設計 （6） 詳細設計 （7） 製造 （8） システム構築 （9） 試験項目作成 （10） 試験実施 （11） マニュアル作成 1.4.2. 作業内容 作業範囲と作業内容を次の「表 1-4 作業範囲と作業内容」に示す。 表 1-4 作業範囲と作業内容 項番 1 2 作業範囲 プロジェクト管理 課題管理 3 要件定義 4 5 ハードウェア／ソフ トウェア構成設計 基本設計 6 詳細設計 7 8 製造 システム構築 9 試験項目作成 10 試験実施 11 マニュアル作成 作業内容 プロジェクト推進における管理作業全般を行う。 システム設計で発生した課題の抽出と整理を含めた管理を行う。また、課題を解 決するための提言を行う。 本発注仕様書を基に、システムの具体的な機能要件を定義し、要件定義書として まとめる。 要件を基に、ハードウェア設計、ソフトウェア設計、及び調達物件の構成作成を 行う。 要件定義に基づき、システム全体の概要、機能構成、機能の概要設計、データ設 計、ユーザーインターフェース設計、機能間インターフェース設計などを行う。 基本設計の結果を、基本設計書としてまとめる。 基本設計に基づき、各機能のアルゴリズム、具体的なデータ構造（スキーマ、フ ァイルフォーマット） 、設定パラメータなどの設計を行う。また、ネットワークの 論理設計と物理（配線）設計を行う。 詳細設計の結果を、詳細設計書としてまとめる。 開発が必要な機能について、実装（コーディング）を行う。 当機構が調達したサーバやネットワーク機器へ、製造したプログラム、設定ファ イル、必要に応じてオープンソースソフトウェアや商用製品等のインストール作 業及び設定作業を行い、使用可能な状態とする。 設計した内容が正しく実装されていることを検証するための試験項目を試験仕様 書として作成する。単体試験、結合試験、システム試験、性能試験を実施するこ と。なお、各試験の範囲や定義については、 「1.2 用語の定義」を参照のこと。 作成した試験仕様書に基づき、試験を実施し、実施結果を試験結果報告書として まとめる。単体試験、結合試験については、実施できない理由が特に存在する場 合を除き、請負者の環境にて実施すること。システム試験、性能試験については、 当機構の実機・実環境にて実施すること。 システム構築手順書及びシステム運用者のためのマニュアルを作成する。 7 1.4.3. プロジェクトの流れと作業分担 本開発・構築作業における、プロジェクトの流れと、請負者、当機構、及び機器等納入業者 の作業分担関係について「図 1-5 プロジェクトの流れ」に示す。 図 1-5 プロジェクトの流れ 図の内容について次に補足する。 プロジェクトの始めに、要件定義とハードウェア／ソフトウェア構成設計を、請負者と 当機構の両者にて実施する。作業主体は請負者とし、要件定義書やハードウェア／ソフ トウェア構成は成果物の一部となる。 作成したハードウェア／ソフトウェア構成に従い、当機構が機器等納入業者へ調達を行 う（分離調達） 。請負者においては、次の点に留意すること。 一部の例外を除き、原則として、一般に販売されている商用製品については、全て 分離調達の対象となる。 当機構による調達作業の開始から、機器の設置等が完了して請負者がシステム構築 作業に着手できるまで、約 3 ヵ月の期間を要する。 当機構においては、特に必要と認められない限り、具体的なメーカー名、ソフトウ ェア名、型番等は指定せず、スペックや実現機能の提示によりハードウェア／ソフ トウェアの調達を行う（詳細は構成設計作業の中で定める） 。 8 1.4.4. ハードウェア及びソフトウェアに関する作業範囲 ハードウェア及びソフトウェアに関する、請負者の作業範囲と当機構及び機器等納入業者の 作業範囲の考え方について、 「図 1-6 システム構成要素」を基に説明する。 図 1-6 システム構成要素 図中の各要素の作業範囲を「表 1-5 システム構成要素と作業範囲」に示す。 表 1-5 システム構成要素と作業範囲 項番 構成要素 1～4、 サーバ機器、ホス 8 ト OS、ミドルウェ ア等(※)、仮想化 ソフトウェア、そ の他の機器 形態 分離 調達 5 請負 6、7 開発プログラム等 作業範囲 請負者が構成を作成し、商用製品については、当機構が機器等納入業者よ り調達する。機器の設置及びサーバのホスト OS のインストールまで完了し た状態で、請負者へ引き継ぎを行う。 その他のソフトウェアのインストールやネットワーク機器の設定等は請負 者が実施すること。 オープンソースソフトウェアや無償で利用できるソフトウェアを使用する 場合は、該当機能の実装方式の説明として、提案書内に記載すること。 請負者にて製造を行い、インストール、設定までを行う。 なお、分離調達の例外として、 「高対話型ウェブクローラ」に関する機能、 例えば、URL 収集、仮想マシン管理、攻撃検知、ウイルス検体捕獲、ウイ ルス振る舞い検知などの機能については、要件に従い、新規開発を行うか、 既存ソフトウェアを適用するかといった実現手段を含めて提案すること。 既存ソフトウェアを適用する場合、どの機能要件を当該ソフトウェアで実 現するのか、範囲を明記すること。 更に、既存ソフトウェアとして商用製品を適用する場合、それに係る費用 は本開発・構築作業に含み、納品物にライセンス証書、インストール媒体、 マニュアル等を含めること。 請負者との調整の上、当機構が構成を定め、機器等納入業者より調達する。 仮想マシンへのインストール、設定等は請負者が実施すること。 ゲスト OS、 分離 攻撃対象アプリケ 調達 ーション (※) 「ミドルウェア等」とは、データベース、運用管理ソフト、アプリケーションサーバ、ウイルス対策 ソフト、UPS 管理／エージェントソフト、プロキシサーバソフト等の、無償または商用製品のソフトウェアを 指す。 9 1.4.5. 納入期限 2011 年 8 月 25 日 1.4.6. 納入場所 東京都文京区本駒込二丁目 28 番 8 号 独立行政法人 情報処理推進機構 セキュリティセンター 1.4.7. 納入物件 納入期限までに、次の「表 1-6 開発成果物一覧」に示す開発成果物を納入すること。 表 1-6 開発成果物一覧 項番 1 2 3 開発成果物 要件定義書 基本設計書 詳細設計書 試験仕様書 試験結果報告書 システム構築手順書 システム運用マニュアル 障害対応手順書 4 ソースコード 実行プログラム 構築用スクリプト 設定ファイル 5 件外プロダクトに係るラ イセンス等の証書 内容 発注仕様書に基づいて定義及び設計した、要件定義、基本設計、詳 細設計を記載した資料。システム機器構成（ハードウェア／ソフト ウェア）を含む。 試験方法や試験項目などを記載した資料と、それに基づき実施した 試験結果を記載した資料。 障害時にサーバを復旧（再構築）する手順、及び巡回用クローラの 増設における手順を示す、システム構築手順書。 システム運用者が日常的な業務遂行を行ったり、システムの設定変 更を行うためのシステム運用マニュアル。 障害発生時の切り分け手順を含む、障害対応手順書。 開発したプログラムのソースコード、実行プログラム、実行プログ ラムを作成するためのスクリプト。オープンソースソフトウェアや 商用製品を使用した場合は、そのソースコード（公開されている場 合）と実行プログラム。 システム構築作業（インストール作業含む）において、システム構 築手順書の中で使用する構築用スクリプト。 開発したプログラムやその他ソフトウェアの設定ファイル。 件外プロダクト（商用製品等）を使用した場合に、そのライセンス 等の使用権が当機構に帰属することを証明する書類など。 部数 1式 1式 1式 1式 1式 1～4 は記録媒体（CD-R、DVD-R 等）に格納して当機構に納入すること。形式等について は当機構が指定する様式とすること。 検収用に 1～3 は紙媒体 1 部を当機構に納入すること。 1～3 は日本語で作成し、図表等は本文中に挿入すること（ただし、固有名詞や文献参 照等に外国語表記を用いてもよい）。また、図表等については、全て編集可能であるこ と（例えば、作図ツール等を用いて作成した図について、ビットマップ化したものを文 書中に挿入した場合は、その元ファイル（作図ツール用のファイル形式）を併せて納入 すること） 。 1～4 は公開を前提とした内容となっていること（件外プロダクトを除く） 。 開発成果物以外のドキュメント（プロジェクト進行に伴う報告書、課題管理票など）に ついても、適宜、当機構に提出することとする。 1.4.8. 検収条件 検収では、本仕様書の条件、項目を満たすかの確認を行う。また、開発・構築された本シス テムについては、機能・品質・性能が「1.1 本システムの目的」に示す目的、「1.3 対象業務 の概要」に示す業務内容、及び「2 システムの要件」に示す要件を満たすに十分か否かを判断 し確認を行う。 10 2. システムの要件 2.1. システムの概要 2.1.1. システムの概要と処理の流れ 本システムの概要図を「図 2-1 システム概要図」に示す。この図は、まず主要な機能と動 作を説明することを目的とした想定図であり、詳しい要件は後述する。また、実際の具体的な サーバ・ソフトウェア構成については提案を求める。 図中、破線の枠で囲まれた範囲が TIPS 全体であり、「追加機能」と表した部分が今回の開発 対象（SPICA）である。 「追加機能」の外の部分（既存機能）との間には直接的な関連（インタ ーフェース機能等）はなく、本開発のスコープ外である。このため、既存機能については、説 明を省略する。 図 2-1 システム概要図 本システムでは、 「1.3 対象業務の概要」で示した 2 つの業務について、基本的に共通の機 能と処理フローにより実現することを想定している。図中の処理の流れについて、「表 2-1 シ ステム概要図 処理の説明」に示す。 11 表 2-1 システム概要図 処理の説明 番号 ① 処理項目 調査／巡回対象とするウェブ サイトのリストを登録 ② ウェブサイトを構成する URL の リストを取得 ③ 調査（クロール）指示 ④ ウェブサイトへアクセスし、脅 威を検出 ⑤ 調査結果データを保存 ⑥ 調査・巡回結果レポートを確認 － 捕獲した検体を検体解析シス テムへ 説明 システム運用者が、SPICA に対して調査／巡回対象とさせるウェブサイ トの情報を登録する。ここでは、次に挙げるケースがある。 ウェブサイト調査依頼対応業務：一度だけ調査を行う対象のウェ ブサイトの情報を登録する。 ウェブサイト自動巡回業務：巡回（不定期に繰り返し調査を行う） 対象のウェブサイトの情報を登録、削除する。 ゼロデイ攻撃判定：ゼロデイ攻撃判定のための調査を行う対象の ウェブサイトの情報を登録する。ゼロデイ攻撃判定では、ウェブ サイト調査依頼対応と同じく、一度だけ調査処理を行う。 ①でシステム運用者が登録する調査対象の情報は、例えば 「http://www.ipa.go.jp/ 及び、そこからリンクを 1 階層辿った範囲」 といった内容となる。この情報から、具体的な調査先となる URL のリス トを作成する。 作成した URL のリストを巡回用クローラまたはゼロデイ攻撃判定用クロ ーラへ連携し、調査指示を行う。①で示した「ウェブサイト調査依頼対 応」 「ウェブサイト自動巡回」においては巡回用クローラによる調査を 行い、 「ゼロデイ攻撃判定」においてはゼロデイ攻撃判定用クローラに よる調査を行う。 巡回用クローラは、脆弱な仮想マシンを操作して URL のリストを順次ア クセスし、脆弱性を突く攻撃やウイルス感染などの脅威を検出する。 ゼロデイ攻撃判定用クローラは、脆弱性を解消した 3 種類の仮想マシン を操作し、それぞれで URL のリストを順次アクセスする。 いずれも、脅威を検出した際、可能な限りウイルス検体の捕獲も行う。 巡回用クローラとゼロデイ攻撃判定用クローラは、各種の調査結果デー タを単一のサーバへ集約して保存する。調査結果データとしては、調査 した URL のリスト、脅威の有無、検出した攻撃サイトのリスト、捕獲し たウイルス検体に関する情報、検体ファイルなどがある。 SPICA では、調査結果データとして個々の調査の結果を出力するほか、 それらを日次レポート、月次レポートに統計情報として集約する機能を 持つ。システム運用者はサーバへアクセスし、調査・巡回結果レポート を参照する。ここでは、次に挙げるケースがある。 ウェブサイト調査依頼対応業務：登録した調査対象に対応するレ ポートを参照し、脅威が検知されたか否かを確認する。 ウェブサイト自動巡回業務：定期的にレポートを参照し、巡回対 象としているウェブサイトにて脅威が検知されたか否かを確認す る。 ゼロデイ攻撃判定：登録した調査対象に対応するレポートを参照 し、脆弱性を解消した 3 種類の仮想マシンのいずれかでウイルス 感染が発生したか否かを確認する。 捕獲したウイルス検体を当機構内の他システムである「検体解析システ ム」 （ZHA）へ連携を行う。 具体的には、捕獲した検体のうち、実行形式のものについてのみ、パス ワード付き zip ファイルにした上で、 当機構が指定する FTP サーバへ PUT 処理を行う。 12 2.1.2. システムのユーザー 本システムは、システム運用者のみがアクセスして利用する形態となる。システム運用者は、 「表 2-2 システム運用者の区分」に示す 2 種類の区分を定めることを想定している。 表 2-2 システム運用者の区分 項番 1 区分 システム管理者 2 業務運用者 説明 本システムの全てのサーバ、全ての機能へアクセス可能であり、システムの起動と停 止、パッチの適用、障害対応などのシステム運用を行う。 項番 2 の業務運用者の作業も実施できる。 主に次の対象業務の遂行作業を実施する。サーバや機能へのアクセスについて、必要 以上の権限を持たないこととする。 ウェブサイト調査依頼対応業務：調査対象の登録とレポートの参照。 ウェブサイト自動巡回業務：巡回対象の登録や削除と、定期的なレポートの参照。 ゼロデイ攻撃判定：調査対象の登録とレポートの参照。 その他、自動巡回スケジュールの設定、ルータの電源制御など、日常業務の遂行 に係る作業 本システムは秘密情報を扱うものではないため、上記区分のための厳密な権限制御・アクセ ス制御の実装は求めず、誤った操作による障害等を避けることを主たる目的としている。例え ば、 「ログインできるサーバを限定することで、アクセスできる機能を制限する」、「ファイル システムのパーミッション設定でアクセスできる情報を制限する」というように、特別な作り こみ（プログラム開発等）を伴わない範囲での実現を想定している。 システム運用者の区分と、区分によるアクセス制御に関する要件と仕様についての詳細は、 機能設計の方針を考慮した上で、要件定義もしくは基本設計の段階にて、改めて当機構と協議 の上で定める。 2.1.3. 運用形態 本機能は、最低 3 年、原則として 5 年間の運用を想定している。その後については、本 機能をとりまく情勢等を考慮し、改めて検討する。 本機能は 24 時間 365 日の稼動を基本とする。 ただし、ミッションクリティカルシステムという扱いではなく、障害やメンテナン スのための一時的な停止は許容する。 13 2.2. 業務要件 2.2.1. 業務要件一覧 本システムで想定する業務要件の概要を「表 2-3 業務要件一覧」に示す。ここで想定して いる各業務とその機能要件については、要件定義の段階で、当機構と協議の上、見直すことが 可能である。 表中の「番号」は、業務要件番号を示す。以降「業務要件 1-1」などと参照する場合がある。 表 2-3 業務要件一覧 番号 1 1-1 1-2 1-3 業務 ウェブサイト調査 調査対象エントリの登録 調査対象エントリの参照 調査対象エントリの削除 1-4 1-5 1-6 1-7 1-8 処理済み調査対象エントリの参照 処理済み調査対象エントリの削除 調査結果レポートの参照 調査結果レポートの取得 調査結果レポートの削除 1-9 1-10 2 2-1 2-2 2-3 攻撃サイトリストの参照 攻撃サイトリストの取得 ウェブサイト巡回調査 調査対象エントリの登録 調査対象エントリの参照 調査対象エントリの削除 2-4 2-6 2-7 2-8 次回巡回待ち調査対象エントリの 参照 次回巡回待ち調査対象エントリの 削除 調査結果レポートの参照 調査結果レポートの取得 調査結果レポートの削除 2-9 2-10 3 攻撃サイトリストの参照 攻撃サイトリストの取得 ゼロデイ攻撃調査 3-1 3-2 3-3 調査対象エントリの登録 調査対象エントリの参照 調査対象エントリの削除 3-4 3-5 3-6 3-7 3-8 処理済み調査対象エントリの参照 処理済み調査対象エントリの削除 調査結果レポートの参照 調査結果レポートの取得 調査結果レポートの削除 3-9 3-10 4 攻撃サイトリストの参照 攻撃サイトリストの取得 統計レポート参照 4-1 日次レポートの参照 2-5 概要 システム運用者が個別のウェブサイトの脅威を調査する。 新たな調査対象エントリを登録する。 登録済みで、処理待ちとなっている調査対象エントリを参照する。 登録済みで、処理待ちとなっている調査対象エントリを削除（キャ ンセル）する。 処理済みとして保管してある調査対象エントリを参照する。 処理済みとして保管してある調査対象エントリを削除する。 調査結果レポートを参照する。 調査結果レポートを運用 PC へ取得する。 調査結果レポートを削除する。 ※日次レポートの結果に影響するため、この作業は原則実施しない。 現時点で判明している攻撃サイトのリストを参照する。 現時点及び過去時点の攻撃サイトのリストを運用 PC へ取得する。 システム運用者が多数のウェブサイトの巡回調査を運用する。 新たな調査対象エントリを登録する。 登録済みで、処理待ちとなっている調査対象エントリを参照する。 登録済みで、処理待ちとなっている調査対象エントリを削除（キャ ンセル）する。 次回巡回待ちとなっている調査対象エントリを参照する。 次回巡回待ちとなっている調査対象エントリを削除する。 調査結果レポートを参照する。 調査結果レポートを運用 PC へ取得する。 調査結果レポートを削除する。 ※日次レポートの結果に影響するため、この作業は原則実施しない。 現時点で判明している攻撃サイトのリストを参照する。 現時点及び過去時点の攻撃サイトのリストを運用 PC へ取得する。 システム運用者が個別のウェブサイトについて、ゼロデイ攻撃が発 生するか否かを焦点とした調査を行う。 新たな調査対象エントリを登録する。 登録済みで、処理待ちとなっている調査対象エントリを参照する。 登録済みで、処理待ちとなっている調査対象エントリを削除（キャ ンセル）する。 処理済みとして保管してある調査対象エントリを参照する。 処理済みとして保管してある調査対象エントリを削除する。 調査結果レポートを参照する。 調査結果レポートを運用 PC へ取得する。 調査結果レポートを削除する。 ※日次レポートの結果に影響するため、この作業は原則実施しない。 現時点で判明している攻撃サイトのリストを参照する。 現時点及び過去時点の攻撃サイトのリストを運用 PC へ取得する。 システム運用者が SPICA による調査処理の統計レポートを参照す る。 SPICA による調査処理の日次レポートを参照する。 14 番号 4-2 4-3 業務 日次レポートの取得 日次レポートの削除 4-4 4-5 4-6 5 月次レポートの参照 月次レポートの取得 月次レポートの削除 巡回調査スケジュール設定 5-1 巡回調査実行時間設定 5-2 6 巡回調査例外日設定 外部接続用ルータ電源操作 6-1 6-2 6-3 6-4 7 7-1 7-2 8 外部接続用ルータ電源状態参照 外部接続用ルータ電源開始 外部接続用ルータ電源停止 外部接続用ルータ再起動 ウイルス検体操作 ウイルス検体の取得 ウイルス検体の削除 システム監視 8-1 9 サーバ死活監視 システム運用管理 9-1 9-2 9-3 9-4 9-5 システム起動 システム停止 ウェブサイト調査一時停止 ウェブサイト調査一時停止解除 クローラ仮想マシンイメージメン テナンス プロキシアクセス制御設定 バックアップ 9-6 9-7 概要 SPICA による調査処理の日次レポートを運用 PC へ取得する。 SPICA による調査処理の日次レポートを削除する。 ※月次レポートの結果に影響するため、この作業は原則実施しない。 SPICA による調査処理の月次レポートを参照する。 SPICA による調査処理の月次レポートを運用 PC へ取得する。 SPICA による調査処理の月次レポートを削除する。 システム運用者がウェブサイト巡回調査の運用スケジュールを設定 する。 ウェブサイト巡回調査処理を実行する曜日及び時間のスケジュール を設定する。 ウェブサイト巡回調査処理を実行しない日を設定する。 システム運用者が外部接続用ルータの電源操作を必要に応じて行 う。 外部接続用ルータへの電源供給状態を参照する。 外部接続用ルータへの電源供給を開始する。 外部接続用ルータへの電源供給を停止する。 外部接続用ルータへの電源供給を停止・開始して再起動する。 システム運用者がウイルス検体の取り出し等を必要に応じて行う。 ウイルス検体を運用 PC へ取得する。 ウイルス検体を削除する。 システム運用者が SPICA を構成するサーバ等の状態確認を随時行 う。 SPICA を構成する各サーバの死活監視を行う。 システム運用者が SPICA のシステム運用管理作業を必要に応じて行 う。 SPICA を構成する機能全体の起動を行う。 SPICA を構成する機能全体の停止を行う。 業務要件 1,2,3 の調査処理を一時停止する。 業務要件 9-3 で行った一時停止措置を解除する。 巡回用クローラ、ゼロデイ攻撃判定用クローラで使用する仮想マシ ンの OS やアプリケーションの構成を変更する。 特定のドメイン名等に対してアクセス制御を行う。 バックアップサーバへ仮想マシンイメージ、調査結果に関するデー タ、ウイルス検体、ログ等のファイルバックアップを行う。 15 2.2.2. 業務データ要件 本章では、以降の業務要件において使用する業務データの用途、構成内容等について定める。 2.2.2.1. 調査対象エントリ システム運用者が SPICA でウェブサイトの調査を行う際の、具体的な調査指示を示す一組の データ。 SPICA では、このエントリを単位として調査処理を行い、調査結果を出力する。 内容の詳細を「表 2-4 調査対象エントリの構成情報」に示す。なお、同等の業務処理が実 現できる場合は、この仕様に必ずしも従わなくともよい。 表 2-4 調査対象エントリの構成情報 項番 1 名称 識別名 2 種別 3 優先度 4 5 基点 URL リンク深度 6 外部ドメインフラグ 説明 システム運用者が命名する、この調査対象エントリを識別するための名前。 例：「IPA」 「www_ipa_go_jp」 「chousa_20110801_001」 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査のうち、どの調査 に使用するエントリかを示す識別子。 この調査対象エントリの処理優先度。 例えば、00～99 の値（値が小さいほど優先度が高い）で設定する仕様とし、ウ ェブサイト巡回調査の調査対象エントリの優先度は全て 99、ウェブサイト調査 の処理対象エントリの優先度は 50 などと指定することで、巡回よりも個別調査 を優先させる仕組みを想定している。また、個別調査の中でも、一度に大量に実 行する場合に、優先付けが行えることが望ましい。 調査対象とする URL。1 つの調査対象エントリの中で複数指定可能とする。 この調査対象エントリから調査の対象とする URL のリストを作成する際、基点 URL からリンクを何回辿ったページまでを対象とするかを指定する。次の値を指 定可能とする。 0：基点 URL のみを調査する。 1～n：基点 URL から指定した回数のリンクを辿った URL を調査する。 -1：無制限。基点 URL から辿れる限りのリンクを辿った URL を調査する。 リンク深度に従ってリンクを辿る際、基点 URL 以外のドメイン（ウェブサーバ） のページも対象とするか否かを指定する。 具体的にどこまでを同じドメインとみなすかは、基本設計等の中で当機構と協議 の上定める。基本的には、URL 中のホスト名部分が同一 FQDN の範囲を同じドメ インとみなすことを想定している。 一つの調査対象エントリに複数の基点 URL を指定できるため、 「1 個の基点 URL が指定され た 100 個の調査対象エントリ」と、 「100 個の基点 URL が指定された 1 個の調査対象エントリ」 では、SPICA が行う調査内容は、結果的にはほぼ等価である（調査 URL の重複の度合いや、タ イミングのずれ等の違いはある） 。システム運用者は、「表 2-5 調査対象エントリの設定のト レードオフ」の観点で調査対象エントリを設定することを想定している。 表 2-5 調査対象エントリの設定のトレードオフ 調査対象エントリの数：多 基点 URL 数：尐 調査対象エントリの全体数 多くなる 優先度の高いエントリの割り込み 早めに処理される 調査の一時停止指示（2.2.11.3参照）を出した後や、 短くなる 巡回調査停止時間（2.2.7.1参照）に入ってから実際 に処理が停止するまでの時間 機能全体のパフォーマンス 低くなる （設計によるが、ここでは右記のように想定） 16 調査対象エントリの数：尐 基点 URL 数：多 尐なくなる 時間がかかる場合がある 長くなる 高くなる なお、調査対象エントリは、状態により呼び方を変える場合がある。 処理済み調査対象エントリ：URL リスト作成機能での処理が完了した調査対象エントリ。 巡回用クローラまたはゼロデイ攻撃判定用クローラでの処理待ち、あるいは処理済み状 態であることを示す。 次回巡回待ち調査対象エントリ：ウェブサイト巡回調査において、次回の巡回のため待 機している調査対象エントリ。 2.2.2.2. 調査結果レポート 調査対象エントリに対応する、SPICA が調査処理を行った結果レポート。 巡回調査として登録された調査対象エントリについては、一つのエントリに対して繰り返し 調査が行われるため、一対多で出力される。同様に、ゼロデイ攻撃調査として登録された調査 対象エントリについても、一つのエントリに対して複数の仮想マシンを用いた調査が行われる ため、一対多で出力されることを想定している（設計により、１つの調査結果レポートに結合 してもよいが、どの仮想マシンで攻撃が成立したか識別できるよう注意すること） 。 システム運用者が調査対象エントリを同一の識別名で複数回登録することを想定し、過去の 調査結果レポートが上書きされて消えないよう考慮すること。 システム運用者は、指示した調査の結果について、このレポートと「2.2.2.3 攻撃サイトリ スト」を併せて参照することを想定している。 内容の詳細を「表 2-6 調査結果レポートの構成情報」に示す。 表 2-6 調査結果レポートの構成情報 項番 1 2 名称 識別名 種別 3 調査日時 4 仮想マシン種別 5 6 調査済み URL 攻撃検知 URL 7 捕獲検体情報 説明 この調査結果レポートの元となった調査対象エントリの識別名。 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査のうち、どの調査 を行ったかを示す識別子。 調査を行った日時。年月日時分秒の情報を含むこと。 システム運用者から見た時の、調査結果レポートのユニークな識別子が「識別名 ＋調査日時」となることを想定している。 調査を実施した仮想マシンを識別する情報。特にゼロデイ攻撃調査の場合に必要 で、それ以外の調査の場合は、この項目の有無は問わない。 調査を行った URL のリスト。 調査を行った中で攻撃を検知した URL のリスト。項番 5 の調査済み URL の付加情 報として、攻撃検知の有無を併記する形式でもよい。 攻撃を検知した際に捕獲できた検体に関する情報。検知時のファイル名、SPICA 内での保存先のファイル名が分かること。 2.2.2.3. 攻撃サイトリスト SPICA が巡回及び調査の過程において、過去 n 日（設定可能とする）において攻撃サイトと して検出した URL のリスト。 個別の調査対象エントリごとの調査結果は「2.2.2.2 調査結果レポート」で参照できるが、 このリストは、過去 n 日分の調査結果を横断解析し、攻撃を検知した URL の一覧としたもので ある。横断解析においては、 「ガンブラー」型攻撃手口で使われたような、複数のウェブサイ トをリダイレクトさせたり、同一の IP アドレスからの二回目以降のアクセスに対しては無害 なふりをする攻撃サイトについても、可能な限り検知することを期待している。 システム運用者は、基本的にこのリストの最新版のみを参照することを想定している。 内容の詳細を「表 2-7 攻撃サイトリストの構成情報」に示す。 17 表 2-7 攻撃サイトリストの構成情報 項番 1 2 名称 リスト作成日時 攻撃サイト URL リスト 説明 このリストが作成された日時。年月日時分秒の情報を含むこと。 攻撃が行われると考えられる URL のリスト。アルファベット順にソートして参照 することが可能であること。 2.2.2.4. 日次レポート SPICA が巡回及び調査を実施した内容の一日ごとの集計情報。 調査結果レポートと攻撃サイトリストの内容を集計して作成する。集計対象となっている日 のデータがひとつも存在しない場合でも、集計値をゼロとして作成を行うこと。 項番 4 と 5 は、SPICA での攻撃サイトの発見状況を概観することを目的とした情報であり、 ここに示した仕様に厳密に従う必要はない。同等の目的が達成できればよいという前提で、要 件定義の段階で、当機構と協議の上、見直すことが可能である。 表 2-8 日次レポートの構成情報 項番 1 名称 日次レポート対象日 2 調査 URL 数 3 攻撃検知 URL 数 4 攻撃サイトリスト数 5 新規発見攻撃サイト数 説明 この日次レポートの集計対象となっている日付。例えば、2011 年 1 月 2 日の早 朝に昨日分（1 月 1 日の 00:00～23:59）の情報を集計して日次レポートを作成し た場合は、日次レポートの完成時点の日付ではなく、 「2011 年 1 月 1 日」付けと すること。 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査それぞれについて、 調査を実施した URL の数。及び、その合計数。 一日分の全「調査結果レポート」の「調査済み URL」の総数である。 すなわち、この数は「延べ」の数値となる。一日の間に同一の URL を調査したり、 ゼロデイ攻撃調査のように複数の仮想マシンで同一の URL を調査した場合、 「1URL」とは数えず、原則として調査した延べ回数が集計されることを想定して いる。 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査それぞれについて、 攻撃を検知した URL の数。及び、その合計数。 一日分の全「調査結果レポート」の「攻撃検知 URL」の総数である。 項番 2 と同じく、この数は「延べ」の数値となる。 日次レポートの集計対象となっている日までに作成された最新の攻撃サイトリ ストに載っている URL の総数。 新たに発見した（攻撃サイトリストに追加された）URL の数。 日次レポートの集計対象となっている日の最後に作成された攻撃サイトリスト と、その前日以前（※）の最後に作成された攻撃サイトリストとを比較し、増加 した URL の数。 （※）前日に SPICA が動作していなかった場合など、前日のデータが存在すると は限らないため、前日以前で最後に作成された攻撃サイトリストを比較対象にす る必要がある。どこまで過去情報を遡るかは、基本設計以降の段階で定めること。 なお、集計対象となっている日に攻撃サイトリストが作成されなかった（調査が 行われなかった）場合は、ゼロとカウントする。 18 2.2.2.5. 月次レポート SPICA が巡回及び調査を実施した内容のひと月ごとの集計情報。 ひと月分の日次レポートの内容と、最新の攻撃サイトリストを集計して作成する。対象とな る月の日次レポートが全く存在しない場合は、集計値をゼロとして作成を行うこと。 表 2-9 月次レポートの構成情報 項番 1 名称 月次レポート対象月 2 調査 URL 数 3 攻撃検知 URL 数 4 攻撃サイトリスト数 5 新規発見攻撃サイト数 説明 この月次レポートの集計対象となっている日付。例えば、2011 年 2 月 1 日の早 朝（1 月 31 日の日次レポート作成後）に先月分（2011 年 1 月 1 日～31 日）の情 報を集計して月次レポートを作成した場合は、月次レポートの完成時点の日付で はなく、 「2011 年 1 月」付けとすること。 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査それぞれについて、 調査を実施した URL の数。及び、その合計数。 ひと月分の日次レポートの同項目の集計値。 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査それぞれについて、 攻撃を検知した URL の数。及び、その合計数。 ひと月分の日次レポートの同項目の集計値。 月次レポートの集計対象となっている末日までに作成された最新の攻撃サイト リストに載っている URL の総数。 新たに発見した（攻撃サイトリストに追加された）URL の数。 ひと月分の日次レポートの同項目の集計値。 2.2.2.6. ウイルス検体 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査それぞれについて、調査を実 施した際に捕獲したウイルスの検体ファイル。 「2.2.2.2 調査結果レポート」に含む、ウイルス検体を識別する情報により、どのウェブサ イトの調査で捕獲したかが特定できること。 19 2.2.3. 業務要件 1 ウェブサイト調査 システム運用者が個別のウェブサイトの脅威を調査する。 調査の指示は調査対象エントリの登録という形で行い、調査結果の確認は調査結果レポート 及び攻撃サイトリストの参照という形で行う。 この調査の指示は、業務要件 2 の「ウェブサイト巡回調査」の処理対象よりも優先して（巡 回調査に割り込む形で）処理される必要がある。 2.2.3.1. 業務要件 1-1 調査対象エントリの登録 新たな調査対象エントリを登録する。 【要件】 システム運用者が、調査対象エントリを新たに作成し、登録できること。 2.2.3.2. 業務要件 1-2 調査対象エントリの参照 登録済みで、処理待ちとなっている調査対象エントリを参照する。 【要件】 システム運用者が、登録済みで、処理待ちとなっている調査対象エントリの一覧を参照 し、任意の調査対象エントリの内容を参照できること。 2.2.3.3. 業務要件 1-3 調査対象エントリの削除 登録済みで、処理待ちとなっている調査対象エントリを削除（キャンセル）する。 【要件】 システム運用者が、登録済みで、処理待ちとなっている調査対象エントリの一覧を参照 し、任意の調査対象エントリを削除できること（処理待ちとなっている状態から調査を キャンセルできること） 。 2.2.3.4. 業務要件 1-4 処理済み調査対象エントリの参照 処理済みとして保管してある調査対象エントリを参照する。 【要件】 システム運用者が、処理済みとなっている調査対象エントリの一覧を参照し、任意の調 査対象エントリの内容を参照できること。 日を置いて同じウェブサイトを再調査する場合など、処理済み調査対象エントリを、調 査対象エントリとして再利用を行う場合があることを考慮すること。 2.2.3.5. 業務要件 1-5 処理済み調査対象エントリの削除 処理済みとして保管してある調査対象エントリを削除する。 20 【要件】 システム運用者が、処理済みとなっている調査対象エントリの一覧を参照し、任意の調 査対象エントリを削除できること。 2.2.3.6. 業務要件 1-6 調査結果レポートの参照 調査結果レポートを参照する。 【要件】 システム運用者が、自身が登録した調査対象エントリに対応する調査結果レポートを、 複数存在する調査結果レポートの中から特定できること。 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートの内容 を参照できること。 2.2.3.7. 業務要件 1-7 調査結果レポートの取得 調査結果レポートを運用 PC へ取得する。 【要件】 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートの内容 を、運用 PC へ取得できること。 取得においては、多数の調査結果レポートをまとめて取得することを考慮した方式とす ること。 取得における実装方式は、Windows ファイル共有によるファイルコピー、HTTP や FTP によるダウンロードなどを想定している。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.3.8. 業務要件 1-8 調査結果レポートの削除 調査結果レポートを削除する。 調査結果レポートの情報は、後述する日次レポートの元データとなることを想定している。 このため、日次レポートの結果への影響を避けるため、本作業は原則として実施しないが、要 件としては挙げている。 【要件】 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートを削除 できること。 調査結果レポートを削除した結果、日次レポートへの影響は、削除された調査結果レポ ートの内容の範囲に留まること（日次レポート全体に異常が生じないようにすること） 。 なお、既に日次レポートへの集計処理が終わった調査結果レポートを削除した場合 において、日次レポートを再作成する必要はない。 2.2.3.9. 業務要件 1-9 攻撃サイトリストの参照 現時点で判明している攻撃サイトのリストを参照する。 【要件】 システム運用者が、現時点の（最新版の）攻撃サイトリストを参照できること。 21 2.2.3.10. 業務要件 1-10 攻撃サイトリストの取得 現時点及び過去時点の攻撃サイトのリストを運用 PC へ取得する。 【要件】 システム運用者が、現時点及び過去時点の攻撃サイトリストのうち、任意の攻撃サイト リストの内容を、運用 PC へ取得できること。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.4. 業務要件 2 ウェブサイト巡回調査 システム運用者が多数のウェブサイトの巡回調査を運用する。 調査の指示は調査対象エントリの登録という形で行い、調査結果の確認は調査結果レポート 及び攻撃サイトリストの参照という形で行う。業務要件 1 の「ウェブサイト調査」や業務要件 3 の「ゼロデイ攻撃調査」とは異なり、基本的にはシステム運用者が定期的に攻撃サイトリス トを確認するといった形での運用を想定している。 一度登録した調査対象エントリは、システム運用者が削除するまで巡回調査の対象となる。 2.2.4.1. 業務要件 2-1 調査対象エントリの登録 ※ 業務要件 1-1 に同じ。 新たな調査対象エントリを登録する。 【要件】 システム運用者が、調査対象エントリを新たに作成し、登録できること。 2.2.4.2. 業務要件 2-2 調査対象エントリの参照 ※ 業務要件 1-2 に同じ。 登録済みで、処理待ちとなっている調査対象エントリを参照する。 【要件】 システム運用者が、登録済みで、処理待ちとなっている調査対象エントリの一覧を参照 し、任意の調査対象エントリの内容を参照できること。 2.2.4.3. 業務要件 2-3 調査対象エントリの削除 ※ 業務要件 1-3 に同じ。 登録済みで、処理待ちとなっている調査対象エントリを削除（キャンセル）する。 【要件】 システム運用者が、登録済みで、処理待ちとなっている調査対象エントリの一覧を参照 し、任意の調査対象エントリを削除できること（処理待ちとなっている状態から調査を キャンセルできること） 。 22 2.2.4.4. 業務要件 2-4 次回巡回待ち調査対象エントリの参照 次回巡回待ちとなっている調査対象エントリを参照する。 【要件】 システム運用者が、次回巡回待ちとなっている調査対象エントリの一覧を参照し、任意 の調査対象エントリの内容を参照できること。 2.2.4.5. 業務要件 2-5 次回巡回待ち調査対象エントリの削除 次回巡回待ちとなっている調査対象エントリを削除する。 【要件】 システム運用者が、次回巡回待ちとなっている調査対象エントリの一覧を参照し、任意 の調査対象エントリを削除できること。 一旦、巡回調査の対象から外して、再度登録しなおすといった業務が発生することを考 慮すること。 2.2.4.6. 業務要件 2-6 調査結果レポートの参照 ※ 業務要件 1-6 に同じ。 調査結果レポートを参照する。 【要件】 システム運用者が、自身が登録した調査対象エントリに対応する調査結果レポートを、 複数存在する調査結果レポートの中から特定できること。 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートの内容 を参照できること。 2.2.4.7. 業務要件 2-7 調査結果レポートの取得 ※ 業務要件 1-7 に同じ。 調査結果レポートを運用 PC へ取得する。 【要件】 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートの内容 を、運用 PC へ取得できること。 取得においては、多数の調査結果レポートをまとめて取得することを考慮した方式とす ること。 取得における実装方式は、Windows ファイル共有によるファイルコピー、HTTP や FTP によるダウンロードなどを想定している。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.4.8. 業務要件 2-8 調査結果レポートの削除 ※ 業務要件 1-8 に同じ。 調査結果レポートを削除する。 23 調査結果レポートの情報は、後述する日次レポートの元データとなることを想定している。 このため、日次レポートの結果への影響を避けるため、本作業は原則として実施しないが、要 件としては挙げている。 【要件】 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートを削除 できること。 調査結果レポートを削除した結果、日次レポートへの影響は、削除された調査結果レポ ートの内容の範囲に留まること（日次レポート全体に異常が生じないようにすること） 。 なお、既に日次レポートへの集計処理が終わった調査結果レポートを削除した場合 において、日次レポートを再作成する必要はない。 2.2.4.9. 業務要件 2-9 攻撃サイトリストの参照 ※ 業務要件 1-9 に同じ。 現時点で判明している攻撃サイトのリストを参照する。 【要件】 システム運用者が、現時点の（最新版の）攻撃サイトリストを参照できること。 2.2.4.10. 業務要件 2-10 攻撃サイトリストの取得 ※ 業務要件 1-10 に同じ。 現時点及び過去時点の攻撃サイトのリストを運用 PC へ取得する。 【要件】 システム運用者が、現時点及び過去時点の攻撃サイトリストのうち、任意の攻撃サイト リストの内容を、運用 PC へ取得できること。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.5. 業務要件 3 ゼロデイ攻撃調査 システム運用者が個別のウェブサイトについて、ゼロデイ攻撃が発生するか否かを焦点とし た調査を行う。 調査の指示は調査対象エントリの登録という形で行い、調査結果の確認は調査結果レポート 及び攻撃サイトリストの参照という形で行う。 この調査の指示は、業務要件 2 の「ウェブサイト巡回調査」の処理対象よりも優先して（巡 回調査に割り込む形で）処理される必要がある。 SPICA における「ゼロデイ攻撃判定」とは、次の内容を指す。 高対話型クローラを使い、OS とアプリケーションに全てのパッチを適用した状態で、 指定したウェブサイトを開く。OS 別に複数の仮想マシンイメージを用意し、順番にこ れを実施する。 システム運用者が調査結果レポートを参照して、ウェブサイトからの攻撃が成立し、ウ イルス等への感染が発生したか否かを確認する。 SPICA における「ゼロデイ攻撃判定」は、自動化可能な範囲で実装する簡易なものであり、 完全な判定は求めない。例えば、次のケースでは、仮にウェブサイトにゼロデイ攻撃用のコン 24 テンツが設置されていたとしても、この判定の方式では検知できない可能性がある。 ゼロデイ攻撃判定用の仮想マシンイメージに、ゼロデイ攻撃で悪用されるアプリケーシ ョンが搭載されておらず、攻撃が成立しなかった場合。 ゼロデイ攻撃判定用の仮想マシンイメージに搭載されていた OS やアプリケーションの エディションやバージョンが、ゼロデイ攻撃で悪用される対象と異なり、攻撃が成立し なかった場合。 攻撃サイト側に何らかの仕掛けが施され、調査を行ったタイミングでは攻撃用のコンテ ンツがダウンロードされず、攻撃が成立しなかった場合。 2.2.5.1. 業務要件 3-1 調査対象エントリの登録 ※ 業務要件 1-1 に同じ。 新たな調査対象エントリを登録する。 【要件】 システム運用者が、調査対象エントリを新たに作成し、登録できること。 2.2.5.2. 業務要件 3-2 調査対象エントリの参照 ※ 業務要件 1-2 に同じ。 登録済みで、処理待ちとなっている調査対象エントリを参照する。 【要件】 システム運用者が、登録済みで、処理待ちとなっている調査対象エントリの一覧を参照 し、任意の調査対象エントリの内容を参照できること。 2.2.5.3. 業務要件 3-3 調査対象エントリの削除 ※ 業務要件 1-3 に同じ。 登録済みで、処理待ちとなっている調査対象エントリを削除（キャンセル）する。 【要件】 システム運用者が、登録済みで、処理待ちとなっている調査対象エントリの一覧を参照 し、任意の調査対象エントリを削除できること（処理待ちとなっている状態から調査を キャンセルできること） 。 2.2.5.4. 業務要件 3-4 処理済み調査対象エントリの参照 ※ 業務要件 1-4 に同じ。 処理済みとして保管してある調査対象エントリを参照する。 【要件】 システム運用者が、処理済みとなっている調査対象エントリの一覧を参照し、任意の調 査対象エントリの内容を参照できること。 日を置いて同じウェブサイトを再調査する場合など、処理済み調査対象エントリを、調 査対象エントリとして再利用を行う場合があることを考慮すること。 25 2.2.5.5. 業務要件 3-5 処理済み調査対象エントリの削除 ※ 業務要件 1-5 に同じ。 処理済みとして保管してある調査対象エントリを削除する。 【要件】 システム運用者が、処理済みとなっている調査対象エントリの一覧を参照し、任意の調 査対象エントリを削除できること。 2.2.5.6. 業務要件 3-6 調査結果レポートの参照 調査結果レポートを参照する。 【要件】 システム運用者が、自身が登録した調査対象エントリに対応する調査結果レポートを、 複数存在する調査結果レポートの中から特定できること。 ゼロデイ攻撃調査においては、内部で複数回（仮想マシンの種類ごと）の調査とな るため、複数の調査結果レポートとなってもよい（設計による）。詳細は要件定義も しくは基本設計の段階で定める。 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートの内容 を参照できること。 2.2.5.7. 業務要件 3-7 調査結果レポートの取得 ※ 業務要件 1-7 に同じ。 調査結果レポートを運用 PC へ取得する。 【要件】 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートの内容 を、運用 PC へ取得できること。 取得においては、多数の調査結果レポートをまとめて取得することを考慮した方式とす ること。 取得における実装方式は、Windows ファイル共有によるファイルコピー、HTTP や FTP によるダウンロードなどを想定している。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.5.8. 業務要件 3-8 調査結果レポートの削除 ※ 業務要件 1-8 に同じ。 調査結果レポートを削除する。 調査結果レポートの情報は、後述する日次レポートの元データとなることを想定している。 このため、日次レポートの結果への影響を避けるため、本作業は原則として実施しないが、要 件としては挙げている。 【要件】 システム運用者が、調査結果レポートの一覧を参照し、任意の調査結果レポートを削除 できること。 調査結果レポートを削除した結果、日次レポートへの影響は、削除された調査結果レポ ートの内容の範囲に留まること（日次レポート全体に異常が生じないようにすること） 。 26 なお、既に日次レポートへの集計処理が終わった調査結果レポートを削除した場合 において、日次レポートを再作成する必要はない。 2.2.5.9. 業務要件 3-9 攻撃サイトリストの参照 ※ 業務要件 1-9 に同じ。 現時点で判明している攻撃サイトのリストを参照する。 【要件】 システム運用者が、現時点の（最新版の）攻撃サイトリストを参照できること。 2.2.5.10. 業務要件 3-10 攻撃サイトリストの取得 ※ 業務要件 1-10 に同じ。 現時点及び過去時点の攻撃サイトのリストを運用 PC へ取得する。 【要件】 システム運用者が、現時点及び過去時点の攻撃サイトリストのうち、任意の攻撃サイト リストの内容を、運用 PC へ取得できること。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.6. 業務要件 4 統計レポート参照 システム運用者が SPICA による調査処理の統計レポートを参照する。 統計レポートは日次と月次の二種類について、SPICA 内で自動的に集計・生成を行う。 2.2.6.1. 業務要件 4-1 日次レポートの参照 SPICA による調査処理の日次レポートを参照する。 【要件】 システム運用者が、日次レポートの一覧を参照し、任意の日次レポートの内容を参照で きること。 2.2.6.2. 業務要件 4-2 日次レポートの取得 SPICA による調査処理の日次レポートを運用 PC へ取得する。 【要件】 システム運用者が、日次レポートの一覧を参照し、任意の日次レポートの内容を、運用 PC へ取得できること。 取得においては、多数の日次レポートをまとめて取得することを考慮した方式とするこ と。 取得における実装方式は、Windows ファイル共有によるファイルコピー、HTTP や FTP によるダウンロードなどを想定している。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 27 してある圧縮形式等で構わない。 2.2.6.3. 業務要件 4-3 日次レポートの削除 SPICA による調査処理の日次レポートを削除する。 日次レポートの情報は、後述する月次レポートの元データとなることを想定している。この ため、月次レポートの結果への影響を避けるため、本作業は原則として実施しないが、要件と しては挙げている。 【要件】 システム運用者が、日次レポートの一覧を参照し、任意の日次レポートを削除できるこ と。 日次レポートを削除した結果、月次レポートへの影響は、削除された日次レポートの内 容の範囲に留まること（月次レポート全体に異常が生じないようにすること）。 なお、既に月次レポートへの集計処理が終わった日次レポートを削除した場合にお いて、月次レポートを再作成する必要はない。 2.2.6.4. 業務要件 4-4 月次レポートの参照 SPICA による調査処理の月次レポートを参照する。 【要件】 システム運用者が、月次レポートの一覧を参照し、任意の月次レポートの内容を参照で きること。 2.2.6.5. 業務要件 4-5 月次レポートの取得 SPICA による調査処理の月次レポートを運用 PC へ取得する。 【要件】 システム運用者が、月次レポートの一覧を参照し、任意の月次レポートの内容を、運用 PC へ取得できること。 取得においては、多数の月次レポートをまとめて取得することを考慮した方式とするこ と。 取得における実装方式は、Windows ファイル共有によるファイルコピー、HTTP や FTP によるダウンロードなどを想定している。 一定期間より過去時点のものについては、サーバ上でアーカイブデータとして保存 してある圧縮形式等で構わない。 2.2.6.6. 業務要件 4-6 月次レポートの削除 SPICA による調査処理の月次レポートを削除する。 月次レポートの情報は、十分な期間（10 年分）を保持可能なだけの記録領域を確保し、原 則として削除は行わない運用を想定している。 【要件】 システム運用者が、月次レポートの一覧を参照し、任意の月次レポートを削除できるこ と。 28 2.2.7. 業務要件 5 巡回調査スケジュール設定 システム運用者がウェブサイト巡回調査の運用スケジュールを設定する。 2.2.7.1. 業務要件 5-1 巡回調査実行時間設定 ウェブサイト巡回調査処理を実行する曜日及び時間のスケジュールを設定する。 「ウェブサイト巡回調査処理を実行する」とは、具体的には次の処理を指す。 ウェブサイト巡回調査用として登録された調査対象エントリの情報をもとに、URL のリ ストを作成する処理。 URL のリストをもとに、巡回用クローラで各 URL を調査する処理。 ウェブサイト巡回調査が実行されることを許可する時間帯を「巡回調査実行時間」と呼び、 許可しない時間帯を「巡回調査停止時間」と呼ぶ。 なお、ここで設定したスケジュールについて、厳密な制御は求めない。SPICA では、処理の 単位を調査対象エントリとすることを想定しているため、例えば巡回調査実行時間内に開始し た調査対象エントリの処理が終わるまでは、巡回調査停止時間に入っても、処理が継続するこ とは許容する。 【要件】 システム運用者が、現在の巡回調査処理のスケジュール内容を確認し、設定変更できる こと。 スケジュールの設定として、各曜日ごとに、尐なくとも 30 分単位で、巡回調査実行時 間が指定できること（それ以外の時間帯は巡回調査停止時間となる） 。 例えば、次のような設定が行えること。 月曜～水曜 09:30～18:30 木曜 10:00～12:30、13:30～18:00 金曜 22:00～24:00 土曜 00:00～02:00（※金曜の 22:00～土曜の 02:00 という設定意図） 日曜 なし 2.2.7.2. 業務要件 5-2 巡回調査例外日設定 巡回調査処理を実行しない日を設定する。 この設定は、巡回調査実行時間の設定に優先する。 業務要件 5-1 で各曜日の設定を行った上で、祝日に巡回調査を停止させるために設定を行う ことを想定している。 【要件】 システム運用者が、現在の巡回調査例外日の設定内容を確認し、設定変更できること。 巡回調査例外日の設定として、年月日による指定が可能であること。また、複数の巡回 調査例外日を設定可能であること。 （例）2011 年 1 月 1 日、2011 年 1 月 10 日、2011 年 2 月 11 日、… 巡回調査実行時間であっても、ここで設定された日にはウェブサイト巡回調査処理を実 行しないこと。 29 2.2.8. 業務要件 6 外部接続用ルータ電源操作 システム運用者が外部接続用ルータの電源操作を必要に応じて行う。 SPICA から外部インターネットへの接続には、 一般的な ISP の回線を用途別に複数使用する。 接続においては PPPoE ルータ（ブロードバンドルータ）を設置し、更にその電源を電源制御装 置でリモートからオン／オフ可能とする構成を想定している。 システム運用者による実際の操作イメージとしては、例えば運用端末経由で SPICA 管理サー バへアクセスし、CUI の電源状態参照コマンドや電源開始・停止・再起動コマンド等を入力し、 出力された結果を目視確認するといった運用を想定している。 この業務要件の目的は、主に次の三点である。 「ガンブラー」型攻撃の手口の中で、同一の IP アドレスから複数回アクセスがあった 場合に、攻撃サイトが無害なふりをするというものがあった。システム運用者は、クロ ーラ等による調査処理が行われていないタイミングで、定期的に PPPoE ルータのリセッ トを行い、ISP から与えられる IP アドレスを変更することで、この手口による検知率 低下の影響を緩和する。 SPICA から外部インターネットに対し、望ましくない、もしくは想定外の通信が発生し ていることが判明した際に、最初に行う最も単純な停止手段として、PPPoE ルータの電 源オフを行う。 巡回調査停止時間など、明らかに通信を行う必要性の無い時間帯について、SPICA から 想定外の通信が発生しないよう、PPPoE ルータの電源をオフとしておく。 2.2.8.1. 業務要件 6-1 外部接続用ルータ電源状態参照 外部接続用ルータへの電源供給状態を参照する。 【要件】 システム運用者が、SPICA 内に存在する外部接続用の各ルータの電源供給状態（オン／ オフ）を確認できること。 2.2.8.2. 業務要件 6-2 外部接続用ルータ電源開始 外部接続用ルータへの電源供給を開始する。 【要件】 システム運用者が、SPICA 内に存在する任意の外部接続用ルータの電源供給を開始でき ること。 システム運用者が、一回の指示で SPICA 内に存在する全て（当初は 3 台）の外部接続用 ルータの電源供給を開始できること。 2.2.8.3. 業務要件 6-3 外部接続用ルータ電源停止 外部接続用ルータへの電源供給を停止する。 【要件】 システム運用者が、SPICA 内に存在する任意の外部接続用ルータの電源供給を停止でき ること。 システム運用者が、一回の指示で SPICA 内に存在する全て（当初は 3 台）の外部接続用 ルータの電源供給を停止できること。 30 2.2.8.4. 業務要件 6-4 外部接続用ルータ再起動 外部接続用ルータへの電源供給を停止・開始して再起動する。 【要件】 システム運用者が、SPICA 内に存在する任意の外部接続用ルータを再起動できること。 システム運用者が、一回の指示で SPICA 内に存在する全て（当初は 3 台）の外部接続用 ルータを再起動できること。 2.2.9. 業務要件 7 ウイルス検体操作 システム運用者がウイルス検体の取り出し等を必要に応じて行う。 2.2.9.1. 業務要件 7-1 ウイルス検体の取得 ウイルス検体を運用 PC へ取得する。 【要件】 システム運用者が、SPICA 内に保持されているウイルス検体の一覧を参照し、任意のウ イルス検体を、運用 PC へ取得できること。 ウイルス検体の取得においては、圧縮や暗号化されていない生のファイルと、パスワー ド付き zip 形式のファイルが選択できること。 zip ファイルに設定するパスワードについては、単一のものをシステムの設定値とし て設定できること（検体ごとに異なるパスワードを付ける必要はない）。 zip ファイルとするにあたり、ひとつの検体につきひとつの zip ファイルとすること （複数の検体をまとめないこと）。 取得においては、多数のウイルス検体をまとめて取得することを考慮した方式とするこ と。 取得における実装方式は、Windows ファイル共有によるファイルコピー、HTTP や FTP によるダウンロードなどを想定している。 2.2.9.2. 業務要件 7-2 ウイルス検体の削除 ウイルス検体を削除する。 【要件】 システム運用者が、SPICA 内に保持されているウイルス検体の一覧を参照し、任意のウ イルス検体を削除できること。 2.2.10. 業務要件 8 システム監視 システム運用者が SPICA を構成するサーバ等の状態確認を随時行う。 なお、SPICA の業務機能の稼動状況の確認は、ウェブサイト巡回調査の調査結果レポートが 滞りなく出力されていることを、システム運用者が随時確認を行うことを想定している。 31 2.2.10.1. 業務要件 8-1 サーバ死活監視 SPICA を構成する各サーバの死活監視を行う。 死活状況については、システム運用者が運用端末で随時確認できること。 【要件】 SPICA 管理またはシステム運用者用の運用端末から、SPICA を構成する各サーバの死活 監視が行えること。 2.2.11. 業務要件 9 システム運用管理 システム運用者が SPICA のシステム運用管理作業を必要に応じて行う。 2.2.11.1. 業務要件 9-1 システム起動 SPICA を構成する機能全体の起動を行う。 【要件】 システム運用者が、手順書に従い、SPICA を構成する機能全体の起動（電源オンからの 作業を含む）が行えること。 起動後、SPICA の各機能の正常動作確認が行えること。 2.2.11.2. 業務要件 9-2 システム停止 SPICA を構成する機能全体の停止を行う。 【要件】 システム運用者が、手順書に従い、SPICA を構成する機能全体の停止（電源オフまでの 作業を含む）が行えること。 システム停止は次の二種類のケースを想定している。 計画停止：システム停止のために必要十分な時間（仕掛り中の処理の完了を待つ時 間）を確保した上で実施する。この場合、次に SPICA の機能を起動した際、停止に よる影響は、 （停止していた期間は調査が行われないという点を除き）原則として発 生しないものとする。 強制停止：緊急の場合や、障害が発生した場合など、仕掛り中の処理等に関わらず 実施する停止作業。できる限り計画停止の手順に沿って停止を行うが、プログラム の正常終了を待たずに強制終了したり、ハングアップしたプロセスやサーバを強制 停止する場合が考えられる。これらの場合においても、停止による影響や、次に SPICA の機能を起動した際の復旧作業等をできるだけ尐なくするよう考慮すること。 2.2.11.3. 業務要件 9-3 ウェブサイト調査一時停止 業務要件 1,2,3 の調査処理を一時停止する。 この指定は、巡回調査実行時間の設定に優先する。 システム停止（計画停止）や、外部接続用ルータ再起動、クローラ仮想マシンイメージメン テナンス等を行う中での事前作業として、ウェブサイト調査の機能と各種運用・保守作業との 衝突を回避するために実施することを想定している。この目的が達成できるのであれば、下記 要件に厳密に従う必要はない。 32 【要件】 システム運用者が、ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査それ ぞれについて、調査処理を停止できること。 一時停止とは、具体的には次の内容に相当する処理を想定している。 仕掛り中の調査対象エントリに関する調査処理は、完了するまで継続してもよい。 新たな調査対象エントリの処理は開始しない。 巡回調査実行時間として設定されている時間内であっても、こちらの指定を優先させ、 調査処理を停止すること。 2.2.11.4. 業務要件 9-4 ウェブサイト調査一時停止解除 業務要件 9-3 で行った一時停止措置を解除する。 システム起動作業の最終ステップとしての作業や、外部接続用ルータ再起動、クローラ仮想 マシンイメージメンテナンス等を行った後に実施することを想定している。 【要件】 システム運用者が、業務要件 9-3 で行った一時停止措置を解除できること。 2.2.11.5. 業務要件 9-5 クローラ仮想マシンイメージメンテナンス 巡回用クローラ、ゼロデイ攻撃判定用クローラで使用する仮想マシンの OS やアプリケーシ ョンの構成を変更する。 巡回用クローラについては、頻繁に脆弱性が悪用される OS の機能やアプリケーションが新 たに顕在化した場合において、OS の設定変更やアプリケーションの追加インストール、ある いはバージョンの置き換えを行うことを想定している。 ゼロデイ攻撃判定用クローラについては、仮想マシン上の OS とアプリケーションが常に最 新の状態である必要があるため、修正プログラムの公開と共にその適用を随時行っていくこと を想定している。 【要件】 システム運用者が、巡回用クローラとゼロデイ攻撃判定用クローラで使用している仮想 マシンを直接操作し、OS の設定変更、アプリケーションの追加と削除、修正プログラ ムの適用等の作業が可能であること。 本機能の初期構築時の仮想マシンイメージ、及び最低限過去二世代分の仮想マシンイメ ージのコピーをサーバ上に保持できること。また、万が一の場合に過去のイメージへ巻 き戻せること。 仮想マシン用のファイル群をローカルファイルシステム内でコピーする程度の運用 を想定している。 2.2.11.6. 業務要件 9-6 プロキシアクセス制御設定 特定のドメイン名等に対してアクセス制御を行う。 巡回用クローラとゼロデイ攻撃判定用クローラでは、調査に使用する仮想マシンからの全て のウェブアクセスについて、SPICA 内のプロキシを経由させる。 この業務要件は、例えば特定のウェブサイトへ HTTP を使った攻撃を行うことが明白なウイ ルス等が流行している状況下において、本機能が同じように攻撃を行ってしまうことを防ぐた め、当該ウェブサイトのドメイン名や URL を指定し、プロキシでアクセスをブロックするとい った用途を想定している。 33 【要件】 システム運用者が、巡回用クローラとゼロデイ攻撃判定用クローラからのウェブアクセ スについて、ドメイン名や URL の指定でアクセスを禁止する設定が行えること。 2.2.11.7. 業務要件 9-7 バックアップ バックアップサーバへ仮想マシンイメージ、調査結果に関するデータ、ウイルス検体、ログ 等のファイルバックアップを行う。 SPICA におけるバックアップの考え方を次に示す。 障害等に備えるデータバックアップは、原則としてバックアップサーバへのファイルコ ピー（データのミラー）により行う。 サーバ自体のシステムバックアップは行わない。サーバ故障等からの復旧は、該当サー バの再構築にて行う。 各種設定ファイル、仮想マシンイメージ、データベースを使用する場合はデータベース 上のデータなど、開発／構築時点から内容が変化するもので、サーバ障害からの復旧を 迅速に行うために必要なデータ（以下、システムデータと呼ぶ）は、該当データの変更 作業に併せて、または随時自動的に変化するものについては定期的に、システム運用者 や保守作業者がバックアップサーバへのバックアップを行う。 調査結果に関するデータ（調査結果レポート、攻撃サイトリスト、日次レポート、月次 レポート） 、ウイルス検体、システム上重要なログ等については、必要に応じてシステ ム管理者が定期的にバックアップサーバへのバックアップを行い、最終的には運用 PC にて DVD-R 等へ保存する（バックアップサーバは永久的な保存先ではない） 。 各種処理上の一時データ、キャッシュ、調査データ（機能要件 3-7 及び 4-7「調査結果 横断解析」で保存している過去の調査に関するデータ）、及び各種ログファイルについ ては、失われてもシステムの動作には問題がないため、バックアップは行わない。 【要件】 システムデータについて、システム運用者による手動、もしくは自動処理にて、バック アップサーバへバックアップコピーを行えること。 34 2.3. 情報システムの機能等に関する要件 2.3.1. 機能要件 2.3.1.1. 機能構成 本追加機能で想定している機能構成を「図 2-2 機能構成図」に示す。 図 2-2 機能構成図 上記機能構成図におけるポイントを次に示す。 インターネットへの接続に際しては、一般利用者と同じ ISP の回線を使用し、PPPoE ル ータ（いわゆるブロードバンドルータ）にて接続する。回線は用途別に複数用意し、電 源制御装置で電源のオン・オフを行うことで、グローバル IP アドレスの付け替えや、 緊急時の外部への通信停止を行う。 クローラサーバは、性質上、サーバ上の仮想マシンがウイルスに感染するため、ファイ アウォールで隔離したエリアに設置する。 クローラサーバからのインターネットへの危害行為のリスクを低減するため、外部への アクセスは、ファイアウォールだけでなく、プロキシサーバを経由させる。これにより、 http/https プロトコル以外の通信（例えばスパムメール送信など）を遮断する。 図中の各機能の概要を「表 2-10 機能概要一覧」に示す。なお、各機能の機能要件の表中の 「番号」は、機能要件番号を示す。以降「機能要件 1-1」などと参照する場合がある。 35 表 2-10 機能概要一覧 番号 1 機能 SPICA 管理 2 URL リスト作成機能 3 巡回用クローラ 4 ゼロデイ攻撃判定用クローラ 5 検証用クローラ 6 7 フォワードプロキシ PPPoE ルータ 8 9 電源制御装置 バックアップサーバ 概要 クローラで調査した結果レポートや、捕獲したウイルス検体を保管する。 その他、システム運用関連の機能を備える。 調査／巡回対象とするウェブサイトを構成する URL のリストを作成し、 クローラへ調査指示を行う。 ウェブサイト調査、ウェブサイト巡回調査の処理に使用する。脆弱な仮 想マシンを操作し、URL リストのウェブページを調査することで、攻撃の 検知やウイルス検体の捕獲を行う。 ゼロデイ攻撃調査の処理に使用する。脆弱性を解消した複数種類の仮想 マシンを操作し、URL リストのウェブページを調査して、攻撃の成立有無 を判定する。 巡回用クローラとゼロデイ攻撃判定用クローラの機能を同居させたテス ト環境。障害時の再現調査、パッチ適用・機能強化時の動作確認、クロ ーラサーバ障害時のハードウェア予備機として使用する。 クローラがインターネットへ接続する際に経由するプロキシサーバ。 インターネットとの接続に使用する、一般的な PPPoE 機能を備えるルー タ。 PPPoE ルータの遠隔電源制御を行う装置。 仮想マシンイメージ、調査結果に関するデータ、ウイルス検体、ログ等 をミラーとして保持する。 2.3.1.2. 機能要件 1 SPICA 管理 クローラで調査した結果レポートや、捕獲したウイルス検体を保管する。その他、システム 運用関連の機能を備える。 表 2-11 SPICA 管理 機能要件 番号 1-1 機能 調査結果レポート管理 1-2 攻撃サイトリスト管理 1-3 攻撃サイト差分チェック 1-4 攻撃サイト追加時処理 要件 調査結果レポートを保管すること。 業務要件から導きだされる、調査結果レポートに関する操作が行え ること。 調査結果レポートは、必要に応じて圧縮などを行い、過去 90 日分を 保持すること（保持日数は設定により変更可能であること） 。 攻撃サイトリストを保管すること。 業務要件から導きだされる、攻撃サイトリストに関する操作が行え ること。 攻撃サイトリストは、必要に応じて圧縮などを行い、過去 90 日分を 保持すること（保持日数は設定により変更可能であること） 。 攻撃サイトリストを更新する際、リストに加わった URL（新たに発 見された攻撃サイト）を抽出し、別途 1 行 1URL とした一時ファイル へ出力すること。 その後、出力した一時ファイルのパスを引数として、特定のコマン ド（スクリプト）を実行すること。このコマンドは、機能要件 1-4 「攻撃サイト追加時処理」である。 この機能は、新たに発見された攻撃サイトを何らかの方法でシステ ム運用者へ通知するための拡張機能の実装地点を確保するために存 在する。この処理は、将来的に実装を入れ替える可能性がある。 引数で与えられたファイルについて、その行数とファイルの内容 （URL のリスト）を、特定のログファイルへ出力すること。 36 番号 1-5 機能 日次レポート管理 1-6 月次レポート管理 1-7 巡回調査スケジュール管理 1-8 ルータ電源管理 1-9 ウイルス検体管理 1-10 サーバ状態監視 1-11 ウイルス検体外部連携 1-12 調査機能一時停止管理 要件 「2.2.2.4 日次レポート」の要件に従い、各日分の集計処理を行う こと。 日次レポートを保管すること。 業務要件から導きだされる、日次レポートに関する操作が行えるこ と。 日次レポートは、圧縮などを行い、過去 1 年分を保持すること（保 持日数は設定により変更可能であること） 。 「2.2.2.5 月次レポート」の要件に従い、各月分の集計処理を行う こと。 月次レポートを保管すること。 業務要件から導きだされる、月次レポートに関する操作が行えるこ と。 月次レポートは、圧縮などを行い、削除は行わずに過去分を全て保 持すること（最大で過去 10 年分が保管できること） 業務要件から導きだされる、巡回調査実行時間や巡回調査例外日に 関する操作が行えること。 巡回調査停止時間においては、新たな処理に着手しないよう、URL リスト作成機能、巡回用クローラ、ゼロデイ攻撃判定用クローラの 動作を抑制すること。 業務要件から導きだされる、外部接続用ルータに関する操作が行え ること。 この操作はシステム運用者による手動実施に限らず、何らかの自動 処理に組み込まれることを想定すること。例えば、コマンドの実行 など、システム上単純な実行方法を用意したり、実行結果（電源状 態情報、電源制御における成功／エラー等の結果）について、シス テム運用者が理解できると同時に、機械処理に向く形式で出力を行 うこと。 （必要に応じて、巡回調査スケジュール管理の機能と合わせ、タス クスケジューラや cron によってルータの再起動を定期自動実行す ることを想定している） クローラで捕獲したウイルス検体を保管すること。 業務要件から導きだされる、ウイルス検体に関する操作が行えるこ と。 SPICA を構成するサーバや機器について、OS レベル（例えば ping） での死活監視を行い、その情報をシステム運用者が適宜参照可能で あること。なお、クローラサーバ上の仮想マシンは対象外とする。 本機能についての詳細は、監視対象にできる範囲／できない範囲を 含め、機能設計の方針を考慮した上で、要件定義もしくは基本設計 の段階にて、改めて当機構と協議の上で定める。 クローラで捕獲したウイルス検体について、新たに追加されたもの のうち、実行ファイルについて SPICA 外部へ連携（FTP PUT）できる こと。 実行ファイルか否かの判定は、Windows PE 形式のヘッダ（マジック ナンバー）の有無の確認程度を想定している（判定誤差により PE 形式以外のファイルが連携されても問題はない） 。 連携するファイルは、業務要件 7-1 で設定するものと同じパスワー ドの zip 形式とし、1 検体 1 ファイルとすること。 この機能は有効・無効（動作させる・させない）をシステム運用者 によって変更可能であること。 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査に係 る処理の一時停止及び再開ができること。 一時停止中は、新たな処理に着手しないよう、URL リスト作成機能、 巡回用クローラ、ゼロデイ攻撃判定用クローラの動作を抑制するこ と。 2.3.1.3. 機能要件 2 URL リスト作成機能 調査／巡回対象とするウェブサイトを構成する URL のリストを作成し、クローラへ調査指示 37 を行う。 本書では、機能 2-1「調査対象エントリの管理」は、本「URL リスト作成機能」に属し、こ こでシステム運用者が調査対象エントリを登録・参照・削除を行うこととしているが、設計に よりこの機能は「SPICA 管理」へと一元化してもよい。 表 2-12 URL リスト作成機能 機能要件 番号 2-1 機能 調査対象エントリ管理 2-2 URL 収集 2-3 クローラ調査指示 2-4 巡回調査スケジュール対応 2-5 機能一時停止 2-6 機能単体実行 要件 ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査、そ れぞれの調査を行うための調査対象エントリについて、業務要件か ら導きだされる操作が行えること。 調査対象エントリに含まれる優先度の情報を参照し、優先度の高い ものから順番に URL 収集の処理に回すこと。 処理が完了した調査対象エントリ（巡回調査用を除く）は、処理済 み調査対象エントリとして保管すること。 巡回調査用の調査対象エントリは、次回巡回待ち調査対象エントリ として保管し、繰り返し調査対象エントリとして再登録されること。 調査対象エントリ内の情報をもとに、基点 URL 及びそこからのリン ク先のウェブページを取得し、クローラでの調査対象とする URL の リストを作成できること。 この処理においては、PPPoE ルータ#3 を経由した回線（URL リスト 作成用回線）を使用すること。 作成した URL リストを、ウェブサイト調査とウェブサイト巡回調査 の場合は巡回用クローラへ、ゼロデイ攻撃調査の場合はゼロデイ攻 撃判定用クローラへ、調査指示として送信すること。 機能要件 1-7「巡回調査スケジュール管理」により、SPICA 管理機能 から巡回調査停止時間の指示が出ている場合は、巡回調査用の調査 対象エントリに対する新たな処理は開始しないこと。 機能要件 1-12「調査機能一時停止管理」により、SPICA 管理機能か ら調査機能一時停止の指示が出ている場合は、対応する調査（ウェ ブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査）の調査 対象エントリに対する新たな処理は開始しないこと。 URL 収集のテストや、機能要件 5 の検証用クローラへ投入するデー タ（URL リスト）作成のため、システム運用者が直接、調査対象エ ントリ相当の情報を入力することで、クローラへ調査指示を行うた めの URL リスト相当の情報を出力できること。 2.3.1.4. 機能要件 3 巡回用クローラ ウェブサイト調査、ウェブサイト巡回調査の処理に使用する。脆弱な仮想マシンを操作し、 URL リストのウェブページを調査することで、攻撃の検知やウイルス検体の捕獲を行う。 表 2-13 巡回用クローラ 機能要件 番号 3-1 機能 URL リスト管理 3-2 巡回用仮想マシン管理 要件 URL リスト作成機能から調査指示として送信された、ウェブサイト 調査用、ウェブサイト巡回調査用の URL リストについて、優先度に 従って調査処理を順次実行すること。 複数の物理サーバ上に設置する複数の仮想マシンを動作させ、ウェ ブサイト（URL リスト内の URL）を並列／分散調査できること。 調査処理においては、フォワードプロキシを経由し、PPPoE ルータ #1 を経由した回線（巡回用回線）を使用すること。 仮想マシンを定期的にクリーンな状態への巻き戻しを行う機能を備 えること。 38 番号 3-3 機能 攻撃検知 3-4 ウイルス検体捕獲 3-5 ウイルス振る舞い検知 3-6 調査結果レポート出力 3-7 調査結果横断解析 3-8 調査完了処理 3-9 巡回調査スケジュール対応 3-10 機能一時停止 2.3.1.4.1. 要件 仮想マシンでウェブサイトへアクセスした際に、脆弱性を突く攻撃 が発生したことを検知できること。 攻撃がゼロデイ攻撃であっても検知できること。 「2.6.2.2 クローラ仮想マシン ソフトウェア構成」に示す「巡回用 仮想マシン」の構成にある各アプリケーションの脆弱性を突く攻撃 の検知に対応できること。また、アプリケーションのバージョンの 変化やアプリケーションの追加への対応を考慮すること。 本機能要件については、完全であること（例えば、検知率が 100%で あること等）は求めないが、SPICA の目的に沿い、本機能要件を十 分に達成できる裏付けを提案書の中で示すこと（詳しくは2.3.1.4.1 を参照すること） 。 攻撃を検知した際、仮想マシンにて攻撃コード（Exploit）や感染さ せられるウイルスについて、可能な限り捕獲すること（詳しくは 2.3.1.4.2を参照すること） 。 攻撃によりウイルスに感染した後、仮想マシンから SPICA 内部の他 機能及びインターネットへの不審な通信や危害行為（DoS 攻撃、ス パムメール配信等）が発生した際に、それを検知する機能を備える こと。 これらの振る舞いを検知した際に、その動作を停止させる機能を備 えること。また、動作を停止させる機能は、システム管理者が有効・ 無効を設定変更できること。 本機能要件については、完全であること（例えば、検知及び停止率 が 100%であること等）は求めないが、極力安全性を確保するため、 本機能要件を十分に達成できる裏付けを提案書の中で示すこと（詳 しくは2.3.1.4.3を参照すること） 。 実際に調査を行った URL の一覧と、攻撃の発生有無を含む調査結果 レポートを出力すること。 調査結果レポートは SPICA 管理へ送信すること。 過去 n 日分（設定可能とする）の調査データを保持し、その調査デ ータをもとに、攻撃サイトリストを作成し、出力すること。 複数のウェブサイトをリダイレクトさせたり、同一の IP アドレスか らの二回目以降のアクセスに対しては無害なふりをする攻撃サイト について、可能な限り検出すること（詳しくは2.3.1.4.4を参照する こと） 。 攻撃サイトリストは SPICA 管理へ送信すること。 横断解析を行うデータの対象として、ゼロデイ攻撃判定用クローラ で蓄積した情報を含めることが望ましいが、必須ではない。機能設 計の方針を考慮した上で、要件定義もしくは基本設計の段階にて、 改めて当機構と協議の上で仕様を定める。 機能要件 3-6 及び 3-7 の処理が全て完了した後、出力した調査結果 レポートの名称（ファイル名など、特定できる情報）を引数として、 特定のコマンド（またはスクリプト）を実行すること。 実行するコマンドは、調査の完了をシステム運用者へ通知するため の拡張機能の実装地点を確保するために存在するもので、当面は何 も処理を行わないダミーのコマンドを設置する。 機能要件 1-7「巡回調査スケジュール管理」により、SPICA 管理機能 から巡回調査停止時間の指示が出ている場合は、巡回調査用の調査 対象エントリに対する新たな処理は開始しないこと。 機能要件 1-12「調査機能一時停止管理」により、SPICA 管理機能か ら調査機能一時停止の指示が出ている場合は、対応する調査（ウェ ブサイト調査、ウェブサイト巡回調査）の調査対象エントリに対す る新たな処理は開始しないこと。 機能要件 3-3「攻撃検知」に関する補足 機能要件 3-3「攻撃検知」については、提案する実装が要件を十分に達成できることを、 次の観点について、提案書の中で説明すること。 39 脆弱性を突く攻撃の検知 脆弱性を突く攻撃を検知する方式について、要件を十分に達成できることを説 明する根拠として、その技術的方式または採用するソフトウェアの実績等を示 すこと。 ゼロデイ攻撃の検知 過去 1 年以内にゼロデイ攻撃を検出できた実績が 1 件以上ある実装方式、また はソフトウェアを採用すること。 2.3.1.4.2. 機能要件 3-4「ウイルス検体捕獲」に関する補足 機能要件 3-4「ウイルス検体捕獲」については、提案する実装が要件を十分に達成でき ることを、次の観点について、提案書の中で説明すること。また、説明の中で、どのよう な場合にどのような検体が捕獲できる見込みであるかを、代表的なケースを基に示されて いることが望ましい。 ウイルス感染の検知と検体の捕獲 過去 1 年以内に、仮想マシンに感染したウイルスを検知し、その検体を捕獲で きた実績が 1 件以上ある実装方式、またはソフトウェアを採用すること。 なお、ウイルス検体捕獲に関して「可能な限り」と表現しているのは、次の例に示すよ うに、本機能の仕組み上の様々な制約が考えられるためであり、これらの制約による限界 については許容する前提である。 仮想環境の見破り 仮想環境で実行されていることを検知し、悪意のある動作を行わないウイルス については、ウイルスとして認識できない可能性がある。 通信環境／マシン環境等による見破り 仮想環境の見破りとは別に、外部との通信がどの程度可能かといった情報を集 め、その結果により悪意のある動作を行わないようにするウイルスもあり、そ れらはウイルスとして認識できない可能性がある。 「ウイルス振る舞い検知」により動作を停止させた場合の影響 ダウンローダ型ウイルス等、別のウイルスを通信により取得し感染させるウイ ルスについて、機能要件 3-5「ウイルス振る舞い検知」でその動作を停止させ た場合は、ダウンロード先のウイルスは捕獲できない。 2.3.1.4.3. 機能要件 3-5「ウイルス振る舞い検知」に関する補足 機能要件 3-5「ウイルス振る舞い検知」については、提案する実装が要件を十分に達成 できることを、次の観点について、提案書の中で説明すること。 振る舞い検知及びウイルスの動作停止 振る舞い検知及びウイルスの動作停止を行う方式について、要件を十分に達成 できることを説明する根拠として、その技術的方式または採用するソフトウェ アの実績等を示すこと。 2.3.1.4.4. 機能要件 3-7「調査結果横断解析」に関する補足 機能要件 3-7「調査結果横断解析」については、具体的には次のようなケースで、別々 の調査対象エントリに登録されたウェブサイト A と B が両方とも攻撃サイトリストへ出力 されることを期待している。 40 この要件を十分に達成できることを説明する根拠として、その技術的方式または採用す るソフトウェアの実績等を示すこと。 (1) ウェブサイト A の調査を行う。 (2) ウェブサイト A から、ウェブサイト R へリダイレクトが行われる。 (3) ウェブサイト R から、ウェブサイト X へリダイレクトが行われる。 (4) ウェブサイト X において、脆弱性を突く攻撃が行われる。 ⇒ この場合、横断解析は行わなくとも、ウェブサイト A は調査結果レポートの中で攻 撃サイトとして報告される。 (5) 続いてウェブサイト B の調査を行う。 (6) ウェブサイト B から、ウェブサイト R へリダイレクトが行われる。 (7) ウェブサイト R は、何らかのロジックにより、ウェブサイト X へのリダイレクトは 行わない（無害なふりをする） 。 ⇒ この場合、ウェブサイト B は調査結果レポートの中では無害であると判定されるが、 実際にはアクセスを行うと攻撃を受ける可能性のある危険なサイトである。 (8) ウェブサイト A の調査で得られたデータと、ウェブサイト B の調査で得られたデー タを横断的に解析する。 ⇒ 結果として、ウェブサイト A と B 両方を攻撃サイトリストに含めて出力する。 なお、機能要件に「過去 n 日分（設定可能とする）の調査データを保持し」と書いた通 り、例えば上記(1)のウェブサイト A の調査と(5)のウェブサイト B の調査との間が n 日間 空いた場合は、横断解析を行う時点でウェブサイト A、R、X に関する調査データが消えて いるため、ウェブサイト B は攻撃サイトリストには登録されない。これは、本機能の制限 事項となる。なお、調査データの保持期間は 30～90 日分程度を想定している。 2.3.1.5. 機能要件 4 ゼロデイ攻撃判定用クローラ ゼロデイ攻撃調査の処理に使用する。脆弱性を解消した複数種類の仮想マシンを操作し、URL リストのウェブページを調査して、攻撃の成立有無を判定する。 表 2-14 ゼロデイ攻撃判定用クローラ 機能要件 番号 4-1 機能 URL リスト管理 4-2 ゼロデイ攻撃判定用仮想マシ ン管理 4-3 攻撃検知 要件 URL リスト作成機能から調査指示として送信された、ゼロデイ攻撃 調査用の URL リストについて、優先度に従って調査処理を順次実行 すること。 複数の種類の仮想マシンを、並列または逐次的に動作させ、ウェブ サイト（URL リスト内の URL）を調査できること。 調査処理においては、フォワードプロキシを経由し、PPPoE ルータ #2 を経由した回線（ゼロデイ攻撃判定用回線）を使用すること。 当初は 3 種類の仮想マシンで調査を行うこととするが、将来的に仮 想マシンのイメージを増やすことが可能な拡張性を考慮した設計と すること。この機能についての具体的な実現方式については提案を 求める。 仮想マシンを定期的にクリーンな状態への巻き戻しを行う機能を備 えること。 機能要件 3-3 に同じ。 「2.6.2.2 クローラ仮想マシン ソフトウェア構成」に示す「ゼロデ イ攻撃判定用仮想マシン」1～3 の構成にある各アプリケーションの 脆弱性を突く攻撃の検知に対応できること。また、アプリケーショ ンのバージョンの変化やアプリケーションの追加への対応を考慮す ること。 41 番号 4-4 4-5 4-6 機能 ウイルス検体捕獲 ウイルス振る舞い検知 調査結果レポート出力 要件 4-7 調査結果横断解析 4-8 4-9 調査完了処理 機能一時停止 機能要件 3-4 に同じ。 機能要件 3-5 に同じ。 機能要件 3-6 に同じ。 調査結果レポートは、調査を実施した仮想マシンの種類ごとに、複 数となってもよい。 機能要件 3-7 に同じ。 横断解析を行うデータの対象として、巡回用クローラで蓄積した情 報を含めることが望ましいが、必須ではない。機能設計の方針を考 慮した上で、要件定義もしくは基本設計の段階にて、改めて当機構 と協議の上で仕様を定める。 機能要件 3-8 に同じ。 機能要件 1-12「調査機能一時停止管理」により、SPICA 管理機能か ら調査機能一時停止の指示が出ている場合は、対応する調査（ゼロ デイ攻撃調査）の調査対象エントリに対する新たな処理は開始しな いこと。 業務要件及び機能要件に示した通り、SPICA における「ゼロデイ攻撃判定」とは、攻撃の内 容や悪用された脆弱性を解析・特定するという方式ではなく、「脆弱性を解消した仮想マシン で当該ウェブサイトを閲覧し、攻撃が成立したか否かを確認する」という方式である。 従って、例えば、実際にはゼロデイ攻撃が行われているウェブサイトであっても、次のよう な場合はそれを検出できない可能性があり、これらについては SPICA で実装する方式の限界 （制限）となる。 同一の IP アドレスからの複数回のアクセスや、IP アドレス帯により攻撃を行ったり止 めたりする攻撃サイトにおいて、調査を行ったタイミングでは攻撃が行われなかった場 合。 高対話型ウェブクローラであることを見破られ、ゼロデイ攻撃判定用クローラの仮想マ シンに対しては攻撃が発生しなかった場合。 攻撃で悪用される脆弱性を持つアプリケーションが、ゼロデイ攻撃判定用クローラの仮 想マシンに搭載されていなかった場合。あるいは、搭載されていても、細かなバージョ ンの差異等により攻撃が成立しなかった場合。 2.3.1.6. 機能要件 5 検証用クローラ 巡回用クローラとゼロデイ攻撃判定用クローラの機能を同居させたテスト環境。障害時の再 現調査、パッチ適用・機能強化時の動作確認、クローラサーバ障害時のハードウェア予備機と して使用する。 検証用クローラでは、具体的には次のような検証・テストを実施することを想定している。 以降、巡回用クローラとゼロデイ攻撃判定用クローラを併せて「本番環境」と呼ぶ。 本番環境で発生した障害について、本番環境は早期復旧を優先し、検証用クローラにて 同等の環境を使って再現テストを行う。 本番環境のサーバのホスト OS や仮想化ソフトウェアなどへのパッチ適用を行う際、事 前に検証用クローラで実施して問題等が発生しないことを確認する。 機能強化やバグ改修等を行う際のテスト環境として使用する。 巡回用クローラやゼロデイ攻撃判定用クローラ用の仮想マシンへ、脆弱性を悪用される 新たなアプリケーションを追加するといった大きな変更を加える際の事前検証に使用 する。 これらの目的を達成するためには、検証用クローラのサーバ上には、本番環境の巡回用クロ ーラとゼロデイ攻撃判定用クローラの環境を相乗りさせる必要がある。また、入力と出力につ 42 いても、本番環境相当の動作が確認できることが望ましい。 具体的に何をどこまで実現できるか（テストや検証が行えるか）は、本番環境の機能の設計 に依存するため、詳細は要件定義もしくは基本設計の段階にて、改めて当機構と協議の上で定 める。下表に示す機能要件を満たすことができるよう考慮した提案内容とすること。 表 2-15 検証用クローラ 機能要件 番号 5-1 機能 本番環境相当の機能の実現 5-2 本番環境への影響抑制 要件 巡回用クローラとゼロデイ攻撃判定用クローラ相当の機能が実行で きること。 両方の機能を同時実行可能とするか、システム管理者による簡単な 操作により、環境を切り替えられること。 巡回用クローラ相当の機能を使う場合、通信経路もそれにならい、 フォワードプロキシを経由し、PPPoE ルータ#1 を経由した回線（巡 回用回線）を使用すること。 ゼロデイ攻撃判定用クローラ相当の機能を使う場合、通信経路もそ れにならい、フォワードプロキシを経由し、PPPoE ルータ#2 を経由 した回線（ゼロデイ攻撃判定用回線）を使用すること。 検証用クローラの機能を使って検証作業を行うにあたり、本番環境 へ発生する影響は原則として発生しないようにすること。 ただし、本番環境と共有するリソース（例えば、ネットワークトラ フィック、URL 作成機能の負荷、フォワードプロキシの負荷等）に ついては、検証作業の作業量に応じた影響が生じてもよい。 2.3.1.7. 機能要件 6 フォワードプロキシ クローラがインターネットへ接続する際に経由するプロキシサーバ。 巡回用クローラとゼロデイ攻撃判定用クローラ上の仮想マシンから、それぞれ対応する PPPoE ルータ経由でインターネットへアクセスするという要件の関係上、各 PPPoE ルータをデ フォルトゲートウェイとした 2 つのプロキシサーバを構築することを想定している。 なお、本機能の実装は、オープンソースソフトウェアである Squid の適用を想定している。 表 2-16 フォワードプロキシ 機能要件 番号 6-1 機能 プロキシ処理 6-2 アクセス制御 要件 HTTP と HTTPS のフォワードプロキシ処理を行うこと。また、HTTP と HTTPS 以外のプロトコルは通過させないこと。 巡回用クローラから接続を受け付けるプロキシは、PPPoE ルータ#1 を経由した回線（巡回用回線）を使用すること。 ゼロデイ攻撃判定用クローラから接続を受け付けるプロキシは、 PPPoE ルータ#2 を経由した回線（ゼロデイ攻撃判定用回線）を使用 すること。 業務要件 9-6 に従い、アクセス制御の設定が行えること。 設定の方式や自由度等については、要件定義もしくは基本設計の段 階にて、改めて当機構と協議の上で定める。 2.3.1.8. 機能要件 7 PPPoE ルータ インターネットとの接続に使用する、一般的な PPPoE 機能を備えるルータ。 一般利用者向けに市販されているブロードバンドルータを調達して利用することを想定し ている。 43 表 2-17 PPPoE ルータ 機能要件 番号 7-1 機能 PPPoE 接続 7-2 ファイアウォール 7-3 Web GUI 7-4 設定保持 要件 PPPoE、NAPT により ISP を経由したインターネットアクセスが行え ること。 インターネットからの通信の接続は受け付けないこと。 ICMP 等の通信へも応答しないこと。 障害調査等の状況において使用する、ルータの設定内容や PPPoE セ ッション接続状態等が確認できる Web ベースの GUI を備えること。 GUI へのアクセスは SPICA 管理のサーバから行うことを想定してい る。 GUI へは、インターネットからのアクセスは行えないこと。 GUI の表示、操作の前に、ID とパスワード等による認証を行うこと。 電源断が発生しても、PPPoE の接続パスワード等の設定内容が保持 されること。 2.3.1.9. 機能要件 8 電源制御装置 PPPoE ルータの遠隔電源制御を行う装置。 市販されている電源制御装置の専用機器を調達して利用することを想定している。 表 2-18 電源制御装置 機能要件 番号 8-1 機能 電源制御 8-2 遠隔操作インターフェース 要件 PPPoE ルータ 3 台分の出力用電源コンセントを持ち、それの電源オ ン・オフの制御が可能であること。 機能要件 1-8「ルータ電源管理」から機械処理で電源制御の操作を 可能とするためのインターフェース（telnet など）を備えること。 2.3.1.10. 機能要件 9 バックアップサーバ 仮想マシンイメージ、調査結果に関するデータ、ウイルス検体、ログ等をミラーとして保持 する。 実装として、Windows ファイル共有や FTP などのインターフェースを持つ単純なファイルサ ーバを想定している。 SPICA におけるバックアップに関する考え方については、「2.2.11.7 業務要件 9-7 バックア ップ」を参照すること。 表 2-19 バックアップサーバ 機能要件 番号 9-1 機能 ファイル入出力 9-2 ファイル保持 要件 SPICA を構成する各サーバとの間で、ファイルのコピーによる入出 力が可能であること。 RAID1 など、耐障害性を持つ記憶装置にデータを保持すること。 SPICA 内で使用するシステムデータ（設定ファイルや仮想マシンイ メージのファイルなど）を保持できるだけの容量を確保しすること。 また、将来性を考慮し、その状態でのディスク利用率は 50%以下と すること。 44 2.3.1.11. 機能フロー ウェブサイト調査、ウェブサイト巡回調査における、機能間の連携を示す想定フローを「図 2-3 機能フロー図（ウェブサイト調査、ウェブサイト巡回調査）」に示す。図中の番号は機能 要件番号に対応している。 図 2-3 機能フロー図（ウェブサイト調査、ウェブサイト巡回調査） 45 続いて、ゼロデイ攻撃調査における、機能間の連携を示す想定フローを「図 2-4 機能フロ ー図（ゼロデイ攻撃調査） 」に示す。URL リスト作成機能からの URL リストの連携先がゼロデ イ攻撃判定用クローラになっているという点が異なるのみで、全体のフローはウェブサイト調 査を行う場合とほぼ同じである。 図 2-4 機能フロー図（ゼロデイ攻撃調査） 46 2.3.2. 画面要件 SPICA の今回の構築範囲においては、原則として画面（GUI）は要件に含まず、システム運 用者による各業務は、例えばテキスト形式のファイルの設置や参照であったり、コマンドの実 行といった形式を想定している。ただし、データベース操作ツール（内部のデータ管理にデー タベースを使用する場合）を直接システム運用者が使う場合や、システム監視用の一般的な商 用／非商用の運用監視ソフトウェア等については、その GUI を通じて行う形式としてもよい。 2.3.3. 情報・データ要件 ここでは、SPICA で取り扱う情報・データについて、その区分と扱いの方針について「表 2-20 情報・データ要件」に示す。 個々のデータの具体的な扱いについては、この方針に基づき、要件定義もしくは基本設計の 段階にて、改めて当機構と協議の上で定める。 表 2-20 情報・データ要件 項番 1 情報・データ区分 業務データ 2 システムデータ 3 ログデータ 4 テンポラリデータ 5 その他 説明・方針 業務遂行上、SPICA への入出力となるデータ。具体的には、 「2.2.2 業務データ 要件」で示すデータが該当し、この要件を満たすこと。 業務データの消失はシステム障害には繋がらないが、業務遂行上に不都合が生じ ることになるため、システム運用者により、適宜バックアップサーバへのコピー による情報の二重化や、外部記憶媒体への保存等を実施する。 SPICA の機能を稼動させるためのデータ。例えば、各種設定ファイル、仮想マシ ンイメージ、データベースを使用する場合はデータベース上のデータなど、開発 ／構築時点から内容が変化するもので、サーバ障害からの迅速な復旧に必要なデ ータを指す。 システムデータの消失はシステム障害に繋がるものであるため、自動もしくは手 動にて、適宜バックアップサーバへのコピー等による情報の二重化を行えるこ と。 過去分の調査結果データや、各機能が出力するログファイルなど、SPICA 内で生 成され保持されるが、消失してもシステム障害には繋がらないデータ。また、日 常業務においてはシステム運用者による参照が不要で、一定期間後に削除しても 問題のないデータ。 システム運用者は、データの重要度に応じて、適宜バックアップ等を取得する。 これらのデータについては、一定期間を過ぎたら削除する機能や、ログであれば ローテーション等の機能を実装すること。 各機能が動作する際に作成する中間ファイルや、ウェブコンテンツのキャッシュ など、消失しても機能に影響のないデータ、もしくは調査などを再処理すること で自動的に復旧するデータ。 これらのデータについては、不要になった時点で削除する機能を実装すること。 キャッシュデータや障害発生時の調査に必要なデータについては、一定期間保持 しておき、その後削除するという扱いでもよい。 項番 1～4 に当てはまらないデータについては、要件定義もしくは基本設計の段 階にて、改めて当機構と協議の上で扱いを検討する。 47 2.3.4. 外部インターフェース要件 次の外部インターフェースの機能を備えること。 機能要件 1-11「ウイルス検体外部連携」 2.4. 設計に係る要件 2.4.1. 設計方針 本開発において原則とする設計方針と考え方について、次に示す。 SPICA は、その一部に、故意にウイルスに感染する機能を持つ特殊なシステムである。 このため、GUI 等によるユーザーフレンドリーな UI を整備するよりも、システム内の 動作（処理の状況、データの在り処など）について、システム管理者からの見通しを良 くすることを優先する。 このため、本開発においては、必要に応じてシステム管理者が SPICA の各機能へ直接的 にアクセスできるよう、極力シンプルな設計とするよう心がけること。 2.4.2. 基本設計及び詳細設計に係る要件 本書で示す要件を満たすシステムの開発及び構築に向けた基本設計及び詳細設計を行 うこと。 基本設計書及び詳細設計書は、当機構のシステム責任者の承認を受けること。 2.4.3. 構築作業及びシステム構築手順書に係る要件 システム構築手順書は、サーバやネットワーク機器の初期設定・構築作業のみならず、 障害時の復旧・再構築にも利用する。構築作業前に手順書を作成し、実環境での構築作 業で判明した誤りや注意点を反映させ、手順書の精度を高いものとすること。 2.4.4. 信頼性要件 本機能は 24 時間 365 日の稼動を基本としているが、障害やメンテナンスのための一時 的な停止は許容する。 障害発生率（業務実施に影響があるレベル）は年に 4 回程度を想定する。 ハードディスクドライブのミラー機能を除き、機器等の二重化は行わない。 2.4.5. 拡張性要件 2.4.5.1. 性能拡張性 巡回用クローラはスケールアウト可能な構成とすること。また、巡回用クローラの増設 に伴い、巡回用回線がボトルネックとなった場合に、ISP との接続回線、PPPoE ルータ、 フォワードプロキシの増設を伴うことを想定し、拡張性を考慮した設計とすること。 48 2.4.5.2. 機能拡張性 今回の開発では、システム運用者向けの GUI は開発対象ではないが、将来的に今回開発 する各機能を呼び出すことで GUI が拡張開発できる（GUI によるラッパーを作成できる） ことを考慮した設計とすること。 ウェブサイトの調査が完了したことをシステム運用者へ通知する機能を拡張開発する ためのインターフェースを備えること（機能要件 3-8 及び 4-8 を参照）。 新たな攻撃サイトを検知したことをシステム運用者へ通知する機能を拡張開発するた めのインターフェースを備えること（機能要件 1-4 を参照） 。 2.4.5.3. 攻撃判定マシン拡張性 ゼロデイ攻撃判定用仮想マシンについて、判定に用いる仮想マシンのイメージを増やす ことが可能な拡張性を考慮した設計とすること（機能要件 4-2 を参照）。 2.4.6. 上位互換性要件 OS、ミドルウェア及びアプリケーションなどについては、安定かつ最新バージョンを導 入すること。ソフトウェアのバージョンによる相性問題等がある場合は、その旨を示し た上で、動作確認の取れている中で最新のバージョンを採用すること。 オープンソースソフトウェアを使用する場合は、セキュリティパッチ等のバージョンア ップの際の影響を避けるため、開発コミュニティや OSS ベンダーが提供するソースコー ドを無改造の状態で使用すること。 2.4.7. システム中立性要件 機能間の連携に使用する通信プロトコル等は原則としてオープンな規格に準拠したも のとすること。 2.4.8. 事業継続性要件 サーバ故障、データ消失等が発生した場合のサーバの復旧は、基本的に該当サーバの再 構築にて実施する。迅速な復旧のため、全てのサーバの構築手順書を備え、開発成果物 の「システム構築手順書」に含めること。 サーバ故障、データ消失等に備え、迅速に復旧するために必要なデータ（システムデー タ）をバックアップサーバへコピーする運用が行えること。 障害からのシステム復旧は、3 営業日以内を目標とする。なお、ハードウェア故障を伴 う場合は、ハードウェアが復旧したのち 3 営業日以内を目標とする。 2.4.9. 権限管理要件 「2.1.2 システムのユーザー」に示した方針に基づき、システム運用者の区分によるア クセス（システムの操作、情報登録・参照・削除）の制御を考慮した設計を行うこと。 システム運用者の区分と、区分によるアクセス制御に関する要件と仕様についての詳細 は、機能設計の方針を考慮した上で、要件定義もしくは基本設計の段階にて、改めて当 機構と協議の上で定める。 49 2.4.10. 情報セキュリティ対策 2.4.10.1. サーバセキュリティ Windows サーバにはウイルス対策ソフトを導入すること（仮想マシンには導入する必要 はない） 。本機能ではウイルス検体を扱う箇所があるため、ウイルス対策ソフトの例外 設定を行うなど、機能に支障のないよう留意すること。本要件について、開発時点で問 題等が判明した場合は、改めて当機構と協議の上で処置を定める。 サーバの要塞化を行うこと。具体的には、不要なソフトウェアの削除、不要なサービス の停止、不要な通信ポートの閉鎖、不要なアカウントの削除、適切なパスワードの設定、 セキュリティパッチの適用等を実施すること。なお、いわゆるセキュア OS（SELinux 等）を使用する必要はない。 2.4.10.2. ネットワークセキュリティ SPICA を構成する一部のサーバがウイルス等に感染した場合の影響を局所化するため の施策として、 「図 2-2 機能構成図」と「図 2-5 論理ネットワーク構成図（例） 」に示 すように、本機能内のサーバ間同士の通信であってもファイアウォールによるアクセス 制御が可能であること（詳しくは詳細設計の段階で定める） 。 特に、クローラサーバを設置するネットワークセグメントは、ファイアウォールにより 他のネットワークセグメントから隔離し、必要最低限の通信のみを許可するよう構成で きること。 クローラサーバからインターネットへの通信は、必ずファイアウォールとフォワードプ ロキシを通し、http/https 以外のプロトコルは許可しないこと。 インターネットからの本システムへの通信要求は、PPPoE ルータやファイアウォールに より完全に遮断し、応答も返さないこと。 2.5. 稼働環境等要件 本機能を構成するハードウェア（サーバ、ネットワーク機器、UPS、モニタ、KVM 等）は、当 機構のサーバルームに本機能専用の 19 インチサーバラックを設置し、収容する。 当機構のサーバルームで使用できる電源は、一般商用電源（AC100V、200V）である。 50 2.6. 全体構成 本章では、本機能を構成するハードウェア（サーバ関連機器、ネットワーク機器等）と開発プロ グラム以外のソフトウェアについて、構成を定めるための指針を示す。提案書においては、業務要 件及び機能要件を満たすシステム提案に基づき、ここで示す指針を参考に、ハードウェア、ソフト ウェア及びネットワークの概要構成を定め、記載すること。 概要構成としては、システム構成の妥当性や、必要となるネットワーク機器の数量が分かるレベ ルの機器構成及びネットワーク構成を示すこと。詳細度については、次に示す想定構成情報の記載 例を参考にすること。また、概要構成を示す際には、本書の想定構成図等を流用、編集したり、過 不足等を指摘する形でも構わない。 【参考例】 「表 2-22 機器構成一覧（例）」 「図 2-5 論理ネットワーク構成図（例） 」に、参考として、本書 で示す業務要件及び機能要件を基に、当機構にて仮作成した想定機器構成及び想定ネットワーク構 成を示す。この構成はあくまで参考であり、機能要件、性能要件等を充足するか否かを当機構で確 認したものではない。提案内容は、必ずしもこの想定構成に従う必要はなく、また、提案の時点に おいては詳細なネットワーク設計までを行う必要はない。 2.6.1. ハードウェア構成 次の要件に適合するハードウェアを選定することを想定している。 原則として、19 インチのラックマウント機器とする。ただし、電源制御装置等、特殊 な機器については、ラック内の棚に置いて収容する形式でも構わない。 サーバ機器の高可用性については、次の考え方に従う。 ハードディスクは、基本的に、RAID1 によるミラーリングとホットプラグ対応のハー ドディスクドライブが構成できるものを選定する。 電源、ネットワークインターフェース、CPU、メモリ等の二重化は行わない。 巡回用クローラ、ゼロデイ攻撃判定用クローラ、検証用クローラのサーバ機器について は、共通の構成とする。 全てのサーバ機器、ネットワーク機器、KVM スイッチ、モニタの電源を UPS で保護する （KVM スイッチとモニタ用それぞれ 1 口の電源を確保する） 。ただし、電源制御装置、 PPPoE ルータ、ISP 接続用モデムは保護の対象外とする。 電源障害発生時、UPS からの通知により、各サーバ機器のシャットダウンを自動的に行 う。 2.6.2. ソフトウェア構成 2.6.2.1. システムソフトウェア構成 次の要件に適合するソフトウェアを選定することを想定している。 ソフトウェアの保守・サポート費用を極力低減するよう意識した構成とする。 例えば、データベース、運用管理ソフト、ウェブ／アプリケーションサーバなどの ミドルウェア（使用する場合） 、及びプロキシサーバ、FTP サーバなど、広くオープ ンソースの実装が使われており、十分に安定していると考えられるものについては、 オープンソースソフトウェアや無償利用可能なソフトウェアを採用するといった対 応が望ましい。 ウイルス対策ソフトについては、本機能で捕獲したウイルス検体などが誤って隔離／削 除されないように設定できる機能を持った、商用製品を採用する。 商用製品のライセンスは、原則として永久ライセンスのものとする。 51 「高対話型ウェブクローラ」に関する機能の実現のために商用製品を採用する場合、脅 威の進化に合わせて、サイト評価や脅威検知の機能等を適宜アップデート可能なものと し、サポート等によって提供されるものとする。 2.6.2.2. クローラ仮想マシン ソフトウェア構成 巡回用クローラとゼロデイ攻撃判定用クローラで使用する仮想マシンのソフトウェア構成 の案を「表 2-21 クローラ仮想マシン ソフトウェア構成（案） 」に示す。詳しくは要件定義も しくは基本設計の段階にて、改めて当機構と協議の上で定める。 表 2-21 クローラ仮想マシン ソフトウェア構成（案） 項番 1 仮想マシン名 巡回用仮想マシン 2 ゼロデイ攻撃判定用 仮想マシン 1 3 ゼロデイ攻撃判定用 仮想マシン 2 4 ゼロデイ攻撃判定用 仮想マシン 3 構成 OS・攻撃対象アプリケーション OS: Windows XP SP2 Professional Edition 攻撃対象アプリケーション: 7-zip 4.36beta、Adobe Reader 8.0.0、Adobe Flash Player 9(ActiveX 版)、JRE 5.0 Update 16、RealPlayer 10 GOLD (6.0.12.883)、QuickTime 7.1.0.210、Microsoft Office Standard Edition 2003 OS: Windows XP SP3 Professional Edition 攻撃対象アプリケーション: 7-zip(最新)、Adobe Reader(8 系統で最新)、 Adobe Flash Player(ActiveX 版、最新)、JRE(最新)、RealPlayer SP(最新)、 QuickTime(最新)、Microsoft Office Standard Edition 2003(最新) OS: Windows Vista SP1 Business Edition 攻撃対象アプリケーション: 7-zip(最新)、Adobe Reader(9 系統で最新)、 Adobe Flash Player(ActiveX 版、最新)、JRE(最新)、RealPlayer SP(最新)、 QuickTime(最新)、Microsoft Office Standard 2007(最新) OS: Windows 7 Professional Edition (32bit) 攻撃対象アプリケーション: 7-zip(最新)、Adobe Reader(9 系統で最新)、 Adobe Flash Player(ActiveX 版、最新)、JRE(最新)、RealPlayer SP(最新)、 QuickTime(最新)、Microsoft Office Home and Business 2010(最新) 2.6.3. ネットワーク構成 業務要件、機能要件、性能要件の条件から導かれる機能を稼動させるために必要なネッ トワークの設計及び構築（機器の設定）を行う。 ネットワーク機器の物理的な設置及び配線は、当機構にて手配する作業者が実施す る。このため、物理ネットワーク設計を、当機構が別途定める日までに提出するこ と。 ネットワークの経路及びネットワーク機器の二重化の必要はない。 システム運用者用の専用端末（運用 PC）を 2 台用意し、サーバルームの外の執務室に 設置することを想定しているため、これを考慮した設計とする。 障害対応などの例外時を除き、原則としてシステム運用端末から日常的な業務遂行操作 が行えること（SSH、リモートデスクトップ、共有フォルダ、アナログ KVM／KVM over IP 等の使用を想定している） 。採用する方式と実施できる作業の範囲等について、詳しく は、要件定義もしくは基本設計の段階にて、改めて当機構と協議の上で定める。 各サーバから、OS やアプリケーションのオンラインアップデートやウイルス対策ソフ トのパターンファイルのアップデートが可能な通信経路を確保する。仮想化環境を使う サーバについては、ホスト OS とゲスト OS の両方を含む。 この通信に使用するインターネット回線は、巡回用回線、ゼロデイ攻撃判定用回線、 URL リスト作成用回線のいずれを使っても構わない。 ホスト OS とゲスト OS とで、フォワードプロキシの使用有無といった差異が発生し ても構わない。 52 表 2-22 機器構成一覧（例） 項番 1 1-1 機器名 サーバ/PC 関連機器 SPICA 管理サーバ (Windows Server 2008 R2 Standard (x64)) 数量 構成 1式 1-2 URL リスト作成サーバ (Windows Server 2008 R2 Standard (x64)) 1式 CPU: Xeon クアッドコア 2GHz 以上 x 1、メモリ: 4GB ドライブ: RAID1 500GB HDD + DVD-R/RW、NIC: 2 ポート以上 【要件／確認事項／備考】 ・開発プログラムの実行環境として、cygwin、perl、XX を使用予定。 ・サーバの死活監視ソフトウェアとして、XX を使用予定。 ・HDD 容量は、XXX の概算に余裕度を考慮し 500GB 以上とする。 CPU: Xeon クアッドコア 2GHz 以上 x 1、メモリ: 4GB ドライブ: RAID1 500GB HDD + DVD-R/RW、NIC: 2 ポート以上 1-3 巡回用クローラ、ゼロ デイ攻撃判定用クロー ラ、検証用クローラ (Windows Server 2008 R2 Standard (x64)) 5式 1-4 フォワードプロキシ (Red Hat Enterprise Linux) 2式 1-5 バックアップサーバ (Windows Server 2008 R2 Standard (x64)) 1式 1-6 電源制御装置 1式 1-7 UPS 装置 3式 1-8 2式 1-9 運用 PC (Windows 7 Professional) モニタ＋KVM スイッチ 2 2-1 ネットワーク関連機器 PPPoE ルータ 3式 2-2 ファイアウォール 2式 1式 【要件／確認事項／備考】 ・開発プログラムの実行環境として、cygwin、perl、XX を使用予定。 CPU: Xeon クアッドコア 2GHz 以上 x 1、メモリ: 4GB ドライブ: RAID1 500GB HDD + DVD-R/RW、NIC: 2 ポート以上 【要件／確認事項／備考】 ・開発プログラムの実行環境として、cygwin、perl、XX を使用予定。 ・VMware Workstation を使用し、仮想マシンを 3 つ稼動可能とする。 ・4 コア以上の CPU、及び各ゲスト OS に 768MB のメモリを割り当てるこ とを考慮し、4GB のメモリを搭載する。 CPU: Xeon クアッドコア 2GHz 以上 x 1、メモリ: 4GB ドライブ: RAID1 300GB HDD + DVD-R/RW、NIC: 2 ポート以上 【要件／確認事項／備考】 ・プロキシサーバとして Squid を使用予定。 CPU: Xeon クアッドコア 2GHz 以上 x 1、メモリ: 4GB ドライブ: RAID1 1TB HDD + DVD-R/RW、NIC: 2 ポート以上 【要件／確認事項／備考】 ・HDD 容量は、XXX の概算に余裕度を考慮し 1TB 以上とする。 【要件／確認事項／備考】 ・3 個以上の電源出力/制御が行えること（PPPoE ルータ x 3） 。 ・telnet プロトコルによる制御インターフェースを備えていること。 ・想定装置： XX 社 XXX または XX 社 XXX 【要件／確認事項／備考】 ・合計 15 個以上の電源出力が行えること（サーバ機器 x10、ファイアウ ォール x2、L2 スイッチ x1、KVM スイッチ x1、モニタ x1） ・項番 1-1～1-5、1-9、2-2～2-3 の機器が接続できること。 ・Windows Server 2008 R2 Standard (x64)に対応した電源管理サーバソ フトが提供されていること ・Windows Server 2008 R2 Standard (x64)、Red Hat Enterprise Linux に対応した電源管理エージェントソフトが提供されていること 【要件／確認事項／備考】 ・本機能の運用に十分な能力を持つ PC であること。 【要件／確認事項／備考】 ・19 インチラックへのマウントが可能であること。 ・項番 1-1～1-5 のサーバ機器が接続できること。 ・項番 1-8 の運用 PC から、LAN 経由で遠隔操作が可能であること。 一般家庭向けブロードバンドルータ（無線機能不要） 【要件／確認事項／備考】 ・管理用の Web GUI を備えること。 ・19 インチラックに本機器及びモデムを収納するための棚が必要。 ・ステートフルインスペクション/NAT/静的ルーティング対応 ・6 個の 10/100/1000Base-T/TX ポート 【要件／確認事項／備考】 ・業務用ネットワークのファイアウォールとして 5 ポートを備えるもの が 1 台必要 ・運用セグメントをクローラサーバとその他のサーバで分割するための ファイアウォールとして 2 ポートを備えるものが 1 台必要 53 項番 2-3 機器名 L2 スイッチ 数量 1式 構成 ・19 インチラックマウント対応 ・48 個の 10/100/1000Base-T/TX ポート ・ポートベース VLAN 対応 【要件／確認事項／備考】 ・ネットワーク構成上、最低限 XX ポートが必要。構成変更や将来の拡張 性を考慮し、48 ポートの機器とする。 2-4 運用 PC 用スイッチン グハブ ソフトウェア 仮想化環境ソフトウェ ア ウイルス対策ソフトウ ェア（Windows サーバ 用） ウイルス対策ソフトウ ェア（運用 PC 用） 1式 デスクトップ設置用スイッチングハブ（8 ポート以上） 5式 ※ 特に、調達が必要なものを挙げる VMware Workstation 7.x （最新版） 3 3-1 3-2 3-3 8式 【要件／確認事項／備考】 ・Windows Server 2008 R2 Standard (x64)に対応していること。 2式 【要件／確認事項／備考】 ・Windows 7 Professional に対応していること。 54 図 2-5 論理ネットワーク構成図（例） 55 2.7. 規模・性能要件 2.7.1. 規模要件 「調査対象エントリ」については、巡回対象及び未処理のものをあわせて（すなわち、 処理済みとして保管してあるものを除き）、最大 5,000 エントリが登録できること。 クローラ物理サーバ 1 台あたり最低 3 つの仮想マシンを並列稼動させることが可能であ ること。 余裕度や障害時の縮退運転を考慮し、巡回用クローラは最低 9 つの仮想マシンを稼動さ せること。本書では、3 台の物理サーバで各 3 つの仮想マシンを稼動させることを想定 している。 2.7.2. 性能要件 SPICA で実施する調査（ウェブサイト調査、ウェブサイト巡回調査、ゼロデイ攻撃調査） について、24 時間 365 日稼動を行う前提において、100 万 URL/月の調査が行えること。 1 つの仮想マシンあたり、4 千 URL/日の調査が行えること。最大性能としては、8 千～1 万 URL/日程度の調査が行えることを目標値とする。 3. 作業及び作業環境等に係る要件 開発、単体試験に係る作業については、請負者が用意する場所にて実施すること。 当機構が調達した本番用の機器にシステム構築を行うこと。本番用の機器は、当機構が用意 する環境（当機構サーバルーム）に設置する。 結合試験のうち本番用の機器が必須でない試験項目については、請負者が用意する場所にて 実施すること。 システム構築、結合試験のうち本番用の機器が必須である試験項目、システム試験、及び性 能試験については、当機構が用意する環境にて実施すること。 開発、システム構築、各種試験の作業実施に使用する機器等については、請負者が用意する こと。 開発、システム構築、各種試験の作業実施に使用する機器等については、ウイルス対策、セ キュリティホール対策等、十分なセキュリティ対策が実施されていること。 4. システム試験 システム構築が完了した後、納入期限までの間にシステム試験を行うこと。また、併せて性 能試験も行うこと。 できるだけ早い段階でシステム試験及び性能試験の計画を立案し、当機構のシステム責任者 の承認を受けること。 システム試験は「2 システムの要件」で定義された要求仕様を全て満たすことを確認するこ と。また、システムの障害回復等に留意し、十分な信頼性が確保されているか確認作業を行 うこと。 「2.4.10 情報セキュリティ対策」で示した要件に対する十分なテストを行うこと。発見さ れた問題について対応し解消すること。 性能試験は「2.7.2 性能要件」で定義された要求仕様を満たすことを確認すること。また、 1 つの仮想マシンでの最大性能の目標値が達成できるか否かを確認し、当機構の環境や外的 要因等により目標値を達成できない場合、原因の究明、ボトルネックの解消等を、当機構と 協議の上で可能な範囲で実施すること。 56 5. 作業の体制及び方法 5.1. プロジェクトの体制等 プロジェクト体制内に、本機能と同等規模のシステムの開発・運用を行った経験を有するプ ロジェクトメンバが含まれること。 プロジェクト体制内に、サーバ仮想化技術、コンピュータウイルスによる攻撃の検知技術に 知見のあるプロジェクトメンバが含まれること。 プロジェクト体制内に、経済産業大臣指定試験機関である情報処理技術者試験センターが行 う情報処理技術者試験のうち、以下の試験合格者と同等の能力を有するプロジェクトメンバ が含まれること。 プロジェクトマネージャ試験 システムアーキテクト試験 旧アプリケーションエンジニア試験でも可 情報セキュリティスペシャリスト試験 旧テクニカルエンジニア試験(情報セキュリティ)または情報セキュリティアドミニス トレーターでも可 日本語の会話及び読み書きが可能で、当機構の役職員と十分な意思疎通が図れること。 サーバ仮想化ソフトウェアを使ったシステム構築の実績があること。 5.2. プロジェクト管理等 「1.4.5 納入期限」で示した納入期限までの納入を目標とした計画を立てること。 PMBOK（the project management body of knowledge/プロジェクトマネジメント知識体系） 等に基づいた、当機構と合意したプロジェクト計画書に従って作業を実施すること。 プロジェクト計画書については、最低限次の内容を含むこと。 プロジェクトの背景、目的及びスコープ 実施体制 工程計画（資源・工数・要員などの計画を含む） 工程管理計画 ドキュメント一覧 品質保証計画 セキュリティ計画 前提条件、制約条件及びリスク分析 工程計画については、EVM（Earned Value Management）に基づく WBS（Work Breakdown Structure）等による定量的な内容が記述されていること。成果物ベースの WBS を例とする と、レベル 2 を成果物一覧とし、尐なくともレベル 3（各成果物の大目次） 、必要に応じて レベル 4 以降まで細分化し、作業項目毎に工数もしくはコストを含めて記載されていること。 また、主要なマイルストーンが設定されていること。 ミーティング等により当機構と作業内容の調整及び報告を行うこと。 請負者は、すべての作業において、当機構が提供した業務上の情報を細心の注意をもって管 理し、第三者に開示または漏洩しないこと。また、そのために必要な措置を講じること。 当機構及び請負者は、相互に本契約の履行過程において知り得た相手方の機密を他に漏洩せ ず、また本契約の目的の範囲を超えて利用しないものとする。ただし、当機構が、法令等、 官公署の要求、その他公益的見地に基づいて、必要最小限の範囲で開示する場合を除く。 57 6. 保守要件 開発・構築作業の完了した日から 1 年間、納入物件の瑕疵に対して無償で修正すること。詳しく は契約書第 9 条（保証）を参照のこと。 7. 条件等 7.1. スケジュール 本開発・構築作業は、 「図 7-1 想定スケジュール」のスケジュールで作業を実施することを想定 している。提案書には、下記スケジュール要件を満たせることを示すレベルの概略スケジュールを 含めること。 詳細なスケジュールについては、開発・構築作業の着手時に改めて当機構と調整の上、請負者に て策定し、プロジェクト計画書に含めて提示すること。 スケジュールにおける要件を次に示す。 「1.4.3 プロジェクトの流れと作業分担」で示した通り、ハードウェアとソフトウェアは分 離調達を行う。当機構による調達作業の開始から、機器の設置等が完了して請負者がシステ ム構築作業に着手できるまで、約 3 ヵ月を要する点に注意し、スケジュールを作成すること。 このため、ハードウェアとソフトウェアの構成設計は早期に行う必要があり、作業開始 から約 1 週間での実施を想定している。 図 7-1 想定スケジュール 以上 58