1 目次 1. 全体の仮説 2 2. 国際標準と情報セキュリティ早期警戒パートナーシップ 9 3. ソフトウェア製品開発者における国際的な脆弱性情報の取扱い グローバルなウェブサイトにおける脆弱性対応 情報セキュリティ早期警戒パートナーシップのグローバル化対応に向けて 73

Transcription

1 別紙 2 情報セキュリティ早期警戒パートナーシップにおけるグローバル化の課題と今後の方針調査報告書 2014 年 3 月

2 1 目次 1. 全体の仮説 2 2. 国際標準と情報セキュリティ早期警戒パートナーシップ 9 3. ソフトウェア製品開発者における国際的な脆弱性情報の取扱い グローバルなウェブサイトにおける脆弱性対応 情報セキュリティ早期警戒パートナーシップのグローバル化対応に向けて 73

3 1. 全体の仮説 1.1. 背景 目的 1.2. 調査方針 1.3. 情報セキュリティ早期警戒パートナーシップの国際対応に関する問題意識 1.4. 国際標準とパートナーシップの整合に関する仮説 1.5. 日本企業の海外拠点のサイトに脆弱性があった場合の対応に関する仮説 1.6. 報告書の全体構成 2

4 1.1. 背景 目的 情報セキュリティ早期警戒パートナーシップ ( 以下 パートナーシップ という ) は 国際的にも例を見ない我が国独自の制度として運営されてきた 製品開発者の脆弱性ハンドリングや脆弱性開示に関する国際標準化の作業が進んできたことから 今後はそうした国際標準とパートナーシップの整合等について検討すべきと考えられる パートナーシップは 主として国内のユーザのために運営されているが 多くの日本企業が国際展開を進める昨今 企業 ( 製品開発者 ウェブサイト運営者 ) のグローバルな活動における脆弱性対応を支援する役割がパートナーシップに求められる可能性もある そこで パートナーシップのグローバル化に向けた対応 を検討課題として捉え 広い観点から脆弱性取扱に関して国際的な対応を要する場面に関して実態を調査し パートナーシップの今後の課題を抽出する 1.2~1.6 では 調査全体の仮説を得るために実施した事前調査とその結果 また本報告書の全体構成を示す 3

5 1.2. 調査方針 事前調査として 現在のパートナーシップの活動において 国際的な対応を要する場面の実態について調査し 現状と課題を明らかにした 具体的には IPA JPCERT/CC のパートナーシップ担当者に パートナーシップのグローバル対応に関する問題意識について伺い 調査全体の仮説を設定した 仮説設定は IPA JPCERT/CC の各担当者への質疑応答ではなく 各担当者とのディスカッションから得られた問題意識をもとにとりまとめた [ 調査方法 ] ヒアリング調査 [ 調査対象 ] IPA JPCERT/CC のパートナーシップ担当者 [ 調査項目 ] ソフトウェア製品に関する国際的な脆弱性情報取扱の実態と課題 ( ソフトウェア製品開発者から見た国際標準の活用可能性など ) ウェブサイトに関する国際的な脆弱性情報取扱の実態と課題 ( 届け出られたウェブサイトのドメインと受理 不受理の状況など ) 特に 各取扱いにおいて 現在の告示や P ガイドラインにより制約されるため円滑な活動が妨げられている点や将来顕在化しうる問題 4

6 1.3. 情報セキュリティ早期警戒パートナーシップの国際対応に関する問題意識 国際標準とパートナーシップの整合 グローバル企業がグループ横断的な脆弱性取扱ルールを形成する場合の 共通の指針として国際標準 (ISO/IEC29147, ISO/IEC30111) を活用するようになると 日本の制度 ( パートナーシップ ) がガラパゴス化する可能性があるのではないか 日本のみの独自ルールや国際標準との不整合 ギャップを解消しなければ グローバル企業における統合ルールとしてパートナーシップを位置付けることが難しくなるのではないか 日本企業の海外拠点のサイトに脆弱性があった場合の対応 日本企業の海外拠点の外国語サイトに脆弱性があった場合 パートナーシップの取扱いの対象にならない 当該サイトでインシデントが発生し JPCERT/CC に届出された場合 インシデント対応はなされても 脆弱性対応がなされたかどうか確認できない 海外拠点が別会社の場合 子会社であったとしても IPA 等から親会社に連絡を入れることは 営業妨害にあたる可能性がある 日本企業の脆弱性問題が結果的に放置されるリスクがあるのではないか JPCERT/CCは パートナーシップにおける調整機関とは別に インシデントハンドリング( インシデントの届出受付 依頼に応じた対応 ) の活動を行っている 5

7 1.4. 国際標準とパートナーシップの整合に関する仮説 日本のみの独自ルールや国際標準との不整合 ギャップを解消しなければ グローバル企業における統合ルールとしてパートナーシップを位置付けることが難しくなるのではないか 検討結果 グローバル企業から見た場合 国際標準を統合ルールに採用した場合も パートナーシップと矛盾なく整合することが重要 仮説 国際標準と競合するのではなく 国際標準を実装した先進事例となることをめざす 実態 海外の研究者から JPCERT/CC にソフトウェア製品の脆弱性が届け出られた実績あり ( 公表済 19 件 ) 実態 POC 登録している海外のソフトウェア製品開発者は 100 社程度 仮説 海外 ( アジア 豪州等 ) のソフトウェア製品開発者や研究者に対し パートナーシップを積極的に展開することも可能 今後の対応 パートナーシップと国際標準との整合に着手すべき パートナーシップの国際展開の是非について検討すべき 6

8 ドメイン件数 (2013 年 10 月末 ) 備考 受理した届出 JP 5,463 件 連絡先が国外と思われるため英語で連絡 (10 件程度 ) 上記は 左記の件数の内数です 不受理の届出 合計 1.5. 日本企業の海外拠点のサイトに脆弱性があった場合の対応に関する仮説 日本企業の脆弱性問題が結果的に放置されるリスクがあるのではないか P ガイドラインの適用の範囲 (P ガイドラインより引用 ) 主に日本国内からのアクセスが想定されるサイトで稼動するウェブアプリケーション 例えば 主に日本語で記述されたウェブサイトや URL が jp ドメインのウェブサイト等を指します ウェブサイトの届出のドメイン名で分類した件数 JP 以外 1,830 件 連絡先が国外と思われるため英語で連絡 (30 件程度 ) 上記は 左記の件数の内数です 172 件 7,465 件 ウェブサイトの届出で 外国語サイトのために不受理にした件数 不受理の届出 不受理理由 外国語サイトのため その他 ( 外国語サイトとは別の理由 ) 件数 7 34 件 138 件 実態 受理分については 連絡先が国外でも適宜対応 (40 件程度 ) JP 以外のドメインかつ外国語サイトのため不受理とした案件は 34 件 仮説 深刻な規模ではない? 今後の対応 企業側のニーズを踏まえ 対応を検討すべき

9 1.6. 報告書の全体構成 仮説 調査 脆弱性情報の取扱における国際的な対応の実態 1 章 日本のみの独自ルールや国際標準との不整合 ギャップを解消しなければ グローバル企業における統合ルールとしてパートナーシップを位置付けることが難しくなるのではないか 日本企業の脆弱性問題が結果的に放置されるリスクがあるのではないか 国際標準と情報セキュリティ早期警戒パートナーシップ 2 章 パートナーシップの活動に関連する国際標準について調査し パートナーシップガイドライン ( 以下 P ガイドライン という ) との整合性を明らかにした 現在 製品開発者の脆弱性開示に係る対応を規定するガイドライン (ISO/IEC 29147: Vulnerability disclosure ) や製品開発者の組織内での脆弱性情報取扱い手順を規定するガイドライン (ISO/IEC 30111: Vulnerability handling processes ) の国際標準化が完了した段階にある ソフトウェア製品開発者における国際的な脆弱性情報の取扱い 3 章 ソフトウェア製品開発者に対して調査を実施し ソフトウェア製品等の脆弱性情報の取扱いに関して国際的な対応が必要とされる場面を明らかにして 当該組織が抱える課題を明らかにした グローバルなウェブサイトにおける脆弱性対応 4 章 グローバルに展開しているウェブサイトを運営する組織について調査を実施し 脆弱性への対応に関して国際的な対応が必要とされる場面を明らかにした 検証 情報セキュリティ早期警戒パートナーシップのグローバル化対応に向けて 5 章 上記の全体仮説や調査結果を踏まえ パートナーシップにおける国際的な対応を要する場面と課題を整理し 方針と対応策について検討する 8

10 2. 国際標準と情報セキュリティ早期警戒パートナーシップ 2.1. 概要 2.2. ステークホルダ 2.3.ISO/IEC Vulnerability Disclosure 脆弱性の公開 2.4.ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 2.5. 情報セキュリティ早期警戒パートナーシップから見た国際標準 9

11 2.1. 概要 ISO/IEC Vulnerability disclosure 外部の個人又は組織からの潜在的な脆弱性に関する情報の受領 及び影響を受けるユーザへの脆弱性対策情報 (vulnerability resolution information) の配布を ベンダが通常のビジネスプロセスに組み込むにあたっての指針を提供する 対象 : 脆弱性に関する届出を受領し 必要時にアドバイザリを配布する方法を必要とするユーザ又は組織 ISO/IEC Vulnerability handling processes 製品やオンラインサービスの潜在的な脆弱性を発見した個人や組織によって届け出られた潜在的な脆弱性の情報を処理し 解決するにあたっての指針を提供する 対象 : 受領した脆弱性に関する届出を取扱う社内プロセスを強化したいと望む組織 P ガイドラインには 以下の事項を記載 ベンダの外側における脆弱性情報の流通のしくみ JPCERT/CC とベンダとの情報のやりとり ISO/IEC ベンダの行動基準 ISO/IEC 29147,

12 2.2. ステークホルダ P ガイドラインと国際標準のステークホルダの構成は類似しているが 一致しているわけではない P ガイドライン 製品開発者ソフトウエアを開発した企業または個人です 企業の場合それが外国の会社である場合には そのソフトウエア製品の国内での主たる販売権を有する会社 ( 外国企業の日本法人や総代理店など ) を指します ウェブサイト運営者脆弱性関連情報が発見されたウェブアプリケーションを運営する主体です 当該ウェブアプリケーションが企業や組織によって運営されているのであれば その企業や組織が該当します 個人によって運営されているのであれば その個人が該当します ( 現行の P ガイドラインでは未定義 本年度の改訂案にて下記を提案 ) システム構築事業者ソフトウエア製品を入手し それを使ってシステムを構築し 利用者に提供する企業または個人です システムの保守 運用のサービスを提供することもあります 国際標準 (ISO/IEC29147, ISO/IEC30111) ベンダ個人または組織 当該製品やサービスを開発した 又はその維持管理に対して責任がある オンラインサービスベンダハードウェア ソフトウェア 又はそれらの組合せにより実施されるサービスで 通信線又は通信網上に提供される 例 : サーチエンジン オンラインバックアップサービス インタネットホステッドメール 及びオンラインサービスと考えられるソフトウェア 中間ベンダベンダからサブシステムを入手し それを使ってシステム又はサービス ( 又は両方の組み合わせ ) をユーザ ( 又は他の中間ベンダ ) に提供する 典型的な例では次のようなのものがある : 1) システムハウス : 例として PC や OS と自社のヘルスケア管理ソフトウェアを合わせ 統合したシステムを医師に販売する ( 保守契約も一緒に提供することも ) 2) 携帯電話本体とサービス契約を合わせて提供する通信事業者等 11

