情報処理安全確保支援士 2025年 春期 午後 問題

共通の文章

サプライチェーンのリスク対策に関する次の記述を読んで，設問に答えよ。 L社は、金融業向けにシステムを開発している従業員1,000名の企業である。L社 のシステム開発プロジェクトでは，プラットフォームGというソフトウェア開発プラ ットフォームを利用している。プラットフォームGの機能には，ソースコード及び開 発ドキュメントのバージョンを管理する機能，CI/CD パイプラインの管理機能，開発 対象のSBOM 作成機能がある。CI/CD パイプラインの管理機能を利用してテストやリ リースの自動実行が可能である。開発対象のSBOM 作成機能はプラットフォームG上 のリポジトリサーバ内のソースコード及びライブラリをシステム構成要素として一 覧する。開発対象の SBOM 作成機能は現状では特に利用していない。また、L社が 採用しているSASTツール（以下、ツールFという）は、プラットフォームG上のリ ポジトリサーバや開発者の端末にインストールして利用するツールであり、コンパ イルエラーが解消されたソースコードに対してだけ正常な検査が可能である。プラ ットフォームGのCI/CD パイプラインの管理機能で，ツールFでのチェックを自動 に行うようなワークフローを構成することができる。 近年，業務委託先でのセキュリティ侵害に起因する情報セキュリティインシデン トが大きく報道されるなど外部環境が変化し、L社経営陣もサプライチェーンリスク 対策の強化を考えるようになった。経営陣の指示で，情報セキュリティ担当のBさん は，サプライチェーンリスク対策を強化したセキュリティガイドライン（以下，ガ イドラインという）を作成し，全てのシステム開発プロジェクト及び運用サービス を点検することになった。Bさんは，L社が契約しているセキュリティコンサルタン 7で情報処理安全確保支援士（登録セキスペ）のD氏にガイドラインの作成について 相談することにした。 ［ガイドラインの作成］ 次は、ガイドラインの作成についてのBさんとD氏の会話である。 Bさん：カイドラインはどのような構成がよいでしょうか。 D氏：システムライフサイクルの工程に合わせるのがよいでしょう。L社のシステ ム開発業務を踏まえて、調達，開発，リリース・デプロイ，運用の工程に 分し、さらに全ての工程で共通するような項目も抜き出して記載しまし よう。 Bさんが修正したガイドライン案を経営陣に報告したところ，過去に外部ベンダー でのセキュリティ侵害に起因してL社でインシデントが何度か発生したことがあった ので，それらのインシデントに対するガイドライン案の有効性を評価するように指 示があった。 ［過去のインシデントの確認］ Bさんは，過去のインシデントに対するガイドライン案の有効性を評価することに した。次は、1件目のインシデントについてのD氏とBさんの会話である。 D氏：はじめに，インシデントの内容を確認しておきましょう。 Bさん：L社が開発し、運用していたシステム（以下、システムという）では、古 いWebブラウザをサポートするためのJavaScript（以下、スクリプトPとい う）を利用していました。スクリプトPは、当時広く使われていたT社製の ものです。スクリプトは、「社が運営するサーバ（以下、サーバTという） に配置され，システムにアクセスしたWebブラウザがスクリプトPを都度 読み込むようにシステムは構成されていました。ある日、サーバTが乗っ 取られてしまい，スクリプトPが改ざんされたことによって、システムへ の利用者のアクセスが悪意のあるWebサイトにリダイレクトされてしまいま した。 D氏 ：発見の経緯を教えてください。 Bさん：システムの利用者からの問合せで気付き，対策を実施しました。当時の情 報セキュリティ担当は、サーバが侵害されたというニュースは知っていま したが、システム＆へのアクセスが影響を受けることを把握していませんで した。 D氏：他社の発表によると，③スクリプトPを利用していたシステムでもスクリプ トPの配置方法が違えば，影響を受けなかったようですね。 Bさん：はい。違う配置方法にするという対策もありました。しかし、Web ブラウザ 開発元での古い Web ブラウザの公式サポートが終了していたことから、当社 の対策としては、④システムQのソースコードに変更を加えて，古い Webブ ラウザのサポートを終了しました。 8. 資産管理台帳にサーバ及びネットワーク機器の一覧を担当者が入力する。 9. システムSに組み込む OSS ライブラリは、開発者が取得する。OSS ライブラリは資産管理台帳 に入力しない。 10. 開発は、L社内及びオフショア拠点で行い，次のLAN に接続した端末で実施する。 ・L社内に用意した従業員 LAN ・L社内に用意したパートナーLAN ・オフショア拠点にある業務委託先のLAN また、テストなどのためにシステムSの開発系サーバがあるLAN（以下，開発LAN という）に アクセスする際には一旦、踏み台サーバにログインする。踏み台サーバには、L社，業務委託 先など会社ごとに発行した共用アカウントでログインするが、ログインごとに、利用記録簿に 記載する。開発 LAN 上のサーバには製品仕様上、アクセスログが取れないものもある。 11. インシデント発生時にL社のシステムSの担当者に連絡するための業務フローがインシデン ト対応手順書に定められており，システム Sの担当者がインシデントのハンドリングを行う。 12. ツールFが開発者の端末とプラットフォームGにインストールされている。 図1 システムSの開発プロジェクト及び運用サービスの概要（続き） オフショア拠点 L3SW：レイヤー3スイッチ FW ：ファイアウォール インターネット VPN-GW : VPNケートウェイ L社 「ニトテーLAN VPN-GW 開発LAN •従業員LAN L3SW-1 踏み台サーバ L3SW-2 開発系サーバ 図 2 システムSの開発環境の構成図（抜粋） Bさんは、システムSの担当者へのヒアリング前に論点を整理しておこうと考え、 表1の各項番について、図1に基づき，対策状況を確認した。結果は表2のとおりで ある。 表2 システムSの事前確認結果（抜粋） 工程 表1の項番 確認した図1の項番 確認結果又は問題点 共通 1 8,9 OSS ライブラリを台帳管理していない。 2 ア a 調達 5 イ 問題なし。 開発 9 ウ b リリース・ 10 6 開発したソフトウェアについて SBOM を作 デプロイ 成していない。 運用 15 工 Bさんは、システムSの担当者であるCさんにヒアリングを行った。 ［SBOM についての雀認） 次は、表1の項番10についてのCさんとBさんの会話である。 Cさん：システム S のソフトウェア構成は設計書で把握できると考えていますが、 SBOMの作成も必要でしょうか。 ぜい Bさん：SBOM を利用すると、⑥将来，脆弱性管理がしやすくなります。プラットフ オームGで作成することができます。 Cさん：なるほど。それでは，SBOMの作成を検討します。 ［開発工程のセキュリティ対策についての催認」 Bさんは、表1の項番7,8について催認した。次は、そのときのBさんとしさんの 会話である。 Bさん：表1の項番7の対策は実施できていますか。 Cさん：オフショア拠点から開発 LANへのアクセスについてはVPN-GWでアクセスロ グを取得できているものの，社内からのアクセスについては取得できてい ません。 Bさん：アクセスログは図2中の d ■で取得するのがよいでしょう。 Cさん：分かりました。 Bさん：表1の項番8の対策はどのようにしていますか。 Cさん：現在はソースコードの変更内容を開発リーダーがレビューしています。 Bさん：開発リーダーによるレビューに加えて、ツールFでチェックするのがよいで しょう。 Cさん：開発フローのどこでツールFを実行するのがよいでしょうか。 Bさん：ツールFの特性を踏まえると、図3のシステムSの開発フロー中の（あ）又は （い）で実行するのがよいと考えられます。①それぞれ利点が異なります。 開発者の端末 ブラットフォームG テスト環境 本番環境 ソースコードの コンパイルの 機能テストの リリース及び 修正 実行（2）1） 実行 本番への切替え （い） 本番環境用 コンパイルの 開発リーダー ソースコード 実行（1） によるレビュー への反映 （あ） 開発者による テスト環境用 本番環境への ソースコード デブロイ テスト への反映 ソースコードの リポジトリへの テスト環境への デブロイ アップロード 注1 複数の開発者が変更した内容を反映させた上でコンパイルエラーが出ないことを確認して いる。 図 3 システムSの開発フロー ガイドラインを用いた点検の後、L社のサプライチェーンリスク対策は強化された。

