A 社グループは，全体で従業員 20,000 名の製造業グループである。技術開発や新製品の製造・販売を行う A 社のほか，特化型の製品の製造・販売を行う複数の子会社（以下，グループ各社という）がある。A 社及びグループ各社には，様々な Web サイトがある。A 社では，資産管理システムを利用し，IT 資産の管理を効率化している。Web サイトの立上げ時は，資産管理システムへの Web サイトの概要，システム構成，IP アドレス，担当者などの登録申請が必要である。
A 社には，CISO が率いるセキュリティ推進部がある。セキュリティ推進部の業務は，主に次の三つである。
A 社の情報セキュリティマネジメントを統括する。
A 社の Web サイトの脆弱性診断（以下，脆弱性診断を診断という）を管理する。例えば，A 社の会員サイトなど，重要な Web サイトについて，診断を新規リリース前に実施し，その後も年 1 回実施する。なお，診断は，セキュリティ専門業者の B 社に委託している。
IoT 製品の市場拡大によってグループ各社による新規 Web サイト開発の増加が予想されている中，A 社の経営陣は，グループ各社の Web サイトのセキュリティが十分かどうかを懸念し始めた。そこで，グループ各社の重要な Web サイトも，A 社のセキュリティ推進部がグループ各社と協議しつつ診断を管理することになった。
セキュリティ推進部が B 社に診断対象となる Web サイトのリリーススケジュールを伝えたところ，同時期に多数の診断を依頼されても対応することができない可能性があるとのことだった。そこで，グループ各社の一部の Web サイトに対する診断を A 社グループ内で実施できるようにするための内製化推進プロジェクト（以下，S プロジェクトという）を立ち上げた。
セキュリティ推進部の Z さんは，S プロジェクトを担当することになった。Z さんはこれまでも B 社への診断の依頼を担当しており，診断の準備から診断結果の報告まで，診断全体をおおむね把握していた。
〔S プロジェクトの進め方〕
S プロジェクトは，B 社の支援を得ながら，表 1 のとおり進めることにした。B 社からは，セキュリティコンサルタントで情報処理安全確保支援士（登録セキスペ）である Y 氏の支援を受けることになった。
表1 S プロジェクトの進め方
〔フェーズ 1：診断項目の決定〕
S プロジェクトでは，診断項目を決めた。
〔フェーズ 2：診断ツールの選定〕
B 社が Web サイトの診断にツール V を使っていることもあり，A 社はツール V を購入することに決めた。ツール V の仕様を図 1 に示す。
図1 ツールVの仕様（抜粋）
診断対象 URL の自動登録機能及び手動登録機能の特徴を表 2 に示す。
表2 診断対象 URL の自動登録機能及び手動登録機能の特徴
A 社は，診断項目のうち，ツール V では診断ができないものは手動で診断を実施することにした。
〔フェーズ 3：Z さんと B 社での診断の実施と結果比較〕
Z さんと B 社は，サイト M に対して診断を実施した。サイト M の画面遷移を図 2 に示す。
図2 サイト M の画面遷移（抜粋）
Z さんは，Z さんの診断結果と B 社の診断結果とを比較した。その結果，Z さんは脆弱性の一部を検出できていないことが分かった。検出できなかった脆弱性は，アンケート入力 1 の画面での入力値に起因するクロスサイトスクリプティング（以下，クロスサイトスクリプティングを XSS という）と，トピック検索の画面での入力値に起因する SQL インジェクションであった。サイト M のアンケート入力 1 からの画面遷移を図 3 に示す。
図3 サイト M のアンケート入力1からの画面遷移
トピック検索の画面で検索条件として入力した値の処理に関する診断で，ツール V が送ったパラメータと検索結果の件数を表 3 に示す。なお，トピック検索の画面で検索条件として入力した値は，パラメータ keyword に格納される。
表3 ツール V が送ったパラメータと検索結果の件数（抜粋）
ツール V は，B 社の診断では，keyword=manual a と keyword=manual b の検索結果を比較して SQL インジェクションを検出できたが，Z さんの診断では SQL インジェクションを検出できなかった。
Z さんは，検出できなかった二つの脆弱性について，どうすれば検出できるのかを Y 氏に尋ねた。次は，その際の Y 氏と Z さんの会話である。
Y 氏 ：XSS については，入力したスクリプトが二つ先の画面でエスケープ処理されずに出力されていました。XSS の検出には，ツール V において図 1 中の c の②設定が必要でした。SQL インジェクションについては，keyword の値が文字列として扱われる仕様となっており，SQL の構文エラーが発生するような文字列を送ると検索結果が 0 件で返ってくるようです。そこで，③keyword の初期値として SQL インジェクションを検出できる“manual”のような値を設定する必要がありました。
そこで，Z さんは，“開発者への報告の際に，診断結果の報告内容が脆弱性なのか偽陽性なのか，その判断を開発者に委ねる。一方，診断結果の報告内容における脆弱性の内容，リスク及び対策について，開発者が B 社に直接問い合わせる。”という案にした。なお，B 社のサポート費用は，問合せ件数に比例するチケット制である。グループ各社が B 社とサポート契約を結ぶが，費用は，当面 A 社がまとめて支払い，後日グループ各社と精算する。
これまでの検討を踏まえて，Z さんは，フェーズ 4 で A 社グループの診断手順案を作成した。
〔フェーズ 5：診断手順案に従った診断の実施〕
Y 氏の協力の下，Z さんは，診断手順案に従ってサイト N の診断を実施することにした。サイト N は既にリリースされている。サイト N の会員（以下，会員 N という）は，幾つかのグループに分けられており，申し込むことができるキャンペーンが会員の所属しているグループによって異なる。サイト N の画面遷移を図 4 に示す。
図4 サイト N の画面遷移（抜粋）
まず，Z さんは，診断対象 URL，アカウントなど，診断に必要な情報を K 社に確認した。しかし，サイト N については診断に必要な情報が一元管理されていなかったので，確認の回答までに 1 週間掛かった。診断開始までに要する時間が課題として残った。
次に，Z さんは，アカウントの設定を行った後，④探査を開始する URL に図 4 のトップページを指定してツール V の診断対象 URL の自動登録機能を使用したが，一部の URL は登録されなかった。その後，登録されなかった URL を手動で登録した。診断を実施してもよいか，Y 氏に確認したところ，注意点の指摘を受けた。具体的には，⑤特定のパラメータが同じ値であるリクエストを複数回送信するとエラーになり，遷移できない箇所があることに注意せよとのことであった。適切な診断を行うために，ツール V の拒否回避機能を設定して診断を実施した。診断では，次に示す脆弱性が検出された。
XSS
アクセス制御の回避
Z さんは，これらの脆弱性について，サイト N の開発部門（以下，開発部 N という）に通知し，偽陽性かどうかの判断，リスクの評価及び対策の立案を依頼した。
〔XSS〕
XSS の脆弱性は，複数の画面で検出された。開発部 N から，“cookie に HttpOnly 属性が付いていると，d が禁止される。そのため，cookie が漏えいすることはなく，修正は不要である。”という回答があった。Z さんは，この回答を受けて Y 氏に相談し，“XSS を悪用しても cookie を盗めないのは確かである。しかし，⑥XSS を悪用して cookie 以外の情報を盗む攻撃があるので，修正が必要である。”と開発部 N に伝えた。
〔アクセス制御の回避〕
Z さんは，手動で診断し，アクセス制御の回避の脆弱性を，図 4 中のキャンペーン一覧の画面などで検出した。ある会員 N が⑦アクセス制御を回避するように細工されたリクエストを送ることで，その会員 N が本来閲覧できないはずのキャンペーンへのリンクが表示され，さらに，リンクをたどってそのキャンペーンに申し込むことが可能であった。正常なリクエストとそのレスポンスを図 5 に，脆弱性を検出するのに使ったリクエストとそのレスポンスを図 6 に示す。
図5 正常なリクエストとそのレスポンス図6 脆弱性を検出するのに使ったリクエストとそのレスポンス
開発部 N は，サイト N へ送られてきたリクエスト中の e から，ログインしている会員 N を特定し，その会員 N が所属しているグループが f の値と一致するかを検証するように，ソースコードを修正することにした。
開発部 N は，B 社の支援によって対応を終えることができたが，B 社へ頻繁に問い合わせることになった結果，B 社のサポート費用が高額になった。サポート費用をどう抑えるかが課題として残った。
〔フェーズ 6：A 社グループの診断手順の制定〕
Z さんは，フェーズ 5 の診断で残った二つの課題についての対策を検討し，グループ各社から同意を得た上で，A 社グループの診断手順を完成させた。
ログイン時に発行されるセッション ID である JSESSIONID は cookie に保持される。
図4 注記3
group_code というパラメータがリクエストに追加される
サーバ側でログイン中の会員 N を特定する手掛かりは，ログイン時に発行され cookie に保持されるセッション ID である JSESSIONID（e）である。これをキーにすれば，サーバ側が持っている会員 N の所属グループを引ける。
一方，クライアントから送られる group_code（f）は，利用者が書き換えたり削除したりできる値である。図6のように group_code を削除した場合に全キャンペーンが出たのは，サーバがこの値を信用して表示を決めていたからである。修正では，セッション ID から特定した会員 N の所属グループが，リクエストの group_code の値と一致するかを検証して，一致しなければ拒否する。
A 社では，資産管理システムを利用し，IT 資産の管理を効率化している。Web サイトの立上げ時は，資産管理システムへの Web サイトの概要，システム構成，IP アドレス，担当者などの登録申請が必要である。
〔フェーズ 5〕
サイト N については診断に必要な情報が一元管理されていなかったので，確認の回答までに 1 週間掛かった。
診断開始までに時間が掛かったのは，サイト N の診断に必要な情報（診断対象 URL，アカウントなど）が一元管理されておらず，K 社に確認して回答を待つ必要があったためである。A 社は，資産管理システムに Web サイトの概要，システム構成，IP アドレス，担当者などを登録することで，IT 資産を効率よく管理している。
この管理策をグループ各社にも広げ，グループ各社でも資産管理システムを導入して Web サイトの情報を管理すれば，診断に必要な情報をその場で確認でき，確認の待ち時間をなくせる。
W 社は，L 社とクラウドサービスの利用契約を締結して，日記サービスを L 社のクラウドサービスに移行し，運用を開始した。
〔機能拡張の計画開始〕
W 社は，サービス拡大のために，機能を拡張した日記サービス（以下，新日記サービスという）の計画を開始した。新日記サービスの要件は次のとおりである。
要件 1：会員が記事を投稿する際，他社の SNS にも同時に投稿できること
要件 2：スマートフォン用のアプリ（以下，スマホアプリという）を提供すること
W 社は，要件 1 を実装した後で要件 2 に取り組むことに決めた。その上で，要件 1 を実現するために，T 社の SNS（以下，サービス T という）と連携することにした。
〔サービス T との連携の検討〕
OAuth 2.0 を利用してサービス T と連携した場合のサービス要求から記事投稿結果取得までの流れを図 3 に，送信されるデータを表 8 に示す。
図3 サービス要求から記事投稿結果取得までの流れ表8 送信されるデータ（抜粋）
各リクエストの通信で TLS 1.2 及び TLS 1.3 を利用可能とするために，②暗号スイートの設定をどのようにすればよいかを検討した。また，サービス T との連携のためのモジュール（以下，R モジュールという）の実装から単体テストまでを F 社に委託することにした。F 社は，新技術を積極的に活用している IT 企業である。
〔F 社の開発環境〕
F 社では，R モジュールの開発は，取りまとめる開発リーダー 1 名と，実装から単体テストまでを行う開発者 3 名のチームで行う。システム開発において，顧客から開発を委託されたプログラムのソースコードのリポジトリと外部に公開されている OSS リポジトリを利用している。二つのリポジトリは，サービス E というソースコードリポジトリサービスを利用して管理している。
サービス E の仕様と，R モジュールについての F 社のソースコード管理プロセスは，表 9 のとおりである。
表9 サービス E の仕様と F 社のソースコード管理プロセス
〔悪意のある不正なプログラムコードの混入〕
F 社は，R モジュールの実装について単体テストまでを完了して，ソースコードを W 社に納品した。その後，W 社と T 社は結合テストを開始した。
結合テスト時，外部のホストに対する通信が R モジュールから発生していることが分かった。調べたところ，不正なプログラムコード（以下，不正コード M という）がソースコードに含まれていたことが分かった。不正コード M は，OS の環境変数の一覧を取得し，外部のホストに送信する。新日記サービスでは，エンコード値 G が OS の環境変数に設定されていたので，その値が外部のホストに送信されていた。
W 社は，漏えいした情報が悪用されるリスクの分析と評価を行うことにした。それと並行して，不正コード M の混入の原因調査と，プログラムの修正を F 社に依頼した。
〔W 社によるリスク評価〕
W 社は，リスクを分析し，評価した。評価結果は次のとおりであった。
エンコード値 G を攻撃者が入手した場合，m の Web サーバであると偽ってリクエストを送信できる。しかし，図 3 のシーケンスでは，③攻撃者が特定の会員のアクセストークンを取得するリクエストを送信し，アクセストークンの取得に成功することは困難である。
F 社は，不正コード M が混入した原因を調査した。調査の結果，サービス E の OSS リポジトリ上に，X トークンなどの情報が含まれるファイル（以下，ファイル Z という）がアップロードされた後に削除されていたことが分かった。
F 社の開発者の 1 人が，ファイル Z を誤ってアップロードし，承認した後，誤ってアップロードしたことに気付き，ファイル Z を削除した上で開発リーダーに連絡していた。開発リーダーは，ファイル Z が OSS リポジトリから削除されていること，ファイル Z がアップロードされてから削除されるまでの間にダウンロードされていなかったことを確認して，問題なしと判断していた。
F 社では，⑤第三者が X トークンを不正に取得して，リポジトリ W に不正アクセスし，不正コード M をソースコードに追加したと推測した。そこで，F 社では，X トークンを無効化し，次の再発防止策を実施した。
表 9 中のバージョン管理に関わる見直しと⑥表 9 中の権限管理についての変更
X トークンが漏えいしても不正にプログラムが登録されないようにするための，⑦表 9 中のサービス連携に関わる見直し
ソースコードには他の不正な変更は見つからなかったので，不正コード M が含まれる箇所だけを不正コード M が追加される前のバージョンに復元した。
W 社は，F 社が改めて納品した R モジュールに問題がないことを確認し，新日記サービスの提供を開始した。
W 社が定めた，CPU 稼働率，処理性能及び応答時間に関わる指標（以下，性能指標という）を監視する。
〔移行先のクラウドサービス選定〕
表 1 の項番 1〜項番 3 の運用を D 社に委託する計画にした。
〔L 社のクラウドサービスにおける権限設計〕
W 社は，D 社に付与する権限が必要最小限となるように，表 7 に示す D 社向けの権限のセットを作成した。
D 社に委託するのは，表1の項番1〜3（ログ保全，障害監視，性能監視）で，項番4の機器故障対応は委託しない。権限は，この運用に必要な最小限にする。
仮想マシンサービス（j）：項番2・項番3の一次切分けでサーバの一覧を参照するので，仮想マシン一覧の閲覧に当たる“一覧の閲覧権限”（ウ）だけが必要である。ログはログ保管ストレージ（オブジェクトストレージサービス）から取り出すので，仮想マシン上のファイルの閲覧権限や，起動・停止などの編集権限は不要である。DB サービス（k）：D 社の運用は DB に登録された会員のデータに触れる必要がなく，権限は“なし”（エ）にする。モニタリングサービス（l）：項番3で性能指標を監視するので，監視している指標の一覧と，過去から現在までの値を見る“一覧の閲覧権限，閲覧権限”（イ）が必要である。監視する指標の追加・削除は W 社が定めるものなので，編集権限は付与しない。
間違えやすいのは，“なし”を選ぶ DB サービスである。表6のとおり DB サービスの一覧の閲覧権限でもスキーマー覧とテーブル一覧が見えるので，運用に必要がなければ付与しない。表7の権限のセットで，オブジェクトストレージサービスにだけ編集権限まで与えているのは，ログのバックアップに使うためである。
設問2(2)
本文中の下線①のイベント検知のルールを，JSON 形式で答えよ。ここで，D 社の利用者 ID は，1110〜1199 とする。
D 社の運用者がシステムから日記サービスのログを削除したときに，そのイベントを検知してアラートをメールで通知するための検知ルール
表1 項番1 ログ保全
D 社作業用端末でのバックアップ作業後に，D 社作業用端末からログを削除する。なお，各機器からログを削除する作業は W 社が行う。
表5
4000：ログ保管ストレージ，・オブジェクトストレージサービス
表4 注記
system と account の取り得る値には正規表現を利用できる。
日記サービスのログは，ログ保管ストレージ（システム ID 4000）に保管され，ストレージは，オブジェクトストレージサービスで構築されている（表5）。したがって，ルールの system は "4000"，service は "オブジェクトストレージサービス"，event は表4にある“オブジェクトの削除”になる。
OAuth 2.0 では，利用者（会員）の代わりに他のサービスの資源にアクセスするものをクライアントと呼ぶ。図3の Web サーバは，会員が投稿した記事を他社の SNS にも投稿するために (9) で記事を投稿しており，クライアントである新日記サービス（m）の Web サーバである。一方，アクセストークンを発行する認可サーバ（n）と，記事の投稿を受け付けるリソースサーバ（o）は，連携先のサービス T が提供する。
エンコード値 G は，クライアント ID とクライアントシークレットを連結して base64 でエンコードしたものなので，これを入手した攻撃者は，新日記サービスの Web サーバになりすまして，認可サーバにリクエストを送れる。しかし，アクセストークンを取得するための表8 q のリクエストには，クライアント認証の値のほかに，認可コード（code パラメータ）が要る。
認可コードは，会員が認可に同意した後に，(5)・(6) で会員の Web ブラウザ経由で正規の Web サーバに渡される。攻撃者は特定の会員の認可コードを手に入れる手段がなく，エンコード値 G だけでは q のリクエストを作れない。認可コードは短い有効期間で 1 回しか使えないとされている（RFC 6749）。
40 字以内に収めるには，“アクセストークン要求に必要な code パラメータ”と“不正に取得できない”の 2 点を書く。“エンコード値 G は推測できない”と書くと，G を入手した前提に反する。
F 社の開発者の 1 人が，ファイル Z を誤ってアップロードし，承認した後，誤ってアップロードしたことに気付き，ファイル Z を削除した上で開発リーダーに連絡していた。
表9 バージョン管理
新規作成，変更，削除の前後の差分をソースコードの変更履歴として記録する。
表9 注記
OSS リポジトリのソースコードと変更履歴のダウンロードは誰でも可能である。
〔F 社による原因調査〕
ファイル Z がアップロードされてから削除されるまでの間にダウンロードされていなかったことを確認して，問題なしと判断していた。
ファイル Z には X トークンが含まれていた。開発リーダーは，ファイル Z が OSS リポジトリから削除されていることと，アップロードから削除までの間にダウンロードされていないことだけを確認して問題なしと判断した。しかし，サービス E は，削除も含む変更の前後の差分を変更履歴として記録するので，削除前のファイル Z の内容は変更履歴に残っている。
OSS リポジトリには利用者認証がなく，ソースコードと変更履歴のダウンロードは誰でも可能である（表9注記）。したがって，第三者は OSS リポジトリの変更履歴をダウンロードして，削除前のファイル Z を取得し，X トークンを得られる。
40 字以内に収めるには，“OSS リポジトリのファイル Z の変更履歴”という取得元と，“削除前のファイルを取得する”という操作を書く。ファイルが削除されていても履歴に残るという点が，この設問の分かれ目である。講評にもあるように，インシデントの再発防止では攻撃の経路を特定することが重要である。
F 社では，開発者・開発リーダーなど全ての利用者に，設定できる権限を全て与えていた。承認権限を持つ開発者は，自分でアップロードしたソースコードを承認できるうえ，変更履歴の削除（承認権限が必要）も行える。これは，権限は必要最小限にするという原則に反している。
F 社のルールでは，開発者がソースコードをアップロードして，開発リーダーに承認を依頼する。そこで，承認権限を開発リーダーだけに与えれば，開発者は承認できず，変更履歴の削除もできなくなり，不正なソースコードや X トークンが入ったファイルが残る経路が絞られる。開発者にはアップロード権限とダウンロード権限だけを付与する。
X 社 CI に発行する E トークン（以下，X トークンという）には，リポジトリ W の全ての権限が付与されている。
表9 注2)
アップロードされたソースコードが承認されると，ビルドと単体テストを自動実行するサービスである。
X 社 CI は，承認されたソースコードをダウンロードして，ビルドと単体テストを自動実行するサービスである。連携に必要なのはソースコードのダウンロード権限だけだが，X トークンにはリポジトリ W の全ての権限が付与されていた。そのため，X トークンが漏えいすると，第三者がソースコードをアップロードして承認し，不正コード M を追加できてしまった。
E トークンの発行形式と有効期間は変更できない（表9 サービス連携）ので，見直しの対象はトークンに付与する権限である。X トークンには，ソースコードのダウンロード権限だけを付与する。そうすれば，トークンが漏えいしても，ダウンロードされるだけで，ソースコードの追加や変更は行われない。