13 2.3.ISO/IEC Vulnerability Disclosure 脆弱性の公開 1 概要 ISO/IEC JTC1 SC27 WG3 にて国際標準化 (2014 年可決 ) Target publication date: 潜在的な脆弱性に関する情報の受領及び脆弱性対策情報 (vulnerability resolution information) の配布を ベンダがビジネスプロセスに組み込むにあたっての指針を提供 適用範囲 1) ベンダに対して 製品又はオンラインサービスの潜在的な脆弱性に関する情報の受領方法についての指針を提供する 2) ベンダに対して 製品又はオンラインサービスの潜在的な脆弱性の対策情報 (resolution information) の配布方法についての指針を提供する 3) ベンダが脆弱性公開プロセスの導入を通じて生成するべき情報項目を提供する 4) 情報項目が含むべきコンテンツを提供する 製品又はオンラインサービスの定義 製品とは ベンダからユーザに有償又は無償で提供されるソフトウェア又はシステムをいう 販売モデル 配布モデル サポートモデルによって ベンダが正確なユーザリストを保持している場合もあれば ない場合もある これは 脆弱性の影響を受けるユーザにどう通知するかを考えるうえで重要となる オンラインサービスとは ネットワーク 一般的にはインターネットを通じてサービスを提供するソフトウェアアプリケーションである 12

14 2.3.ISO/IEC Vulnerability Disclosure 脆弱性の公開 2 構成 1. 適用範囲 2. 引用規格 3. 用語及び定義 4. 略語 5. 概念 5.1 一般 5.2 ISO/IEC 脆弱性の公開と ISO/IEC 脆弱性取扱いプロセスの接点 5.3 製品とオンラインサービス 5.4 ステークホルダー 5.5 脆弱性公開プロセスの概要 5.6 脆弱性公開プロセスにおける情報交換 5.7 交換情報の機密性 5.8 脆弱性アドバイザリ 5.9 脆弱性の悪用 6. 脆弱性公開ポリシーにおける考慮事項 7. 脆弱性情報の受領 8. ベンダ間における脆弱性の報告 9. アドバイザリの配布 各章で考慮事項や実施すべきプロセス 含むべき内容等を記載 付録 A.( 補足情報 ) 脆弱性 / アドバイザリ情報の取扱いに関する詳細 付録 B( 補足情報 ) ポリシー アドバイザリ グローバルレベルでの調整例 13

15 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC 用語及び定義 3.2 調整機関 5. 概念 調整機関 脆弱性情報の取扱い及び公開にあたって ベンダと発見者を支援するオプション的な関係者 調整機関 ベンダと発見者の間を取り持ち 前向きなコミュニケーションと脆弱性プロセスを促進するオプション的な関係者をいう コンピュータセキュリティインシデントレスポンスチーム (CSIRT) の中には 運用として脆弱性に関する調整サービスを提供しているところもある 他の CSIRT は 事案ごとに調整を支援する 調整サービスを提供するベンダもある 調整機関が提供する主なサービスには以下を含む : 発見者に対し ベンダの特定と連絡を支援する 複数ベンダに影響を及ぼす脆弱性に関する調整を行う 届出を受けた脆弱性の技術的分析及び検証を行う アドバイザリを公表する調整機関はしばしば顧客層を守ることに関心を寄せるが 技術的に客観的であり 全てのステークホルダーのリスクを軽減するよう努めるべきである P ガイドライン [P ガイドラインは定義無 告示の記載は以下 ] Ⅲ. 本基準における関係者の定義 /3. 調整機関脆弱性関連情報に関して 製品開発者への連絡及び公表等に係る調整を行う機関 3.6 製品 販売用の 又は無償で提供されるシステム又はサービス Ⅱ. 用語の定義と前提 /5. ソフトウエア製品ソフトウエア自体又はソフトウエアを組み込んだハードウエア等の汎用性を有する製品のことです ただし オープンソースソフトウエアのように技術情報を統括する企業が一社に定まらないもの 複数の者又は団体によりその改善が行われるものも含みます 具体例は 付録 4に示します 製品製品とは ベンダからユーザに有償又は無償で提供されるソフトウェア又はシステムをいう 製品には特定のユーザとの契約によって個別に開発されるソフトウェア ライセンス形態のもの 他の製品で使われることを想定したライブラリ 商用既製品 (COTS) コミュニティによる開発プロジェクト 遊びや趣味として提供されるものなどを含む ( が これらだけに限定されるわけではない ) 多数の異なるタイプの製品が存在する この規格の目的にとって ハードウェア製品とソフトウェア製品の区別はあまり重要ではない 販売モデル 配布モデル サポートモデルによって ベンダが正確なユーザリストを保持している場合もあれば ない場合もある これは 脆弱性の影響を受けるユーザにどう通知するかを考えるうえで重要となる 全ての製品利用者を把握している場合の通知について記載

16 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC 中間ベンダ 中間ベンダ 製品やサービスの開発者ではないが より大規模なシステムの一部としてや 再販業者として提供し ベンダ自身が開発したのではない製品やサービスの保守を担う個人又は組織 中間ベンダは ベンダからサブシステムを入手し それを使ってシステム又はサービス ( 又は両方の組み合わせ ) をユーザ ( 又は他の中間ベンダ ) に提供する 典型的な例では次のようなものがある : 1) システムハウス : 例として PC や OS と自社のヘルスケア管理ソフトウェアを合わせ 統合したシステムを医師に販売する ( 保守契約も一緒に提供することも ) 2) 携帯電話本体とサービス契約を合わせて提供する通信事業者 P ガイドライン - P ガイドラインでは明確に規定していない 3.5 オンラインサービス オンラインサービスの定義 オンラインサービス ハードウェア ソフトウェア 又はその組み合わせによって実装され 通信回線又はネットワーク経由で提供されるサービス注記 1 ホスティングされたコンテンツには財産的価値があることもある例検索エンジン オンラインバックアップサービス ウェブメール及び SaaS などがオンラインサービスと考えられる注記 2 オンラインサービスを提供するベンダは サービスプロバイダと呼ばれることもある オンラインサービスと製品は 主に両者ともソフトウェアシステムだという点で類似している オンラインサービスと製品の 2 つの主な相違点は サービスはユーザにとって 1 つのソフトウェアのように見えるという点と ユーザはソフトウェアのインストール 管理 又は展開を行わず サービスを利用するだけという点である オンラインサービスとは ネットワーク 一般的にはインターネットを通じてサービスを提供するソフトウェアアプリケーションである オンラインサービスベンダは サービスプロバイダと呼ばれることもある オンラインサービスは 両者とも主にソフトウェアシステムであるという点で製品と似ている オンラインサービスと製品の 2 つの主な違いは オンラインサービスはユーザにとってしばしば 1 つのソフトウェアに見えるという点と ユーザはソフトウェアのインストール 管理 又は展開を行わず サービスを利用するのみという点である Ⅱ. 用語の定義と前提 /7. ウェブアプリケーションインターネットのウェブサイトなどで 公衆に向けて提供するサービスを構成するシステムで そのソフトウエアがサイトごとに個別に設計 構築され 一般には配布されていないもののことを指します

17 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC 公開フェーズ オンラインサービスにも対策を実施した旨の公表を要請 ベンダは対策 (remediation) を配布する オンラインサービスであれば ベンダは対策 (remediation) を実施し その旨を文章で記す 製品であれば ベンダは通常脆弱性アドバイザやソフトウェアパッチ ソフトウェアアップデートといった形で解決策 (remediation) や軽減策情報をユーザに提供し ユーザが対策 (remediation) を実施する とりわけ当該脆弱性への攻撃が活発的に行われていたり 既に一般に知られている場合 対策 (remediation) が利用可能になる前にベンダがアドバイザリを出すこともある できれば ベンダは対策 (remediation) が新しい脆弱性や 全体の品質に関わる問題 他の製品及びサービスとの相互運用性に支障をきたさないことを確実にするよう努めなければならない P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 7) 対策方法の周知製品開発者は 対策方法を作成した場合 脆弱性情報一般公表日以降 それを利用者に周知してください 望ましい公表の手順を 付録 5 に示します Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 5) 脆弱性関連情報の公表ウェブサイト運営者は ウェブアプリケーションの脆弱性関連情報に関して 積極的に公表する必要はありません 3.10 脆弱性悪用される可能性のある ソフトウェア ハードウェア 又は オンラインサービスの弱点 脆弱性脆弱性とは 一般的に ユーザの明白な又は暗黙のセキュリティポリシーの侵害を可能にする一連の状態をいう ユーザのセキュリティポリシーの侵害は 概してユーザにとって悪影響又は損失をもたらす 損失を分類する一般的な方法の 1 つが 機密性 完全性 可用性への影響の考察である 例えば 攻撃者によるユーザシステムへの悪意のあるソフトウェアのインストールを可能にする脆弱性は 攻撃者が機密情報を閲覧したり変更するのにその悪意のあるソフトウェアを使うことができるため 機密性や完全性に深刻な影響を与え可能性がある ネットワーク製品の脆弱性で製品をクラッシュされるような脆弱性は 可用性に影響を及ぼす 脆弱性の実際の影響度は どのようにその製品が使用されているか 及び他の主観的要因による Ⅱ. 用語の定義と前提 /1. 脆弱性の定義脆弱性とは ソフトウエア製品やウェブアプリケーション等において コンピュータ不正アクセスやコンピュータウイルス等の攻撃により その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です

18 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC 脆弱性公開ポリシーにおける考慮事項 6.2 ポリシーに最低限含むべき内容ベンダは脆弱性公開ポリシーを策定するべきだが ポリシーが機微な情報を含むこともあるため 公開するのはその一部だけとしてもよい 脆弱性公開ポリシーは 最低でも以下の情報を含むべきである a) どのようにベンダに連絡して欲しいか b) セキュアな通信オプション c) 予想されるやり取りの説明 d) 脆弱性と思われる届出を行う際に役立つ可能性がある情報 e) 範囲外のサービス多くの場合 脆弱性の届出に対処するチームは セキュリティインシデントや他のセキュリティに関する質問に対応していることができない そうした種類のリクエスト用の連絡先も明確にする P ガイドライン - P ガイドラインでは ベンダが脆弱性公開ポリシーを策定することやその内容について言及していない ベンダは 脆弱性及び可能な対策 (remedies) を理解する助けになるさらなる詳細情報の提出を発見者に提案することを望むかもしれない そうした目的のフォームを提供することを検討してもよい f) 届出をどう追跡するかベンダは 受領した 脆弱性と思われる届出の進展を追跡する方法を定義し その方法を発見者に伝えるべきである 6.3 ポリシーにオプションとして含める内容脆弱性公開ポリシーには 複数のオプション情報を含む可能性がある a) 発見者の功績 b) 一般公開の同期 c) 配布

19 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC 脆弱性情報の受領 7 日以内の連絡を推奨 中間ベンダについて記載 7.2 潜在的な脆弱性の情報と安全な受領モデル潜在的な脆弱性の情報は 脆弱性取扱プロセスの開始を促すために 発見者からベンダ又は調整機関に届出が行われる 脆弱性の届出は 実証コードなど機微な情報を含む可能性があるため ベンダは情報を安全に受領する方法を提供するべきである 7.3 受理の確認ベンダは 脆弱性公開ポリシーに規定された時間軸以内に 脆弱性の届出に対処するべきである 発見者への脆弱性を受理した旨の連絡は 暦で 7 日以内に行うことが推奨される 7.4 届出の追跡ベンダは潜在的な脆弱性に関する全ての届出を記録し 追跡する仕組みを保有するべきである 仕組みは 各届出を一義的に追跡できなければならない この課題は ベンダ 中間ベンダ 発見者 調整機関 又は他の脆弱性公開プロセスに関わる誰が行っても良い 7.5 発見者との進行中のやり取りベンダは届出を受けた問題を評価し 脆弱性かそうでないかを判断しなければならない ベンダは 結果について発見者に ( もし調整機関が関与していれば調整機関にも ) 知らせるべきである 中間ベンダは 潜在的な脆弱性に関して自身で判断できるか 関連するサブシステムを購入したベンダを巻き込む必要があるか 確認しなければならない 他のベンダの関与を必要とし そのために回答が遅れる場合 中間ベンダは発見者及び / 又は調整機関にその事実と今後の進め方について知らせるべきである P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 2) 脆弱性検証の実施製品開発者は JPCERT/CC から脆弱性関連情報を受け取ったら ソフトウエア製品への影響を調査し 脆弱性検証を行い その結果を JPCERT/CC に報告してください 4) 発見者との直接の情報交換製品開発者は JPCERT/CC から脆弱性関連情報を受け取った後 JPCERT/CC および IPA を介し 発見者の了解を得て 発見者と直接情報交換を行うことができます 5) 問い合わせへの対応製品開発者は JPCERT/CC からの脆弱性関連情報に係わる技術的事項および進捗状況に関する問い合わせに的確に答えてください Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 1) 脆弱性関連情報への対処ウェブサイト運営者は 通知を受けたら 脆弱性の内容の検証および脆弱性の及ぼす影響を正確に把握した後 影響の大きさを考慮し 脆弱性を修正してください また 当該脆弱性関連情報に関して検証した結果 および修正した場合その旨を IPA に連絡してください この連絡は IPA から脆弱性関連情報の通知を受けてから 3 ヶ月以内を目処としてください