共通の文章

脆弱性管理に関する次の記述を読んで，設問に答えよ。 M社は、従業員3,000名の情報サービス業を営む企業である。ソフトウェアの開 発・販売を行っており，自社ホームページのほか，販売したソフトウェアのサポー ト用 Webサイトなど複数のWebサイト（以下、Webサイトをサイトという）を保有し ている。M社では、メンテナンスのために管理者が自宅や外出先からサイトにリモー トアクセスする。セキュリティに関する問合せ窓口は，情報システム部が担当して いる。 M社が保有するサイトのうち、重要なサイト（以下、重要サイトという）は、プラ ットフォームに対する脆弱性診断（以下、PF 診断という）及び Webアプリケーショ ンプログラムに対する脆弱性診断（以下、Webアプリ診断といい、PF 診断とWebアプ リ診断を併せて両診断という）を初回リリース前に実施するルールになっている。 初回リリース後の両診断の実施については任意である。重要サイトの指定は，扱う 情報の重要性，停止による影響などを勘案し、各サイトの所管部門が判断している。 重要サイト以外のサイトに対する両診断の実施は任意である。 両診断は，情報システム部の選定した専門ベンダーP社に依頼して実施，又は情報 システム部の選定した脆弱性診断ツール（以下、診断ツールという）を用いて各サ イト担当者が実施する。ただし、緊急の場合，情報システム部が実施することもあ る。P社のWebアプリ診断は，脆弱性が実際に悪用できることを確認した上で報告し てくれるので，評判がよい。 脆弱性は CriticaL， High， Medium， Low， Noneの5段階の深刻度レベルに分され る。P社に頼して診断を行う場合は、P社から深刻度レベルの報告を受ける。深刻 度レベルは、情報システム部が選定した診断ツールの場合は CVSS 基本値によって分 頼される。P社の診断では、P社が独自の知見でCVSS 基本値を基に値を変え、分し ている。M社では、深刻度レベルが High以上の場合は速やかな修正を必須とし、そ れ以外は所管部門が対応要否を判断する。 ［脆弱性の報告］ ある日、M社のキャンペーンサイト×（以下、サイト✕という）のキャンペーンペ ージにSQLインジェクションの脆弱性が存在しているという指摘が問合せ窓口に報告 - 10一 された。報告内容についてサイト担当者に確認したところ、脆弱性が存在する可能 性があるとの回答であった。サイト×は重要サイトに指定されていなかった。サイト Xの仕様を図1に示す。 Web サーバ，Web アプリケーションサーバ及びデータベース（以下、DB という）サーバから成 る。 ・キャンペーン情報をDBサーバに格納している。 ・顧客情報は保有していない。 ・キャンペーンページのURLのクエリパラメータにコンテンツ番号が含まれている。 URL 例：https://site-x.m-sha.co.jp/info?article=20250101 ・コンテンツ番号がDB サーバ上に存在しない場合，又は SQL が構文エラーになる場合は、“コン テンツがありません”というメッセージを返す。 ・Web アプリケーションプログラムにおいて、クエリパラメータ articleの値は SQL での検索で は数値型として扱われる。 図1 サイト×の仕様（抜粋） 情報システム部のEさんとJ課長は、報告の内容を確認するために，情報システム 部が診断ツールを実行する旨をサイトメの担当者に伝えた。 Web アプリ診断用の診断ツールを該当ページに対して実行したところ、深刻度レベ ルがHighのSQLインジェクションの脆弱性が検出された。SQLインジェクションの脆 弱性検出時のクエリパラメータ及び応答を表1に示す。 表1 クエリパラメータ及び応答（概要） クエリパラメータ 応答 article=20250401 2025年4月1日のキャンペーンのコンテンツが返される。 article=20250401' a article=202504012%20and%20'a'='a b article=20250401%20and%20' a'='b C article=20250401%20and%201=0 article=20250401%20and%201=1 e Eさんは、速やかにサイト担当者に連絡し、インターネットからサイトメにアクセ スできないようネットワーク構成を変更した上で，該当するプログラムを修正する よう依頼した。これに対してサイト × の担当者は、“重要情報の漏えいなどの問題が 発生することはない。DBには重要情報もない。サイト✕にアクセスできないように する必要はない。”と主張した。それに対してEさんは，“本脆弱性はブラインド SQL インジェクションの脆弱性に該当する。そのため、表1と同様の手法を用いることに よって，DB のテーブル名が特定できることになる。”と説明した。Eさんは、Dのテ ーブル名を使うと攻撃者が次にどのような攻撃を行えるかを説明し，対応する必要 性を説いた。これを受け、迅速に対応が行われた。 ［脆弱性が存在していた状況の確認と一斉診断の実施］ 対応完了後，情報システム部では，公開サイトは全て重要サイトに指定するよう にルールを変更することにした。同時に、M社が保有する全ての公開サイトに対する 一斉の両診断（以下、一斉診断という）を実施することにし、その診断をP社に依頼 した。診断対象サイトの情報を表2に示す。 表2 診断対象サイトの情報 サイト名 サイト特性 社外利用者向け 1日当たりの 顧客情報 停止によ アカウントの作成方法 アクセス数 有無 る影響 サイトA ECサイト 利用者が作成 10,000 有 大 サイトB 業務サイト 管理者が発行 3,000 有 中 サイトC 情報提供サイト なし 10,000 浦 小 ： ： ： ： ： ： サイトZ （省略） （省略） （省略） （省略） （省略） 診断の結果、深刻度レベル High以上の脆弱性が検出されたサイトが数サイトあり、 Medium 以下の脆弱性が数十件検出されたサイトも多数あった。 サイトによっては，初回リリース時の両診断以降にアップデートや設定変更をし ていないにもかかわらず，初回リリース時の両診断結果と今回の一斉診断結果が異 なっている場合もあった。P社の診断は、決められた手順に従って行い，診断結果は 技術レビューを行うので，診断員による差異はほぼないと、EさんはP社から聞いて いた。また、初回リリース時の両診断では、サイトに不具合はなかったと報告を受 けている。Eさんが、改めてP社に確認すると、診断結果が異なっていた要因は、 f や だった。これらのことから、Eさんは初回リリース後も定 期的な両診断が必要であると結論づけた。 【PF診断で検出された脆弱性］ PF 診断で検出された脆弱性を表3に示す。 表3 PF 診断で検出された脆弱性（抜粋） サイト名 脆弱 脆弱性 深刻度 CVSSv3 補足 性 ID レベル 基本値 サイトA PA-1 SSL/TLS サーバの暗号強度が弱 Medium 5.9 く、推奨されていない鍵交換 をサポート サイトB PB-1 OpenSSH でリモートから認証な High 8.1 CVE 番号：CVE-20XX- しに任意のコード実行が可能 XXXXX PB-2 管理者用のWebのログイン画面 Medium 5.3 に認証試行が何回でも可能 PB-3 SSL/TLS サーバの暗号強度が弱 Medium 5.9 く，推奨されていない鍵交換 をサポート サイトC PC-1 SSH 接続の安全性を低下させる Medium 5.9 CVE 番号：CVE-20YY- ことが可能 YYYYY サイトD PD-1 （省略） High 7.2 PD-2 （省略） CriticaL 9.8 サイトE PE-1 （省略） Medium 6.5 脆弱性 PA-1とPB-3について、CRYPTRECが作成し、IPAが発行している“TLS 暗号 設定ガイドラインVer. 3.1.0”の“4.推奨セキュリティ型の要求設定”には、表4に 示す鍵交換におけるビットセキュリティの基準を満たすよう記載されていた。その ため、サイトA及びサイトBは基準を満たす設定に変更することにした。 表4 鍵交換におけるビットセキュリティの基準 鍵交換プロトコル 基準 ECDHE h ビットセキュリティ以上を満たす DHE 」 ビットセキュリティ以上を満たす 脆弱性PB-1は、管理者がメンテナンス用にリモートアクセスで使っている OpenSSH において検出された。OpenSSHでは、ログインが一定時間内に成功しないと，認証試 行のタイムアウト処理が実行される。脆弱性 PB-1は、あるセキュリティベンダーの 報告によると、認証試行のタイムアウト処理が同時に多数実行されると起き得る問 題であり、認証試行の接続時間（LoginGraceTime）の設定が120秒の場合、その間に 100件試行されると、OpenSSHのログに “Timeout before authentication”という認 証タイムアウトのメッセージが多数出力され、3～4時間で悪用に成功する可能性が あるとのことだった。もしも，脆弱性を修正したバージョンの 0penSSHに更新できな い場合には，次のいずれかを行う。 ・トレードオフはあるものの，認証試行にタイムアウトを設けないようにサーバの 設定を変更する。 ・サイト担当者が攻撃を早期に検知する方法を採用することによって被害を抑制 する。 サイトBでは、OpenSSH の更新を行った。 脆弱性PB-2は、送信元IPアドレス制限が対策の一つだが現実的な運用が難しい。 代わりの対策として、ログイン画面のアカウントロックがあるが、採用する場合は ロック解除の運用方法や実装について検討が必要である。サイトBでは，②アクセス 元のPCを認証する対策を採用した。 ［Webアプリ診断で検出された脆弱性〕 Webアプリ診断で検出された脆弱性を表5に示す。 表5 Web アプリ診断で検出された脆弱性（抜粋） 脆弱性 深刻度 CVSSv3 補足 性 ID レベル 基本値 サイ WA-1 本来閱 Medium 購入機能で，商品の詳細を閲覧するリクエストに ト A 覧でき 含まれるパラメータ itemの5桁の数字を変更す ない画 ることによって一般会員が本来閲覧できない商品 面を閲 の説明画面を閲覧できた。評価指標を次に示す。 覧可能 CVSS:3. 1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N サイ WB-1 本来開 Medium 5.3 管理者用アカウントでログインし，発注確認機能 7B 覧でき のURL”を確認後、一般利用者アカウントでログ ない画 インし直し、Web ブラウザのアドレスバーに当該 面を閲 URLを入力することによって、管理者用の画面を 覓可能 閲覧できた。この画面では，他人の発注情報が全 て閲覧できた。評価指標を次に示す。 CVSS:3.1/AV:N/AC: H/PR:L/UI:N/S:U/C：H/T:N/A:N 注”https://site-b.m-sha.co.jp/administrator0001/order_history 表5 Web アプリ診断で検出された脆弱性（抜粋）（続き） サイ 脆弱 脆弱性 深刻度 CVSSv3 補足 ト名 性 ID レベル 基本値 サイ WC-1 0Sコマ Critic 9.8 問合せフォームが直接シェルに入力値を渡す作り 7C ンドイ al になっていて，任意の OS コマンドが実行でき ンジェ た。ただし、管理者権限が必要な操作はできなか クショ った。 ン 脆弱性 WA-1とWB-1は、HTTPリクエストの内容を一部変更することによって本来閲 覧できない画面を閲覧できるという点では同じであるが，評価指標の値が異なる。 評価指標のうち、③Attack CompLexity （AC）の値はそれぞれLとHであった。 脆弱性 WC-1 について、④管理者権限が必要な操作ができなかったのは，サイト C の仕様どおりであった。サイトCの仕様を図2に示す。 1. Web サーバ及び Web アプリケーションサーバから成る。 2. DB サーバとの連携はしていない。 3. Web アプリケーションプログラムは、一般利用者権限の専用アカウントでプロセスを実行し 問合せフォームに入力された値をメールコマンドで管理者宛てに送る。 5. 問合せ内容がログに保存され、その中にメールアドレスなどの個人情報をもつ。 ログには特定のアカウントだけがアクセスできる。 図2サイトCの仕様（抜粋） 〔脆弱性評価方法の検討］ 一斉診断が一段落したところで、情報システム部は脆弱性管理についての課題を 議論した。対応の要否判断が不適切であったサイトや対応が遅すぎたサイトがあっ たので、課長は、Eさんに新たな脆弱性評価方法を検討するよう指示した。 はじめにEさんが調査したところ，IPA のホームページに“脆弱性対応におけるり スク評価手法のまとめ”というレポートが公開されていたので、これを参考にする ことにした。Eさんは，検討内容を↓課長に報告した。次は，その際のEさんと」課 長の会話である。 Eさん：レポートでは、対応要の脆弱性を簡易的な1次評価で選び、さらに、2次評 価で優先度を評価する手法が提案されています。 J課長：1次評価は具体にはどのような評価をするのか。 Eさん：1次評価では、基本値と ExpLoit Prediction Scoring System （EPSS）値を 用います。EPSS 値の代わりにCVSSv3 の現状値を用いる方法もありますが、 ⑤現状値と EPSS値を比べると、現状値は手間が掛かり，EPSS値は手間が掛 からないとされています。1次評価では図3のように脆弱性を領域図で 4領 域に分します。 EPSS値（%） 100へ しきい値B IV |I 0 → 基本値 0.0 しきい値A 10.0 注記 EPSS値がしきい値Bの場合は、領域！又は！と、基本値がしき い値Aの場合は、領域「又は！！と考える。 図31次評価の領域図 J課長：しきい値はどうするのか。 Eさん：しきい値Aは7.0に、しきい値Bは1%に設定しようと考えています。領域 Iは対応不要とし、領域｜〜！を2次評価の対象にします。 J課長：なるほど。では、そのしきい値に設定してみて，対応すべき脆弱性に漏れが 出るなどの問題があれば、しきい値を見直すことにしよう。 Eさん：はい。分かりました。 J課長：あとは EPSS値を用いた脆弱性評価について、しきい値の見直し以外にも、 し を継続に行うことで被害を防ぐ助けになるだろう。 Eさん：分かりました。 J課長：ところで，Webアプリ診断では，見つかった脆弱性のEPSS値が報告されない ことが普通だが、どのように評価するのか。 Eさん：SP社のWebアプリ診断であれば，見つかった脆弱性のEPSS 値は、しきい値 B よりも高いとみなすのが妥当であると考えられます。Web アプリ診断で検 出される脆弱性を、全て領域1か！とみなそうと考えています。 J課長：その方法が安全だな。次に、2次評価はどうするのか。 Eさん：2次評価は、環境値と先に評価した領域とを組み合わせた方法にしようと考 えています。 J課長：環境値を全て算出するのだな。 Eさん：環境値の算出においては，現状評価基準の各評価指標を，“Not Defined”と 設定することができます。環境評価基準での各評価指標の値の判断は各サ イト担当者に依頼します。そして、表6に示す対応優先度表によってS～C の最終的な対応優先度を決定します。 表6 対応優先度表 CVSSv3 環境値 領域 9.0～10.0 0～3.9 4.0～6.9 7.0～8.9 C B A S C C B A S：即時対応 A ：対応優先度高 B：対応優先度中 C： 対応優先度低 J課長：分かった。一斉診断の結果で幾つか評価して確認してほしい。 Eさん：分かりました。 〔対応優先度評価の実施」 Eさんが2次評価を幾つか行った結果を表7及び表8に示す。 表7 PF診断で検出された脆弱性に対する評価結果（抜粋） 脆弱性 ID PB-1 PC-1 PD-1 PD-2 PE-1 EPSS 値（%） 39 96.54 0.0 2.6 8.7 CVSSv3 環境値 8.1 7.7 5.7 8.0 6.5 対応優先度 m n 9 表8 Webアプリ診断で検出された脆弱性に対する評価結果（抜粋） 脆弱性 ID WA-1 WB-1 WC-1 EPSS 値 （%） 対象外 対象外 対象外 CVSSv3 環境値 5.0 7.1 9.8 对応優先度 r S t この運用によって，脆弱性対応の優先度評価がサイト担当者によらず適切かつ迅 速にできるようになった。

