平成21年度 春期に実施された情報処理安全確保支援士試験
午後Ⅱの全2問（記述式）の全設問に，運営者が独自に書いた解説を付けています。事例本文のどこが根拠になるかを示し，IPA の解答例・採点講評と並べています。
問1 公開鍵基盤の構築
公開鍵基盤の構築に関する次の記述を読んで，設問1〜6に答えよ。
A社は，持株会社（以下，グループ本部という）を中心とした企業グループの中の一社であり，従業員数1,200名の中堅機械製造会社である。業務は，製造業向けの製造機械の製造である。A社には，製造部門以外に，人事総務部，商品管理部，営業部，配送部，情報システム部がある。商品管理部は，在庫管理が主な業務であり，受注状況によって，商品の製造指示を行っている。営業部は，販売推進とA社のグループ会社である販売会社（以下，グループ販社という）からの受注業務を行っている。受注業務には，電話とファックスを利用してきた。
グループ本部では，従業員のワークライフバランスに積極的に取り組んでおり，A社の経営者も，具体的な施策を段階的に実施してきている。ワークライフバランスへの取組の一環として，製造部門以外の部署を対象とするテレワーク環境（以下，Tシステムという）を提供することになった。
また，営業部における受注業務において，誤った商品の納品や，数量の誤りが年に数件発生し，損失と信用の失墜を招いていたので，受注誤りを減らすためのシステム（以下，Nシステムという）の構築もTシステム構築と同時に行うことになった。
両システムの構築は，情報システム部のX課長とZ主任が担当することになり，2人は検討を開始した。
〔Tシステムの検討〕
X課長とZ主任は，まず，Tシステムにおける，ネットワーク接続方法を検討した。次は，そのときの会話である。
X課長：まず，Tシステムの構築に当たって，利用形態や用途を洗い出し，どのようなネットワーク接続方法が適切かを考えてみよう。 Z主任：はい。最初にテレワークでの利用形態ですが，人事総務部のまとめによれば，現時点での対象者は，育児休職，介護休職を取得中で，在宅での勤務を希望する従業員です。その後，段階的に対象者の範囲を広げていくことになっています。勤務場所については，自宅以外にサテライトオフィスも検討されています。 X課長：作業の内容については，社内で行う作業のほとんどが対象となる。外部から無制限に社内のシステムにアクセスできることは，セキュリティ上の大きなリスクとなるから，何らかの制限をかける必要がある。どこから，どのシステムにアクセスする必要があるか，説明してくれ。 Z主任：はい。まず，場所ですが，従業員の自宅とサテライトオフィスからアクセスする必要があります。利用する社内システムには，二つの形態があります。一つは，Webシステムの形態で，受注管理システム，発注管理システムとグループウェアがあります。もう一つは，クライアントサーバシステムの形態で，勤怠管理システムと電子メール（以下，メールという）があります。テレワークについての事前調査で，ほとんどの従業員は自宅でインターネットを利用できることが分かっています。サテライトオフィスについては，提供事業者に確認したところ，十分な帯域が確保されたインターネットが利用できるとのことでしたので，インターネットの利用を前提とすることはTシステムの実現上，問題ないようです。 X課長：費用の面からも，公衆回線や専用線よりもインターネットを利用した方がよいだろう。インターネットを利用することになると，セキュリティ面での要件を検討する必要がある。 Z主任：そうですね。インターネットを利用することから，通信の盗聴や改ざんを防ぐことと，利用者を確実に認証することが必要になります。 X課長：それでは，当社のシステム構築を行っているC社と相談して，Tシステムの通信はどのような仕組みにすべきか，検討してくれ。 Z主任：分かりました。 Z主任は，早速C社でセキュリティを担当しているD氏に連絡を取り，Tシステムにおける安全な通信方法について検討することにした。次は，そのときの会話である。
Z主任：Tシステムを，インターネットを利用して実現するために，IPsecを利用したVPNを構築したいと思いますが，どのようなことに注意する必要があるでしょうか。 D氏：テレワークで利用するPC（以下，テレワークPCという）は，御社の社内ネットワークに直接接続されるのと同様の状態になりますので，社内で使われているPC（以下，社内PCという）と同様の管理が必要になります。 Z主任：テレワークPCについては，社内PCと同じアプリケーションプログラム，ウイルス対策ソフトが導入されたものを貸与することにします。それでよろしいでしょうか。 D氏：それだけでは不十分です。例えば，御社では，ウイルス定義ファイルが，社内に設置されている配布用のサーバだけから自動的に配布されるようになっています。そのため，テレワークPCについては，①VPNで御社の社内ネットワークに接続されていないときに問題が起こる可能性がありますので，その対策が必要です。 D氏は，起こる可能性のある問題と，その対策方法について説明した。
Z主任：分かりました。対策を講じます。それから，不正な接続を防ぐために，信頼性の高い認証を行わなければならないと思いますが，どのような方法をとったらよいでしょうか。 D氏：利用者IDとパスワードによる認証ですと，総当たり攻撃などによって，正当な利用者以外の者が接続できてしまうリスクを無視できません。クライアント証明書を併用した認証方式を採用してはいかがでしょうか。 Z主任：そのようにしたいと思います。 数日後，Z主任はD氏との検討の結果を取りまとめ，D氏にも同席してもらい，X課長に報告した。
Z主任：Dさんと検討した結果，暗号化にはIPsec，認証にはクライアント証明書を利用することにしました。 X課長：分かった。運用上，秘密鍵とクライアント証明書の取扱いには注意が必要だ。そのことも考慮して，C社とともに作業に入ってくれ。 Z主任：そのように手配します。 X課長：ところで，現在広く使われている暗号方式には，暗号強度の問題や脆弱性の問題がある，と聞いたことがあるのですが，どのようなことでしょうか。 D氏：それは，米国国立標準技術研究所（NIST）が定めた，米国政府機関のコンピュータシステムの調達基準のことです。表に示す暗号アルゴリズムを利用したシステムなどの調達は2010年までしか認められていません。
表 米国政府調達基準で現在調達可能で2011年以降調達できなくなる暗号アルゴリズム
D氏：この理由の一つは，コンピュータの性能が上がることによって，数年後には，現在広く利用されている，鍵長a ビットのRSA公開鍵から秘密鍵が推測される可能性があり，②電子署名の対象のデータの改ざんやなりすましが行われる 可能性があることです。これに対しては，鍵長を更に長くすることが求められます。もう一つは，ハッシュ関数として現在広く利用されているb には，ある条件下でc の衝突を意図的に起こすことができる，という脆弱性が発見されていることです。この脆弱性を攻撃されると，電子署名の信頼性が損なわれます。 X課長：なるほど。表の暗号アルゴリズムの問題には今から対策を講じておく必要があるわけですね。 D氏：はい。日本でも政府機関に対して，内閣官房情報セキュリティセンターが2013年度までに対応するように求めています。 X課長：これらは政府機関の基準だが，我々のような民間企業でも，暗号アルゴリズムの問題を考慮してシステムを構築した方がよさそうですね。 D氏：新規に構築するシステムですので，暗号アルゴリズムの問題を考慮した方がよいと考えます。 X課長：Z主任，この件についても，要求仕様を作る上で，十分に気をつけてくれ。 Z主任：はい，分かりました。 〔Nシステム要件の検討〕
続いて，X課長とZ主任は，受注誤りへの対応を行うために，営業部のY主任を交えて，Nシステムの要件を洗い出すことにした。次は，そのときの会話である。
X課長：これまでの電話とファックスによる受注が，どのようなフローで行われているかを確認しよう。Y主任，説明してくれ。 Y主任：はい。まず，電話による受注処理ですが，営業部の従業員が電話を受け，その内容を注文票に記入します。注文票の内容を，同じ従業員が，社内システムの受注管理システムに入力します。商品管理部は，受注管理システムを参照して在庫情報を確認し，製造指示作業を始めます。次に，ファックスによる受注処理ですが，営業部の従業員が，受け取ったファックスの内容を，受注管理システムに入力するようになっています。以後は電話による受注処理と同じです。 X課長：どのような受注誤りが多いのかね。 Y主任：受注誤りで多いのは，受注管理システムへの型番や数量の入力間違いです。 X課長：それでは，表計算ソフトを使って電子化した注文票を，送付してもらってはどうだろうか。そうすれば，受注管理システムとの連携は，比較的容易に構築できるだろう。 Z主任：注文票には，グループ販社の担当者の氏名や電話番号，お客様の事業状況などがうかがい知れる項目が含まれていますので，グループ販社の発注担当者と当社営業部担当者間の機密性を確保することが必要です。 X課長：それでは，電子化された注文票の送付方法について検討することにしよう。 電子化された注文票を安全に送付する方法について，再び，D氏に相談することにした。次は，そのときの会話である。
X課長：電子化された注文票は，注文票を作成したグループ販社と当社の者だけが，内容を知ることができるようにしたいと考えています。電子化された注文票を，インターネットを使って安全に送付する方法として，どのようなものがあるか教えてほしいのですが。 D氏：送付する方法としては，メールを利用する方法と，Webシステムを利用する方法があります。どちらの方法でも，暗号化を利用すれば，安全に送付することができます。 Z主任：Webシステムを利用する場合は，SSLで暗号化された通信路を使って送付することになりますよね。メールを利用する場合は，どのような方法で行うのですか。 D氏：はい，S/MIMEという方法があります。これは，RFCで規定されており，多くのメールソフトが標準で実装しています。S/MIMEを使うと，メールの暗号化と電子署名を行うことができます。 SSLもS/MIMEも公開鍵基盤（PKI）の上で動作しますので，まず，認証局（CA）が必要となります。これには，認証事業者のCA（以下，商用CAという）を利用することもできますし，御社で構築，運用するCA（以下，自営CAという）を利用することもできます。利用者は，自分自身の秘密鍵と公開鍵の対（以下，鍵ペアという）を生成します。CAは，この公開鍵に対して公開鍵証明書（以下，証明書という）を発行します。御社でのCAの設置運用状況は，どうなっていますか。 X課長：はい，グループ本部では，既に証明書ポリシと認証局運用規程（以下，CP/CPSという）を策定しており，ルートCAが自営CAとして設置されています。グループ企業はこのルートCAの利用が可能です。また，グループ企業独自のルートCAを設置してもよいことになっており，商用CAと自営CAのいずれで実現しても構わないことになっています。 Z主任：今回の場合，証明書の発行をタイムリに行う必要があると思うので，独自のルートCAを設置した方がよいと思います。 X課長：そうだな。グループ本部のルートCAを利用するのではなく，当社独自のルートCAを設置することにしよう。 D氏：分かりました。 X課長：この場合，商用CAを利用するか，自営CAを利用するかは何を基準にして決めればよいのですか。 D氏：まず，だれが証明書を利用するのかが基準になります。不特定の利用者を対象とする場合は，商用CAを利用しなければなりませんが，利用者の範囲が限られる場合は，自営CAを利用しても構いません。次に，自営CAの構築費用及び証明書発行費用を含む運用費用と，商用CAの費用との比較によって決めるのが一般的です。 Z主任：今回の場合，利用者がグループ販社と当社に限定されるので，利用者の範囲という観点では，自営CAでも問題なさそうですね。後は，費用と手間の観点での検討が必要ということですね。自営CAを運用する場合，どのようなことをしないといけないのでしょうか。 D氏：構築段階では，自営CAで発行する証明書の種類を決めたり，証明書発行の手順や運用体制を決めたりしなければなりません。これらを文書化してCP/CPSを策定する必要があります。運用段階の主な作業は，証明書の発行と証明書失効リストの発行です。 X課長：自営CAの構築はどのように行うのでしょうか。 D氏：自営CAを構築する方法は幾つかあります。一つ目は，OSの機能やオープンソースソフトウェア（OSS）を使う方法です。二つ目は，アプライアンス製品を使う方法です。三つ目は，市販されているCAソフトを使う方法です。 Z主任：OSSを利用すると，構築費用はかなり下げることができますね。ただし，そのソフトウェアに精通した技術者が必要になると思いますが。 X課長：そうだな。Z主任，これらの情報を基に，電子化された注文票の送付方法をメールとWebシステムのどちらにするか，CAは自営CAと商用CAのどちらにするか，また，自営CAを利用する場合は，CAの構築方法も含めて検討してくれ。 Z主任：分かりました。 〔PKI構築の検討〕
数日後，X課長は，Z主任の検討結果が適切であるかを，D氏を交えて確認した。
Z主任：電子化された注文票の送付方法について検討したところ，Webシステムを利用した送付については，Webシステムの開発が必要ですので，すぐには開始できません。メールについては，証明書が用意できれば，すぐにでも開始できます。受注管理システムとの連携をスムーズに行うために，将来的にはWebシステムを利用することにして，しばらくの間は，メールにすることにしました。 X課長：そうか。CAについてはどうかね。 Z主任：TシステムとNシステムを合わせると，発行する証明書がかなりの数になります。そのため，多数の証明書を一括して発行できる証明書発行プログラムが必要になりますので，その開発費用も含め，3年間で掛かる総費用を算出してみました。なお，CP/CPSについては，グループ本部のCP/CPSを流用することができますので，比較的容易に策定することができます。その結果，当社にとって最適な方式を採用した自営CAを利用する場合が359万円，商用CAを利用する場合が654万円となり，当社の場合，自営CAを利用した方が安いとの結論に至りました。 D氏：なるほど。しかし，証明書を発行するために，自営CAの秘密鍵を使う必要があります。③自営CAの秘密鍵が漏えいすると，グループ販社と御社に被害が及ぶ ことが想定されます。秘密鍵の漏えい防止対策を施すと，証明書発行に要する費用は，これよりは多くなると思います。 X課長：そのとおりだ。自営CAの秘密鍵を安全に使うための手順を考慮して，証明書発行に要する費用を再度計算してくれ。 Z主任：分かりました。 Z主任は，自営CAの秘密鍵を安全に使うための手順を考慮した費用を計算し，X課長に提示した。
Z主任：秘密鍵を安全に使うための手順を見直したところ，鍵管理のアプライアンス製品を導入することで，秘密鍵を安全に管理できることが分かりました。この製品を使用した場合の3年間の総費用は422万円となり，やはり，自営CAを利用する方が安くなります。 X課長：それでは，自営CAを利用することにしよう。WebシステムになったとしてもCAは必要だからな。 Z主任：分かりました。ところで，利用者が証明書署名要求（CSR）を作成するためには，事前に，鍵ペアを生成しておく必要があります。また，CAで証明書発行を行うためには，利用者からCSRをもらう必要があります。 X課長：証明書発行プログラムとは別に，鍵ペアの生成プログラムと，CSR作成プログラムの開発が必要ということだな。ただ，今回の場合，証明書をTシステムとNシステムの利用に限定すれば，必ずしもCSRの作成までを，利用者に行ってもらう必要はないのではないでしょうか。 D氏：おっしゃるとおりです。今回のPKI構築の目的は，御社とグループ販社の担当者間のメールを，第三者が不正に閲覧することができなければよいわけですから，必ずしも，鍵ペアを利用者本人が生成しなくても，御社が生成すれば問題ないと考えます。鍵ペアを御社が生成するのであれば，CSR作成も御社で可能です。鍵ペアの生成プログラムとCSR作成プログラムは，証明書発行プログラムの一部として開発すれば，運用も容易になると思います。 X課長：そういうことだ。この方法を採用する方がよさそうだな。ただし，CP/CPSの中で，④利用者の鍵ペアの取扱いについて，きちんと決めておいた方がよさそうだ。 Z主任，D氏とともに，テレワークを含め，証明書発行の運用フロー概要を作成してくれたまえ。 Z主任：分かりました。 翌日，Z主任は，証明書発行の運用フローをX課長に提示した。
Z主任：証明書発行の運用フローを，図1にまとめました。Tシステムで利用する証明書と，Nシステムで利用する証明書のいずれも，同じCAで発行するようにしています。また，鍵ペアの生成及びCSRの作成はCA運用者で行う方法を採用しています。
図1 証明書発行の運用フロー
X課長：ところで，利用者属性の真偽の確認は，どこで行うのかね。 Z主任：グループ販社の発注担当者の確認は，図1中のd で行います。テレワーク対象者の確認はe で行います。 X課長：登録局（RA）の役割を，利用申請者をよく知っている当社の従業員が担う形になるわけだな。鍵ペアと証明書は，利用申請者にどのような手段で渡すのかね。 Z主任：鍵ペアと証明書は，パスフレーズを使って暗号化し，メールで送付します。復号に必要なパスフレーズは，グループ販社の場合は郵送します。当社営業部担当者とテレワーク対象者の場合は，情報システム部に取りに来てもらいます。 X課長：分かった。ところで，実際の受注フローについては，どのようになるのかね。 Z主任：はい，図2にまとめました。
図2 受注フロー
X課長：グループ販社側で，注文メールの暗号化と署名，請書メールの復号と署名の検証に手間が掛かるが，最近のメールソフトでは，簡単な操作でこれらができるようになっているから，グループ販社にとっても，そんなに面倒な作業ではないだろう。受注管理システムへの入力は，注文票に組み込まれているプログラムで自動化することで，誤りが防げる。ところで，当社営業部担当者の証明書をグループ販社の発注担当者に送っておく必要があるが，どのようにするのかね。それから，グループ販社と当社ともに，メールの暗号化と署名の検証を行う必要がある。そのときに必要となる当社のf 証明書は，いつ，どこに，どのようにして導入するかを手順書として整備する必要があるな。 Z主任：すみません，それらのことを忘れていました。当社営業部担当者の証明書の送付方法とf 証明書の導入については，手順書を作成して配布するようにします。また，グループ販社での導入を支援できるように，営業部員への教育を検討します。 X課長：CP/CPSについても，営業部員がきちんと説明できるようにしておいてくれ。それから，⑤グループ販社では，証明書をNシステム以外の用途に使用しない ように，徹底してくれ。 Z主任：分かりました。 その後，X課長とZ主任は，C社とともにTシステムとNシステムの構築を順調に終え，運用を開始した。
出題趣旨（IPA）
公開鍵証明書を必要とするシステムを構築する際に，商用CAを利用する場合と，自営CAを利用する場合があるが，いずれのCAを利用すべきかの判断基準がないままに決定されることがある。本問では，自営CAを利用する場合に注意すべき点を明確にし，安全なPKIを構築できる能力を問う。
採点講評（問全体・IPA）
問1では，自営CAを利用したシステムの構築について出題した。全体として，正答率は想定どおりだった。
設問と解答例
設問1
解答欄4つ
本文中のa 〜c 及びf に入れる適切な字句を，8字以内で答えよ。
解説
本文の根拠
表 米国政府調達基準で現在調達可能で2011年以降調達できなくなる暗号アルゴリズム
鍵長a ビットのRSA及びDSA
〔Tシステムの検討〕
ハッシュ関数として現在広く利用されているb には，ある条件下でc の衝突を意図的に起こすことができる，という脆弱性が発見されている
〔Nシステム要件の検討〕
そのときに必要となる当社のf 証明書は，いつ，どこに，どのようにして導入するかを手順書として整備する必要があるな。
a は“1,024”，b は“SHA-1”，c は“ハッシュ値”，f は“ルート”である。本文の表は2011年以降に調達できなくなる暗号アルゴリズムの一覧で，公開鍵暗号の欄が鍵長a ビットの RSA 及び DSA，ハッシュ関数の欄がb である。講評のいう“暗号の2010年問題”は，当時広く使われていた鍵長 1,024 ビットの RSA と SHA-1 を，より強い鍵長やハッシュ関数へ移す必要があるという問題である。本文のとおり，SHA-1 には異なるデータからハッシュ値の衝突を意図的に起こせる脆弱性が見つかっていた。署名はデータそのものではなくそのハッシュ値に付けるので，ハッシュ値を衝突させられると，ある文書に付けた署名を別の文書に流用できる。したがって，現在広く使われている鍵長が a=1,024，ハッシュ関数が b=SHA-1，衝突するものが c=ハッシュ値になる。
f は，メールの暗号化と署名の検証のために，グループ販社の側にも導入しておく必要がある当社の証明書である。当社は独自のルートCAを設置するので，これは当社のルートCAの証明書，つまり“ルート”証明書である。設問6の解答例（“A社CAのルート証明書を導入していないから”）とも対応している。
字数は a が 5 字（カンマも 1 字に数える），b が 5 字，c が 5 字，f が 3 字で，制限の 8 字に収まる。a は鍵長のビット数だけを数字で書き，b は“SHA”だけでなく“SHA-1”まで書く。
採点講評（IPA）
設問1では，a，bの正答率が低かった。暗号の2010年問題のような安全性に関わる環境変化に起因する話題や，暗号の強度や脆弱性についてもよく理解しておいてほしい。
設問2
解答欄2つ
本文中の下線①について，どのような問題が起こるかを，45字以内で述べよ。また，その対策を，50字以内で述べよ。
〔問題〕解答例
社内ネットワークに接続されないと，ウイルス定義ファイルが更新されない。
〔対策〕解答例
インターネット上のウイルス定義ファイル配布サーバからも更新できるように，PCの設定を変更する。
解説
本文の根拠
〔Tシステムの検討〕
例えば，御社では，ウイルス定義ファイルが，社内に設置されている配布用のサーバだけから自動的に配布されるようになっています。
〔Tシステムの検討〕
①VPNで御社の社内ネットワークに接続されていないときに問題が起こる可能性がありますので，その対策が必要です。
〔Tシステムの検討〕
インターネットの利用を前提とすることはTシステムの実現上，問題ないようです。
問題は“社内ネットワークに接続されないと，ウイルス定義ファイルが更新されない。”，対策は“インターネット上のウイルス定義ファイル配布サーバからも更新できるように，PCの設定を変更する。”である。D氏は，ウイルス定義ファイルが社内の配布用サーバだけから自動的に配布される現状を挙げ，テレワークPCが VPN で社内ネットワークにつながっていないときに問題が起こる可能性があると指摘している。VPN が切れている間は配布用サーバに届かないので，定義ファイルが古いままになる。
テレワークPCは自宅やサテライトオフィスからインターネットを使って接続する前提なので，VPN の有無にかかわらず，インターネット側にある配布元からも定義ファイルを取得できるように PC を設定しておけば，この状態を避けられる。社内の配布用サーバだけに頼る仕組みを，PC の側で変えるのがポイントである。
字数は問題が 35 字（制限 45 字），対策が 47 字（制限 50 字）で収まる。問題は“何が起こるか”，対策は“何をどう変えるか”を分けて書き，“更新されない”と“PC の設定を変更する”の両方を入れる。
設問3
解答欄2つ
Tシステムにおいて，テレワーク対象者は，他人が社内ネットワークへ不正にアクセスしないようにするために，自分のテレワークPCに関して，運用する上でどのような点に注意する必要があるか。秘密鍵の漏えい防止の観点から二つ挙げ，それぞれ35字以内で述べよ。
〔①〕解答例
テレワークPCの紛失，盗難対策を行う。 テレワークPCを他人に貸与しない。 テレワークPC以外に秘密鍵及び証明書を導入しない。 テレワークPCの利用者パスワードを堅ろうなものにする。
〔②〕解答例
テレワークPCの紛失，盗難対策を行う。 テレワークPCを他人に貸与しない。 テレワークPC以外に秘密鍵及び証明書を導入しない。 テレワークPCの利用者パスワードを堅ろうなものにする。
〔備考〕このうち異なる二つを答える
解説
本文の根拠
〔Tシステムの検討〕
運用上，秘密鍵とクライアント証明書の取扱いには注意が必要だ。
〔Tシステムの検討〕
暗号化にはIPsec，認証にはクライアント証明書を利用することにしました。
〔Tシステムの検討〕
テレワークで利用するPC（以下，テレワークPCという）は，御社の社内ネットワークに直接接続されるのと同様の状態になりますので
解答例は四つの候補の中から異なる二つを書けばよい。①“テレワークPCの紛失，盗難対策を行う。”，②“テレワークPCを他人に貸与しない。”，③“テレワークPC以外に秘密鍵及び証明書を導入しない。”，④“テレワークPCの利用者パスワードを堅ろうなものにする。”のうち，どれを選んでもよい。
Tシステムでは，認証にクライアント証明書を使い，テレワークPCは社内ネットワークに直接つながるのと同じ状態になる。そのため，テレワークPCに入っている秘密鍵が他人の手に渡れば，他人が本人になりすまして社内に入れる。①は PC ごと奪われる場合，②は貸与先で使われる場合，③は秘密鍵や証明書の複製が別の機器に残る場合，④は PC を手にした者が利用者認証を破る場合を，それぞれ防ぐ。
字数は①が 19 字，②が 17 字，③が 25 字，④が 27 字で，制限の 35 字に収まる。設問は“秘密鍵の漏えい防止の観点”の運用上の注意なので，ウイルス対策ソフトの導入のような秘密鍵と直接関係しない対策は挙げず，同じ内容を二つに分けて書かない。
設問4
70字以内
本文中の下線②について，秘密鍵の推測が成功したとして，どのようにすれば改ざんやなりすましができるか。その方法を，70字以内で述べよ。
解答例
電子署名の対象のデータを改ざんした上で，そのハッシュ値から，推測した秘密鍵で署名を生成し，本来の所有者と偽って送信する。
解説
本文の根拠
〔Tシステムの検討〕
現在広く利用されている，鍵長a ビットのRSA公開鍵から秘密鍵が推測される可能性があり，②電子署名の対象のデータの改ざんやなりすましが行われる可能性があることです。
〔Tシステムの検討〕
この脆弱性を攻撃されると，電子署名の信頼性が損なわれます。
答えは“電子署名の対象のデータを改ざんした上で，そのハッシュ値から，推測した秘密鍵で署名を生成し，本来の所有者と偽って送信する。”である。電子署名は，署名の対象のデータそのものではなく，そのハッシュ値を署名者の秘密鍵で処理して作る。受信者は，所有者の公開鍵でこの署名を確かめる。
そこで秘密鍵が推測できれば，攻撃者は，データを改ざんし，改ざん後のデータのハッシュ値を求めて，推測した秘密鍵でそれに署名できる。その署名は所有者の公開鍵で正しいと確かめられるので，受信者は改ざんに気付かず，攻撃者を本来の所有者と信じる。これが“改ざん”と“なりすまし”が同時に起こる仕組みである。
字数は 60 字で，制限の 70 字に収まる。“データを改ざんする”“ハッシュ値に署名する”“所有者と偽って送る”の三つを順に入れる。講評は，“推測した秘密鍵でメール本文を暗号化する”のように，電子署名を暗号化と取り違えた解答が散見されたと述べているので，署名はハッシュ値に付けるものだと押さえる。
採点講評（IPA）
設問4は，正答率が低かった。特に電子署名について，“推測した秘密鍵でメール本文を暗号化する”など，正確には理解していないと思われる解答が散見された。
設問5(1)
50字以内
本文中の下線③について，どのような被害が考えられるか。50字以内で述べよ。
解答例
グループ販社の発注担当者の証明書が偽造され，偽の注文票が送られる可能性がある。
解説
本文の根拠
〔PKI構築の検討〕
証明書を発行するために，自営CAの秘密鍵を使う必要があります。③自営CAの秘密鍵が漏えいすると，グループ販社と御社に被害が及ぶことが想定されます。
〔Nシステム要件の検討〕
注文票には，グループ販社の担当者の氏名や電話番号，お客様の事業状況などがうかがい知れる項目が含まれていますので
答えは“グループ販社の発注担当者の証明書が偽造され，偽の注文票が送られる可能性がある。”である。自営CAの秘密鍵は証明書の発行に使うものなので，これが漏えいすると，第三者が自営CAを名乗って任意の証明書を作れる。
Nシステムでは，グループ販社の発注担当者が，注文票をメールの暗号化と署名を使って当社に送る。当社は，自営CAが発行した証明書を信頼して署名を確かめるので，偽造された発注担当者の証明書で署名された偽の注文票も，正当なものとして受け付けてしまう。被害は，証明書の利用者であるグループ販社と，それを受け取る当社の双方に及ぶ。
字数は 39 字で，制限の 50 字に収まる。“秘密鍵が漏れる”ではなく，その結果として“何が偽造され，どんな被害になるか”まで書く。
設問5(2)
解答欄2つ
本文中のd とe に入れる適切な記号を，図1中の(ア)〜(サ)から選んで答えよ。
解説
本文の根拠
〔PKI構築の検討〕
グループ販社の発注担当者の確認は，図1中のd で行います。テレワーク対象者の確認はe で行います。
〔PKI構築の検討〕
登録局（RA）の役割を，利用申請者をよく知っている当社の従業員が担う形になるわけだな。
図1
(イ)A社営業業務担当者の“利用申請の承認”へ矢印
図1
(ケ)所属長の“利用申請の承認”へ矢印
d は(イ)，e は(ケ)である。X課長は，登録局（RA）の役割を，利用申請者をよく知っている当社の従業員が担うと述べている。図1で申請を受けて内容を確かめる“利用申請の承認”は二か所あり，グループ販社の発注担当者の申請（ア）を承認するのは A 社営業業務担当者の(イ)，テレワーク対象者の申請（ク）を承認するのは所属長の(ケ)である。
取引先の発注担当者をよく知っているのは A 社の営業業務担当者，社内のテレワーク対象者をよく知っているのは所属長なので，真偽の確認の場がそれぞれこの位置に置かれている。
間違えやすいのは，(ウ)の“鍵ペアの生成，CSRの作成，証明書の発行”を CA 運用者が行う点で，これは真偽の確認ではなく発行の作業であること，また(ア)や(ク)は申請書を作る側で，確認を“行う”側ではないことである。この設問は字数制限のない記号選択なので，図1の矢印の向きと担当者の列を見て選ぶ。
設問5(3)
30字以内
本文中の下線④について，鍵ペアの取扱い上で注意すべき事項を，30字以内で述べよ。
解答例（2通り）
CAにおいて，利用者の秘密鍵を厳重に管理する。 鍵ペアと証明書の送付後に，CAでは秘密鍵を削除する。
解説
本文の根拠
〔PKI構築の検討〕
必ずしも，鍵ペアを利用者本人が生成しなくても，御社が生成すれば問題ないと考えます。
〔PKI構築の検討〕
CP/CPSの中で，④利用者の鍵ペアの取扱いについて，きちんと決めておいた方がよさそうだ。
〔PKI構築の検討〕
鍵ペアと証明書は，パスフレーズを使って暗号化し，メールで送付します。
解答例は“CAにおいて，利用者の秘密鍵を厳重に管理する。”と“鍵ペアと証明書の送付後に，CAでは秘密鍵を削除する。”の二つで，どちらか一方が書けていればよい。本件では，鍵ペアの生成と CSR の作成を CA 運用者が行うので，利用者の秘密鍵は一度 CA 側で生成され，CA の運用者が知り得る状態になる。
秘密鍵は本来，本人だけが持つべきものである。CA 側が利用者の秘密鍵を持ち続ければ，CA の運用者や，CA から秘密鍵が漏えいした場合の第三者が，その利用者になりすませる。そこで，CA にある間は厳重に管理し，パスフレーズで暗号化して送付し終えたら CA 側では削除する，という取扱いを CP/CPSに定めておく。
字数は 23 字と 26 字で，制限の 30 字に収まる。講評は，CA が鍵ペアの生成も行う場合のリスクとリスク対応方法を理解してほしいと述べている。“鍵ペアを暗号化して送る”など送付の手順だけでなく，CA 側での扱い（管理・削除）を書く。
採点講評（IPA）
設問5では，(3)の正答率が低かった。自営CAを利用したシステムでは，公開鍵証明書の発行者が鍵ペアの生成も行うことがあるが，その場合のリスクやリスク対応方法についても，理解しておいてほしい。
設問6
解答欄2つ
本文中の下線⑤について，グループ販社の発注担当者が，証明書の使用制限に反して，第三者に対し，A社の自営CAで生成された秘密鍵を用いて署名したメールを送付した場合，メール受信者では，どのような問題が発生するか。また，その理由は何か。A社が自営CAを採用していることを考慮して，それぞれ20字以内，30字以内で述べよ。
解説
本文の根拠
〔Nシステム要件の検討〕
不特定の利用者を対象とする場合は，商用CAを利用しなければなりませんが，利用者の範囲が限られる場合は，自営CAを利用しても構いません。
〔Nシステム要件の検討〕
グループ本部のルートCAを利用するのではなく，当社独自のルートCAを設置することにしよう。
〔PKI構築の検討〕
⑤グループ販社では，証明書をNシステム以外の用途に使用しないように，徹底してくれ。
問題は“署名の正当性を確認できない。”，理由は“A社CAのルート証明書を導入していないから”である。自営CAは，利用者の範囲が限られる場合に使うものであり，A社の自営CAは，グループ販社と当社の間のメールだけを想定している。
使用制限に反して，グループ販社の発注担当者が第三者に署名付きメールを送ると，その第三者は A 社の自営CAのルート証明書を導入していない。署名を確かめるには，証明書を発行した CA の証明書をたどって信頼できる CA にたどり着く必要があるが，信頼の起点となるルート証明書が無いので，署名が正しいかどうかを確認できない。本文が“想定した範囲外で証明書が使用された”場合を考えさせている点が，この設問のねらいである（講評も同旨）。
字数は問題が 14 字（制限 20 字），理由が 21 字（制限 30 字）で収まる。“署名が偽造される”ではなく，“確認できない”という受信者側の状態を問題に書き，理由には“ルート証明書を導入していない”まで入れる。
採点講評（IPA）
設問6は，正答率が低かった。自営CAを利用したシステムを構築する場合，想定した範囲外で公開鍵証明書が使用されたときの影響についても考慮する必要があることを，理解しておいてほしい。
出典：平成21年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
問2 インターネット販売を行う企業の情報セキュリティ管理
インターネット販売を行う企業の情報セキュリティ管理に関する次の記述を読んで，設問1〜5に答えよ。
P社は従業員数500名の衣料小売業者であり，店頭販売やカタログ販売を行っている。これに加え，5年前からは社内に業務システム（以下，販売システムという）を構築し，一般消費者に対してクレジットカード決済を利用したインターネット販売を行っている。P社では情報セキュリティを確保するための取組を進めており，インターネット販売事業に関してISO/IEC 27001（JIS Q 27001）の認証（以下，ISMS認証という）を2年前に取得している。
P社は先ごろISMS認証の維持審査に合格したが，この審査において四つの観察事項を指摘された。ISMS認証機関から提示された維持審査結果報告書を図1に示す。
図1 維持審査結果報告書
〔観察事項への対応〕
維持審査の結果を受け，P社では，情報セキュリティ責任者を兼務している情報システム部のG部長と，その部下で販売システムの管理を担当しているFさんが観察事項への対応に当たることになった。
次は，G部長とFさんの会話である。
Fさん：維持審査での観察事項への対応ですが，どのように進めていきましょうか。 G部長：不適合はなかったが，四つの観察事項への対応策を検討しよう。1.については適用範囲の定義文書を修正することで対応しよう。2.と3.は情報セキュリティポリシ（以下，ポリシという）の修正に加え，技術的な対応も必要になりそうだ。具体的にどの程度まで実施するのかが難しいね。 Fさん：4.については，新たな法律の制定や業界の動向を踏まえて社内のISMS運営事務局で法的要求事項の改訂案を検討し，a の場で承認を得るというルールを作るとよいと思います。クレジットカード業界に関しては新たな動きがありますね。 G部長：審査が終わってから聞いた話では，2008年6月に公布された改正割賦販売法が施行されると，クレジットカードの発行会社にはクレジットカード番号（以下，カード番号という）を含むカード会員データの保護が義務付けられるそうだ。当社のようなカードの加盟店を直接規制する法律ではないが，当社にもカード発行会社から何らかの対策が求められるかもしれない。 Fさん：カード番号の不正な取得や有償での提供を行った個人も処罰されるということでしたね。カード番号を悪用されると影響が大きいですからね。そういえば，クレジットカード業界では加盟店に対して技術的な対応を含めた自主基準を定めていたようです。観察事項の2.と3.への対応のヒントになるかもしれませんので，調べてみます。 数日後，FさんはG部長に調査の結果を報告した。
Fさん：先日の話ですが，国際クレジットカードブランド5社が共同で設立したPCI SSC（Payment Card Industry Security Standards Council, LLC）という国際協議会が，PCIデータセキュリティ基準（Payment Card Industry Data Security Standard，以下，PCI DSSという）という業界基準を設けています。この基準を参考にして対応を考えてはどうでしょうか。 Fさんは図2に示すPCI DSS（バージョン1.2）の要件をG部長に提示した。
図2 PCI DSS（バージョン1.2）の要件
G部長：全部で12個の要件があるのか。観察事項に対応する要件は要件6，8辺りかな。これらの要件が更に細かく分かれているわけだね。 Fさん：そうです。例えば，観察事項として指摘されたパスワード管理に関しては，要件8の中に，図3に示すような詳細要件が定められています。
図3 パスワード管理に関するPCI DSSの詳細要件
G部長：クレジットカード加盟店では，今後このレベルの管理が求められるということか。当社の現状からみるとかなり厳しい要件もあるが，クレジットカード決済を利用していくのであれば実施する方がいいのだろうね。Webアプリケーションの開発時におけるセキュリティ要件については何か参考になりそうなものはあったかな。 Fさん：Webアプリケーションの開発では，クロスサイトスクリプティングやSQLインジェクションなど，広く知られた脆弱性について対処する必要があります。そのため，詳細要件6.5では，安全なコーディングのためのガイドラインに従うことを推奨しています。PCI DSSでは，その代表的なものとして，米国の団体が策定したガイドラインを挙げています。今後はこのガイドラインに沿って具体的なセキュリティ要件を発注の際の仕様に含めるとよいのではないでしょうか。 G部長：そうだね。詳細については検討する必要があるが，今後Webアプリケーションの改修を行うときや新規の開発を行うときには，①委託先に具体的なセキュリティ要件を提示する ことにしよう。 これらの検討を踏まえ，G部長とFさんは観察事項への対応計画を作成した。この対応計画は経営陣の承認を経て実行に移されることになった。
〔PCI DSSを参考にしたISMSの継続的改善〕
その後，G部長が対応計画の完了を経営陣に報告したところ，PCI DSSで求められる要件をベースラインとしてISMSにおける技術面及び管理面の改善を図るようにとの指示が出た。そこで，G部長とFさんはPCI DSSの要件に沿って販売システムの管理状況を確認することにした。次は，G部長とFさんの会話である。
Fさん：PCI DSSの各要件への対応状況ですが，私の考えで12個の要件ごとに現在の状況を表1のようにまとめてみました。
表1 FさんによるPCI DSSの対応状況のまとめ
G部長：今の時点で対応できている要件はどれかな。 Fさん：要件4，5，7，8は対応できていると思います。要件4はインターネットや無線LANなどの公衆ネットワーク上でのカード会員データの暗号化を求めていますが，販売システムでは無線LANは使用していませんし，インターネット経由でカード会員データを送受信する部分はすべてSSLで暗号化されています。要件5はシステムへのウイルス対策ソフトの導入ですが，ウイルス対策ソフトは販売システムに含まれるすべてのPCとサーバに導入済です。 G部長：②ウイルス定義ファイルの自動更新と定期スキャンも実施している し，問題なさそうだ。 Fさん：要件7はカード会員データへのアクセスを業務上必要な範囲内に制限するということですが，販売システムにはポリシ上も機能上も職責に応じて権限を与えられた担当者だけがアクセスできるようになっているので問題はありません。要件8は利用者ごとに個別の利用者IDを割り当てるという要件で，パスワードポリシについてはISMSの観察事項に基づいて対応しました。それ以外の部分は以前から実施済です。 G部長：この四つの要件に関しては対策が実施されているということだね。次に，要件1，3，12については見直しや確認が必要なところだね。 Fさん：はい。要件1ではファイアウォールの設置を求めていますが，詳細要件1.1.6の，少なくとも6か月ごとに，ファイアウォール及びルータに関するルールセットのレビューを実施するという要件が現状では満たされていません。それ以外の詳細要件はすべて対応できています。 G部長：ファイアウォールもルータも，設定についてのレビューは実施していなかったな。今の運用手順を改訂してレビューを行う必要があるね。 Fさん：要件3はカード会員データの保護についてです。カード番号は販売システムのデータベースサーバ（以下，DBサーバという）の中では暗号化されていますが，詳細要件3.4によるとバックアップやログの中にカード番号が含まれている場合にはカード番号の一部を削除するか，あるいは暗号化やハッシュによって読めないようにする必要があります。 G部長：販売システム以外にもカード番号が存在するかどうかだね。具体的にカード番号がどの情報資産に含まれているか，それがどこに保管されているかについては，先日の維持審査の前に実施したリスク分析で明確にされているから対応はそれほど難しくはないだろう。 Fさん：要件12はポリシの整備が中心になっていますが，ここで対応すべき詳細要件としてはインシデント対応計画があります。PCI DSSでは少なくとも年に一度のテストと見直しを求めていますが，インシデント対応計画についてはこれまでにテストも見直しも行ったことがありません。 G部長：この辺までは今までの対策の延長で対応できそうだが，更に修正が必要になるのが要件2，6，9，10，11だね。 Fさん：要件2は，システムのデフォルト設定を使ってはいけないという要件です。 G部長：サーバについては受入れ検査のときに③ポートスキャンツールを使って不要なサービスの有無を確認している が，その後システムを変更しているからもう一度確認が必要だ。 Fさん：要件6は後回しにして，要件9は物理的アクセスの制限や媒体の取扱いについてです。詳細要件9.1.1では機密エリアはビデオカメラやその他のアクセス管理機器で監視し，少なくとも3か月間は監視データを保管することが求められていますが，現状では保管していません。 G部長：サーバ室とコールセンタはカメラで監視しているが，監視映像は保管していないから，追加投資が必要になりそうだ。 Fさん：ほかにはバックアップ媒体の保管の話があります。今は媒体を④サーバ室に保管していますが，外部の施設への保管も検討する必要があります。 G部長：これについては，先ほどのインシデント対応計画と同様に，ISO/IEC 27001のb 計画でも対応すべきだろうね。 Fさん：要件11に移りましょうか。詳細要件11.2では，少なくとも四半期に一度，そのほかにネットワークに大きな変更があったときにシステムへの脆弱性スキャンを行うことが求められています。また，詳細要件11.3では，少なくとも年に一度と，そのほかにインフラやアプリケーションを大幅に変更した後にペネトレーションテスト（以下，Pテストという）を実施することが求められています。 G部長：Pテストは外部にお願いする必要があるのかな。FさんにPテストのスキルを身につけてもらった上で実施するのはどうだろう。 Fさん：社内で実施することは要件上認められていますが，私にPテストのスキルがあったとしても，⑤私がPテストを実施するのは望ましくない ですね。 G部長：そうだね。内部で実施するか外部で実施するかは別途考えよう。 Fさん：残っているのは要件6，10ですね。まず，要件10はアクセスの追跡と監視についてです。具体的には，各システム上でログを取得するだけではなく，改ざんされないように保護した上で少なくとも日に一度は確認することが求められます。 G部長：Webコンテンツへのアクセス状況は解析しているけれども，セキュリティ上のイベントについては特に何もしていない。日に一度の確認となるとかなり大変だから，今後は何らかの対応が必要だ。 Fさん：ほかにはシステムクロックを正確な時刻に保つことが求められていますが，社内のすべての機器は販売システム上の時刻サーバを介してインターネット上の標準時サーバと時刻を同期させています。これには通信の遅延を補正できるc というプロトコルを使っています。 〔Webアプリケーションの保護の手法〕
Fさん：技術的に最も対応が難しそうな要件6の対応状況は表2のとおりです。詳細要件6.2から6.5までは対応済ですが，残りの二つに関しては対応が必要になりそうです。特に詳細要件6.6ではWebアプリケーションの見直し又はWebアプリケーションファイアウォール（以下，WAFという）の導入が求められています。
表2 要件6の対応状況
G部長：詳細要件6.1はセキュリティパッチ（以下，パッチという）のリリース後1か月以内の適用ということだね。システムを停止できない場合も多いが，パッチの運用体制を見直して対応するしかないね。 Fさん：パッチの適用についてはリスクに応じて優先度をつけることも認められていますので，重大なものを優先させ，軽微なものは3か月以内に適用することができます。 G部長：詳細要件6.6のWebアプリケーションの見直しというのはどんな方法で行うのかな。 Fさん：Webアプリケーションの脆弱性を手動又は自動で評価するツール又は手法によって，Webアプリケーションをレビューすることが求められています。脆弱性はすべて修正し，修正後に再評価する必要があります。 G部長：実施の頻度はどれくらいなのかな。 Fさん：少なくとも年に一度実施することが求められています。そのほかに何らかの変更があった場合にも実施する必要があります。 G部長：Webアプリケーションの見直し以外にはWAFの導入も選択肢としてあるということだが，今導入している侵入防止システム（以下，IPSという）では対応できないのかな。 Fさん：今使っているIPSはシグネチャベースの製品で，ネットワーク層に対する既知の攻撃を防御することに主眼を置いています。Webアプリケーションの脆弱性に対する攻撃にはそれほど効果はありません。 G部長：WAFではWebアプリケーションへの攻撃をどうやって防ぐのだろう。 Fさん：これには二つの考え方があるようです。一つはポジティブセキュリティモデルといって，正常な通信として定義されたもの以外の通信をすべて遮断するものです。どういった通信が正常なのかを定義するために個々のWebアプリケーションに対して細かい設定が必要になり，導入にも手間が掛かります。もう一つはネガティブセキュリティモデルといって，シグネチャや特定のパターンに合致した通信をアプリケーション層で遮断するものです。Webアプリケーションの脆弱性の性質から，⑥個々の攻撃に対してシグネチャを作成することが難しい というデメリットがありますが，特定の情報の漏えいを防ぐ観点からは，こちらのモデルの方が有効な場合があります。このため，PCI DSSでは，この二つのセキュリティモデルをWAFに実装することが推奨されています。 G部長：状況によっては両方のモデルを実装したWAFが必要ということか。 Fさん：WAFには攻撃を検知する機能があるので，当社の対策に欠けているPCI DSSの要件を満たせるというメリットもあります。 G部長：なるほど。ただ，⑦Webアプリケーションの見直しをせずにWAFを導入することには問題がある のではないかな。コスト面での制約はあるが，できるだけ併用する方向で検討しよう。 〔トランザクションログに対する代替管理策〕
その後，P社ではPCI DSSを参考に販売システムの改善を図っていったが，システムの制約上，対応が困難な詳細要件が存在することが分かった。次は，G部長とFさんの会話である。
G部長：ベンダに問い合わせてみたところ，DBMSが作成するトランザクションログについては暗号化を施してカード番号を判読困難にすることは難しいようだ。既存のログからカード番号を除去するのも現実的ではない。そうなると，詳細要件3.4を満たすことができない。できるだけ追加投資を必要とせずに対応する方法はないだろうか。 Fさん：要件を満たせない場合でも，関連するリスクをほかの手段を適用することでd できる場合には，その手段を代替管理策とすることで，要件の目的を実現することが可能です。PCI DSSでは，表3に示すようなワークシートを使って，要件が満たされないことに対するリスクを管理するそうです。まだ検討の途中ですが，このような形になるかと思います。
表3 詳細要件3.4に対する代替管理策のワークシート
G部長：なるほど，表3の代替管理策を実施すれば詳細要件3.4の目的は実現できそうだ。残りの5.と6.についても検討してみてくれないかな。 Fさん：分かりました。残りの部分についてもこれから検討します。 その後，P社はPCI DSSを参考にしてISMSの取組を進め，技術面でのセキュリティ向上とポリシ面での継続的改善を図ることができた。
出題趣旨（IPA）
情報セキュリティの実現に当たっては，適切なセキュリティ技術を選択するとともに，組織に適合したセキュリティポリシを適用し，その継続的な改善を図ることが望まれる。本問では，衣料小売業者における情報セキュリティの見直しを題材に，法的要求事項や情報セキュリティ標準の知識，セキュリティ検査の技法，Webアプリケーションの保護の手法などについて問う。
採点講評（問全体・IPA）
問2では，衣料小売業者における情報セキュリティの見直しを例に取り，情報セキュリティ標準の知識，セキュリティ検査やWebアプリケーションの保護の手法などについて出題した。全体として，正答率は想定どおりだった。
設問と解答例
設問1(1)
解答欄1つ
本文中のa に入れる適切な字句を，15字以内で答えよ。
解説
本文の根拠
〔観察事項への対応〕
4.については，新たな法律の制定や業界の動向を踏まえて社内のISMS運営事務局で法的要求事項の改訂案を検討し，a の場で承認を得るというルールを作るとよいと思います。
図1
法的要求事項に関しては文書化されていますが，これを最新に保つための手法をご検討ください。(A.15.1.1)
a は“マネジメントレビュー”（別解は“情報セキュリティ委員会”）である。観察事項4は，法的要求事項が文書化されているが，これを最新に保つための手法を検討してほしいというものである。Fさんは，運営事務局が改訂案を検討し，その案を承認する場を決めておくというルールを提案している。
承認は，運営事務局より上位で，組織としての意思決定ができる場で行う必要がある。ISMS の運用を経営の立場から見直すマネジメントレビューか，情報セキュリティについて組織の方針を審議する情報セキュリティ委員会がこれに当たり，解答例はどちらも正解としている。
字数は“マネジメントレビュー”が 10 字，“情報セキュリティ委員会”が 11 字で，制限の 15 字に収まる。運営事務局のような作業部門ではなく，承認権限のある会議体の名前を書く。
設問1(2)
60字以内
本文中の下線①について，Webアプリケーションの開発委託先に対してセキュリティ要件を提示していなかった場合，受入れ検査時に脆弱性の存在が判明したときにどのような問題が発生するか。60字以内で述べよ。
解答例（2通り）
開発の要件としてセキュリティ要件を提示していない以上，成果物に脆弱性が発見された場合でも受け入れざるを得ない。 発見された脆弱性に対する改修費用を開発元と委託先のどちらが負担するかでトラブルが生じる。
解説
本文の根拠
図1
Webアプリケーションの開発委託におけるセキュリティ要件を明確にすることが望まれます。(A.12.5.5)
〔観察事項への対応〕
今後Webアプリケーションの改修を行うときや新規の開発を行うときには，①委託先に具体的なセキュリティ要件を提示することにしよう。
〔観察事項への対応〕
今後はこのガイドラインに沿って具体的なセキュリティ要件を発注の際の仕様に含めるとよいのではないでしょうか。
解答例は“開発の要件としてセキュリティ要件を提示していない以上，成果物に脆弱性が発見された場合でも受け入れざるを得ない。”と“発見された脆弱性に対する改修費用を開発元と委託先のどちらが負担するかでトラブルが生じる。”の二つで，どちらか一方が書けていればよい。観察事項3は，Webアプリケーションの開発を委託するときにセキュリティ要件が明確でないことを指摘している。
発注の際の仕様にセキュリティ要件が入っていなければ，受入れ検査で脆弱性が見つかっても，それは“要件にないこと”なので，委託先に修正を求める根拠が弱く，受け入れるしかなくなる。逆に修正を求めれば，改修の費用を発注側と委託先のどちらが負担するかで争いになる。要件を発注時に提示しておくのは，この二つの問題を避けるためである。
字数は 55 字と 44 字で，制限の 60 字に収まる。“要件を提示していなかった”ことを前提にした問題（受け入れざるを得ない，費用負担のトラブル）を書き，脆弱性が見つかったこと自体の被害（情報漏えいなど）は書かない。
設問2(1)
解答欄2つ
本文中のb ，c に入れる適切な字句を，それぞれ5字以内で答えよ。ただし，b は漢字とし，c は英字の略称とする。
解説
本文の根拠
〔PCI DSSを参考にしたISMSの継続的改善〕
これについては，先ほどのインシデント対応計画と同様に，ISO/IEC 27001のb 計画でも対応すべきだろうね。
〔PCI DSSを参考にしたISMSの継続的改善〕
今は媒体を④サーバ室に保管していますが，外部の施設への保管も検討する必要があります。
〔PCI DSSを参考にしたISMSの継続的改善〕
これには通信の遅延を補正できるc というプロトコルを使っています。
b は“事業継続”，c は“NTP”である。b の直前でFさんは，バックアップ媒体を外部の施設にも保管する話をしており，G部長はこれを，インシデント対応計画と同様に，ISO/IEC 27001 のb 計画でも対応すべきと受けている。災害でサーバ室ごと被災しても事業を続けられるようにするための計画なので，“事業継続”計画である。講評も，事業継続計画（BCP）が事業継続管理（BCM）の中核を成し，災害や事故などに遭遇した際の対応をあらかじめ定めておくものだと述べている。
c は，システムクロックを標準時サーバと同期させるプロトコルである。RFC 5905 は，NTP をインターネット上でコンピュータの時計を同期させるために広く使われるものと述べ，8章では，4個のタイムスタンプ T1〜T4 から，相手との時刻のずれ（offset）と往復遅延（round-trip delay）を求めると定めている。通信の遅延を補正できる，という本文の説明に合う。
字数は b が 4 字，c が 3 字で，制限の 5 字に収まる。b は漢字，c は英字の略称という指定に従い，b を“BCP”のような英字にしたり，c を“ネットワークタイムプロトコル”のように書いたりしない。
採点講評（IPA）
設問2(1)bは正答率が低かった。事業継続計画（BCP）は，事業継続管理（BCM）の中核を成し，組織が予期せぬ災害や事故，広範囲の伝染病などに遭遇した際の対応をあらかじめ定めておくものである。BCMは国際標準化が計画されているので，今後の動向を注目しつつ理解を深めてほしい。
設問2(2)
30字以内
本文中の下線②について，自動更新と定期スキャンが確実に実施されていることをどのように確認するべきか。30字以内で述べよ。
解答例
ウイルス対策ソフトの動作ログを採取し，レビューを行う。
解説
本文の根拠
〔PCI DSSを参考にしたISMSの継続的改善〕
②ウイルス定義ファイルの自動更新と定期スキャンも実施しているし，問題なさそうだ。
〔PCI DSSを参考にしたISMSの継続的改善〕
ウイルス対策ソフトは販売システムに含まれるすべてのPCとサーバに導入済です。
〔PCI DSSを参考にしたISMSの継続的改善〕
要件10はアクセスの追跡と監視についてです。具体的には，各システム上でログを取得するだけではなく，改ざんされないように保護した上で少なくとも日に一度は確認することが求められます。
答えは“ウイルス対策ソフトの動作ログを採取し，レビューを行う。”である。G部長は，ウイルス定義ファイルの自動更新と定期スキャンを実施しているので問題なさそうだと述べているが，それは“設定してある”ことを述べているだけで，PC とサーバのすべてで実際に更新とスキャンが行われたかどうかは確認できていない。
確実に実施されているかどうかは，ウイルス対策ソフトが残す動作ログ（更新の履歴，スキャンの実施結果など）を集め，レビューして，更新やスキャンの漏れがないかを調べることで確かめられる。本文の要件10も，ログを取得するだけでなく確認することを求めており，同じ考え方である。
字数は 27 字で，制限の 30 字に収まる。“ログを採取する”だけで終わらず，“レビューする（確認する）”まで書く。
設問2(3)
50字以内
本文中の下線③について，検査対象と同一のネットワークセグメントからポートスキャンツールを利用して検査を行う場合，不要なサービスがあるかどうかをどのような基準で判断するか。50字以内で述べよ。
解答例
システムで利用されるサービスのポート番号以外のポートがオープンになっていないかどうか。
解説
本文の根拠
〔PCI DSSを参考にしたISMSの継続的改善〕
サーバについては受入れ検査のときに③ポートスキャンツールを使って不要なサービスの有無を確認しているが，その後システムを変更しているからもう一度確認が必要だ。
〔PCI DSSを参考にしたISMSの継続的改善〕
要件2は，システムのデフォルト設定を使ってはいけないという要件です。
表1 FさんによるPCI DSSの対応状況のまとめ
システム上での不要なサービスや機能の無効化，停止
答えは“システムで利用されるサービスのポート番号以外のポートがオープンになっていないかどうか。”である。ポートスキャンで分かるのは，サーバのどのポートが開いているか（応答するか）だけで，そのポートで動くサービスが不要かどうかは，スキャン結果だけでは決まらない。
そこで，そのシステムが業務のために実際に利用するサービスのポート番号を一覧にしておき，それ以外のポートが開いていれば不要なサービスが動いている疑いがある，と判断する。要件2の対策が“不要なサービスや機能の無効化，停止”であることから，開いている不要なポートを見つけ，対応するサービスを止める作業につながる。
字数は 43 字で，制限の 50 字に収まる。“利用するサービスのポート番号以外”という基準と“オープンになっていない”という判断の対象の両方を書く。
設問2(4)
50字以内
本文中の下線④について，現状のままバックアップ媒体をサーバ室に保管する場合のリスクを，50字以内で述べよ。
解答例
災害の発生時にシステムのデータとバックアップ媒体上のデータが同時に被災する可能性がある。
解説
本文の根拠
〔PCI DSSを参考にしたISMSの継続的改善〕
今は媒体を④サーバ室に保管していますが，外部の施設への保管も検討する必要があります。
表1 FさんによるPCI DSSの対応状況のまとめ
カメラなどによるサーバ室の監視，安全なバックアップ媒体の保管
答えは“災害の発生時にシステムのデータとバックアップ媒体上のデータが同時に被災する可能性がある。”である。バックアップ媒体は，システムが壊れたときに元の状態へ戻すためのものである。その媒体をシステムと同じサーバ室に置いていると，火災や地震などの災害でサーバ室が被災したときに，システムのデータとバックアップのデータがまとめて失われ，復旧に使えなくなる。
Fさんが外部の施設への保管も検討する必要があると述べているのは，このリスクを避けるためで，G部長がこれを事業継続計画の中で扱うとしている（設問2(1)）こととも整合する。
字数は 44 字で，制限の 50 字に収まる。“盗難”や“持出し”のような物理アクセスのリスクではなく，“同じ場所に置く”ことで“同時に被災する”点を書く。
設問2(5)
30字以内
本文中の下線⑤について，Fさんが自身でPテストを実施することは望ましくないとした理由を，30字以内で述べよ。
解答例
管理を行っているシステムを自ら検査することになるから
解説
本文の根拠
〔観察事項への対応〕
その部下で販売システムの管理を担当しているFさんが観察事項への対応に当たることになった。
〔PCI DSSを参考にしたISMSの継続的改善〕
社内で実施することは要件上認められていますが，私にPテストのスキルがあったとしても，⑤私がPテストを実施するのは望ましくないですね。
答えは“管理を行っているシステムを自ら検査することになるから”である。Fさんは，情報システム部で販売システムの管理を担当している。PCI DSS は社内でのペネトレーションテスト（Pテスト）を認めているが，Fさんが行うと，自分が管理しているシステムを自分で検査することになる。
管理する立場の人が検査も行うと，自分の設定や運用の誤りを見落としやすく，検査の客観性と独立性が保てない。Fさんにスキルがあるかどうかとは関係のない，検査する者と検査される者の分離の問題である。
字数は 26 字で，制限の 30 字に収まる。“スキルが足りない”ではなく，“自分が管理するシステムを自分で検査する”という立場の問題として書く。
設問3(1)
50字以内
本文中の下線⑥について，シグネチャを作成することが難しい理由を，50字以内で述べよ。
解答例
Webでは，一つの脆弱性に対して攻撃を引き起こす可能性のあるアクセスのパターンが多岐にわたるから
解説
本文の根拠
〔Webアプリケーションの保護の手法〕
Webアプリケーションの開発では，クロスサイトスクリプティングやSQLインジェクションなど，広く知られた脆弱性について対処する必要があります。
〔Webアプリケーションの保護の手法〕
今使っているIPSはシグネチャベースの製品で，ネットワーク層に対する既知の攻撃を防御することに主眼を置いています。
〔Webアプリケーションの保護の手法〕
もう一つはネガティブセキュリティモデルといって，シグネチャや特定のパターンに合致した通信をアプリケーション層で遮断するものです。
答えは“Webでは，一つの脆弱性に対して攻撃を引き起こす可能性のあるアクセスのパターンが多岐にわたるから”である。ネガティブセキュリティモデルは，シグネチャや特定のパターンに合致した通信を遮断する方式なので，攻撃の通信を表すパターンを一つ一つ用意できるかどうかが有効性を決める。
クロスサイトスクリプティングや SQL インジェクションのような Web アプリケーションの脆弱性は，同じ脆弱性を突く入力でも，書き方の組合せが多岐にわたる。ネットワーク層の既知の攻撃のように，決まった形の通信を見分けるのとは違い，攻撃になり得るアクセスのパターンを漏れなく網羅したシグネチャを作ることが難しい。
字数は 48 字で，制限の 50 字に収まる。“一つの脆弱性に対して”“パターンが多岐にわたる”の二つを入れ，“Webアプリケーションが多様だから”のような一般的な理由で済ませない。
設問3(2)
60字以内
本文中の下線⑦について，Webアプリケーションの見直しをせずにWAFを導入することによって発生するセキュリティ上の問題点を，60字以内で述べよ。
解答例
WAF単独では取りこぼしが発生し得るので，脆弱性が修正されない場合には攻撃を受ける可能性が高い点
解説
本文の根拠
〔Webアプリケーションの保護の手法〕
Webアプリケーションの見直し以外にはWAFの導入も選択肢としてあるということだが
〔Webアプリケーションの保護の手法〕
なるほど。ただ，⑦Webアプリケーションの見直しをせずにWAFを導入することには問題があるのではないかな。コスト面での制約はあるが，できるだけ併用する方向で検討しよう。
〔Webアプリケーションの保護の手法〕
シグネチャや特定のパターンに合致した通信をアプリケーション層で遮断するものです。
答えは“WAF単独では取りこぼしが発生し得るので，脆弱性が修正されない場合には攻撃を受ける可能性が高い点”である。WAF はシグネチャやパターンを使ってアプリケーション層で攻撃を遮断するが，設問3(1)のとおり，すべての攻撃のパターンを網羅するのは難しく，防ぎきれずに通り抜ける通信（取りこぼし）が出る。
Web アプリケーションに脆弱性が残ったままだと，WAF をすり抜けた攻撃がその脆弱性を突いて成功する。見直しで脆弱性を修正しておけば，取りこぼしがあっても攻撃は成功しにくい。G部長が，コスト面の制約があるにしても，できるだけ併用したいと言っているのはこのためである。
字数は 48 字で，制限の 60 字に収まる。“WAF 単独では取りこぼす”と“脆弱性が残れば攻撃を受ける”の二つを書き，WAF の導入費用や性能の問題には触れない。
設問4(1)
解答欄1つ
本文中のd に入れる適切な語句を解答群の中から選び，記号で答えよ。 解答群 ア 移転 イ 回避 ウ 受容 エ 低減
解説
本文の根拠
〔トランザクションログに対する代替管理策〕
要件を満たせない場合でも，関連するリスクをほかの手段を適用することでd できる場合には，その手段を代替管理策とすることで，要件の目的を実現することが可能です。
表3 詳細要件3.4に対する代替管理策のワークシート
DBサーバにアクセス可能な従業員に対してトランザクションログに含まれるカード番号が露呈するリスクがある。
答えはエ（低減）である。代替管理策は，元の要件を満たせないことで増えるリスクを，ほかの手段で小さくして，要件の目的を実現するものである。表3の項番3が“元のコントロールの不足によって生じる追加リスク”を特定し，項番4で代替コントロールがそれにどう対応するかを定めるので，リスクを小さくする“低減”に当たる。
ア（移転）はリスクを第三者に預けること，ウ（受容）はリスクをそのまま受け入れること，イ（回避）はリスクの原因そのものを無くすことである。講評は，回避を選んだ解答が多かったが，リスクの原因を排除する回避は題意を満たさないと述べている。この場合は，トランザクションログにカード番号が含まれるという原因を取り除けず，その状態でリスクを小さくしているので，回避ではない。
この設問は記号選択で字数制限はない。間違えやすいのは，“対策を講じる”という印象から回避を選ぶことで，代替管理策は原因を残したまま影響や起こりやすさを下げるものだと押さえる。
採点講評（IPA）
設問4(1)は正答率が低く，“回避”を選んだ解答が多かった。リスク対応の観点からは，リスクの原因を排除する“回避”は題意を満たさない。同様の考えからか，(2)においては“トランザクションログを消去する”という誤った解答が散見された。また，前提として問題文中に“暗号化を施してカード番号を判読困難にすることは難しい”と記述されているのに，“暗号化を施す”という解答も多かった。問題に含まれる条件をよく吟味して解答してほしかった。
設問4(2)
解答欄1つ
表3中のe に入れる代替管理策を，40字以内で述べよ。
〔e〕解答例
トランザクションログに対して参照可能な利用者を制限する
解説
本文の根拠
〔トランザクションログに対する代替管理策〕
DBMSが作成するトランザクションログについては暗号化を施してカード番号を判読困難にすることは難しいようだ。既存のログからカード番号を除去するのも現実的ではない。
表3 詳細要件3.4に対する代替管理策のワークシート
DBサーバにアクセス可能な従業員に対してトランザクションログに含まれるカード番号が露呈するリスクがある。
表3 詳細要件3.4に対する代替管理策のワークシート
これによって，トランザクションログに含まれるカード番号の露呈を防ぐ。
答えは“トランザクションログに対して参照可能な利用者を制限する”である。表3の項番3が挙げるリスクは，DBサーバにアクセスできる従業員にカード番号が露呈することである。暗号化も除去もできない以上，ログを見られる人を絞れば，このリスクが小さくなり，項番4の“カード番号の露呈を防ぐ”に結び付く。
G部長は，トランザクションログの暗号化は難しく，既存のログからカード番号を除去するのも現実的でないと述べている。したがって，暗号化する，ログを消去するといった答えは，この設問の前提を満たさない。講評も，“トランザクションログを消去する”や“暗号化を施す”という誤答が多かったことを，問題中の条件を吟味していないこととして挙げている。
字数は 27 字で，制限の 40 字に収まる。“アクセス制御をする”だけでなく，“何に対して”“誰を”制限するかまで書く。
採点講評（IPA）
設問4(1)は正答率が低く，“回避”を選んだ解答が多かった。リスク対応の観点からは，リスクの原因を排除する“回避”は題意を満たさない。同様の考えからか，(2)においては“トランザクションログを消去する”という誤った解答が散見された。また，前提として問題文中に“暗号化を施してカード番号を判読困難にすることは難しい”と記述されているのに，“暗号化を施す”という解答も多かった。問題に含まれる条件をよく吟味して解答してほしかった。
設問5
50字以内
PCI DSSを参考として技術面で新たな対策を追加していったP社が，ISMSの活動として次回の審査に向けて実施すべき作業を，50字以内で述べよ。
解答例（3通り）
追加した対策の有効性を内部監査によって確認し，改善すべき点があれば改善計画を立てて改善を行う。 新たに追加された対策を加味してリスク分析を実施する。 新たに追加された対策についての有効性の評価を行う。
解説
本文の根拠
〔PCI DSSを参考にしたISMSの継続的改善〕
PCI DSSで求められる要件をベースラインとしてISMSにおける技術面及び管理面の改善を図るようにとの指示が出た。
〔トランザクションログに対する代替管理策〕
その後，P社はPCI DSSを参考にしてISMSの取組を進め，技術面でのセキュリティ向上とポリシ面での継続的改善を図ることができた。
表1 FさんによるPCI DSSの対応状況のまとめ
PCI DSSへの対応に伴うポリシの見直し，インシデント対応計画の立案とテスト及び見直し
解答例は三つで，どれか一つが書けていればよい。“追加した対策の有効性を内部監査によって確認し，改善すべき点があれば改善計画を立てて改善を行う。”，“新たに追加された対策を加味してリスク分析を実施する。”，“新たに追加された対策についての有効性の評価を行う。”である。PCI DSS を参考に技術面の対策が追加されたので，次回の審査までに，追加した対策がきちんと効いているかを確かめ，足りなければ直す作業が要る。
講評は，ISMS の審査の目的は，組織において PDCA サイクルが有効に機能していることを確認することであり，管理策を実行するだけでなく，講じた管理策に対する Check と Act が必要であることに言及してほしかったと述べている。三つの解答例は，有効性の評価・確認（Check）と，それに基づく改善（Act），新しい対策を加味したリスク分析のいずれも，この観点から出ている。
字数は 47 字，26 字，25 字で，制限の 50 字に収まる。対策を実施した（Do）ことの報告で終わらせず，“有効性の確認・評価”か“それに基づく改善”のどちらかを入れる。
採点講評（IPA）
設問5では，ISMSの審査の意義について考察が不足している解答が見られた。ISMSの審査の目的は，組織においてPDCAサイクルが有効に機能していることを確認することにある。したがって，本文中で記述した様々な管理策を実行するだけではなく，講じた管理策に対するCheckとActが必要であることについて言及してほしかった。
出典：平成21年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2（表記を一部改変）