20 2.3.ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC 脆弱性情報の受領 ( 続き ) 7.6 詳細情報調査中 ベンダが脆弱性の完全な評価を行うのに十分な情報を欠いている場合もある その場合 ベンダは事前に合意した通信チャネルを通じて 発見者に追加情報の提供を依頼する 7.7 調整機関からの支援調製機関は 脆弱性公開プロセスの中で複数の役割を果たす可能性がある 1) 関係者間の信頼のおける仲介役を務める 2) アドバイザリの一般公開日を調整する 3) 関係者 ( ベンダと発見者 ) の間のやり取りを可能にする 4) 異なる組織の専門家たちが脆弱性への取組みを協働して行うことを可能にする環境又はフォーラムを提供する調製機関の選択は 地理的な近接性 言語 及運用モデルが合っているかなどの要因によることがある 脆弱性の影響を受けるベンダが複数ある場合 ベンダはアドバイザリを公開するタイミングを 直接もしくは調整機関の支援により調整するべきである ベンダは調整機関に対して CVE-ID の提供又は取得を依頼することもある 場合によっては 1 つ以上の調整機関が関与することもある ベンダは 複雑さや混乱を低減するため 1 つの調整機関がリーダー役を行うよう提案するのがよい 19 P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 1) 窓口の設置製品開発者は JPCERT/CC との間で脆弱性関連情報に関する情報交換を行うための窓口を設置し あらかじめ JPCERT/CC に連絡してください この窓口が JPCERT/CC の製品開発者リストに登録されることになります 2) 脆弱性検証の実施製品開発者は JPCERT/CC から脆弱性関連情報を受け取ったら ソフトウエア製品への影響を調査し 脆弱性検証を行い その結果を JPCERT/CC に報告してください /5. その他 2) IPA および JPCERT/CC による普及支援 IPA および JPCERT/CC は 上記 1) の連絡を受け取った 当該脆弱性関連情報及び対策方法を JVN で公表します 公表する時期については 製品開発者と事前に調整を図ります Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 1) 脆弱性関連情報への対処ウェブサイト運営者は 通知を受けたら 脆弱性の内容の検証および脆弱性の及ぼす影響を正確に把握した後 影響の大きさを考慮し 脆弱性を修正してください また 当該脆弱性関連情報に関して検証した結果 および修正した場合その旨を IPA に連絡してください この連絡は IPA から脆弱性関連情報の通知を受けてから 3 ヶ月以内を目処としてください

21 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC ベンダ間における脆弱性の報告 9. アドバイザリの配布 8.1 全般届出を受けた脆弱性の詳細調査の結果 ベンダはその脆弱性が他のベンダが供給しているコンポーネント 又は基盤となるプラットフォームに起因するもので 自分たちでは解決できないものと気づくかもしれない このような場合を含め ベンダは時に脆弱性について他のベンダに報告することが望ましい状況に遭遇することがある この節では ベンダ間におけるそうした脆弱性の報告がどのように行われるべきかについて述べる 全般 以下では アドバイザリに含むべき項目の一覧について詳細を記す 一覧は網羅的なものではなく ベンダは状況に応じて他の情報を含めて構わない ID タイトル 概要 影響を受ける製品 対象とする読者 説明 影響 対策 (Remediation) 参考情報 功績者 更新履歴 連絡先 利用規約 P ガイドライン - 国内では JPCERT/CC を介した形で情報を共有 (P ガイドラインの記載はなし ) 付録 5 ソフトウエア製品開発者による脆弱性対策情報の公表マニュアル 3.1. 脆弱性対策情報の公表項目 タイトル 概要 該当製品の確認方法 脆弱性の説明 脆弱性がもたらす脅威 対策方法 回避策 関連情報 謝辞 更新履歴 連絡先

22 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC アドバイザリの配布 9.4 アドバイザリ公開のタイミングベンダは アドバイザリの公開タイミングを計る際に リスクを天秤に掛けて考えなければならない 脆弱性の解決策 (remediation) は存在しないが 攻撃が行われているのであれば ベンダはユーザにリスクとリスクを軽減又は取り除くためにできることを知らせるため アドバイザリを公開する必要があるかもしれない そうでなければ ベンダは対策 (remediation) が準備ができたと同時にアドバイザリを公開するべきである 脆弱性が攻撃者によって盛んには悪用されていない場合 対策 (resolution) の準備ができ次第 アドバイザリと対策 (resolution) を発行することが望ましい しかし 同じ製品やオンラインサービスの複数のアドバイザリが関わっている場合は 対策 (resolutions) が引き起こす運用中断回数を全体として減少させるためにも それらのアドバイザリを同時に出した方がよい 脆弱性が攻撃者によって盛んに悪用されている 又は脆弱性が故意に 又は意図せず一般に公開されている場合 その脆弱性に責任を負うベンダは 回避策又は暫定的対策を添えて迅速にアドバイザリを出すことを検討するべきである それが パッチや修正 (fix) が提供されるまでの短期的な解決策 (solution) になるかもしれない その場合 最新の詳細がわかったら アドバイザリもアップデートされるべきである P ガイドライン - 解決策がない場合のアドバイザリ公開を言及

23 ISO/IEC Vulnerability Disclosure 脆弱性の公開 3P ガイドラインの整合性 ISO/IEC アドバイザリの配布 9.6 アドバイザリの提供手段ベンダは ユーザにアドバイザリを提供するのに適切な方法を確立し 維持するべきである 一般的な方法には ウェブサイト メーリングリスト フィード 自動アップデートメカニズムなどがある 各ベンダで 自社のユーザコミュニティにとって最適の方法を決めるとよい ベンダはより幅広い読者と情報を共有するために アドバイザリを公共の脆弱性ディスカッション フォーラムに投稿することを選ぶこともできる P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 7) 対策方法の周知製品開発者は 対策方法を作成した場合 脆弱性情報一般公表日以降 それを利用者に周知してください 望ましい公表の手順を 付録 5 に示します Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 5) 脆弱性関連情報の公表ウェブサイト運営者は ウェブアプリケーションの脆弱性関連情報に関して 積極的に公表する必要はありません ただし この脆弱性が原因で 個人情報が漏洩したなどの事案が起こったまたは起こった可能性がある場合 二次被害の防止および関連事案の予防のために 以下の項目を含むように公表してください また 当該個人からの問い合わせに的確に回答するようにしてください

24 2.4.ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 1 概要 ISO/IEC JTC1 SC27 WG3 にて国際標準化 (2013 年 ) publication date: 製品またはオンラインサービスの潜在的な脆弱性情報を処理し 解決する方法についてのガイドラインを提供する 脆弱性の取扱いに関係するベンダにも適用可能 適用範囲 1) 製品やオンラインサービスにおける潜在的な脆弱性情報の処理方法や解決方法について ガイドラインを与える 2) 脆弱性の取扱いに関係するベンダに適用可能 3) 潜在的な脆弱性報告の受領時点と脆弱性解決情報の配布時点で ISO/IEC29147 に記載された要素をつなぐ 4) ISO/IEC (IT セキュリティのための評価基準パート 3): 13.5 不具合改善 (ALC_FLR)) におけるセキュリティ保証コンポーネントの関連要素を考慮している 製品又はオンラインサービスの定義 製品とは 販売又は無償提供のため 導入された又は改良された システム又はサービス オンラインサービスとは ハードウェア ソフトウェア 又はそれらの組合せにより実施されるサービスで 通信線又は通信網上に提供される 例 : サーチエンジン オンラインバックアップサービス インターネットホステッドメール 及びオンラインサービスと考えられるソフトウェア ベンダとは 開発した当該製品やサービス 又はその維持管理に対して責任がある個人または組織 脆弱性とは 攻撃される可能性のある ソフトウェア ハードウェア 又はオンラインサービスの弱点 23

25 2.4.ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 2 構成 1. 適用範囲 2. 引用規格 3. 用語及び定義 4. 略語 5.ISO/IEC29147( 脆弱性開示 ) と ISO/IEC 30111( 脆弱性取扱いプロセス ) の間のインタフェース 6. 脆弱性取扱いプロセスのためのポリシーと組織上のフレームワーク 6.1 一般 6.2 脆弱性取扱いポリシー 6.3 脆弱性取扱いプロセスを支援するための組織上のフレームワークの策定 6.4 ベンダ CSIRT 又は PSIRT 一般 脆弱性レスポンスチームの使命 脆弱性レスポンスチームの責任 スタッフの能力 6.5 製品担当部門の責任 6.6 顧客支援部門と広報部門の責任 7. 脆弱性取扱いプロセス 7.1 脆弱性取扱いフェーズの紹介 7.2 脆弱性取扱いフェーズ 一般 脆弱性報告の受領 検証 解決策の策定 プロセスにおける次段階への脆弱性解決策のリリース 解決策適用後の活動 7.3 脆弱性取扱いフェーズの監視 7.4 脆弱性情報の機密性 8. サプライチェーン脆弱性取扱いプロセス 24

26 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 用語及び定義 3.1 調整者 オプションの参加者で 脆弱性情報の取扱いや開示をする際に ベンダや発見者を補助できる 3.6 製品販売又は無償提供のため 導入された又は改良された システム又はサービス 注記 : 情報技術においては ハードウェアとソフトウェア製品をしばしば区別する とは言っても その境界は常に明確ではないが 例 : ルータは 例え重要な部品がソフトウェア及び / 又はファームウェアであっても ハードウェア製品としてみることができる 3.5 オンラインサービス ハードウェア ソフトウェア 又はそれらの組合せにより実施されるサービスで 通信線又は通信網上に提供される 例 : サーチエンジン オンラインバックアップサービス インタネットホステッドメール 及びオンラインサービスと考えられるソフトウェア P ガイドライン [P ガイドラインは定義無 告示の記載は以下 ] Ⅲ. 本基準における関係者の定義 /3. 調整機関脆弱性関連情報に関して 製品開発者への連絡及び公表等に係る調整を行う機関 Ⅱ. 用語の定義と前提 /5. ソフトウエア製品ソフトウエア自体又はソフトウエアを組み込んだハードウエア等の汎用性を有する製品のことです ただし オープンソースソフトウエアのように技術情報を統括する企業が一社に定まらないもの 複数の者又は団体によりその改善が行われるものも含みます 具体例は 付録 4 に示します Ⅱ. 用語の定義と前提 /7. ウェブアプリケーションインターネットのウェブサイトなどで 公衆に向けて提供するサービスを構成するシステムで そのソフトウエアがサイトごとに個別に設計 構築され 一般には配布されていないもののことを指します