共通の文章

スマートフォン用アプリケーションプログラムの開発に関する次の記述を読んで， 設問に答えよ。 A社は，撮影機器の販売や写真のプリントサービスを全国に 200店舗で展開する従 業員2,000名の企業である。実店舗の運営に加え、インターネットを介して撮影機器 の販売を行う ECサイト事業を有している。このたび，会員がスマートフォン（以下、 スマホという）用アプリケーションプログラム（以下、スマホ用アプリケーション ブログラムをスマホアプリという）を通じて，写真入りのカレンダーなどのグッズ （以下，フォトグッズという）を注文できるサービス（以下、Eサービスという）を 新規に開始することになった。Eサービス用スマホアプリ（以下、Fアプリという） は国内で流通する主要なスマホ 0Sである 0S-αとOS-βの過去5年以内に正式リリー スされたバージョンをサポートする。 ［Eサービスの説明〕 Eサービスは、「アプリとサーバサイドのシステム群で構成される。F アプリは， インターネットを介してEサービス用 Webサーバ（以下、A社 Webサーバといい、 FQDN は www.a-sha.co.jp とする）及び大手クラウドサービスプロバイダC社のクラウ ドストレージサービス（以下，Cサービスという）との間で HTTPS を使用して通信す る。フォトグッズの作成に使う写真は，Fアプリから＆サービスにアップロードする。 Eサービスのネットワーク構成を図1に、機能概要を図2に、Fアプリの画面構成を 図3に、フォトグッズの注文処理の流れを図4に、Cサービスの仕様を図5に示す。 スマホ A社 Fアプリ インターネット FW A社Webサーバ DBサーバ Cサービス FW： ファイアウォール DBサーバ：データベースサーバ 図1Eサービスのネットワーク構成（概要） 1.新規会員登録機能 Eサービスを利用するための新規会員登録を行う。 2.ログイン機能 会員IDとパスワードでログインする。ログインした会員には、認証トークン 1が払い出さ れ、ログアウトするまでの間、Fアプリに保存される。認証トークンは，A社Web サーバ上で 会員のセッションを識別するために使用する推測困難な値である。 3.フォトグッズ注文機能 Fアプリ上でフォトグッズを注文する。ログイン済み会員だけが利用できる。 なお，フォトグッズは，指定したA社の実店舗で受け取ることができる。 4.キャンペーン案内機能 キャンペーンのWebページ（以下、キャンペーンページという）を表示する。ログイン済み会 員だけが利用できる。 なお，キャンペーンに応募することによって、フォトグッズの割引などに利用可能なクーポン を入手できる。会員には，電子メール（以下、メールという）などを通じて、期間限定のキャ ンペーンを案内する。キャンペーンの内容は、2週間ごとに更新される。 1認証トークンは、ログイン後にFアプリがA社Webサーバに HTTPリクエストを送信する際， Authorization ヘッダーに指定される。 図2 Eサービスの機能概要（抜粋） キャンペーン 初期画面 ログイン画 ホーム画 案内画面 会員ID 新規会員登録へ フォトグッズ注文 パスワード キャンペーン キャンペーン案内 ペ ージ ログイン画面へ ログイン ログアウト →：ボタンが押下されたときの画面遷移 -≥：適切な値を入力してボタンが押下されたときの画面遷移 注記キャンペーンページは HTML形式で作成し、A社 Web サーバにアップロードしておく。 図3Fアプリの画面構成（抜粋） Fアプリ A社Webサーバ Cサービス フォトグッズを注文 （あ 7注文内谷をBBサーバに豆録し， -注文番号を採 注文番号を通知 写真を“nnnnnn.zip”という ファイル名でZIP形式に圧縮 （え） nnnnnnnn.zipをアップロード お アップロード成功を通知 注記 "nnnn”は注文番号であり、00000001から始まる十進数の連番である。 図4 フォトグッズの注文処理の流れ 1. サービスの概要 （1） Cサービスはマルチテナントのストレージサービスである。テナントの管理権限をもつ利 用者（以下、管理者という）が作成したストレージに対し、テナントの作成したシステム （以下，利用システムという）からファイルのアップロードやダウンロード（以下、アッ プロード，ダウンロードを併せてファイル操作という）を行う。 （2）管理者は、ストレージの作成時に任意のストレージ名を設定する。ストレージを作成す ると、Cサービスからアクセスキーが発行される。アクセスキーはストレージごとに異なる 40字の英数字である。 （3）利用システムは、ストレージ上のファイルをURL のパスで指定する。例えば、ストレー ジ“●●●”上のファイル“AAA”をファイル操作する際は、"/●●●/AAA”を指定 する。ファイルのアップロードには HTTPのPUT メソッドを，ファイルのダウンロードには GETメソッドを用いる。 （4） 利用システムは、次の方式a又は方式bでファイル操作を行う。 2. 方式 a （1） 説明 アクセスキーを HTTPリクエストのAuthorizationヘッダーに指定する方式である。利用シ ステムは、Cサービスから発行されたアクセスキーを用いることによって、アクセスキーに 対応するストレージに格納された全てのファイルに対するファイル操作が可能となる。 Authorization ヘッダーに正しいアクセスキーが指定されていない場合，ファイル操作は 拒否される。 図5Cサービスの仕様（抜粋） （2）使用例 アクセスキー“O•O”を指定して、ストレージ“abc”上のファイル“xyz”をダウンロ ードする際に送信する HTTPリクエストの例を次に示す。 リクエストライン ：GET /abc/xyz HTTP/1.1 ヘッダーフィールド： Host: storage.c-sha.jp Authorization: Bearer OOC 3. 方式b （1） 説明 有効期限（Expires）と署名値（Signature）をクエリパラメータとして付加したURL（以 下，署名付き URL という）を用いて、特定のファイルに対するファイル操作を一時的に可 能とする方式である。ここで，Expires パラメータに指定する有効期限はUNIX タイムスタ ンプ形式である。署名値の生成は次のように行う。 （i） GET 又はPUTから始まり、パス中の"/●●●/AAA?Expires=【有効期限】”で終わ る文字列を署名対象文字列とする。 （ii） アクセスキーを秘密鍵とする。 （ii）署名対象文字列と秘密鍵から HMAC-SHA256 値を求める。 （iv）（ii）で求めた値を base64urlエンコードする。 利用システムは、署名付き URLを生成し、ファイル操作を許可する利用者に伝える。伝え られた利用者は、署名付き URLを指定して HTTPリクエストを送ることによって、ファイル 操作ができる。有効期限が切れた場合やサーバ側で署名値の検証が失敗した場合は，ファ イル操作が拒否される。 （2）使用例 ストレージ“abc”上のファイル"xyで”をダウンロードする場合で、かつ、署名値が“A AA”の場合のHTTPリクエストの例を次に示す。Xyzは，日本時間の2025年5月30日0 時0分0秒、つまり UNIX タイムスタンプで1748530800までの間、ダウンロードが許可さ れている。 リクエストライン：GET /abc/xyz?Expires=1748530800&Signature=AAA HTTP/1.1 ヘッダーフィールド：Host：storage.c-sha.jp 図5 Cサービスの仕様（抜粋）（続き） Eサービスで使うCサービスのストレージ名は、e-serviceである。「アプリでは， 方式aを利用する。アクセスキーは，鍵長 256ビットの共通鍵と AES-CBC アルゴリズ ムで暗号化し、Fアプリ内にリソースとして保存する。Cサービスのストレージ名並 びに AES-CBC の共通鍵及び初期ベクトルは，Fアプリのコード中に定数として定義す る。 〔キャンペーン案内機能の実装方法］ Fアプリでのキャンペーンページの表示には，Webview という仕組みを用いる。 MebView は、スマホOSの提供する仕組みであり、スマホアプリの画面の一部にWebペ ージを表示させることができる。キャンペーンページのHTMLは，WebViewを用いて、 Fアプリの画面上に表示させる。 会員に送るキャンペーン案内のメール本文中には、「アプリでキャンペーンページ を表示するためのURL（以下、F-URL という）を含める。会員がメールアプリから F- URLを開くと、Fアプリが起動し、WebView 上にキャンペーンページが表示される。 キャンペーンページからキャンペーンに応募する際の会員のセッションの識別には， F アプリに保存されている認証トークンを用いる。0S-αでは、キャンペーンページ が表示された後に，WebViewの機能によってキャンペーンページ上の ECMAScript コ ードがFアプリの getToken 関数を呼び出す。これによって、認証トークンが「アプ リからキャンペーンページに引き渡される。OS-βでは別の方式で同様の機能を実現 する。キャンペーンページ上の ECMAScript コードを図6に示す。 const token = f_app.getlokenO）； 図6 キャンペーンページ上の ECMAScript コード キャンペーンページ以外から getToken関数を悪用されないように、getToken 関数 の内部では，図7のように呼出し元のWeb ページのURLを確認する。 開始 呼出し元のWebページのURLの先頭は No “https://www.a-sha.co.jp”か。 Yes 認証トークンを返す。 空文字列，つまり長さ0の 文字列を返す。 終了 図7 getToken 関数の処理の流れ F-URL の例を図8に示す。 f-app://campaign?url=https://www.a-sha.co.jp/campaign/ロロロ 注記 1 "f-app” はカスタムURLスキームである。 注記 2 “ロロロ”はキャンペーンページのURLのパスである。 図8 F-URL の例 ぜい 〔F アプリの脆弱性診断結果］ A社は、セキュリティ専門会社のD社に依頼してFアプリの脆弱性診断を実施した。 その結果，表1に示す脆弱性が検出された。 表1 脆弱性診断結果（抜粋） 脆弱性 脆弱性の概要 解説 1 サーバ証明書の検 F アプリは、HTTPSでサーバと接続する際、サーバ証明書の検証 証不備がある。 エラーがあっても無視し、通信を続行する。そのため、HTTPS通 信の内容が盗聴されたり、改ざんされたりするおそれがある。盗 聴されると，①盗聴した内容からアクセスキーとストレージ名を 攻撃者が取得するおそれがある。 （省略） 2 Cサービスのアク ②攻撃者がFアプリから平文のアクセスキーとストレージ名を取 セスキーの保護に 得できる。そのアクセスキーを用いて、③攻撃者がEサービスの 不備がある。 全利用者の写真を不正にダウンロードするおそれがある。 （省略） 3 F-URL の処理にア F-URL の urlクエリパラメータに、④細工したURL が指定される クセス制御の不備 ことによって、攻撃者のWebサイトにアクセスしてしまうおそれ がある。 がある。また、攻撃者が会員の認証トークンを取得するおそれが ある。 （省略） 〔脆弱性 1］ F アプリの開発チームに所属するUさんは、D社のSさんが開催する診断結果報告 会に参加した。 Uさんは、脆弱性1が作り込まれた経緯を説明した。いさんによると、FアプリとA 社 Web サーバとの間の通信内容に異常がないかどうかを調査するために、開発用 PC で通信解析ツールを利用した。この通信解析ツールはプロキシサーバとして動作す る。このツールを利用すると、Fアプリでは、サーバ証明書の検証エラーが発生し、 F アプリとA社 Web サーバとの間の通信が中断されてしまった。そこで，インターネ ット上のある記事でエラーが発生しても通信を続行する方法が紹介されていたのを 参考にして，Fアプリのコードを変更したということであった。 この通信解析ツールを利用し、“https://www.a-sha.co.jp/campaign/ロロロ” に アクセスした際のレイヤー4～7の通信フローの例を図9に示す。 スマホ 通信解析ツール A社Webサーバ TCPの3ウェイハンドシェイク a を送信 b を送信 C を送信 5サーバ証明書を生成”） 次の順にまとめて送信 （1） d TLS （2） Encrypted Extensions ハンド （3） シェイク （4） f （5） g g を送信 h を送信 TCPの3ウェイハンドシェイク 不 左記のTLSハンドシェイクと同様のフロー h を送信 を送信 不 b を送信 注記 通信解析ツールのプライベートIPアドレスは，000.000.000.000とする。 注”通信解析ツールは、自身のプライベート認証局機能を用いる。 図9 通信解析ツールを利用した際の通信フローの例（抜粋） Uさんは，通信解析ツールを利用してテストを行う際も通信を正常に続行させる方 法をチーム内で話し合った。その結果，今後，開発用のスマホに⑥必要な設定を行 うことにした。加えて，OS-αではテストを行う際だけその設定を有効化するように， Fアプリの中にも設定を追加した。 ［脆弱性2］ 脆弱性2への対応について、Sさんからは方式bを利用し、その際に署名付き URL の生成を図4中の の時点で行ってはどうかとの提案があった。しさんは Sさんの提案を了承した。 〔脆弱性 3］ 次は、脆弱性3についてのUさんとSさんの会話である。 Uさん：対策として、図7の処理を修正します。 Sさん：図7の処理を修正すれば，認証トークンを盗まれるリスクは回避できます。 しかし、Web ブラウザと比べると、①フィッシングサイトにアクセスしてし まっても気付くことができないというFアプリの仕様上の問題点が残ります。 フィッシングサイトに気付くことができるようにするための機能か，そも そもフィッシングサイトにアクセスできないようにする機能が必要です。 しさん：はい。図7の処理の修正に加えて、⑧フィッシングサイトにアクセスできな いようにする機能を実装します。 A社は、検出された脆弱性を修正し、Eサービスの提供を開始した。

