平成22年度 春期に実施された情報処理安全確保支援士試験
午後Ⅱの全2問（記述式）の全設問に，運営者が独自に書いた解説を付けています。事例本文のどこが根拠になるかを示し，IPA の解答例・採点講評と並べています。
問1 インターネットに公開されているサーバの情報セキュリティ対策
インターネットに公開されているサーバの情報セキュリティ対策に関する次の記述を読んで，設問1〜4に答えよ。
Y社は，従業員数1,000名の通信販売会社である。Y社では，会員として登録した顧客あてに，3か月ごとに商品カタログを送付し，会員からの注文を，電話，ファックス及び郵便によって受け付けている。さらに，商品カタログを掲載するWebサーバ（以下，カタログWebサーバという）と，会員からの注文を受け付けるWebサーバ（以下，受注Webサーバという）などからなる受注システムを用いたネット通販も行っている。
Y社のネットワーク構成を図1に示す。従業員による社内業務サーバの利用，電子メール（以下，メールという）の送受信及びプロキシサーバ経由のインターネットWebサイトの閲覧のためにPCを設置している。
図1中の，現在の受注システムのサーバ群が老朽化したので，更新することになった（以下，更新後のシステムを新受注システムという）。新受注システムのサーバ構成は，現在の受注システムと同じである。
図1 Y社のネットワーク構成
FWのフィルタリングルール（以下，FWルールという）では，通信パケットの送信元，あて先及びサービスの組合せによって，許可又は拒否の動作を指定することができる。FWルールを表1に示す。
表1 FWルール
DMZに設置されているサーバのIPアドレスは表2のとおりである。
表2 DMZに設置されているサーバのIPアドレス
新受注システムへの更新は情報システム部で行うことになった。
情報システム部は，技術グループ（以下，技術Gという），開発グループ（以下，開発Gという）及び運用グループ（以下，運用Gという）から構成されている。各グループの主な業務は次のとおりである。
- 技術Gは，情報システム関連技術の調査及びY社の情報システムの品質管理を行う。
- 開発Gは，Y社の情報システムのインフラ構築及びアプリケーション開発を行う。
- 運用Gは，Y社の情報システムの運用，監視及び保守を行う。
情報システム部では，新受注システムへの更新を機会に，情報セキュリティ対策として，次の二つを行った。
- (1) 最新の情報セキュリティ対策を盛り込み，DMZに設置されるサーバの情報セキュリティ対策基準（以下，DMZ対策基準という）を作成
- (2) 情報セキュリティ品質向上のために，DMZに設置されるサーバの導入手順（以下，サーバ導入手順という）を作成
作成したDMZ対策基準を図2に示す。このDMZ対策基準は新受注システムに適用される。
図2 DMZ対策基準
作成したサーバ導入手順の概要を図3に示す。このサーバ導入手順は新受注システムに適用される。
図3 サーバ導入手順の概要
〔設計書作成及び設計書審査の実施〕
新受注システムへの更新は，開発GのM主任とNさんが担当することになった。M主任とNさんは，設計書の作成を行った。技術Gによって設計書審査が行われ，審査指摘事項が図4のとおり通知された。
図4 審査指摘事項
M主任とNさんは審査指摘事項について検討を始めた。
〔DMZに設置されるサーバへのSSH接続に関する検討〕
運用Gでは，DMZに設置されているサーバにログインが必要な場合は，各サーバのコンソールからログインを行っている。しかし，休日や夜間は，運用Gのメンバが不在なので，トラブルに対して社外からの緊急対応が必要な場合に備え，各サーバ上にSSHサーバソフト（以下，SSHサーバという）を導入し，運用GのメンバにノートPCと通信カードを貸与した上で，SSH接続によるログインを可能としている。契約している通信カードのインターネット接続サービス（以下，契約通信サービスという）では，通信サービス会社が管理しているIPアドレスを動的に割り当てる。
M主任とNさんは，DMZに設置されるサーバへの接続についての審査指摘事項を確認した。指摘を受ける前，Nさんは，サーバへの接続は，SSHによって通信が暗号化されること及び推測しにくいパスワードを使用していることから，パスワード認証方式でもセキュアであると考えていた。しかし，コンピュータセキュリティインシデント対応機関から発表されたSSHサーバへのパスワード総当たり攻撃についての注意喚起においては，パスワードが推測される可能性が高いと説明されていた。そのため，開発Gは，図4の審査指摘事項に従って，SSHの認証方式を公開鍵認証方式に設計変更した。
次に，FWルールの設定内容についての見直しを行った。見直しの結果，契約通信サービスを，Y社専用のIPアドレスが割り当てられるものに変更し，更に①FWルールの設定内容も変更することにした。
〔DNS機能に関する検討〕
Y社のDMZに設置されているサーバのドメイン名の情報は，DNSサーバを使用して管理している。Y社のPC及びサーバは，内部LAN1に接続されているPC及び内部LAN2に接続されているサーバの名前解決には，hostsファイルを用いている。
M主任とNさんは，DNSキャッシュポイズニング対策について検討した。根本的な対策として，aというDNSのセキュリティ拡張方式の導入が考えられた。aは，DNSのレコードに公開鍵暗号方式によるbを付加し，応答を受け取った側ではそのbを検証する方式である。しかし，aには，鍵の管理をどのように行うかなど，今までのDNSサーバにはない運用手順が必要であること，Y社だけでなく大多数の組織が対応していなければならないことから，すぐには採用できない。M主任は，開発Gだけでは解決が難しいと判断し，DNSサーバに導入しているDNSソフトの製品サポート窓口に対応方法を照会した。DNSソフトの製品サポート窓口からは，現時点でとり得る対策として，DNSサーバで，②名前解決の問合せにおいてDNSキャッシュポイズニング攻撃を受けやすい不適切な設定を行わないという解決策が提示され，それに従い設計書を修正した。念のため，現在のDNSサーバの設定を確認したところ，設定は適切であった。
開発Gでの設計書の修正に対して，技術Gは，設計書の審査指摘事項がすべて解決されていることを確認した。
〔サーバ設定及びサーバ設定検査の実施〕
開発Gでは設計書に基づいて，サーバ設定を行った。構築後，技術Gは，接続前Pテストを実施し，図5の設定検査指摘事項を通知した。
図5 設定検査指摘事項
〔迷惑メール対策に関する検討〕
M主任とNさんは設定検査指摘事項について検討を行った。次は，迷惑メール対策について検討した際の会話である。
- M主任：まず，カタログWebサーバ及び受注Webサーバのドメイン名を使用したメール送信について検討しよう。
- Nさん：当社では表3のとおり，三つのドメイン名（以下，Y社管理ドメイン名という）を使用しています。カタログWebサーバ及び受注Webサーバに使用するドメイン名を使ったメールの送信は一切ありません。cを行うことという設定検査指摘事項の必要性がよく理解できません。
表3 Y社が使用しているドメイン名と使用方法
- M主任：例えば，送信者メールアドレスとしてカタログWebサーバのドメイン名を使用したメールがお客様あてに届いているとしよう。当社から，メール送信をしていないのに，だれが送信したのかな。
- Nさん：迷惑メールの送信者でしょうか。
- M主任：そのとおりだ。送信者メールアドレスとしてカタログWebサーバのドメイン名を使用し，当社以外のサーバから送信されたメール（以下，詐称メールという）だから，当社では止めることができない。どのような対処が必要かな。
- Nさん：受信側のメールサーバで詐称メールを拒否するか破棄するしかありません。受信側のメールサーバでは，どのように判定できるのでしょうか。
- M主任：メールを送信するサーバはどれかということを判定してもらうために，送信側のDNSサーバにSender Policy Framework（SPF）の設定を追加すれば対応できるよ。メールを送信するサーバがない場合は，それに対応した設定をすることもできる。詐称メールの送信を止めることはできないが，受信側のメールサーバにおいて，当社からのメールであるかどうかを判別してもらうことができる。
- Nさん：cの方法の一つですね。
- M主任：そのとおりだ。送信者メールアドレスとしてカタログWebサーバ及び受注Webサーバのドメイン名を使用したメールは送信しない。③その事実を踏まえてDNSサーバにSPFの設定を追加してくれ。
- Nさん：はい，分かりました。
- M主任：次に，NDRメールの対策について検討しよう。例えば，受信者メールアドレスとして，カタログWebサーバのドメイン名を使用したメールがメールサーバ1に届いたとしよう。どうなるかな。
- Nさん：メールの送受信方法は図6のとおりで，④メールサーバ1ではオープンリレー防止設定がされているので，そのメールは転送拒否されます。
図6 Y社のメール送受信方法
- M主任：そのとおりだ。では，ドメイン名がy-sha.co.jpの実在しない受信者メールアドレスあてにメールが届いた場合はどうなるかな。
- Nさん：メールサーバ1からメールサーバ2に転送しようとするが，受信者メールアドレスが実在しないので転送せずに，転送できなかったメールを添付ファイルとしたNDRメールを送信者メールアドレスに向けて送信します。
- M主任：では，送信者メールアドレスを偽って，ドメイン名がy-sha.co.jpの実在しない受信者メールアドレスあてに送信されたらどうなるかな。
- Nさん：偽られた送信者メールアドレスあてに，NDRメールを送信します。送信者メールアドレスが正しいのか偽りなのかはメールサーバ1とメールサーバ2では判断できません。
- M主任：仮に，偽られた送信者メールアドレスが実在したらどうなるかな。
- Nさん：偽られた送信者メールアドレスあてにNDRメールが届きます。
- M主任：⑤そうしたNDRメールが多いと，メールサーバ1がスパム発信源としてブラックリストに登録される可能性があり，対策が必要だね。
- Nさん：はい，分かりました。
以上を踏まえて，迷惑メールに関する対策を行った。技術Gにおいて，再度，接続前Pテストを実施し，設定検査指摘事項がすべて解決されていることを確認した。
続いて，Webアプリケーション検査を実施した。
〔DMZ接続及びDMZ接続検査の実施〕
開発Gで現在の受注システムのサーバ群を一時的に新受注システムのサーバ群に切り替えた後，技術Gで接続後Pテストを実施した。検査の結果，問題が発見され，技術Gは接続検査指摘事項を図7のとおり通知した。
図7 接続検査指摘事項
〔オープンリゾルバ対策に関する検討〕
開発Gは，まず，A案を検討した。検討の結果，次の三つを行うことで，オープンリゾルバ対策を技術的に実現できることが分かった。
- DNSサーバにコンテンツ機能だけを割り当てる。
- DMZにキャッシュDNSサーバを導入し，キャッシュ機能だけを割り当てる。
- 表4のとおり，表1中の項番7を修正する。
表4 FWルールの修正案
しかし，キャッシュDNSサーバの導入は，インフラ構築のための時間を必要とし，運用開始に間に合わない。
次に，B案を検討した。今回，指摘があった現状の名前解決問合せ通信のアクセス制御ルールを表5に示す。
表5 現状の名前解決問合せ通信のアクセス制御ルール
表5で動作が許可の場合は，表6に示すY社のDNSサーバの名前解決アルゴリズムを実行する。表5で動作が拒否の場合は，拒否を返答する。
表6 Y社のDNSサーバの名前解決アルゴリズム
M主任とNさんが一緒に表5を見直したところ，表5には問題があり，実際に図1中の接続点(α)からDNSサーバに対してY社管理ドメイン名以外の名前解決を試みると，場合によっては成功することが判明した。更に検討を行い，表5のアクセス制御ルールを修正すればこの問題は解決できるというめどがついた。
開発Gにおいて，A案とB案との比較検討を行った結果，運用開始を延期しなくてもよいB案を採用することに決定した。Nさんは，表5の名前解決問合せ通信のアクセス制御ルールを表7のように修正し，技術Gは図1中の接続点(α)から，Y社管理ドメイン名以外の名前解決ができないことを確認した。
表7 修正した名前解決問合せ通信のアクセス制御ルール
技術Gは接続検査指摘事項への対処結果に問題がないことを確認して，運用Gでの新受注システムの運用が開始された。
出題趣旨（IPA）
インターネットに公開されているサーバは，セキュリティ侵害の脅威にさらされている。サーバの導入時や更新時に，脅威への対応が行われていることを確認するため，セキュリティ検査の実施が望まれる。本問では，システムの更新時に実施するセキュリティ検査を題材にして，ファイアウォール，SSHサーバ，DNSサーバ及びメールサーバに関する知識と設計能力について問う。
採点講評（問全体・IPA）
問1では，インターネットに公開されているサーバの導入におけるSSHサーバ，DNSサーバ及びメールサーバの情報セキュリティ対策について出題した。全体として正答率は想定どおりだった。
設問と解答例
設問1(1)
30字以内
初めてSSHサーバにSSH接続を行う際には，利用者はSSHサーバのフィンガプリントと呼ばれる情報を確認する必要がある。フィンガプリントから確認できることを30字以内で述べよ。
解答例
- SSHサーバの公開鍵が正しく，なりすましがないこと
解説
本文の根拠
〔DMZに設置されるサーバへのSSH接続に関する検討〕
各サーバ上にSSHサーバソフト（以下，SSHサーバという）を導入し
図4
パスワード認証方式の利用を中止し，公開鍵認証方式に変更すること。
フィンガプリントから確認できるのは，接続先のSSHサーバが提示した公開鍵が本物であること，つまり，なりすましたサーバに接続していないことである。解答例は“SSHサーバの公開鍵が正しく，なりすましがないこと”である。
SSHでは，利用者が初めて接続するとき，手元にはそのサーバの公開鍵の控えがない。このためサーバが提示した鍵が本物かどうかを接続だけでは判断できず，確認しないと攻撃者が間に入る中間者攻撃を受けるおそれがある。RFC 4251（SSH のアーキテクチャ）の4.1節は，ホスト鍵の確認ができない実装は中間者攻撃に弱いと述べ，確認の手段としてホスト鍵から導いたフィンガプリントを挙げている（例は公開鍵の SHA-1 ハッシュ値の16進表記）。同じ節は，電話など別の通信路でフィンガプリントを確かめられるとも述べている。本文のSSHサーバは各サーバ上に導入され，図4の指摘で公開鍵認証に変わるので，利用者は最初の接続でこの確認を行う。
字数は25字で，制限の30字に収まる。“公開鍵”（サーバの鍵が本物であること）と“なりすましがない”（接続先が本物のサーバであること）の両方を書く。通信の暗号化の話ではなく，接続先のサーバが本物かどうかの確認である点を書く。
採点講評（IPA）
設問1(1)は，正答率が低かった。初めてSSHサーバにSSH接続を行う際の，公開鍵の真正性を確認することの重要性について，よく理解しておいてほしい。
設問1(2)
解答欄2つ
本文中の下線①について，表1中の項番12の定義内容のうち，送信元又はあて先を変更することになった。変更箇所は送信元又はあて先のいずれか。答案用紙の“送信元・あて先”のいずれかの文字を○印で囲んで示せ。また，その変更後の内容を40字以内で述べよ。
〔変更後の内容〕解答例
- 契約通信サービスにおいて割り当てられるY社専用のIPアドレス
解説
本文の根拠
〔DMZに設置されるサーバへのSSH接続に関する検討〕
契約している通信カードのインターネット接続サービス（以下，契約通信サービスという）では，通信サービス会社が管理しているIPアドレスを動的に割り当てる。
〔DMZに設置されるサーバへのSSH接続に関する検討〕
見直しの結果，契約通信サービスを，Y社専用のIPアドレスが割り当てられるものに変更し，更に①FWルールの設定内容も変更することにした。
表1 項番12
項番12：すべて，DMZ，SSH，許可。
変更箇所は“送信元”で，変更後の内容は“契約通信サービスにおいて割り当てられるY社専用のIPアドレス”である。
表1の項番12は，送信元がすべて，あて先がDMZ，サービスがSSHの通信を許可している。契約通信サービスは通信サービス会社が管理するIPアドレスを動的に割り当てるので，社外のノートPCの送信元アドレスを決められず，送信元を“すべて”にするしかなかった。契約通信サービスをY社専用のIPアドレスが割り当てられるものに変更すると，送信元をそのアドレスに絞れる。DMZのサーバへのSSH接続というあて先は変わらないので，あて先は変更しない。図4の“FWルールの設定内容を見直し，より厳しく制限すること”にも合う。
字数は30字で，制限の40字に収まる。“Y社専用のIPアドレス”だけでなく，それが契約通信サービスで割り当てられるものであることまで書く。
設問2(1)
解答欄2つ
本文中のa，bに入れる適切な字句を，aについては英字8字以内，bについては8字以内で答えよ。
解説
本文の根拠
〔DNS機能に関する検討〕
aは，DNSのレコードに公開鍵暗号方式によるbを付加し，応答を受け取った側ではそのbを検証する方式である。
〔DNS機能に関する検討〕
根本的な対策として，aというDNSのセキュリティ拡張方式の導入が考えられた。
aは“DNSSEC”，bは“ディジタル署名”である。DNSSECは，DNSのデータに公開鍵暗号方式によるディジタル署名を付け，受け取った側が検証することで，応答が正しい提供元のもので改ざんされていないことを確かめる。RFC 4033は，DNSSECがDNSデータの提供元の認証とデータの完全性の保護を提供し，DNSの資源レコードの集合に暗号的に生成したディジタル署名を結び付けることで認証を行うと述べている。偽の応答を受け取っても署名の検証で見破れるので，DNSキャッシュポイズニングへの根本的な対策になる。
本文は，鍵の管理など今までのDNSサーバにない運用手順が必要なこと，Y社だけでなく大多数の組織が対応していなければならないことから，すぐには採用できないとしている。
字数は，aが英字6字で制限の8字，bが7字で制限の8字に収まる。aはDNSのセキュリティ拡張方式の名称で，空欄の文の“公開鍵暗号方式によるb”が署名を指すことから，bを導く。
採点講評（IPA）
設問2(2)は，正答率が高かったが，(1)及び(3)は，正答率が低かった。DNSキャッシュポイズニング攻撃についての理解は高いが，DNSサーバの設定に関する知識がまだ不十分であるための結果と思われる。DNSサーバには，DNSプロトコルの性質から様々な脆弱性が指摘されており，設定には細心の注意が必要であることを理解してほしい。
設問2(2)
40字以内
Y社のDNSサーバがDNSキャッシュポイズニング攻撃を受けた場合，Y社のPCでのインターネットへのWebアクセスにおいて，どのような問題が発生するか。40字以内で述べよ。
解答例
- アクセスしたいWebサーバとは別のサーバにアクセスしてしまう。
解説
本文の根拠
Y社のネットワーク
従業員による社内業務サーバの利用，電子メール（以下，メールという）の送受信及びプロキシサーバ経由のインターネットWebサイトの閲覧のためにPCを設置している。
〔DNS機能に関する検討〕
Y社のDMZに設置されているサーバのドメイン名の情報は，DNSサーバを使用して管理している。
DNSキャッシュポイズニング攻撃を受けると，DNSサーバのキャッシュに偽の名前解決の結果が入るので，PCでWebアクセスしたいWebサイトのドメイン名が，攻撃者が用意した別のサーバのIPアドレスに解決される。このため，アクセスしたいWebサーバとは別のサーバにアクセスしてしまう。解答例は“アクセスしたいWebサーバとは別のサーバにアクセスしてしまう。”である。
Y社のPCはプロキシサーバ経由でインターネットのWebサイトを閲覧するが，名前解決の結果が偽であれば，利用者が正しいURLを入力しても偽のサーバに誘導される。
字数は31字で，制限の40字に収まる。講評は，この設問の正答率が高かったと述べている。名前解決の結果が偽の情報になり，別のサーバに接続されてしまうことを書く。
採点講評（IPA）
設問2(2)は，正答率が高かったが，(1)及び(3)は，正答率が低かった。DNSキャッシュポイズニング攻撃についての理解は高いが，DNSサーバの設定に関する知識がまだ不十分であるための結果と思われる。DNSサーバには，DNSプロトコルの性質から様々な脆弱性が指摘されており，設定には細心の注意が必要であることを理解してほしい。
設問2(3)
25字以内
本文中の下線②について，DNSキャッシュポイズニング攻撃を受けやすいDNSサーバの不適切な設定とはどのような設定であるか。25字以内で述べよ。
解答例
解説
本文の根拠
〔DNS機能に関する検討〕
DNSサーバで，②名前解決の問合せにおいてDNSキャッシュポイズニング攻撃を受けやすい不適切な設定を行わないという解決策が提示され
不適切な設定は“送信元ポート番号を固定する設定”である。DNSサーバが名前解決のために外部へ出す問合せの送信元ポート番号を固定していると，攻撃者は偽の応答を送るときにポート番号を推測する必要がなくなる。RFC 5452の4.5節は，送信元ポート番号が固定（従来のDNSのポート番号53）の実装が多いことと，固定だと攻撃者が観測できるサーバから番号を知り，推測が要らなくなることを述べ，9.2節は予測しにくい送信元ポート番号と問合せIDを使うことを求めている。送信元ポート番号を固定しない（ランダムにする）ことが，DNSソフトの設定でとれる対策になる。
本文は，DNSSECを今すぐ採用できないので，製品サポート窓口が示した“現時点でとり得る対策”としてこの設定を挙げている。
字数は15字で，制限の25字に収まる。“設定”なので，“ポート番号を固定する”という設定の内容までを書く。講評は，この設問の正答率が低く，DNSサーバの設定に関する知識が不十分なためと述べている。
採点講評（IPA）
設問2(2)は，正答率が高かったが，(1)及び(3)は，正答率が低かった。DNSキャッシュポイズニング攻撃についての理解は高いが，DNSサーバの設定に関する知識がまだ不十分であるための結果と思われる。DNSサーバには，DNSプロトコルの性質から様々な脆弱性が指摘されており，設定には細心の注意が必要であることを理解してほしい。
設問3(1)
解答欄1つ
図5及び本文中のcに入れる適切な迷惑メール対策技術の名称を10字以内で答えよ。
解説
本文の根拠
図5
DNSサーバの設定によってcを行うこと。
〔迷惑メール対策に関する検討〕
メールを送信するサーバはどれかということを判定してもらうために，送信側のDNSサーバにSender Policy Framework（SPF）の設定を追加すれば対応できるよ。
cは“送信ドメイン認証”である。SPFは，ドメインの所有者が，そのドメイン名を使ってよいメール送信元をDNSで公開し，受信側のメールサーバが送信元の正当性を確かめる方式である。RFC 4408の概要は，ドメインが使用を許可するホストを明示でき，受信ホストがその許可を確認できる，と述べている。送信者メールアドレスのドメインを偽っていないかを判定する対策の名称として，“送信ドメイン認証”を答える。
会話でM主任が示すとおり，詐称メールの送信そのものは止められないが，受信側のメールサーバで，Y社からのメールかどうかを判別してもらえる。
字数は8字で，制限の10字に収まる。空欄は“迷惑メール対策技術の名称”で，会話でSPFが“cの方法の一つ”とされているので，SPFを含む上位の分類名を答える。
設問3(2)
本文中の下線③について，カタログWebサーバのドメイン名に対して，SPFを設定したTXTレコードを解答群から一つ選び，記号で答えよ。解答群 ア catalog.y-sha.co.jp. IN TXT "v=spf1 +ip4:x1.y1.z1.2 -all" イ catalog.y-sha.co.jp. IN TXT "v=spf1 +ip4:x1.y1.z1.4 -all" ウ catalog.y-sha.co.jp. IN TXT "v=spf1 +ip4:x1.y1.z1.5 -all" エ catalog.y-sha.co.jp. IN TXT "v=spf1 +ip4:x1.y1.z1.6 -all" オ catalog.y-sha.co.jp. IN TXT "v=spf1 -all"
解答例
解説
本文の根拠
〔迷惑メール対策に関する検討〕
カタログWebサーバ及び受注Webサーバに使用するドメイン名を使ったメールの送信は一切ありません。
〔迷惑メール対策に関する検討〕
メールを送信するサーバがない場合は，それに対応した設定をすることもできる。
〔迷惑メール対策に関する検討〕
送信者メールアドレスとしてカタログWebサーバ及び受注Webサーバのドメイン名を使用したメールは送信しない。
答えはオの“catalog.y-sha.co.jp. IN TXT "v=spf1 -all"”である。
カタログWebサーバのドメイン名を送信者メールアドレスに使ったメールは，Y社のどのサーバからも送信されない。そこで，このドメインから送信してよいホストを一つも許可しない設定にする。RFC 4408は，レコードの先頭を“v=spf1”とし（4.5節），“ip4”でIPv4アドレス（範囲）を指定し（5.6節），“all”は常に一致する指定（5.1節），先頭の“-”は“許可していない”という結果（Fail）を示す（4.6.2節）としており，“v=spf1 -all”は許可するホストを列挙せず，すべてを不許可にする。ドメインがメールを送らないときは，許可するホストが無い記録を公開できる（2.3節）。
ア〜エは，“+ip4:”で表2のDNSサーバ（.2），メールサーバ1（.4），カタログWebサーバ（.5），受注Webサーバ（.6）のアドレスからの送信を許可してしまう。メールサーバ1はY社のメールを送るが，このドメインでは送信しないので，イも誤りである。講評は，選択肢形式なのに正答率が低く，問題中の記述と図表をよく読めば導けると述べている。
採点講評（IPA）
設問3(2)は，選択肢形式であるにもかかわらず正答率が低かった。問題中の記述と図表をよく読めば正答を導けるはずである。インターネットに公開されているメールサーバでの迷惑メール対策についてよく理解しておいてほしい。
設問3(3)
解答欄1つ
本文中の下線④について，メールサーバ1ではインターネット側から届いたメールに対して，どのようなオープンリレー防止設定を実装しているか。図6中のdに入れる条件を表3中の字句を含めて40字以内で述べよ。
〔d〕解答例
- 受信者メールアドレスのドメイン名がy-sha.co.jp
解説
本文の根拠
図6
SMTPを使用し，メールサーバ1で受信し，dである場合はメールサーバ2へ転送し，ほかの場合は拒否する。
表3
メールアドレス：y-sha.co.jp，user@y-sha.co.jp
〔迷惑メール対策に関する検討〕
メールサーバ1ではオープンリレー防止設定がされているので，そのメールは転送拒否されます。
dは“受信者メールアドレスのドメイン名がy-sha.co.jp”である。
メールサーバ1は，インターネット側から届いたメールのうち，Y社あてのものだけをメールサーバ2へ転送し，ほかは拒否する。表3でY社のメールアドレスのドメイン名はy-sha.co.jpなので，受信者メールアドレスのドメイン名がy-sha.co.jpであることが転送の条件になる。会話の例は，受信者メールアドレスにカタログWebサーバのドメイン名を使ったメールで，これはy-sha.co.jpではないので転送拒否される。第三者あてのメールを中継しないというオープンリレー防止の設定である。
字数は28字で，制限の40字に収まる。表3中の字句を含める指定なので，“Y社あて”とせず“y-sha.co.jp”を書く。送信者ではなく受信者のドメイン名を見る点に注意する。
設問3(4)
60字以内
本文中の下線⑤について，対策を行わない状態で悪用されたとき，Y社のメール送信において，受ける被害を60字以内で述べよ。
解答例
- メールサーバ1から送信される正常なメールが，ブラックリストを利用しているメールサーバで受信拒否される。
解説
本文の根拠
〔迷惑メール対策に関する検討〕
偽られた送信者メールアドレスあてに，NDRメールを送信します。
〔迷惑メール対策に関する検討〕
そうしたNDRメールが多いと，メールサーバ1がスパム発信源としてブラックリストに登録される可能性があり，対策が必要だね
図6
Y社からインターネット側へのメール送信：SMTPを使用し，メールサーバ2からメールサーバ1へ転送し，メールサーバ1では，受信者メールアドレスに対応するメールサーバへ転送する。
被害は，メールサーバ1から送信される正常なメールが，ブラックリストを利用しているメールサーバで受信拒否されることである。解答例は“メールサーバ1から送信される正常なメールが，ブラックリストを利用しているメールサーバで受信拒否される。”である。
送信者メールアドレスを偽って実在しない受信者メールアドレスあてにメールを送ると，メールサーバ1が偽られた送信者あてにNDRメールを返す。偽られた先にとっては迷惑メールなので，大量に送られるとメールサーバ1がスパムの発信源としてブラックリストに登録される。図6のとおり，Y社からインターネット側へのメールはすべてメールサーバ1から出るので，登録されるとY社の通常のメール送信も受信側で拒否される。
字数は51字で，制限の60字に収まる。設問はY社のメール送信において受ける被害を問うているので，ブラックリストに登録されることで正常なメールが受信拒否される，という結果まで書く。
設問4(1)
50字以内
図7中の下線⑥について，どのような場合に成功するかを50字以内で述べよ。
解答例
- 非再帰的な問合せで，キャッシュ領域に保持されているY社管理ドメイン名以外の名前解決を行った場合
解説
本文の根拠
表5
項番1：すべて，非再帰的な問合せ，すべてのドメイン名，許可。
表6
キャッシュ領域に保持されているY社管理ドメイン名以外のドメイン名：再帰的な問合せでは，キャッシュ領域に保持されているY社管理ドメイン名以外のドメイン名に関する情報を問合せ元に返答する。非再帰的な問合せでは，左に同じ。
表6
非再帰的な問合せでは，解決できずに，問合せ元にネームエラーを返答する。
成功するのは，非再帰的な問合せで，キャッシュ領域に保持されているY社管理ドメイン名以外の名前解決を行った場合である。
表5では，項番2がDMZからの再帰的な問合せだけを許可し，項番3が再帰的な問合せをその他すべての送信元について拒否するので，接続点(α)（インターネット側）からの再帰的な問合せは拒否される。一方，項番1は，すべての送信元からの非再帰的な問合せを，すべてのドメイン名について許可している。表6のとおり，非再帰的な問合せは，キャッシュ領域に保持されているY社管理ドメイン名以外のドメイン名なら，保持している情報を返答する。キャッシュに無いドメイン名はネームエラーになる。このため，成功する場合があるのは，キャッシュに保持されている名前だけである。
字数は47字で，制限の50字に収まる。“非再帰的な問合せ”と“キャッシュに保持”の二つの条件を書く。RFC 5358の4節は，外部のネットワークには再帰的な問合せのサービスを提供しないことを既定とするよう勧めている。
設問4(2)
解答欄1つ
表4中のeに入れる適切なあて先を，図1中の(a)〜(d)の記号で答えよ。
解説
本文の根拠
表1 項番7
項番7：DNSサーバ，インターネット，DNS，許可。
〔オープンリゾルバ対策に関する検討〕
DMZにキャッシュDNSサーバを導入し，キャッシュ機能だけを割り当てる。
表4
項番7：キャッシュDNSサーバ，e，DNS，許可。
eは(a)である。表1の項番7は，DNSサーバから(a)インターネットへのDNS通信を許可するルールである。A案は，DNSサーバにはコンテンツ機能だけを割り当て，DMZに導入するキャッシュDNSサーバにキャッシュ機能だけを割り当てる。キャッシュDNSサーバがY社管理ドメイン名以外の名前解決のためにインターネット上のDNSサーバへ問い合わせるので，修正後の項番7は，送信元がキャッシュDNSサーバ，あて先が(a)インターネットになる。
項番6は，インターネットからDNSサーバへの問合せ（コンテンツ機能）を許可するルールのまま残る。
解答は図1の記号で指定されているので，“インターネット”ではなく，記号(a)で答える。(b)DMZは，キャッシュDNSサーバが置かれる場所で，あて先ではない。
設問4(3)
解答欄2つ
表7中のf，gに入れる適切な字句を答えよ。
解説
本文の根拠
表5
項番1：すべて，非再帰的な問合せ，すべてのドメイン名，許可。項番2：DMZ，再帰的な問合せ，すべてのドメイン名，許可。
表7
項番1：すべて，非再帰的な問合せ，f，許可。項番2：g，非再帰的な問合せ，すべてのドメイン名，許可。
表6
Y社管理ドメイン名：再帰的な問合せでは，Y社管理ドメイン名に関する情報を問合せ元に返答する。
fは“Y社管理ドメイン名”，gは“DMZ”である。
表5の問題は，項番1がすべての送信元からの非再帰的な問合せをすべてのドメイン名について許可していたことである。表7の項番1は，すべての送信元からの非再帰的な問合せを，問合せ対象がY社管理ドメイン名のときだけ許可する（f）。これでインターネットからは，Y社が管理するドメイン名以外の名前解決ができなくなる。ただし，それだけでは，表5の項番1が許可していたDMZ内からの非再帰的な問合せ（すべてのドメイン名）が，項番4で拒否されてしまう。そこで項番2で，問合せ元をDMZとし（g），非再帰的な問合せをすべてのドメイン名について許可する。DMZからの再帰的な問合せを許可する項番3と，それ以外を拒否する項番4はそのままである。
問合せ元と問合せ対象が一つずつ空欄なので，対象のドメイン名の側をY社管理ドメイン名に絞る（f），送信元の側をDMZに絞る（g）という対応で考える。講評は，(1)及び(3)の正答率が低く，DNSサーバの設定に関する知識が不十分なためと述べている。
出典：平成22年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
問2 情報セキュリティインシデント対応
情報セキュリティインシデント対応に関する次の記述を読んで，設問1〜5に答えよ。
X社は，従業員数300名のソフトウェア開発会社である。X社の主要な事業内容は，ソフトウェア製品の自社開発，Webアプリケーションの受託開発及びオープンソースソフトウェア（OSS）を利用したサーバとネットワークの構築サービスである。また，契約した顧客に対しては，ハードウェア及びソフトウェアの保守サポートも有償で提供しているが，顧客のシステムの運用は行っていない。
X社の組織を図1に示す。
図1 X社の組織
X社では，各部署の部長及び課長から構成される情報セキュリティ委員会と，その委員会の事務局を担当している情報システム課が連携して，情報セキュリティポリシ（以下，ポリシという）の策定やセキュリティ対策の実施を行っている。
X社では，社内の情報システム，ネットワークなどは自社で企画し，開発や構築を行っている。社内の情報システムは業務系システムと開発系システムの二つに分かれており，セキュリティ確保の観点からこの二つのシステムはネットワークを分け，それぞれ別の回線を通じてインターネットに接続されている。業務系システムの運用は情報システム課が行い，開発系システムの運用は開発課とネットワーク課が共同で行っている。
業務系ネットワークには各部署のLANが接続され，全社共通のグループウェアサーバや営業管理サーバ，経理事務サーバなどの業務系サーバ群と接続できるようになっている。また，DMZ上にメールサーバ，Webサーバ及びDNSサーバが設置され，インターネットに公開されている。
開発系システムは技術部のプロジェクト単位で開発環境が構築されており，その上でソフトウェアの開発や機器のテストなどを行っている。それぞれの開発環境からはOSSの技術情報収集やセキュリティパッチ取得のために，インターネットに対してHTTPやFTPでのアクセスが可能になっている。ただし，インターネットに対して公開しているサーバは開発系ネットワークにはない。
X社のシステム構成を図2に示す。
図2 X社のシステム構成
年度末を控えたある日，X社の営業部員が外出した際に，顧客のシステムに関する重要な情報が保管されている業務用のノートPCを紛失するという情報セキュリティインシデント（以下，情報セキュリティインシデントをインシデントという）が発生した。
このインシデントへのX社の対応は迅速とは言い難かった。ノートPCには指紋認証機能が備わっていたので，正当な利用者以外の者がハードディスクやOSにアクセスする可能性は低かったものの，連絡体制の不備から事実関係の把握に手間取り，顧客への連絡も遅れてしまった。数日後にノートPCは発見され，情報流出の可能性は極めて低いものと判断されたが，このインシデントによってX社はインシデント対応の重要性を改めて認識した。このため，情報セキュリティ委員会は今回の反省を踏まえてインシデント対応についての取組みを強化することとし，事務局である情報システム課にインシデント対応計画を策定させることとした。
〔インシデント対応計画の策定〕
次は，情報システム課のSさんとT課長の会話である。
- Sさん：当社ではこれまで，予防策を中心としたセキュリティ対策を進めてきましたが，今回のインシデントでそれだけでは不十分なことがよく分かりました。
- T課長：一つは，社内の連絡体制に問題があった。紛失者から直属の上司である第一営業課の課長にはすぐ連絡があったが，第一営業課ではその先の連絡先が分からなかったことに加えて，発生が金曜日の夕方だったこともあり，本来ならすぐに通知すべき情報システム課や情報セキュリティ委員会への連絡が遅れてしまった。連絡することはポリシに記載されているのだが，インシデント発生時の具体的な連絡先についての周知，教育が不足していたことは否めないね。
- Sさん：社内だけでなく，社外への連絡が遅れたことも反省しなければいけませんね。
- T課長：インシデントが発生したときの，関係者へ連絡を行う担当や手順が明確になっていなかったことも反省点だね。また，当社では個人情報を扱う業務はそれほど多くないので付与を受けていないが，JIPDECなどの機関からaの付与を受けた企業では，個人情報の漏えいが発生したときだけでなく，本人以外の個人情報を含むノートPCの紛失などの際にも，その機関に対して事故報告書を提出する必要があるようだ。
- Sさん：今回はノートPCの紛失でしたので警察にも遺失物届を出しましたが，Webサーバのコンテンツが改ざんされるなど，被害が発生した場合には，警察への連絡が必要になりますね。
- T課長：場合によっては発生したインシデントの内容をb/CC（コーディネーションセンター）のような外部機関に報告する必要もありそうだ。そのような場合の手順も整備しないといけないね。
- Sさん：どれだけ予防策をとってもインシデントの発生をゼロにすることはできないので，①インシデント対応の体制を事前に作っておくことが必要ではないでしょうか。
- T課長：そうだね。これまでは情報システム課が業務系システムのインシデント発生に対応してきたが，情報システム課だけでは対応しきれないことも多い。全社横断的なインシデント対応チーム（以下，IRTという）を設置して，PC紛失のような事例も含めて，インシデント対応に関する社内の体制と役割を明確にするのがよいだろうね。
- Sさん：システムに関するインシデントでは技術的なセキュリティ対策に関する知識やシステムの実装に関する情報が必要になります。技術的なセキュリティ対策については技術部の方が詳しいですし，こちらでは開発系システムについて詳しく把握できていないこともありますから，技術部と互いに協力して会社全体でのインシデント対応を進められるとよいですね。
このように情報システム課で議論した結果，社内にIRTを設置し，インシデントに対応していく計画を情報セキュリティ委員会へ提案することにした。情報システム課がまとめたインシデント対応計画の骨子を図3に示す。
図3 X社におけるインシデント対応計画の骨子
この対応計画を情報セキュリティ委員会に提案したところ，②X社の事業内容を踏まえると，図3で対象としたインシデント以外にも，IRTが対応すべきインシデントがあるのではないかとの意見があり，情報システム課は対応計画を修正した。その後，情報セキュリティ委員会での審議と役員会の承認を経て，社内のポリシが改定され，IRTが発足することとなった。これに伴ってX社は情報セキュリティに関して表1のように各組織で役割を分担することとした。
表1 情報セキュリティに関するX社の組織と役割分担
〔IRTメンバ向けのインシデント対応マニュアルの整備〕
新たに発足したIRTには，情報システム課のT課長とSさんのほか，社内の各部署からメンバが選出され，T課長がチームリーダを務めることとなった。IRTでは，インシデント対応を円滑に行うためにIRTメンバ向けのインシデント対応マニュアルを作成することとし，その具体的な内容として図4に示す各項目を検討した。
図4 IRTメンバ向けのインシデント対応マニュアルに記載する内容
図4中の(1)に関し，必要な機器については，予算面の問題もあることから，優先度の高いものから順に整備を進めていくことになった。また，業務系システムと開発系システムの構成情報は情報システム課と開発課，ネットワーク課が個別に管理していたが，既存のグループウェアを利用してIRTメンバが双方のシステムの構成情報を閲覧できるようにした。
図4中の(2)については，まず，現状を把握するために，現在の業務系と開発系のシステムで取得しているログの情報を収集し，リストアップすることにした。その結果，取得しているログの管理が機器ごとにそれぞれ異なることが判明した。このままでは，インシデントの原因究明に必要な情報を安全に確保及び保全することが困難なことから，IRTでは今年度中に③ログ管理のポリシを策定することとした。来年度以降には各機器のログのバックアップと統合管理を行うシステムの導入を検討する予定である。
図4中の(3)については，情報システム課と共同でシグネチャベースのIPS（侵入防止システム）をDMZに導入し，攻撃を受ける可能性が高いDMZ上のサーバへの脅威を分析することとした。開発系システムにもIPSの導入を検討したが，予算が厳しいことと，インターネットに対して公開しているサーバがないことから今年度の導入は見送った。ただし，開発系システムのFWのログについては定期的な分析を行うことにした。
図4中の(4)については，インシデント発生の報告を受けた後の対応について検討した。PCの紛失やサーバへの攻撃など，インシデントのタイプを何種類か想定し，そのタイプごとにインシデント原因の究明，被害の拡大防止及び仮復旧の方法をマニュアル化することにした。また，作業記録のフォーマットを整備し，個々のインシデント対応に当たってどのような作業を実施したかを記録することにした。
図4中の(5)は，いわゆるコンピュータフォレンジクスの技法についての検討である。インシデント発生時の被害の内容及び範囲の確認並びに発生原因の調査のために必要な情報を確実に保全し，発生した事象を様々な要素から解明することが目的である。IRTでは，ネットワークのインシデントに関する情報はIPS及びFWでの監視並びにログの取得を行うことで保全することとした。また，コンピュータに接続された記憶媒体上の情報は専用の機器を導入して保全できるようにした。保全された情報は，IRTが分析を行うことにした。
図4中の(6)については，コンピュータフォレンジクスで利用する機器やソフトウェアのベンダや，セキュリティ団体が主催するセミナにIRTメンバが出席するなどして，具体的な技法の習得と(6)の手順化に努めることにした。
図4中の(7)については，インシデント発生時の社内の連絡網及び外部の連絡先を整理し，関連部署への周知を図った。また，外部からのセキュリティ情報の収集の際にIRTでは，インシデント対応のコミュニティにおいて広く利用されている実績がある④PGPを利用した電子署名を採用することにした。
このような検討を経て，IRTメンバ向けのインシデント対応マニュアルが完成し，X社のインシデント対応が本格的に始動することになった。
〔IPSの運用〕
情報システム課はネットワーク課の協力を得てDMZにIPSを導入した。このIPSではネットワークの脅威を検知して不正な通信を遮断することができる。また，脅威の検知時刻，通信パケットの送信元及びあて先それぞれのIPアドレス及びポート番号，検知した脅威の種類を示すシグネチャの識別番号（ID），脅威の名称，詳細な通信の内容などの情報をログに記録できる。IPSの管理端末からはこのログを閲覧できるほか，脅威についての解説も閲覧できる。さらに，脅威の検知状況を日次，週次及び月次でレポート化することができる。
なお，IPSのシグネチャは，定期的に最新の状態に更新することとした。
シグネチャによって検知される個々の脅威の危険度はベンダによって4段階のレベルに分類されており，レベル4が最も危険度が高く，レベル1が最も危険度が低い。ただし，利用者側で個々のシグネチャの設定を変更して危険度のレベルを変えることが可能であり，利用者側で設定した脅威の危険度はシグネチャが更新されても維持される。
シグネチャの設定は既定値のままとし，レベル4又はレベル3の脅威が検知されたときにはIRTメンバに対して警告メールが送信される設定を行った上で試験運用を開始したところ，最初の1時間のうちに大量の警告メールがIRTメンバに送信された。このため，T課長はネットワーク課のIRTメンバであるU君に協力を求め，一緒に対応に当たることにした。T課長がIPSの管理端末から1時間の脅威の検知件数を確認したところ，表2のような結果が得られた。
表2 IPSで検知した脅威の集計
次は，T課長とU君の会話である。
- T課長：とりあえずこの集計を見てくれるかな。どう思うかね。
- U君：警告が出た脅威はIPSで遮断しているので，特に問題はないと思いますが，警告メールが多すぎるのは困りますね。調べてみましょう。
U君はIPSの管理端末でログを確認し，検知した脅威に関する解説を表示させた。
- U君：IDが1040番と1042番の脅威は，WebサーバとメールサーバのIPアドレスに対する特殊なポートスキャンのようですね。1040番の脅威は，TCPのコネクションを開始する際にSYN/FINフラグが付加されていたものです。1042番の方は，どのフラグも付加されていなかったものです。
- T課長：通常のポートスキャンとはどう違うのかな。
- U君：この方法ではTCPのコネクションが正常に確立しないので，対象となったホスト上でcされにくいという特徴があります。こうした特徴から，ステルススキャンなどと呼ばれることもあるようです。しかし，この脅威もIPSで遮断されていますし，DoS攻撃が成立するほど大量に発生しているわけでもありませんので，システムへの影響はないと思います。
- T課長：次に進もうか。5021番の脅威では，図5のようなアクセスがたくさんあるようだが，これは当社のWebサーバには影響はないと考えていいね。
図5 5021番の脅威と判定したパケットに含まれていた文字列
- U君：はい。これは，広く使われているCGIプログラムに対する無差別攻撃のようですね。このCGIプログラムは当社では利用していないはずですが，念のため，後でWebサーバの設定とアクセスログを確認してみます。パケットに含まれる文字列からすると，CGIプログラムに含まれるdの脆弱性を利用して，パスワードファイルを取得することをねらったもののようです。
- T課長：5829番の脅威では図6のようなアクセスが発生しているが，これはどうだろう。Webサーバを悪用する攻撃のようだが。
図6 5829番の脅威と判定したパケットに含まれていた文字列
- U君：設定に問題のあるWebサーバを悪用して，外部のメールサーバとSMTPで通信させようとしたようですね。
- T課長：WebサーバなのにSMTPで通信しようとしているというのはちょっと変じゃないかな。
- U君：図6を見ると，HTTP/1.1で定義されているeというメソッドが利用されています。これはWebサーバがいわゆるプロキシサーバとして動作しているときに，TCPの通信を透過的に中継させる目的で利用されるものです。主にSSLを中継させるのに使うことが多いのですが，SMTPのようなプロトコルも中継させることができます。
- T課長：なるほど。この脅威についてはどのように対処しているのかな。
- U君：IPSで遮断していますが，当社ではWebサーバをプロキシサーバとして利用しないので，⑤Webサーバではこのメソッドを受け付けない設定になっていますから，仮にIPSで遮断しなくても問題は発生しません。
- T課長：今日の警告メールについては，システムへの問題はないということだね。それにしても，警告メールが大量に来るのはちょっと困るな。⑥一定の条件を満たす場合には警告メールを送らないよう，シグネチャの設定を調整して危険度のレベルを変えるのがよいだろうね。
- U君：そうですね。シグネチャの設定を調整し，対応マニュアルも書き換えます。
U君がシグネチャの設定を調整したところ，IRTメンバに大量の警告メールが来ることはなくなった。
〔インシデントの発生と対応〕
その後，大きな問題もなく数か月が経過したある日，U君が開発系システムのFWのログを分析したところ，開発系システムの特定のIPアドレスからインターネット上の幾つかのIPアドレスに対して，通常見られない大量の通信が行われていることに気が付いた。
開発系システムの構成情報で送信元のIPアドレスを確認したところ，送信元のIPアドレスに該当する機器が記載されていなかったので，U君は開発課に問い合わせた。担当者の話によると，この機器は，近々顧客に納入するWebコンテンツの動作検証を行うため，開発課が一時的に開発環境に接続したサーバ機であるとのことだった。
U君が更にログを確認したところ，通信の内容に不審なところが見られたことから，U君はT課長に連絡し，インシデント対応マニュアルに従って初期対応に取り掛かった。
U君が証拠収集に必要な機材を持参して開発課に駆けつけたところ，当該サーバ機はU君が電話で問い合わせた直後に担当者がシャットダウンし，電源が切断された後だった。このため，⑦U君はこのサーバ機の電源を再投入せず，サーバ機からハードディスクを取り出した。取り出したハードディスクの内容は，専用の複製装置を用いて別のハードディスクに全セクタを複製し，⑧この複製に対してフォレンジックツールを実行して解析を行った。
解析の結果，サーバ機が最近流行しているボットに感染し，インターネットと通信を行っていた形跡が認められた。開発課によると，サーバ機を開発系ネットワークに接続する前に行うべきOSのパッチ適用を怠っていたとのことであった。情報を最終的に総合すると，パッチ未適用でOSの脆弱性が放置されたまま，フリーのソフトウェアの配布先にアクセスし，その際に脆弱性を悪用するボットに感染したため，インターネットと通信を行っていたものと推測された。
IRTはこうした解析結果を開発課に伝え，ボットに感染したサーバ機を再感染しないように再構築するよう指示した。開発課はIRTの指示に従ってハードディスクを初期化した上でOSを再インストールし，最新のパッチをすべて適用した上でサーバ機を再構築した。納期が迫る中ではあったが，再構築したサーバの動作検証は順調に進み，開発課は無事に顧客への納品を済ませることができた。
〔インシデントからの反省〕
今回のボット感染のインシデント対応が一段落した後で，IRTはメンバ全員を集めて反省会を行った。その席で，IRTでの対応に関する反省に加え，⑨従業員に対する周知，教育が不足していたために対応に問題が生じたのではないかとの意見があった。そこで，IRTは，全従業員向けのインシデント対応マニュアルを作成してインシデント対応に関する周知，教育を図るという改善計画を，情報セキュリティ委員会に提出した。
IRTは改善計画に従ってインシデント対応マニュアルを作成するとともに，全従業員への周知，教育を行い，社内でのインシデント対応への取組みを強化することができた。
出題趣旨（IPA）
これまでの情報セキュリティ対策では，予防策を中心とする事前の対策が重視されてきた。しかし，近年になってインシデント発生後の対応が適切か否かが組織の信頼や評判にも影響を及ぼすことが認識されるようになり，“事故前提社会”の観点からもインシデント対応に対する注目が高まりつつある。本問では，ソフトウェア開発会社におけるインシデント対応体制の構築を題材として，インシデント対応についての理解や，インシデント対応に関連する種々の技術要素についての理解を問う。
採点講評（問全体・IPA）
問2では，ソフトウェア開発会社における情報セキュリティインシデント対応について出題した。全体として正答率は想定どおりだった。
設問と解答例
設問1(1)
解答欄2つ
本文中のa，bに入れる適切な字句を，それぞれ10字以内で答えよ。
解説
本文の根拠
〔インシデント対応計画の策定〕
JIPDECなどの機関からaの付与を受けた企業では，個人情報の漏えいが発生したときだけでなく，本人以外の個人情報を含むノートPCの紛失などの際にも，その機関に対して事故報告書を提出する必要があるようだ。
〔インシデント対応計画の策定〕
場合によっては発生したインシデントの内容をb/CC（コーディネーションセンター）のような外部機関に報告する必要もありそうだ。
aは“プライバシーマーク”，bは“JPCERT”である。
JIPDEC（日本情報経済社会推進協会）が運営するプライバシーマーク制度では，個人情報を適切に管理していると評価された事業者がマークを使用でき，その事業者を“付与事業者”と呼ぶ（プライバシーマーク制度のサイト）。本文の“付与を受けた企業”はこれに当たる。bは“/CC（コーディネーションセンター）”が続くので，JPCERT/CC（JPCERTコーディネーションセンター）である。JPCERT/CCは，インターネットを介して発生するコンピュータセキュリティインシデントについて，報告の受付，対応支援，発生状況の把握，手口の分析，再発防止策の検討や助言を行う組織である（JPCERT/CCのサイト）。
字数は，aが9字，bが6字で，どちらも制限の10字に収まる。空欄の直後に“/CC”が付いているので，bには“JPCERT”だけを書く。講評は，bの正答率が低く，JPCERT/CCがインシデント対応に関する様々な活動を行い，Webサイト上で有用な情報を提供しているので，目を通しておいてほしいと述べている。
採点講評（IPA）
設問1(1)bは，正答率が低かった。JPCERT/CCはインシデント対応に関する様々な活動を行っており，有用な情報をWebサイト上で提供しているので，是非，目を通しておいてほしい。
設問1(2)
35字以内
本文中の下線①について，“事前に作っておくこと”のメリットを，インシデントの原因究明の観点から，35字以内で述べよ。
解答例
- 原因究明に必要な情報の収集に迅速かつ組織的に着手できること
解説
本文の根拠
本文
連絡体制の不備から事実関係の把握に手間取り，顧客への連絡も遅れてしまった。
図3
(10) IRTは，インシデント対応に必要な証拠の収集と保全，分析を行う。
〔IRTメンバ向けのインシデント対応マニュアルの整備〕
インシデント発生時の被害の内容及び範囲の確認並びに発生原因の調査のために必要な情報を確実に保全し，発生した事象を様々な要素から解明することが目的である。
メリットは，原因究明に必要な情報の収集に迅速かつ組織的に着手できることである。解答例は“原因究明に必要な情報の収集に迅速かつ組織的に着手できること”である。
今回のノートPC紛失では，連絡体制が整っていなかったために，事実関係の把握に手間取った。IRTを事前に作り，図3のとおり証拠の収集と保全，分析をIRTの役割として決めておけば，インシデントが起きたときに，だれが何を集めるのかが決まっているので，すぐに，かつ組織として原因究明のための情報の収集に取り掛かれる。
字数は29字で，制限の35字に収まる。“原因究明の観点から”という指定なので，“連絡が早くなる”のような一般的なメリットではなく，原因究明に必要な情報の収集に着手できる点を書く。
設問1(3)
35字以内
本文中の下線②について，X社では更にどのようなインシデントを対象として追加すべきか。35字以内で述べよ。
解答例
- 出荷後の自社開発のソフトウェア製品に関するインシデント
解説
本文の根拠
X社の事業
X社の主要な事業内容は，ソフトウェア製品の自社開発，Webアプリケーションの受託開発及びオープンソースソフトウェア（OSS）を利用したサーバとネットワークの構築サービスである。
図3
(3) IRTが対応を行うインシデントは，次のとおりとする。(a) 当社の所有する情報資産の紛失，改ざん，漏えいなどが疑われる場合。(b) 当社の業務系システムに異常，不具合などが発生した場合。(c) 当社の開発系システムに異常，不具合などが発生した場合。
表1
開発課：開発系システムの運用と監視，セキュリティ対策の実施，セキュリティを保ったソフトウェア開発，ソフトウェア製品の保守サポート，ソフトウェア製品のセキュリティパッチ作成。
追加すべきインシデントは，出荷後の自社開発のソフトウェア製品に関するインシデントである。解答例は“出荷後の自社開発のソフトウェア製品に関するインシデント”である。
図3の対象は，当社の情報資産の紛失など(a)，業務系システム(b)，開発系システム(c)の，いずれも社内のものである。一方，X社はソフトウェア製品を自社開発して提供しており，表1のとおり開発課がその保守サポートとセキュリティパッチの作成を担当している。出荷後の製品に脆弱性の悪用などの問題が起きれば，X社の事業と信頼に影響するので，IRTが対応すべきである。X社は顧客のシステムの運用は行っていないので，顧客のシステムそのものではなく，自社開発の製品に関するものを挙げる。
字数は27字で，制限の35字に収まる。“自社開発”と“出荷後”の二つの限定を入れる。
設問2(1)
25字以内
本文中の下線③について，ログ管理のポリシに盛り込むべき具体的な内容を，25字以内で述べよ。
解答例
解説
本文の根拠
〔IRTメンバ向けのインシデント対応マニュアルの整備〕
取得しているログの管理が機器ごとにそれぞれ異なることが判明した。
〔IRTメンバ向けのインシデント対応マニュアルの整備〕
このままでは，インシデントの原因究明に必要な情報を安全に確保及び保全することが困難なことから，IRTでは今年度中に③ログ管理のポリシを策定することとした。
盛り込むべき内容は，取得するログの種類や保管方法，保管期間である。解答例は“取得するログの種類や保管方法，保管期間”である。
現状は，ログの管理が機器ごとにばらばらなので，原因究明に必要なログが残っていない，残っていても消えている，といったことが起こり得る。そこで，全機器に共通するルールとして，どのログを取得するか，どのように保管するか，どれだけの期間保管するかを決めておく。本文はこの後，各機器のログのバックアップと統合管理を行うシステムの導入を検討するとしており，その前提になるルールである。
字数は19字で，制限の25字に収まる。“具体的な内容”という指定なので，“ログを管理する”とせず，管理の項目（種類，保管方法，保管期間）を書く。
設問2(2)
35字以内
本文中の下線④について，IRTではPGPを利用した電子署名を主にどのようなことを確認する目的で採用したと考えられるか。IRTの業務に即して35字以内で述べよ。
解答例
- セキュリティに関する情報やソフトウェアの提供元の真正性
解説
本文の根拠
〔IRTメンバ向けのインシデント対応マニュアルの整備〕
また，外部からのセキュリティ情報の収集の際にIRTでは，インシデント対応のコミュニティにおいて広く利用されている実績がある④PGPを利用した電子署名を採用することにした。
図3
(8) IRTは，インシデント対応に必要な脆弱性情報やセキュリティパッチに関する情報（以下，セキュリティ情報という）を収集し，関連する社内の部署に情報提供を行う。
確認する目的は，セキュリティに関する情報やソフトウェアの提供元の真正性である。解答例は“セキュリティに関する情報やソフトウェアの提供元の真正性”である。
IRTは，外部から脆弱性情報やセキュリティパッチなどのセキュリティ情報を集めて社内の部署に提供する。偽の情報や偽のパッチを受け取ると，誤った対応や不正なソフトウェアの導入を招く。電子署名は，署名した者が作成したこと，改ざんされていないことの確認に使える。RFC 4880（OpenPGP）の5.2.1節は，文書への署名がその署名者が作成したこと又は変更されていないことを保証するものと説明している。
字数は27字で，制限の35字に収まる。“IRTの業務に即して”という指定なので，電子署名一般の説明（改ざんの有無）ではなく，IRTが集める情報とソフトウェアの提供元が本物かどうか，という点を書く。
設問3(1)
解答欄3つ
本文中のc〜eに入れる適切な字句を，それぞれ15字以内で答えよ。
解説
本文の根拠
〔IPSの運用〕
この方法ではTCPのコネクションが正常に確立しないので，対象となったホスト上でcされにくいという特徴があります。
図5
GET /cgi-bin/enquete.cgi
図5
etc/passwd HTTP/1.1
〔IPSの運用〕
図6を見ると，HTTP/1.1で定義されているeというメソッドが利用されています。これはWebサーバがいわゆるプロキシサーバとして動作しているときに，TCPの通信を透過的に中継させる目的で利用されるものです。
cは“アクセスがログに記録”，dは“ディレクトリトラバーサル”，eは“CONNECT”である。
c：1040番はSYN/FINの両フラグ，1042番はどのフラグも付けないTCPパケットで，正常なコネクション確立の手順を踏まない。本文のとおり，コネクションが正常に確立しないので，対象となったホスト上ではアクセスがログに記録されにくい。Nmapの資料は，フラグを付けないNULLスキャンやFINだけを付けたFINスキャンを，SYNスキャンよりも少し見つかりにくく，一部のステートレスなファイアウォールやパケットフィルタを通り抜けることがあると述べている。
d：図5は，view=の後ろに“../”を並べて親のディレクトリへさかのぼり，/etc/passwdを取得しようとしている。OWASPは，パストラバーサル（ディレクトリトラバーサル）を，Webのルートフォルダの外にあるファイルやディレクトリへのアクセスをねらう攻撃と説明している。
e：図6は，“CONNECT mail.example.com:25 HTTP/1.1”の形で，プロキシ経由でホストとポート番号を指定して接続を求めている。RFC 2817の5.2節は，CONNECTがプロキシにトンネル接続を確立させるメソッドで，Request-URIが接続先のホスト名とポート番号になると述べ，RFC 2616の9.9節はプロキシがトンネルに切り替わるためにこのメソッド名を予約するとしている。
字数は，cが10字，dが12字，eが7字で，制限はいずれも15字である。講評は，dとeの正答率が低く，dでは“バッファオーバフロー”，eでは“POST”や“PUT”といった解答が目立ったので，用語だけでなく内容を掘り下げて理解してほしいと述べている。dは図5の“../”の並びから，eは図6のあて先が“ホスト:ポート”の形であることから導く。
採点講評（IPA）
設問3(1)d及びeは，正答率が低かった。dでは“バッファオーバフロー”，eでは“POST”や“PUT”といった解答が目立った。Webに関する脆弱性は多岐にわたるが，代表的なものについては，用語を覚えるだけではなく，その内容を掘り下げて理解しておいてほしい。
設問3(2)
30字以内
本文中の下線⑤について，IPSが設置されておらず，かつWebサーバでこのメソッドが受け付けられる設定になっている状態で図6の脅威が発生した場合には，Webサーバでどのような問題が発生する可能性が高いと考えられるか。30字以内で述べよ。
解答例
- Webサーバがメールの不正中継に利用されるという問題
解説
本文の根拠
〔IPSの運用〕
設定に問題のあるWebサーバを悪用して，外部のメールサーバとSMTPで通信させようとしたようですね。
図6
mail.example.com:25 HTTP/1.1
発生する問題は，Webサーバがメールの不正中継に利用されるという問題である。解答例は“Webサーバがメールの不正中継に利用されるという問題”である。
図6は，CONNECTメソッドで外部のメールサーバのSMTPのポート（25）への接続を中継させようとしている。IPSで遮断せず，WebサーバがこのメソッドをプロキシのようにTCPの中継のために受け付ける設定になっていると，攻撃者はWebサーバを経由してメールサーバにSMTPで接続できる。RFC 2817の8.2節は，汎用のTCPトンネルにはセキュリティ上の危険が多く，権限は少数の既知のポートに限るべきだとし，CONNECTでポート25に接続してSMTPでスパムを中継させる例を挙げている。
字数は26字で，制限の30字に収まる。図6のあて先がSMTPのポート番号であることから，メールの不正中継であることを書く。
設問3(3)
解答欄2つ
本文中の下線⑥について，T課長がシグネチャの設定を調整するように求めたセキュリティ上の理由を40字以内で述べよ。また，ある特定の脅威について危険度のレベルを既定値から下げることを許容する場合の条件を35字以内で述べよ。
〔理由〕解答例
- 対応が不要な警告メールが多いと対応が必要な警告メールを見落とすから
〔条件〕解答例
- DMZでは利用していないシステムや機能に関する警告メールであること
解説
本文の根拠
〔IPSの運用〕
シグネチャの設定は既定値のままとし，レベル4又はレベル3の脅威が検知されたときにはIRTメンバに対して警告メールが送信される設定を行った上で試験運用を開始したところ，最初の1時間のうちに大量の警告メールがIRTメンバに送信された。
〔IPSの運用〕
IPSで遮断していますが，当社ではWebサーバをプロキシサーバとして利用しないので，⑤Webサーバではこのメソッドを受け付けない設定になっていますから，仮にIPSで遮断しなくても問題は発生しません。
〔IPSの運用〕
それにしても，警告メールが大量に来るのはちょっと困るな。⑥一定の条件を満たす場合には警告メールを送らないよう，シグネチャの設定を調整して危険度のレベルを変えるのがよいだろうね。
理由は，対応が不要な警告メールが多いと対応が必要な警告メールを見落とすからである。条件は，DMZでは利用していないシステムや機能に関する警告メールであることである。
試験運用では，対応が不要な脅威（遮断済みのスキャンや，Webサーバが受け付けない設定のメソッド）まで警告メールになり，大量のメールがIRTメンバに届いた。数が多いと，本当に対応が必要な警告が埋もれてしまう。一方，危険度を下げると警告メールそのものが来なくなるので，下げてよいのは，DMZで使っていないシステムや機能に関するもの，つまり攻撃が成立しても影響が無いことが確認できている脅威に限る。本文の5829番の脅威（HTTP Tunneling）は，Webサーバをプロキシとして使わない設定になっているので，この条件に当たる例である。
字数は，理由が33字で制限の40字，条件が33字で制限の35字に収まる。理由は“警告メールが多くて困る”ではなくセキュリティ上の理由（見落とし）を書き，条件は“DMZでは利用していない”という限定を入れる。
設問4(1)
40字以内
本文中の下線⑦について，U君が電源を再投入しなかった理由を40字以内で述べよ。
解答例
- 再起動することでサーバ機上のファイルが改変される可能性があるから
解説
本文の根拠
〔インシデントの発生と対応〕
当該サーバ機はU君が電話で問い合わせた直後に担当者がシャットダウンし，電源が切断された後だった。
図3
(10) IRTは，インシデント対応に必要な証拠の収集と保全，分析を行う。
理由は，再起動することでサーバ機上のファイルが改変される可能性があるからである。解答例は“再起動することでサーバ機上のファイルが改変される可能性があるから”である。
サーバ機は電源が切断されており，電源を再投入すると，OSが起動し，起動時の処理でファイルの内容や更新日時が書き換わるおそれがある。解析の目的は，ボット感染などの証拠を保全して原因を究明することなので，証拠になるファイルが変わってしまうことは避ける。RFC 3227（証拠の収集と保管の指針）は，証拠の収集が終わるまでシャットダウンしないことを求めており，その理由として，攻撃者が起動・停止のスクリプトを書き換えて証拠を消している場合を挙げている。起動時の処理が証拠に影響するという考え方は，電源の再投入にも当てはまる。
字数は32字で，制限の40字に収まる。“証拠が消える”だけでなく，再起動で何が起きるか（ファイルが改変される）を書く。
設問4(2)
35字以内
本文中の下線⑧について，U君が取り出したハードディスクを直接用いて解析を行わなかった理由を35字以内で述べよ。
解答例
- 解析の際に原本のデータを書き換えてしまう可能性があるから
解説
本文の根拠
〔インシデントの発生と対応〕
取り出したハードディスクの内容は，専用の複製装置を用いて別のハードディスクに全セクタを複製し，⑧この複製に対してフォレンジックツールを実行して解析を行った。
〔IRTメンバ向けのインシデント対応マニュアルの整備〕
IRTでは，ネットワークのインシデントに関する情報はIPS及びFWでの監視並びにログの取得を行うことで保全することとした。また，コンピュータに接続された記憶媒体上の情報は専用の機器を導入して保全できるようにした。
理由は，解析の際に原本のデータを書き換えてしまう可能性があるからである。解答例は“解析の際に原本のデータを書き換えてしまう可能性があるから”である。
フォレンジックツールを実行するとディスクへアクセスするので，ファイルのアクセス日時などが変わり，原本の内容を変えてしまうおそれがある。原本を書き換えると，証拠としての価値が失われ，やり直しもできなくなる。そこで専用の複製装置で全セクタを複製し，複製に対して解析する。RFC 3227は，媒体のビット単位のコピーを作ること，解析のためにはさらにそのコピーのコピーを作ることを求め，解析によってファイルのアクセス日時などが変わってしまうことをその理由にしている。
字数は28字で，制限の35字に収まる。“複製を使う理由”ではなく“直接使わない理由”を問われているので，原本を直接使うと何が起こるか（データを書き換える）を書く。
設問5
解答欄4つ
〔インシデントからの反省〕について，本文中の下線⑨の，周知，教育が不足していたために，ボット感染のインシデント対応において露呈したと考えられる問題を二つ挙げ，それぞれ35字以内で述べよ。また，それらの問題への対応として，全従業員向けインシデント対応マニュアルに記載すべき具体的な内容をそれぞれ35字以内で述べよ。
〔①問題〕解答例
- 開発系システムの構成情報が最新に保たれていなかったこと
〔①記載内容〕解答例
- 一時的な変更の際も，開発系システムの構成情報を常に最新に保つ。
〔②問題〕解答例
- 開発課の担当者が勝手にサーバ機をシャットダウンしたこと
〔②記載内容〕解答例
- インシデント発生時の機器の操作はIRTの指示に従って行う。
解説
本文の根拠
〔インシデントの発生と対応〕
開発系システムの構成情報で送信元のIPアドレスを確認したところ，送信元のIPアドレスに該当する機器が記載されていなかったので，U君は開発課に問い合わせた。
〔インシデントの発生と対応〕
この機器は，近々顧客に納入するWebコンテンツの動作検証を行うため，開発課が一時的に開発環境に接続したサーバ機であるとのことだった。
〔インシデントの発生と対応〕
当該サーバ機はU君が電話で問い合わせた直後に担当者がシャットダウンし，電源が切断された後だった。
問題は，①開発系システムの構成情報が最新に保たれていなかったこと，②開発課の担当者が勝手にサーバ機をシャットダウンしたこと，の二つで，対応としてマニュアルに記載する内容は，①一時的な変更の際も，開発系システムの構成情報を常に最新に保つ，②インシデント発生時の機器の操作はIRTの指示に従って行う，である。
①は，FWログで見つかった通信の送信元が構成情報に無く，開発課への問合せが必要になった点である。開発課が一時的に接続したサーバ機が構成情報に載っていなかったので，原因となる機器をすぐには特定できなかった。②は，U君が問い合わせた直後に担当者がサーバ機を止めて電源を切ったため，証拠収集の機会が一部失われた点である。IRTの指示を待たずに操作すると，原因究明に必要な情報が失われる。
字数は，①の問題が27字，記載内容が31字，②の問題が27字，記載内容が29字で，制限はいずれも35字である。講評は，インシデントが発生した原因（パッチの未適用など）だけに着目した解答が見られたと述べ，既知の予防策が無いインシデントや，予防策を施しても防げないインシデントに備えて，原因究明のための情報を確保することが重要だと述べている。問題は“原因”ではなく“対応で露呈した問題”，記載内容はその問題への対応を書く。
採点講評（IPA）
設問5では，インシデントが発生した原因だけに着目した解答が見られた。パッチの適用や，フリーのソフトウェアのダウンロードの禁止などのセキュリティ対策は，インシデント予防の面から極めて重要であることは言うまでもない。しかし，今回のインシデントの原因をそれらの対策によって除去できたとしても，それだけでは不十分である。全く異なる原因によってインシデントが発生する場合や，いわゆるゼロデイ攻撃など，既知の予防策のないインシデントが発生することも想定しておく必要がある。そうしたインシデントに対しても適切に対応できるよう，原因究明のための情報確保が重要であることに気づいてほしかった。
出典：平成22年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2（表記を一部改変）