27 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC ベンダ個人または組織 当該製品やサービスを開発した 又はその維持管理に対して責任がある 3.8 脆弱性攻撃される可能性のある ソフトウェア ハードウェア 又はオンラインサービスの弱点 P ガイドライン Ⅱ. 用語の定義と前提 9. 製品開発者製品開発者とは ソフトウエアを開発した企業または個人です 企業の場合それが外国の会社である場合には そのソフトウエア製品の国内での主たる販売権を有する会社 ( 外国企業の日本法人や総代理店など ) を指します 11. ウェブサイト運営者ウェブサイト運営者とは 脆弱性関連情報が発見されたウェブアプリケーションを運営する主体です 当該ウェブアプリケーションが企業や組織によって運営されているのであれば その企業や組織が該当します 個人によって運営されているのであれば その個人が該当します ウェブサイト運営者の例は 付録 4 に示します Ⅱ. 用語の定義と前提 /1. 脆弱性の定義脆弱性とは ソフトウエア製品やウェブアプリケーション等において コンピュータ不正アクセスやコンピュータウイルス等の攻撃により その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です

28 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 脆弱性取扱いポリシー策定 6.3 脆弱性取扱いプロセスを支援するための組織上のフレームワークの策定 ベンダは 脆弱性取扱いプロセス策定のため脆弱性を調査 修正する際に ベンダの意図を定義し明確化するために 脆弱性取扱いポリシーを策定し維持管理することが望ましい ポリシーは 二つの部分 ( 内部限定の部分と公開する部分 ) から構成することが望ましい 脆弱性取扱いは 単に工学や技術以外に 幾つかの付加的な側面を持っている ( 例 : 顧客支援及び広報 ) 組織的なフレームワークは 各エリアについて責任を持つベンダの関係部門によって 設計 認識 及び支援されることが望ましい 組織は 脆弱性取扱いについて責任を持ち決定する権限を持つような 役割や能力を できれば経営レベルで 有することが望ましい この役割や能力は ベンダのユーザに対する責任 内部プロセス 及び脆弱性取扱いに関する組織上のフレームワークを理解しておかなければならない 組織は 潜在的脆弱性を取扱う窓口になる 役割や能力を有することが望ましい この窓口は 製品やオンラインサービスを顧客に提供するベンダ内の部門や部署ごとに 特定されることが望ましい 組織は 外部の団体が脆弱性に関して連絡をして情報交換をするための窓口を確立することが望ましい 窓口は ベンダコンピュータセキュリティインシデントレスポンスチーム ( ベンダ CSIRT) 又は 製品セキュリティインシデントレスポンスチーム (PSIRT) の一部になるかも知れない 顧客やメディアは脆弱性の開示後に質問や付加情報要請をベンダに連絡するかもしれないため 顧客や広報に対する責任部門は対応できるように準備しておくことが望ましい P ガイドライン - Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 1) 窓口の設置製品開発者は JPCERT/CC との間で脆弱性関連情報に関する情報交換を行うための窓口を設置し あらかじめ JPCERT/CC に連絡してください この窓口が JPCERT/CC の製品開発者リストに登録されることになります Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 1) 脆弱性関連情報への対処ウェブサイト運営者は 通知を受けたら 脆弱性の内容の検証および脆弱性の及ぼす影響を正確に把握した後 影響の大きさを考慮し 脆弱性を修正してください また 当該脆弱性関連情報に関して検証した結果 および修正した場合その旨を IPA に連絡してください この連絡は IPA から脆弱性関連情報の通知を受けてから 3 ヶ月以内を目処としてください

29 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC ベンダ CSIRT 又は PSIRT 脆弱性レスポンスチームの使命や責任 スタッフの能力に言及 ベンダ CSIRT 又は PSIRT は 脆弱性の外部発見者からの脆弱性報告を調整することに対して責任がある 幾つかのケースでは ベンダ PSIRT は ベンダ内の内部チームによって報告された脆弱性についても 調整する 次の節では ベンダ CSIRT や PSIRT について 組織上の役割や責任について記述する 理解を明確にするために言うと PSIRT は 文書の残り全般にわたって この役割の参照をするために使われている 脆弱性レスポンスチームの使命ベンダの脆弱性取扱いプロセスにおいて ベンダ PSIRT は中心的な役割を果たしている 脆弱性取扱いを内部的に調整することに加えて それは脆弱性発見者や調整者のような外部の関係者に対して 唯一の窓口として活動する 脆弱性レスポンスチームの責任この節は 脆弱性レスポンスチームの責任について記述している 潜在的な脆弱性の外部発見者とのコミュニケーション 製品担当部門とのコミュニケーション 調整者や他のベンダとのコミュニケーション 脆弱性開示のタイミング 公開された脆弱性の監視 スタッフの能力ベンダ PSIRT のスタッフは以下を実施することが望ましい a) 報告された潜在脆弱性の性質を理解し それらを適切な団体に配布できること b) 脆弱性関連情報の機密性を理解し 解決策策定前に脆弱性詳細を漏洩しないようにそのような情報の扱いに精通していること c) 適宜 脆弱性取扱いに必要なアクションをとるために 適切な製品担当部門へ知らせること P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 3) 脆弱性情報の一般への公表日の調整製品開発者は 自社製品に新たな脆弱性の存在がある場合 脆弱性情報の一般への公表日について JPCERT/CC と相談してください なお 一般への公表日は IPA および JPCERT/CC が脆弱性関連情報の取扱いを開始した日時 ((1) 2) 参照 ) から起算して 45 日を目安とします 公表に更なる時間を要する場合は JPCERT/CC と相談してください 4) 発見者との直接の情報交換 5) 問い合わせへの対応 Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 1) 脆弱性関連情報への対処また 当該脆弱性関連情報に関して検証した結果 および修正した場合その旨を IPA に連絡してください この連絡は IPA から脆弱性関連情報の通知を受けてから 3 ヶ月以内を目処としてください 2) 問い合わせへの対応 3) 発見者との直接の情報交換

30 2.4.ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 製品担当部門の責任 製品担当部門の責任に言及 製品担当部門は そのベンダにて開発 又は実施された製品やオンラインサービス 及び又は他のベンダの製品やオンラインサービスと共に商品化された製品やオンラインサービス を顧客に提供する 彼らは 彼らの製品やオンラインサービスに影響する脆弱性取扱いプロセスの中核的な部分に責任を持つエンティティである 潜在的な脆弱性がベンダ PSIRT により製品担当部門に報告された時 その製品担当部門は修正案策定のため PSIRT と共に活動しなければならない 製品担当部門は もし案件が脆弱性でありバグの一種ではないと判断された場合に 案件を PSIRT にエスカレートする手段を有することが望ましい 担当部門内の製品セキュリティ連絡先は 製品やオンラインサービス内にある潜在的なセキュリティ脆弱性の通知を受けた時点で 脆弱性取扱いプロセスを主導することが望ましい このプロセスは いかなる必要なレスポンス行動でも ベンダの脆弱性レスポンスポリシーに基づいて実施されるように PSIRT の通知を含むことが望ましい 29 P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 2) 脆弱性検証の実施製品開発者は JPCERT/CC から脆弱性関連情報を受け取ったら ソフトウエア製品への影響を調査し 脆弱性検証を行い その結果を JPCERT/CC に報告してください また 他社のソフトウエア製品に類似の脆弱性があると推定される場合 JPCERT/CC に連絡してください また 何らかの理由で JPCERT/CC からの連絡を受け取れなかった場合も JPCERT/CC から連絡不能開発者として示された場合には すみやかに JPCERT/CC に連絡してください 6) 対応状況の連絡と対策方法の作成製品開発者は 脆弱性情報の一般の公表日までに 脆弱性関連情報に係わる対応状況を JPCERT/CC に連絡するとともに 脆弱性関連情報に係わる対策方法を作成するよう努めてください JPCERT/CC に対する対応状況の報告をもって IPA にも報告したこととみなされます また 対応状況が変わった場合 その都度 JPCERT/CC に最新の情報を連絡してください Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 1) 脆弱性関連情報への対処ウェブサイト運営者は 通知を受けたら 脆弱性の内容の検証および脆弱性の及ぼす影響を正確に把握した後 影響の大きさを考慮し 脆弱性を修正してください

31 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 顧客支援部門と広報部門の役割 顧客支援部門 広報部門の役割に言及 脆弱性取扱いの最終段階で 勧告はしばしば修正策と共にリリースされる 勧告がメーリングリストや直接のコミュニケーションにて顧客に送付される際は その普及連絡はしばしば顧客支援部門により実施される 顧客支援部門は 必要な顧客全てに通知するのに適切な手段を選択し 調整された開示日までに内密に維持することが望ましい 勧告を読んだ後に ユーザの中には 質問やベンダ支援の要請をするかもしれない 顧客支援部門は 勧告についての質問や要請への対応や展開する準備しておくことが望ましい ISO/IEC 脆弱性開示にて詳細化されているように ベンダの公開ウェブサイト上に発行されている勧告は容易にアクセスできることが望ましい 顧客支援や広報の部門は ベンダのウェブサイトの維持管理に関係しているかもしれないが 内のガイドラインを遵守するよう試みることが望ましい もし 公開された脆弱性が深刻で広く知っている案件の場合 広報部門は マスニュースメディアからの連絡先を準備しておくことが望ましい P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 7) 対策方法の周知製品開発者は 対策方法を作成した場合 脆弱性情報一般公表日以降 それを利用者に周知してください 望ましい公表の手順を 付録 5 に示します Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 5) 脆弱性関連情報の公表ウェブサイト運営者は ウェブアプリケーションの脆弱性関連情報に関して 積極的に公表する必要はありません ただし この脆弱性が原因で 個人情報が漏洩したなどの事案が起こったまたは起こった可能性がある場合 二次被害の防止および関連事案の予防のために 以下の項目を含むように公表してください また 当該個人からの問い合わせに的確に回答するようにしてください 個人情報漏洩の概要 漏洩したと推察される期間 漏洩したと推察される件数 漏洩したと推察される個人情報の種類 ( 属性など ) 漏洩の原因 問合せ先

32 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 法的な相談 7.1 脆弱性取扱いプロセスの紹介 ベンダは ベンダが内部ポリシー 法律 及び現存する契約に合致することを確実にするために 提案された修正内容やコミュニケーションについて法的な見直しが必要かもしれない 図 2 は 一般的な脆弱性取扱いプロセスについて概説している そのようなプロセスは一般的には ベンダにより実施される P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応製品開発者に係わる法的な論点は 付録 2 に示します Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者ウェブサイト運営者における法的な論点は 付録 3 に示します -

33 2.4.ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 脆弱性取扱いフェーズ 脆弱性報告を処理する際に生じる典型的なフェーズについて 記述する それは ベンダに 関連するプロセスを理解し 発生した各状況に対処するために 内部プロセスの生成や変更を許可するための最初のポイントを提供するものである 脆弱性報告の受領ベンダは内部又は外部のソースから脆弱性報告を受領する 検証検証中は 次の活動が発生する a) 初期調査 b) 起こり得るプロセスの終了 c) 根本原因分析 d) 更なる調査 e) 優先付け 32 P ガイドライン Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 2) 脆弱性検証の実施製品開発者は JPCERT/CC から脆弱性関連情報を受け取ったら ソフトウエア製品への影響を調査し 脆弱性検証を行い その結果を JPCERT/CC に報告してください また 他社のソフトウエア製品に類似の脆弱性があると推定される場合 JPCERT/CC に連絡してください また 何らかの理由で JPCERT/CC からの連絡を受け取れなかった場合も JPCERT/CC から連絡不能開発者として示された場合には すみやかに JPCERT/CC に連絡してください 4) 発見者との直接の情報交換製品開発者は JPCERT/CC から脆弱性関連情報を受け取った後 JPCERT/CC および IPA を介し 発見者の了解を得て 発見者と直接情報交換を行うことができます Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 1) 脆弱性関連情報への対処ウェブサイト運営者は 通知を受けたら 脆弱性の内容の検証および脆弱性の及ぼす影響を正確に把握した後 影響の大きさを考慮し 脆弱性を修正してください 3) 発見者との直接の情報交換ウェブサイト運営者は 脆弱性を修正するために IPA と協議の上 発見者の了解のある場合 発見者と直接情報交換を行うことが可能です