共通の文章

IT資産管理及び脆弱性管理に関する次の記述を読んで、設問に答えよ。 V社は、従業員3,000名の製造業である。東京に本社，大阪，名古屋，福岡に支社 がある。V社は，事業部、K事業部，情報システム部（以下、情部という），総務 部，経理部などから成る。 V 社の社内システム及びネットワークの運用並びに情報セキュリティ管理は、情シ 部のB部長とS主任を含む8名の部員が担当している。V社のネットワーク構成を図 1に示す。 V社本社 V社データセンター DMZ データセジター DNSキャッシュサーバ 権威DNSサーバ UTM セグメント 公開Webサーバ プロキシサーバ L2SW メールサーバ V社支社 工場セグメシド 夕 サーバセグメント 会計システム PCセグメン下 ツ 人事システム ファイルサーバ L2SW ：レイヤー2スイッチ メール：電子メール PCセグメント UTM ：統合脅威管理 図 1 V社のネットワーク構成 公開 Web サーバでは、V社製品のキャンペーンなどを紹介している。V 社本社と各 支社及びV社データセンターの間はUTMのVPN機能を使用して通信を行っている。各 支社には、UTMを除いてインターネットからアクセス可能なIT機器はない。 V社のIT資産管理，ドメイン名及び IPアドレスの管理、導入ソフトウェア（以下、 ソフトウェアを SW という）の管理並びに脆弱性管理の現状を表1に示す。 表1 V社のIT資産管理、ドメイン名及び IPアドレスの管理， 導入 SW の管理並びに脆弱性管理の現状 項目 状況 IT資産管理 1. IT資産管理台帳に対して、IT資産の登録、更新及び削除を行う。 2．IT資産管理台帳は、全社で共有されている。 3.インターネットからアクセス可能な全てのIT資産を公開 IT資産と定義する。 4．IT資産管理台帳の管理項目には，資産1D、資産名称，取得金額，管理部門名， 管理者名，公開 IT資産かどうかの区分，及びその他特記事項を含める。また， 公開 IT資産の場合はグローバルIPアドレス（以下、GIP という）”及びドメイ ン名も含める。 5. IT資産管理台帳への登録は次のように行っている。 （1） 情部が購入する IT資産は、情部がIT資産管理台帳に登録する。 （2）事業部がV社データセンター又はV社 DMZにサーバを設置する場合は，情 シ部に設置申請し、承認を得た後に設置する。情部は承認後IT資産管理台 帳に登録する。 （3）事業部が他社データセンター、クラウドサービス又はレンタルサービスを 契約して，サーバなどを利用する場合については、IT資産管理台帳に登録し ていない。 6．IT資産は、年1回の棚卸しで管理部門が現物確認する。その際に、管理部門が IT資産管理台帳を更新する。IT資産の廃棄は管理部門が実施し、その際に、管 理部門がIT資産管理台帳を更新する。 ドメイン名 1. V 社データセンター及びV社本社で使用するIPアドレス及びドメイン名の管理 及び IP ア は、次のように行っている。 ドレスの管 （1） 情部が、“v-sha.co.jp”というドメイン名（以下、V社のドメイン名と 理 いう）をレジストラのW社から取得し、V社データセンター、V社DMZなどに ある公開IT資産に使用している。ドメイン名の使用料は情部が支払ってい る。JPRSが管理しているドメイン名の登録者情報の組織名にV社を，担当者 情報の部署名に情部を，担当者名にS主任を登録している。 （2） GIPは，ISPのR社から割り当てられている。GIPの使用料は，情部が回 線使用料と併せてR社に支払っている。JPNIC の登録者情報の組織名にV社 を，担当者情報の部署名に情部を，担当者名にS主任を登録している。 （3）事業部がV社データセンター又はV社 DMZにサーバなどを設置する場合 は，情部にIPアドレス使用申請を行う。 （4）事業部がV社のドメイン名を使用する場合は、情部にドメイン使用申請 を行う。この際、情部は，必要なDNSレコードを登録している。 2. 事業部が他社データセンター、クラウドサービス又はレンタルサービスを契約 し、新たなドメイン名を登録してサーバを利用する場合は，次のように行って いる。 （1） GIPは、各サービス会社から割り当てられたものを使用している。 （2）ドメイン名は，各事業部が取得している。なお，使用するドメイン名は全 て、トップレベルドメインが".jp”のドメインを使用している。 表1V社のIT資産管理、ドメイン名及びIPアドレスの管理 導入 SWの管理並びに脆弱性管理の現状（続き） 項目 状況 導入 SW の 1. PCに導入するSWは，IT資産管理ツール（以下、AM ツールという）で管理して 管理 おり，IT資産管理台帳には登録せず、PCの“資産 ID”をAM ツールに入力して 管理している。 2.ビジネス上、重要なサーバに導入する SWは、AM ツールで管理している。ビジ ネス上，重要ではないサーバに導入する SWは、主なものをIT資産管理台帳の “その他特記事項”に記入している。 脆弱性管理 1. サーバに導入したSWの脆弱性情報は、情シ部が脆弱性のニュースを毎日見て確 認している。 2.情部が，脆弱性のニュースで話題になった脆弱性情報全てを全部門に連絡し ている。 3. 連絡を受けた各部門が取捨選択し、必要に応じて対応している。 注！ インターネットから当該IT資産にアクセスする時のGIPである。 最近，次のようなサイバー攻撃のニュースが報道された。 （1）CVE-20xX-XXXXX というWebサーバでの通信の暗号化に関する弱性が公表され， それを悪用した攻撃で、ある広告代理店に大きな被害が発生した。 （2） 著名な会社が1年前、CDN事業者のサービスを利用してWeb サーバを立ち上げ， 1か月間商品のキャンペーンを行った。このWeb サーバには、その会社のサブド メインを使用した。キャンペーン後すぐに、CDN サービスを解約したが、今にな って、そのサブドメインが海外の会社の広告サイトとして使われていることが発 覚した。 （3）競合他社で、不要になったにもかかわらず公開されたままとなっていたWeb サ ーバが改ざんされ、フィッシングに悪用されていることが発覚した。 これらを受けて、V社の経営層は，V社でも対策が必要だと考え、対策の検討と実 施を情部に指示した。（2）については、V社でも，CDN事業者のサービスを利用して Web サーバを立ち上げてキャンペーンを行った後，CDN サービスを解約した経緯があ ったので，緊急に確認した。その結果、問題があることが分かり、①図1中のサーバ の設定を変更した。この事態も踏まえて，公開 IT資産管理及び脆弱性管理を見直す ことにした。 〔公開 IT資産管理及び脆弱性管理の目標の設定］ 情部のB部長とS主任は，まず，公開IT資産管理の現状を分析し，公開IT資産 — 31 - 管理及び脆弱性管理の主な目標を表2にまとめた。 表2 公開 IT 資産管理及び脆弱性管理の主な目標（抜粋） 内容 IT資産管理台帳に公開 IT資産を漏れなく登録する。具体には、次のようなケースの 登録漏れをなくす。 （1）事業部がクラウドサービスを契約して利用している公開 IT資産 （省略） K-2 情部が、サーバの導入 SW を一元管理する。 K-3 重要な脆弱性を事業部が修正したかどうかを情部が確認できるようにする。 K-4 利用が終了した公開 IT 資産について、必要な措置を漏れなく行う。 〔目標 K-1の実現］ まず、目標 K-1について検討を行い、各事業部への未登録の公開IT資産の調査依 頼を図2にまとめた。 次の未登録の公開 IT資産を調査し、その一覧を回答すること ・クラウドサービスを契約して利用している公開 IT資産 a 公開 IT 資產 b 公開 IT資産 図2 事業部への調査依頼 次は，目標K-1の実現に関するB部長とS主任の会話である。 B 部長：事業部への調査依頼だけでは漏れが出そうだ。情シ部としても調査すべきだ が、どのような方法があるのか。 S主任：自分でインターネットをスキャンする方法（以下、オンアクセス型という） と、既に外部に構築されているデータベースを検索する方法（以下、検索 エンジン型という）があります。 B部長：どちらの方がよいだろうか。 S主任：オンアクセス型では他社の環境に負荷を与える可能性があります。また、ス キャンするには時間が掛かります。今回は検索エンジン型を使用したいと 思います。 B 部長：分かった。検索エンジン型だと、具体的には，どのような方法があり，どの ような情報が収集できるのかな。 S主任：まず、IPアドレスの割当て、ドメイン名の登録などに関する情報をレジス トラヌはレジストリに問い合わせることができます。そのための標準プロ トコルとして、 」が用意されており、RFC 3912 で定義されていま す。次に、Web ブラウザから利用できるサービスには，無償のものとして、 ドメインの検索サービス（以下、Xサービスという）と、GIP の検索サービ ス（以下，Yサービスという）があります。その他、一部有償になりますが、 2サービスというサービスなどがあります。* サービスで検索可能な情報を 表3に，Yサービスで検索可能な情報を表4に、Z サービスで検索可能な情 報を表5に示します。 表3×サービスで検索可能な情報（抜粋） 検索キーワード 検索可能な情報 組織名” 登録されているドメイン名 ドメイン名 組織名，ドメイン名の担当者識別番号 2、ドメイン名を管理するネーム サーバ名”，登録年月日，接続年月日，最終更新日時など ネームサーバ名 ネームサーバのIPアドレス、登録年月日、最終更新日時など ドメイン名の担当者 ドメイン名の担当者名，メールアドレス、ドメイン名の部署名，電話番 識別番号 2） 号など 注”検索キーワードとして入力した文字列が“組織名”とマッチした検索結果が全て得られる。 注2） 一部の“jp”ドメインの場合だけ検索可能である。 注3 セカンダリ DNSなどが設置されている場合は、複数得られる。 表4 Yサービスで検索可能な情報（抜粋） 検索キーワード 検索可能な情報 GIP 組織名，GIP の担当者識別番号，ネームサーバ名，割当て年月日、返却 年月日、最終更新日時など GIPの担当者識別番号 GIPの担当者名、メールアドレス、GIP の部署名，電話番号など 表5 Zサービスで検索可能な情報（抜粋） 検索キーワード 検索可能な情報 ドメイン名，GIP， GIP, GIP 割当て元の事業者名，FQDN，位置情報（国名，都市名，緯度・ 又は組織名 経度），ポート番号，OS，応答メッセージ情報” 注記 1検索キーワードとして入力した文字列が、"ドメイン名”とマッチした検索結果が全て得 られる。 注記2 検索キーワードとして入力した文字列が、“GIP”とマッチした検索結果が全て得られる。 注記3 検索キーワードとして入力した文字列が、“ドメイン名を取得した組織名”又は“GIPを取 得した組織名”とマッチした検索結果が全て得られる。 注1 製品名やバージョン情報，デフォルトパスワードの使用などである。 - 33一 B 部長：当社が管理すべき公開 IT資産をできるだけ多くリストアップしてほしい。 S主任：事業部から提出されるリストと突合せができるように、当社が取得した GIP， ドメイン名，GIP の組織名，部署名及び担当者名，ドメイン名の組織名，部 署名及び担当者名並びに FQDN を抽出してまとめたリスト（以下，『 リスト という）を作成してみます。Fリストの作成手順を図3に示します。 手順 1： サービスを用い，検索キーワードとしてし d 」を入力して，検索し、 手順 2-1：手順1の結果を基に、L いサービスを用い，検索キーワードとして を指定して，検索し，検索結果としてし 9 の組織名及び を得る。 手順 2-2：手順 2-1 の結果を基に， ｜サービスを用い，検索キーワードとして の h を指定して、検索し、検索結果として 9 の部署 名及び 9 の担当者名を得る。 手順 3-1：手順1の結果を基に， う サービスを用い，検索キーワードとして f を指定して，検索し、検索結果として f の組織名及び 手順 3-2：手順 3-1の結果を基に、 ｜サービスを用い、検索キーワードとして を指定して、検索し，検索結果として f ｜の部署 の担当者名を得る。 手順4：得られた検索結果から「リストをまとめる。 注記1手順2-1～3-2は、手順1で得られた検索結果のうち、“.jp” ドメインのものについて、そ れぞれ行う。 注記2 手順4では、『リストの作成に必要な検索結果だけを選択する。 図3Fリストの作成手順 ［V 社の管理すべき IT 資産の確認と管理の強化］ 事業部の提出した未登録の公開 IT 資産一覧と S 主任の調査結果を突合したところ， 幾つかFリストだけにあるもの（以下、調査漏れという）が見つかった。次は、B部 長とS主任の会話である。 B部長：どのような調査漏れが見つかったのか。 S主任：調査漏れのリストは表6のとおりです。事業部からの説明では、古いケース で調査しきれなかったとのことでした。 表6調査漏れのリスト（抜粋） 結果項番 GIP GIP の部署名 ドメイン名の組織名 FQDN 結果 1 （省略） V 社G 事業部 V 社 subl.v-sha-g.Jp 結果 2 （省略） V社H部 P 協議会 （省略） S主任：表6の結果1については、SSHでは接続できませんでしたが，公開サービス は Webだけが稼働しているようだということが、X,Y, Z サービス以外の ②調査から分かりました。しかし、G事業部はもはや存在しません。調べた ところ、K事業部が業務継承部門です。また、利用OSやSWもバージョンが 古く，多くの脆弱性が内在しているようだということが、③別の調査から 分かりました。 攻撃を受けて被害が発生しないようにするために、④表6の結果1の公開IT 資産を継続利用する場合としない場合のそれぞれの場合にK事業部が行うべ き具体な対応方法を伝えます。 ［脆弱性管理の改善〕 次に，目標 K-2及び目標K-3に対する実現方法を検討した。目標K-2については S主任が必要なルールを決めた。次は、目標K-3の実現方法についてのB 部長とS主 任の会話である。 B部長：目標 K-2が実現できたとしても、次々発表される脆弱性に対して，対策の優 先度などはどのように判断すればよいのか。 S主任：脆弱性についての⑤CVSSの深刻度と⑥KEV カタログへの掲載の有無に基づい て判断するのがよいです。対策の優先度などの判断ルールを作成します。 B 部長：分かった。そのルールも踏まえ、目標K-3を実現するために，⑦表1の脆弱 性管理の改善策を考えてほしい。 S主任：分かりました。 さらに、目標 K-4 について，公開 IT 資産の利用終了時に行うべき措置をS主任が まとめた。 経営層に対応策を説明し，了承を得た。その後，B部長とS主任が作成したルール に従って，V社の公開 IT資産管理及び脆弱性管理の運用が開始された。