34 2.4.ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC P ガイドライン 7.2 脆弱性取扱いフェーズ ( 続き ) 解決策の策定脆弱性の解決策策定では 次ステップが順番に実施されることが望ましい a) 解決策の決定 b) 修正の実施 c) 修正内容の試験 プロセス内の次ステージへ脆弱性解決策のリリース脆弱性に対する解決策のリリースについて 脆弱性を解決するのにベンダが取れる二つの可能な経路を示す a) オンラインサービス b) 製品 解決策リリース後の活動脆弱性解決策をリリース後のベンダ活動は以下の通り a) ケースの維持管理 b) セキュリティ開発ライフサイクルフィードバック c) 監視 33 Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 3) 脆弱性情報の一般への公表日の調整製品開発者は 自社製品に新たな脆弱性の存在がある場合 脆弱性情報の一般への公表日について JPCERT/CC と相談してください なお 一般への公表日は IPA および JPCERT/CC が脆弱性関連情報の取扱いを開始した日時 ((1) 2) 参照 ) から起算して 45 日を目安とします 公表に更なる時間を要する場合は JPCERT/CC と相談してください 6) 対応状況の連絡と対策方法の作成製品開発者は 脆弱性情報の一般の公表日までに 脆弱性関連情報に係わる対応状況を JPCERT/CC に連絡するとともに 脆弱性関連情報に係わる対策方法を作成するよう努めてください JPCERT/CC に対する対応状況の報告をもって IPA にも報告したこととみなされます また 対応状況が変わった場合 その都度 JPCERT/CC に最新の情報を連絡してください Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 5) 脆弱性関連情報の公表ウェブサイト運営者は ウェブアプリケーションの脆弱性関連情報に関して 積極的に公表する必要はありません ただし この脆弱性が原因で 個人情報が漏洩したなどの事案が起こったまたは起こった可能性がある場合 二次被害の防止及び関連事案の予防のために 以下の項目を含むように公表してください

35 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC 脆弱性取扱い段階の監視 7.4 脆弱性情報の機密性 ベンダは 脆弱性取扱いプロセスの有効性を監視することが望ましい a) スピード : ベンダは 本プロセスを通して脆弱性を対処するのに要する時間を監視し 脆弱性解決のスピード改善に向けて努力することが望ましい b) 完全性 : ベンダは 脆弱性の根本原因に対処することを確実にするために 修正策の完全性を監視することが望ましい c) 持続性 : ベンダは 影響のあったユーザへリリースした後 修正策の有効性を監視することが望ましい ベンダは 機密にかかわる脆弱性情報の機密性維持のために 注意することが望ましい 保護すべき情報には 二つの重要なクラスがある 一つ目は 個人的な 又は組織上のアイデンティティに関する情報 ( 匿名希望の発見者の氏名 脆弱性の攻撃にさらされてしまった顧客の IP アドレス ) である 二つ目は まだ公表されていない又は広く知られていない脆弱性情報 ( まだ調査中の脆弱性 過度に攻撃者に利するような技術詳細 ) である P ガイドライン - Ⅳ. ソフトウエア製品に係る脆弱性関連情報取扱 /4. 製品開発者の対応 8) 製品開発者内の情報の管理製品開発者は 上記 3) で作成した脆弱性情報の一般公表スケジュールおよび脆弱性関連情報を 脆弱性情報を一般に公表する日まで第三者に漏洩しないように管理してください Ⅴ. ウェブアプリケーションに係る脆弱性関連情報取扱 /4. ウェブサイト運営者 4) ウェブサイト運営者内での情報の管理ウェブサイト運営者は 脆弱性が修正されるまでの間は 脆弱性関連情報を第三者に漏洩しないように管理してください ただし ウェブサイト運営者が脆弱性修正を依頼した外部機関 およびウェブサイトの管理を委託している外部機関には 秘密保持契約を締結した上で脆弱性関連情報を連絡することを推奨します なお ウェブサイト運営者は 脆弱性の修正の過程でソフトウエア製品の脆弱性であることを認識した場合 情報を適切に管理してください

36 ISO/IEC Vulnerability handling processes 脆弱性取扱いプロセス 3Pガイドラインの整合性 ISO/IEC サプライチェーン脆弱性取扱いプロセス 複数のベンダからのコンポーネントを含むような案件を解決するために 複数のベンダが脆弱性情報を共有するような例としては 次を含む a) ある任意の脆弱性 特定部分のソフトウェアに影響を及ぼすと報告されたが 特定の根本となる OS 又は CPU 内の案件により引き起こされている b) 多様な製品に組み込まれた 欠陥のある標準機能仕様内にある 又は公開されたアルゴリズム内にある 複数の脆弱性 c) 従来まで広く受け入れられた開発方法により自然に導入された 脆弱性 d) 共用ライブラリ内の脆弱性 e) 現存の維持管理者に不足しているソフトウェアコンポーネント内の脆弱性 P ガイドライン - 国内では JPCERT/CC を介した形で情報を共有 (P ガイドラインの記載はなし )

37 情報セキュリティ早期警戒パートナーシップから見た国際標準 1 特徴 国際標準では オンラインサービス の事業者 ( サービスプロバイダ ) を ベンダ に含めており 製品開発者と同様に脆弱性情報の受領や脆弱性情報を処理し解決する取組みを求めている ISO/IEC29147 では 以下の点が特徴的である ベンダからサブシステムを入手し それを使ってシステム又はサービス ( 又は両方の組み合わせ ) をユーザ ( 又は他の中間ベンダ ) に提供する 中間ベンダ を規定 オンラインサービスにも脆弱性対策を実施した旨の公表を要請 ベンダが脆弱性公開ポリシーを策定することやその内容について言及 ベンダに対し 発見者からの脆弱性の届出の受理の旨を 7 日以内に連絡することを推奨 全ての製品利用者を把握している場合の通知について記載 ベンダ間における脆弱性情報の共有について言及 ( 国内では JPCERT/CC を介して情報を共有 ) 解決策がない場合のアドバイザリ公開を言及 ISO/IEC30111 では 以下の点が特徴的である 脆弱性レスポンスチームの使命や責任 スタッフの能力に言及 製品担当部門の責任に言及 顧客支援部門 広報部門の役割に言及 ベンダ間における脆弱性情報の共有について言及 ( 国内では JPCERT/CC を介して情報を共有 )

38 2.5. 情報セキュリティ早期警戒パートナーシップから見た国際標準 2Pガイドラインとのギャップ 国際標準 (ISO/IEC29147 及び ISO/IEC30111 を指す ) におけるベンダ - の対応について P ガイドラインと大きく不整合 矛盾が生じる点は見られなかった ただし P ガイドラインと国際標準は趣旨が異なるため 記載内容の粒度や範囲に若干の相違点が見られる また ISO/IEC29147 には 細かいレベルで 整合性の確保に留意すべき点がいくつか見られる 留意すべき点 ISO/IEC29147 では オンラインサービス の事業者 ( サービスプロバイダ ) を ベンダ に含めており 製品開発者と同様に脆弱性情報の受領や脆弱性情報を処理し解決する取組みを求めている ISO/IEC29147 では ベンダが脆弱性公開ポリシーを策定することやその内容について言及している ISO/IEC29147 では 中間ベンダ やその活動について規定している ISO/IEC29147 では 脆弱性情報の受理に関し 7 日以内に連絡することを推奨している 課題 考え方 ウェブサイトが オンラインサービス に含まれるか不明 含まれるとした場合 これまでより高いレベルの対応 ( 脆弱性ハンドリング体制 脆弱性の公表等 ) が求められる SaaS/PaaS/IaaS 等のクラウドサービスは オンラインサービス に含まれることを踏まえ 対応を検討すべき 基本的に ウェブサイトの脆弱性として扱う方向 脆弱性公開ポリシーの策定は 製品開発者にとって負担となるが それを明記することでより適切に対応がなされる効果も期待できる 行動基準に含めるか 国際標準において推奨されている旨を注記してはどうか 中間ベンダ に相当するシステム構築事業者を規定する 代理店は既に製品開発者の枠で規定済 脆弱性情報の受理に関し製品開発者のとるべき行動に補足することを検討する 例 )JPCERT/CC から脆弱性関連情報が届いたらなるべく早く受理した旨を返信すること なお ISO/IEC29147 では 脆弱性情報の受理に関し 7 日以内に返信することを推奨している 37

39 情報セキュリティ早期警戒パートナーシップから見た国際標準 3メリットと考察 情報セキュリティ早期警戒パートナーシップから見た国際標準のメリット 海外に向けて情報セキュリティ早期警戒パートナーシップを説明する際 国際標準と整合することによって信頼感を高める効果が期待できる たとえば 国内のソフトウェア製品開発者が 情報セキュリティ早期警戒パートナーシップに対応している (= 国際標準に準拠している ) と海外の取引先に対して説明できるのであれば ソフトウェア製品開発者にとってもメリットがある ただし 国際標準はベンダの対応を中心に記載しており 各関係者の行動基準を示した P ガイドラインより踏み込んだ面がある したがって パートナーシップへの対応 = 国際標準への準拠 と言うためには 前頁で示した課題を含め 記載内容を検討する必要がある 国際標準の JIS 化に関する考察 JIS 化の意義は 一般に 1 認定 認証 審査等に関する共通の基準の確立 2 当該テーマの普及啓発 の 2 つである 上記の国際標準を JIS 化することで 製品開発者における脆弱性ハンドリングや情報開示の必要性に関する啓発効果は期待できる その一方 当該 JIS は情報セキュリティ早期警戒パートナーシップを前提としていないため 読者である製品開発者から見たとき ダブルスタンダードに見えてしまう懸念がある なお 実務的には 当該案件の国際標準化活動に関わった技術者 国際標準化を推進する有識者もしくは実務家 さらに 経済産業省や日本規格協会等との折衝 調整を担当する調整役などの体制を整えることが必要となる

40 3. ソフトウェア製品開発者における国際的な脆弱性情報の取扱い 3.1. 調査方針 3.2. 調査結果 : 国内のソフトウェア製品開発者のグローバル展開 3.3. 調査結果 : 海外のソフトウェア製品開発者の国内展開 3.4. 調査結果 : 海外のソフトウェア製品の国内販売代理店の国内展開 3.5. ソフトウェア製品開発者における国際的な脆弱性情報の取扱いに関する課題 39

41 調査方針 ソフトウェア製品開発者に対してヒアリング調査を実施し ソフトウェア製品等の脆弱性情報の取扱いに関して国際的な対応が必要とされる場面を明らかにし 当該組織が抱える課題を把握する [ 調査方法 ] ヒアリング調査 [ 調査対象 ] ソフトウェア製品開発者の製品セキュリティ担当者 調査対象者仮説イメージ ( 案 ) 自社製品をグローバルに展開している国内のソフトウェア製品開発者 (3 件 ) 日本法人を有する海外のソフトウェア製品開発者 (4 件 ) 海外のソフトウェア製品の国内販売代理店 (1 件 ) 海外の発見者から情報が入るパスが複数あり未整理 グローバルな情報提供のコストを削減したい 国内 国外で行う情報提供の質はほぼ同じ 日本の発見者との詳細な情報交換にも日本法人が関与する 日本の発見者との詳細な情報交換は海外本社が行う

42 調査結果 : 国内のソフトウェア製品開発者のグローバル展開 1 テーマ 脆弱性対応の体制 グループ全体として 海外拠点とのフォーメーションが未整備 シングル POC ではなく 現地 POC がグローバルに連携 調整する形があるべきモデル シングル POC の場合 海外から現地語で連絡が来るため 気づかない可能性もある また 現地 POC でないと 現地政府の政策や法制度を汲み取るのが難しいこともある インシデントと脆弱性で体制が分かれている インシデントでは SE サポート系が先に動く 脆弱性は 自社製品の脆弱性についてウェブページを通して受け付けている 顧客からの条件に脆弱性対応が入っていることがある 海外で発見されて 当社に直接連絡が来た事例は少ない 海外の調整機関から直接連絡が来るケースが年 1 回程度 海外からの問い合わせは 2005 年頃から今まで 4~5 件程度 セキュリティ研究者やセキュリティベンダからで 国別にはスペイン ドイツ シンガポール シリア等 US-CERT から直接届くことはなく JPCERT/CC 経由に統一されている ただし 制度が始まる以前は CERT/CC から現地法人に連絡がきたこともあった 回答

43 調査結果 : 国内のソフトウェア製品開発者のグローバル展開 2 テーマ 国際的なギャップ 日本で作って海外で販売が主流だったが 最近は現地開発も始めている 米国であっても作り手の意識はそれほど進んでいない 脆弱性情報や対策を公開 無償提供することが理解されない ( 国内中小企業においても同様 ) 海外の場合 パッチ適用のサポート費用をどうするのかという課題もある 現地でのエスカレーションルールを統一 徹底できないため 脆弱性問題が POC に入ってこないケースがある 日本の POC へ現地語で問合せがあった場合 正確に対応できず見逃す可能性がある 暗号機能を搭載するソフトウェア製品のパッチを海外に提供する場合 マスマーケット品はダウンロード提供が可能だが そうではないビジネス サーバ用製品は輸出管理規制の対象となり 現地でダウンロード提供ができず申込制にしている また 現地政府の暗号輸入規制も NSA 盗聴疑惑の影響でますます厳しくなり 使用している暗号の明示を求められる可能性もある 現在は日本語と英語のサイトしかないが 今後 ウェブサイトをローカル言語で出すようになれば ローカル言語での脆弱性届出がくる可能性もある ローカルの人員は減らす方向にあり 対応できるか疑問 クラウドになると 国やサービス / 製品の区別が曖昧になるため 脆弱性対応にも影響が出る 北米やヨーロッパは脆弱性情報を公開しなければ 隠していると問題視される 一方 中国や東南アジアでは 一斉情報公開をすると 販売会社から営業妨害で訴えられる可能性がある 回答

44 調査結果 : 国内のソフトウェア製品開発者のグローバル展開 3 テーマ 情報セキュリティ早期警戒パートナーシップに関わる問題点 課題 回答 海外の入札で 脆弱性情報の取扱いの開示を求められる案件 (CVRF * への対応等 ) があった その際は日本の枠組みに沿って公開していると回答したが 情報セキュリティ早期警戒パートナーシップの英語資料があれば活用できた 今後は 国際標準も視野に入れつつ 対応を検討する必要がある 元請が北米でシステムを構築する際 セキュリティの活動全般について問われたことがある おそらく顧客からの調達要件に含まれていたのだろう 告示や P ガイドラインにも 無償提供が明記されていないため 意識が異なる海外の製品開発者に説明しにくい OEM 製品の場合 こちらから情報を提供できないため US-CERT や JPCERT/CC を介して対応してもらうしかない OEM ベンダや SIer などには POC 登録して情報を取得するようにお願いしてはいるが POC 登録した事例はなく 結局公開まで待って対応している形となっている 脆弱性ハンドリングで 海外のオフショア先にどこまで開示してよいかわからない また OEM の場合 JPCERT/CC 経由で依頼するが 回答がないケースもある OSS の脆弱性情報は製品開発者が事前に知ることができず 公表されてから情報収集して対応するため 数か月ずれてしまう 顧客から問い合わせが先に来る OSS との調整を仲介してもらえると助かる コミュニティからの情報は顧客も同時に見ることができるため 対応が遅いと言われる OSS からの情報は 自社でカスタマイズして検証する必要がある部分もあり トータルで時間がかかる 海外の委託先の教育に苦労している 底上げは民間各社が個別にやるより日本政府の政策の一環として取り組んでもらう方が効率的 *) CVRF(Common Vulnerability Reporting Framework): 脆弱性情報を報告 共有 ( レポーティング ) するための標準記述形式

45 調査結果 : 海外のソフトウェア製品開発者の国内展開 1 テーマ 脆弱性対応の体制 米国にプロダクトチーム セキュリティチームがあり 米国セキュリティチームのパスに沿って日本のセキュリティチームも動く形 米国以外ではセキュリティチームがあるのは日本のみ 日本語環境が独特であったことも少し影響している 日本独自の環境もあるため 現象確認は日本チームでも行っている セキュリティの重要性について 経営陣の意識改革が浸透している 基本的にはローカライズも含めて海外で実施 一部のみ日本で開発しているものもある 開発チームは米国だけでなく全世界に散らばっており 集約されていない 脆弱性対応を行うグループは脆弱性を一括管理しており 開発部門内にある バグであれば修正は次のバージョンということもあるが 脆弱性は公開した時点で対策を用意しているため 公開時点からの提供の遅れはない 脆弱性対応して修正したバージョンがうまく動かないということであれば 高い優先度でサポート窓口経由で対応する 脆弱性発見時は本国主導で修正する 公表はあらかじめ定義された脆弱性対応プロセスに準拠する 脆弱性はトッププライオリティなので 通常のワークよりも優先して対応する 重要度に応じて公開の仕方をローカルの判断で変更 ( お客様へこちらから直接連絡等 ) する可能性がある ビジネスインパクトを付けて本国の開発チームへ連絡する 本国でのレベル 1 が日本では 3 という場合はネゴシエーションを行う お客様にどの程度迷惑がかかるのか というのが一番大きい 受け入れられないということはない 緊急性の高い問題の場合は 経営層に判断を仰ぎ エンジニアを投入する その際には 日本のマネージャーから本国のディレクターに説明を行う 回答

46 調査結果 : 海外のソフトウェア製品開発者の国内展開 2 テーマ 国際的なギャップ グローバル企業だから問題が生じるということはあまりない 筋を通し 理屈を説明できれば 適切に対応してもらえる 評価が日本と本社で異なることもある 日本では不要と判断しても 本社側の流れで対応することもある 日本法人から本社に働きかける必要がある場合 IPA や NISC 等 政府側から要請を受けることは 本社と交渉する際のカードとして有効 脆弱性に関する公表内容の英 日翻訳で時間差が生じる可能性はある ぎりぎりまで内容が変更されるため 日本側が把握できるのはそれが顧客向けに配信される直前の段階になる 世界中でメッセージを統一するため 日本語の文面案を英訳してレビューを受ける 会社としてのブランドを統一するために表現方法など様々な部分をチェックされる US-CERT と JPCERT/CC の情報は最終的に一致するが 時差が発生する 本社が US- CERT から得た情報と日本法人が JPCERT/CC から得た情報が 表現の違いなどで同一の内容か確認するのに時間がかかることもある 製品をつくるのは早いが 維持管理は得意ではない企業も米国には多い 日本は品質管理がしっかりしているが 海外はそうではないことも多い 日本の品質管理は海外と比較して厳しい 日本は 100 点を求めることが多い 回答

47 調査結果 : 海外のソフトウェア製品開発者の国内展開 3 テーマ 問題点 課題 JPCERT/CC による深刻度の評価に日本法人スタッフがコメントしなかったことが原因で 当社側の評価とギャップが生じ 問題となったことがある クラウドのパッチ管理は今後のテーマ SaaS ではどんどんパッチをあてていく 仕様が常に変わっていく ブラウザの互換性に影響が出る可能性もある SaaS PaaS IaaS それぞれでできることが変わってくる US-CERT から問い合わせのあった件について JPCERT/CC からも問い合わせが来たことがある ワンストップ化してもらえるならありがたい 本国の決定に従うため 現状では苦労はあまりない しかし 日本で IPA に届出があった場合 本国への問合せが入るので手間がかかる可能性はある 回答

48 調査結果 : 海外のソフトウェア製品の国内販売代理店の国内展開 1 テーマ 脆弱性対応の体制 基本的に海外のソフトウェア製品開発者から脆弱性情報をもらうことになっているが 契約には含まれておらず 口頭で依頼している 公開前に脆弱性情報をくれるソフトウェア製品開発者も US-CERT で公開されてから連絡がくるソフトウェア製品開発者もいる ただし 5 年前から公開前に情報を欲しいとソフトウェア製品開発者側へお願いしてきたため改善された面もある 当社の脆弱性情報の取扱いはソフトウェア製品開発者の指示通り 公開してよいと言われたら 製品のサポートページに UP する 以前は US-CERT が先に出て 顧客からの問い合わせが来ることもあった ソフトウェア製品開発者の許可があれば顧客へ事前通知する 基本的には全ての顧客へ脆弱性情報を送っている 保守契約を結んでいなくても送っているので ボランティア的対応 もしメールで連絡できなければどうしようもない 顧客から質問があれば適宜対応する 国際的なギャップ 脆弱性対応に無償対応することを拒むソフトウェア製品開発者は今のところない オープンソフトウェアフォーラム等へ加入している企業は脆弱性情報対応に意識が高い 最近は海外ソフトウェア製品開発者 US-CERT JPCERT/CC へと情報が流れるので 代理店から JPCERT/CC には連絡していない 技術的な詳細は CERT/CC Vulnerability Note に移動してすべて英語になる CERT/CC Vulnerability Note 上のリンクも英語だけ 代理店と付き合いがないユーザは相談できず 自分で英語の説明を読み 対応している CERT/CC Vulnerability Note に公開されている情報は 対策方法が明確ではない場合がある 回答

49 調査結果 : 海外のソフトウェア製品の国内販売代理店の国内展開 2 テーマ 問題点 課題 パッチの副作用対応は日本ローカルでのみ起きることもある 日本は 2byte コードの OS を使用しているため シングルコードで再現しないこともある また 日本語の文字表示が壊れていても海外では気付かない アプリ系の代理店の場合 営業部隊が技術部隊を動かして調整するのは難しいケースもある 製品の技術サポートは行わず 米国のソフトウェア製品開発者と直接交渉するように返すケースもある 代理店としてパートナーシップでどのように対応すべきか明確でない 米国の製品開発者に望ましい対応を説明する場合 ガイドラインだけでなく HP も英語化してほしい 回答

50 3.5. ソフトウェア製品開発者における国際的な脆弱性情報の取扱いに関する課題 国内 海外のギャップがもたらす課題 国内のソフトウェア製品開発者の場合 海外での開発を行う上で 脆弱性対応に関する意識の違いや脆弱性情報の共有等に苦戦するケースが見られる 現在は日本語と英語のサイトしかないが 今後 製品紹介のウェブサイトをローカル言語で出すようになれば 製品の脆弱性届出がローカル言語で届く可能性もある ローカルの人員は減らす方向にあり 対応できるか疑問 国際的な脆弱性対応の体制として 米国企業の中央集権型ではなく 現地 POC の設置とそれらの連携 調整による日本型 ( 調整型 ) をめざすべきとの意見もあった シングル POC を志向した場合 エスカレーションルールを統一 徹底できず 情報が POC に届かないケースや 現地語での問合せを見逃してしまう可能性が指摘されている 暗号機能を搭載するソフトウェア製品のパッチを海外に提供する場合 マスマーケット品はダウンロード提供が可能だが そうではないビジネス サーバ用製品は輸出管理規制の対象となり 現地でダウンロード提供ができず申込制にしている また 現地政府の暗号輸入規制も NSA 盗聴疑惑の影響でますます厳しくなり 使用している暗号の明示を求められる可能性もある 海外のソフトウェア製品開発者の場合 日本法人と海外本社の間のギャップが脆弱性対応に関する問題を招くケースはあまり見られない これは 脆弱性対応を最優先する方針が明確化されていること 国内と本社で調整が必要な場合も 筋が通った説明をすれば理解してもらえることが理由と考えられる 技術的な詳細は CERT/CC Vulnerability Note に移動し英語の説明になる CERT/CC Vulnerability Note 上のリンクも英語だけ 代理店と付き合いがないユーザは相談できず 自分で英語の説明を読み 対応している 情報セキュリティ早期警戒パートナーシップに関連する課題 海外の取引先等に脆弱性情報の取扱いについて説明できるように 情報セキュリティ早期警戒パートナーシップの資料の英語化や 国際標準への対応等を検討する必要がある さらに踏み込んで 海外のソフトウェア製品開発者や研究者に向けて積極的に展開することで 結果的に国内の製品開発者をサポートする効果 (OEM グローバル統制 OSS) も期待できる クラウドに関する脆弱性の取扱いをどのように対処すべきか方針を明確にする必要がある 49

51 4. グローバルなウェブサイトにおける脆弱性対応 4.1. 調査方針 4.2. アンケート調査 4.3. ヒアリング調査 4.4. まとめ 50

52 4.1. 調査方針 1 グローバルに展開しているウェブサイトを運営する組織について調査を実施し 脆弱性への対応に関して国際的な対応が必要とされる場面を明らかにする 調査は 海外ウェブサイトを運営する現地企業に出資する日本企業の担当者へのアンケート調査と 海外ウェブサイトの脆弱性を巡るトラブルやヒヤリ ハットの経験がある回答者を対象としたヒアリング調査を実施する 調査準備 調査仮説の設定調査の詳細設計 アンケート調査 項目 調査対象 調査項目 調査方法 概要 海外ウェブサイトを運営する現地企業に出資する日本企業の担当者 (300 件以上を回収 ) 海外ウェブサイトの運営の統制方法 海外ウェブサイトを取り巻く脅威の認識 海外ウェブサイトの脆弱性を巡るトラブルやヒヤリ ハットの経験 海外ウェブサイトの脆弱性対策に関する取組み 海外進出企業総覧 会社別編 ( 東洋経済 ) に掲載された海外出資企業 ( 約 4,300 社 ) の海外出資先統制部署に発送 ( 郵送方式 ) 項目 調査対象 調査項目 調査方法 問題点や課題点の分析 問題解決の方向 概要 ヒアリング調査 海外ウェブサイトを運営する現地企業に出資する日本企業の担当者のうち 海外ウェブサイトの脆弱性を巡るトラブルやヒヤリ ハットの経験がある回答者 (5 件 ) アンケート調査の深掘り ( 実態把握 ) 組織が抱える具体的な課題 組織に望まれる取り組みの方向 アンケート調査において 調査に協力可能 との回答を得た回答者を中心に調査対象を抽出 分析 51

53 アンケート調査 4.1. 調査方針 2 調査期間 :2003 年 11 月 8 日 ~12 月 2 日 調査方法 : 郵送方式 調査名 : 海外拠点におけるウェブサイトのセキュリティに関する調査 調査対象 : 海外進出企業総覧 会社別編 ( 東洋経済 ) に収録された 出資比率 20% 以上の海外現地法人を1 社以上持つ日本企業 4190 社 回収結果 : 有効回答 309 件 ( 回収率 7.4%) 回答を1つだけ選択する場合 : SA と標記複数回答可の場合 : MA と標記 ヒアリング調査 調査対象 : アンケート調査回答企業より 以下の条件を満たす対象 5 件を抽出 調査方法 : 訪問調査 - 海外拠点 ( 海外事業所または海外子会社 ) が海外ドメイン (.jp 以外 ) で外国語のウェブサイト ( 主に海外の顧客向け ) を有すること - 海外ウェブサイトの脆弱性を巡るトラブルやヒヤリ ハットの経験があること - ヒアリング調査への協力を応諾していること 52

54 4.2. アンケート調査 (1) 海外拠点のウェブサイトを取り巻く脅威 1 トラブルの経験 海外事業所や海外子会社のウェブサイト管理に伴うセキュリティリスクについて 貴社にとってどれくらいの頻度でトラブルが起き得ると思いますか (SA) 海外子会社の地域 トラブル頻度の認識 海外拠点のウェブサイトに関するトラブルには 約 15% が既に遭遇していると回答している 特に 東アジア 東南アジア 北米 欧州は拠点数も多く 遭遇経験ありとする回答も多い 53

55 4.2. アンケート調査 (1) 海外拠点のウェブサイトを取り巻く脅威 2 損害の可能性 海外事業所や海外子会社のウェブサイト管理に伴うセキュリティリスクについて 貴社にとってどれくらいの損害をもたらし得ると思いますか 貴社の認識に近いものを選んでください (SA) 海外子会社の有無 損害の可能性 海外拠点のウェブサイト管理に伴うセキュリティリスクの損害として 4 割以上の企業がグループ全体への影響を懸念している 海外子会社とそのウェブサイトが存在する場合 グループ全体への影響を懸念する割合が高い 54

56 4.2. アンケート調査 (1) 海外拠点のウェブサイトを取り巻く脅威 3 セキュリティリスクへの対応 海外事業所や海外子会社のウェブサイト管理に伴うセキュリティリスクについて 貴社ではどのように対応を進めていますか 貴社を含む企業グループでの現状に近いものを選んでください (SA) 従業員数 セキュリティリスクへの対応 海外拠点のウェブサイト管理に伴うセキュリティリスクへの対応を企業グループで進めているのは約 4 割であり 約 5 割はグループ各社の個別対応に任せている 従業員数が多いほど企業グループとしての対応を進めている傾向があり 5000 人以上の企業では 7 割がグループで対応している 55

57 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 1 海外拠点におけるウェブサイトの環境 貴社では 海外事業所 / 海外子会社のウェブサイトをどのように管理していますか (SA) (a) (b) グローバルサイトとしてひとつのサイトに統合する取組みは (a) の方がやや進んでいる * 海外事業所を有する企業の 6 割超 海外子会社を有する企業の 7 割超で 海外向けのウェブサイトについて海外拠点が個別に管理している このため セキュリティを横断一律に確保することが難しい 56 *) (a)(b) は排他的関係ではない

58 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 2 海外拠点におけるウェブサイトの管理 貴社グループでは 貴社の海外子会社のウェブサイトに関する問合せ窓口を どのように設けていますか (MA) (a) 海外事業所を有する企業の 5 割超 海外子会社を有する企業の 6 割超で 現地の言語で問合せ窓口を設けている この結果 サイトの脆弱性等の届出を現地で受けても 本社 / 親会社まで連絡が届かない可能性もある (b) 57

59 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 3 海外拠点におけるウェブサイトのセキュリティ対策 海外事業所 / 子会社におけるウェブサイトのセキュリティ対策は どのように進められていますか (SA) (a) (b) 海外事業所を有する企業の 4 割超 海外子会社を有する企業の 5 割超において 海外拠点側の判断でウェブサイトのセキュリティ対策を独自に行う方針をとっている これは 多くの企業において 海外の事業所 / 子会社のウェブサイトに対する脆弱性対策等を 本社 / 親会社の指示で徹底させるのが容易ではないことを示している 58

60 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 4 海外拠点のウェブサイトのドメイン 言語 貴社の海外事業所のウェブサイトのドメインと言語について あてはまるものを選んでください (MA) 海外拠点のウェブサイトでは 海外ドメイン (.jp 以外 ) でかつ外国語を使用するケースが非常に多いことが明らかになった 特に 海外子会社が 1 社以上海外ドメイン (.jp 以外 ) の外国語サイトを有するケースは 海外子会社サイトを有する企業の 84.2% に及ぶ これは トラブルが発生すれば日本企業にも影響するが 現在の情報セキュリティ早期警戒パートナーシップでは取扱対象としてカバーしていないサイトが多数存在することを意味する 59

61 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 5 海外拠点におけるウェブサイトの脆弱性発見の報告 海外事業所 / 子会社におけるウェブサイトに脆弱性が発見されたという報告を受けたことがありますか (SA) (a) (b) (a)(b) のいずれも 海外の事業所 / 子会社を有する回答の約 1 割で 海外の事業所 / 子会社の運営するウェブサイトに脆弱性が発見された旨の報告を受けた経験がある その一方 (a)(b) とも約 5 割で脆弱性が発見されたことがなく また3~4 割が 把握していない と回答しており 海外の事業所 / 関係会社の運営するウェブサイトの脆弱性や対策の状況について十分に把握できていない実情がうかがえる 60

62 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 6 ウェブサイトの脆弱性の発見方法 海外事業所 / 子会社におけるウェブサイトに貴社の海外事業所のウェブサイトの脆弱性はどのように発見されたでしょうか (MA) (a) (a)(b) のいずれも 脆弱性検査や脆弱性診断のサービスを通じて 発覚したケースが多い ヒアリング調査の結果 何らかのきっかけで本社 / 親会社から脆弱性検査等の実施を要請された結果 発覚したケースが含まれることが判明している (b) 61

63 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 7 海外拠点におけるサイバー攻撃の報告 海外事業所 / 子会社のウェブサイトがサイバー攻撃を受けたという報告を受けたことがありますか (SA) (a) (b) (a)(b) のいずれも 海外の事業所 / 子会社を有する回答の約 1 割で 海外の事業所 / 子会社の運営するウェブサイトがサイバー攻撃を受けた旨の報告を受けた経験がある その一方 (a)(b) とも約 5 割でサイバー攻撃を受けたことがなく また3~4 割が わからない と回答しており 海外の事業所 / 関係会社の運営するウェブサイトでのサイバー攻撃の状況についてあまり把握できていない実情がうかがえる 62

64 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 8 サイバー攻撃対策の方針変更 サイバー攻撃を契機として 貴社の海外事業所におけるウェブサイトのセキュリティ対策の方針は変わりましたか (SA) (a) (b) (a)(b) のいずれも 本社 / 親会社の主導で徹底する方向に変更した とする回答が多いが (a) の方がより本社主導の取組みが適用されている その一方 (a)(b) とも 海外事業所 / 子会社の判断でより徹底する方向に変更した とする回答も 20%~ 25% いる これらは 本社 / 親会社から見て 問題を把握できない構造に陥る懸念も否めない 63

65 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 9 海外拠点のウェブサイト構築 運用時の脆弱性対策 貴社では海外事業所 / 子会社のウェブサイトを構築 運用する際に どのような脆弱性対策を実施していますか (MA) (a) 海外事業所のウェブサイト構築 運用時の脆弱性対策 (b) 海外子会社のウェブサイト構築 運用時の脆弱性対策 海外の事業所 / 子会社において 海外ドメイン (.jp 以外 ) の外国語サイトを有する企業の場合 海外事業所 / 子会社の判断に任せている を選択するケースが圧倒的に多い これは グループ横断的な対策やルールの適用が困難であるか まだリスクとして真剣にとらえていないか いずれかの理由で現状追認となっているものと考えられる 64

66 4.2. アンケート調査 (2) 海外拠点のウェブサイト管理の実態 10 脆弱性対策を阻害する要因 貴社の海外事業所 / 子会社におけるウェブサイトの脆弱性対策を阻害する要因は何ですか (MA) (a) 海外事業所におけるウェブサイトの脆弱性対策を阻害する要因 (b) 海外子会社におけるウェブサイトの脆弱性対策を阻害する要因 海外ドメイン (.jp 以外 ) の外国語サイトを有する企業の場合 海外事業所 / 子会社のいずれにおいても 予算 要員 地域性 統制のしくみといった幅広い問題が阻害要因として取り上げられている 65

67 4.2. アンケート調査 (3) アンケート回答者属性 (a) 業種 カテゴリー名 n % 食料品 飲料 たばこ 飼料製造業 繊維工業 パルプ 紙 紙加工品製造業 化学工業 石油 石炭 プラスチック製品製造業 窯業 土石製品製造業 鉄鋼業 非鉄金属 金属製品製造業 電気機械器具製造業 情報通信機械器具製造業 輸送用機械器具製造業 その他機械器具製造業 その他の製造業 農林漁業 同協同組合 鉱業 建設業 電気 ガス 熱供給 水道業 映像 音声情報制作 放送 通信業 新聞 出版業 情報サービス業 運輸業 郵便業 卸売業 小売業 金融業 保険業 医療業 ( 国 公立を除く ) 教育 ( 国 公立を除く ) 学習支援業 その他のサービス業 無回答 全体 (b) 従業員数 カテゴリー名 n % 99 人以下 ~499 人 ~999 人 ,000~4,999 人 ,000 人以上 無回答 全体 (c) 資本金 カテゴリー名 n % 1 億円未満 ~10 億円未満 ~100 億円未満 億円以上 無回答 全体 (d) 売上高 ( 単体 ) カテゴリー名 n % 50 億円未満 ~100 億円未満 ~500 億円未満 ~1,000 億円未満 ,000~5,000 億円未満 ,000 億円以上 無回答 全体

68 4.3. ヒアリング調査 (1) 脆弱性対応の実態 1 以前は 一定のルールはあったものの現地任せで 情報セキュリティの統制はうまくできていなかった しかし 情報流出事案を契機として グローバルレベルでの統制強化に向けて動き出した 世界 4 拠点の情報セキュリティ担当 ( 現地スタッフ ) にセキュリティ指針を説明 各拠点から さらにそれぞれの地域へ展開している ローカルページが膨大にあるため すべてを統合管理するのは難しい状況 スペック 機能だけ伝えて 何を使うかは現地に判断させている たとえば 日本で選んだ製品を導入するように指示しても 入手が困難 サポートがないなどの問題がでる グローバルレベルでの報告体制はない ただ 情報セキュリティ事故があったときには日本へのレポーティングは徹底している その枠組みの中で ウェブサイトの脆弱性についても報告がくると考えている 親会社のガイドラインから 100 項目程度の指針を自社傘下のグループ会社に配布している ウェブサイトの脆弱性対策については全体の実施項目の一つになっているが 必ずしも当該項目が対策必須とはなっておらず その点では個社に任せている形 来期からは子会社から緊急事態報告の中に ウェブサイト改ざんも項目として含める方向で検討している 今まではそのようなルートはなく IT 系についての項目はなかった 海外拠点に国内同様の統制を敷いているところは金融機関では少ない 現地法人になると 縦割文化もあり 現地の裁量が強くなる 地域独自の制度もあり 本部から配布するものだけでは足りない ウェブサイトに限れば 以前は海外拠点が独自に構築していたが 数年前に 海外拠点と主たる子会社のサイトを一つの基盤に統一した 基盤は親会社が一元管理し コンテンツは各拠点が管理する 欧米はセキュリティ意識が高く 数年先を行っている印象 各拠点の担当者に指示すればできるというものではなく 部署の承認も必要 67

69 4.3. ヒアリング調査 (1) 脆弱性対応の実態 2 ウェブサイトごとに管理責任者 担当者 副担当者を登録している 海外にも同じルールを適用しているが 浸透具合には温度差がある 国の違いか担当者の問題か切り分けにくい また会社規模によっても異なる 海外現地法人は国によっては少人数しかおらず ウェブサイトの管理担当者を確保するのは難しいこともある 定期的なセキュリティ診断 プラットフォーム診断等も遅れがち 関係会社が予算外の投資をするには事業部の判断が必要 セキュリティを優先できないこともある 登録を徹底させるために グループ名の文字列を含むサイトを全て抽出 仕分けして通知した グループ統括会社の社外ウェブサイト運用規定を利用して海外 ( 英語版 中国語版 ) に提供している 新規ウェブサイト構築時は共通インフラへ構築している 海外についても欧州 中国 アメリカの拠点にネットワークセンターがある グループ統括会社が主導してウェブサイトのセキュリティ診断を定期的に実施 本体のウェブサイトの不正侵入を契機として 海外関係会社も含めて すべて登録制にして 脆弱性検査をパスしたウェブサイトしか公開できないルールになった 以前も脆弱性検査は必須であったが 子会社は曖昧で すべてのウェブサイトを把握できていなかった 関係会社に対して 自社の規則と同様の規則をつくってもらうよう指導している ただし 各部門が勝手にたててしまう可能性はある 資本関係でマジョリティを持っている関係会社に対しては指導している 孫会社も間接的にマジョリティを持っていれば同様に管理 昨年度末から 海外の関係会社に対しても 規則の指導や台帳管理を開始している 将来的にはインフラを共通化したい 68

70 4.3. ヒアリング調査 (2) 脆弱性の発覚 サイバー攻撃等の経験 子会社に対してアンケートを実施したところ 改ざんの報告があった 不正アクセスがあったとのことで 不正プログラムの除去までは実施していた しかし トップページがリダイレクションされていたことが後日さらに判明した ローカルなページを共通インフラに移行する過程で ローカルなサイトを 移行しました の連絡ページを残したままにしていたところ そのページが改ざんされていた 現地側はそこだけ削除して使おうとしていたが 本部からは落とすよう要請した ただ 権限の問題もあり 説得が必要であった 親グループ内において個人情報漏えいが発生し それがトリガーとなってグループ全体としてのセキュリティ方針が徹底された グループ内のハッキング情報を常時監視しているチームから連絡がきたことがある 本体のウェブサイトが不正侵入され 個人情報漏えいの可能性があり 問題となった 子会社のウェブサイト管理者のログイン情報の一部が漏えいして 掲示板で公開されていた 第三者から連絡を受けて発覚した 実際に現地に行って 管理元の指導を行った 脆弱性はセキュリティ検査で見つかるケースが最も多く そうした報告を受けている 検査のマニュアルも配布しており 海外版は英語で配布している 69

71 4.3. ヒアリング調査 (3) ウェブサイトのセキュリティリスク 課題 損害のイメージは正直なところわからない 電子商取引は行っていない ( 北米では一部実施 ) ため 現状の影響はブランドの失墜程度ではないか 情報漏えいなどのリスクも認識しているが どちらも大きな危機感はない ウェブサーバもホスティングを利用しており 会社に侵入されるリスクもない 踏み台にされるリスクは考える必要がある 今後 電子商取引も採用されるとリスクが高まる 現地法人系は比較的問題ないが 営業部が設立した事業小会社はスタッフが少なく 兼務も多いため 統制が利きにくい チェック状況は収集できるが 対策の徹底はできない 子会社がどのようなバージョンを使っているか管理できていないので 対応は個社に任せるしかない 事業者がついている欧米系より 内製が多い日本のほうがレベルが低い可能性もある リンク先のサイトで脆弱性が見つかった場合 パッチ適用など統制をきかせることができない 現在はアプリのチェックが甘い マルウェアが組み込まれるのを発見できるかも懸念事項 セキュリティ診断の頻度が少ないのが懸念 改ざんチェックは 1 日 1 回実施 ただし コンテンツを入れ込むところから狙われている場合は防ぎようがなく 対策の検討をはじめている 海外は言語の問題でニュアンスが伝わらず統制が難しくなることもある 本部がガイドラインを提供し 制度を作るのは現地という形 そのため 管理方針まで徹底はできない どのようなサイトに脆弱性診断が必要かなどの指針や クラウドに預けるべき 外注するべきケースなどの指針が欲しい 各社ウェブサイトのサーバ OS や CMS の製品及びバージョンがばらばらであり 現状は何をアナウンスしたらよいかわからないことも課題 各関係会社の窓口にセキュリティ管理をお願いしているが それがどこまで浸透しているのか見えない 理解度に対して不満はある 個人情報とは何か という部分だけでも理解が難しい国も多い 70

72 4.3. ヒアリング調査 (4) IPA への要望 IPA の対応範囲は jp ドメインのサイトまでで良いのではないか 基本的に現地は現地で責任をとるべき 現地も自立している 各拠点にある程度任せてよいと考えている 昔は日本からの集中統制型であったが 今後は海外との協調型 IPA から 中小企業向けのウェブサイトの推奨対策のようなものを出してほしい 結局 メンテは自社でできないので外注する 中小企業にはガイドラインのようなものを出して それを守るように指示するのが有効 IPA コンテンツは日本語版はあるが 外国語版が少ない 英語と中国語が欲しい 各国の CERT と連携して出してもらえないか 海外拠点の情報もいただけるとありがたい なかなか海外拠点の情報は入ってこない 海外では指摘してくれる機関も少ない IPA に URL を登録して届出があれば通知が来る制度がもしあれば登録するだろう 該当するかわからない情報でもいただけるのであればいただきたい 該当しない情報が多くても 読み飛ばすため問題はない IPA に URL を登録して届出があれば通知が来る制度は そのリストが非公開扱いになるのであれば登録することは可能 どこまで管理の対象にしていることは非公開にしている 71

73 まとめ 海外拠点のウェブサイトのセキュリティ対策を海外拠点側の判断に任せている回答が 4~5 割あること 海外拠点のウェブサイトの脆弱性やサイバー攻撃の有無について把握していないとする回答が 3~4 割あることから 多くの企業において 親会社 / 本社の指示で対策を徹底させることが難しい状況にあると考えられる 海外拠点のウェブサイトは海外ドメイン (jp 以外 ) でかつ外国語を使用するケースが非常に多い つまり 現在の情報セキュリティ早期警戒パートナーシップでは取扱対象にしていないが トラブルが発生すると親会社 / 本社である日本企業に影響を及ぼすサイトが多数存在する これに対し 情報流出等の事故を契機に グループとして関連サイトの棚卸に取り組むケースも見られる ただし 海外拠点のウェブサイトの脆弱性やサイバー攻撃等の報告を受けたケースは 1 割程度にとどまることから IPA としてより積極的なサポートを必要とする状況にはまだ至らないと推測される 当面は 現状の取組み ( 対象外の届出を受けた場合もケースバイケースで柔軟に対応する ) を続けるとともに 必要に応じて具体的な方策 ( 例 : 海外拠点等を含む URL リストの登録制度 ( 登録済の URL について脆弱性の届出があった場合には当該登録者の親会社 / 本社の窓口に連絡する )) を試行することも検討すべきである なお ヒアリング調査では IPA のコンテンツの外国語版を求める意見が複数の回答者から得られた

74 5. 情報セキュリティ早期警戒パートナーシップのグローバル化対応に向けて 73

75 74 5. 情報セキュリティ早期警戒パートナーシップのグローバル化対応に向けて 1 日本のみの独自ルールや国際標準との不整合 ギャップを解消しなければ グローバル企業における統合ルールとしてパートナーシップを位置付けることが難しくなるのではないか 今後の対応 ( 整合性や検討事項 ) P ガイドラインは国際標準 (ISO/IEC 29147) との整合を図る方向で改訂に取り組むべき さらに踏み込んで 国際標準に準拠 を目指すか否かについては検討が必要 JIS 化については 製品開発者に対する啓発効果とダブルスタンダードとの誤解を勘案して判断すべき 今後 海外のソフトウェア製品開発者や研究者に向けてパートナーシップを展開することも視野に入れる これにより 国内の製品開発者が抱える課題 (OEM や OSS との調整 グローバル統制等 ) を改善する効果も期待できる 今後の対応 ( 運用面での改善事項 ) 国内の製品開発者が 脆弱性情報の取扱いについて海外の取引先等に説明できるように 情報セキュリティ早期警戒パートナーシップの資料の英語化や 国際標準への対応等を検討する たとえば P ガイドラインの改訂の影響をあまり受けないように P ガイドラインの概要版を作成し その英訳版を作成する

76 75 5. 情報セキュリティ早期警戒パートナーシップのグローバル化対応に向けて 2 日本企業の脆弱性問題が結果的に放置されるリスクがあるのではないか 調査結果の要点 多くの企業において 親会社 / 本社の指示で海外拠点のウェブサイトのセキュリティ対策を徹底させることが難しい状況にある 現在の情報セキュリティ早期警戒パートナーシップでは取扱対象にしていないが トラブルが発生すると親会社 / 本社である日本企業に影響を及ぼすサイトが多数存在する 情報流出等の事故を契機に グループとして関連サイトの棚卸に取り組むケースも見られるが まだ多くの企業でそのリスクが正しく認識されていない 今後の方針 当面は現状の取組み ( 対象外の届出を受けた場合もケースバイケースで柔軟に対応する ) を続けるとともに 必要に応じて具体的な方策 ( 例 : 海外拠点等を含む URL リストの登録制度 ( 登録済の URL について脆弱性の届出があった場合には当該登録者の親会社 / 本社の窓口に連絡する )) を試行することも検討すべき