[平成２８年度秋] 午後2 問2 解説①

[問題文・解答]

平成２８年度１０月に実施された情報セキュリティスペシャリスト試験の午後２問題 問２の解説を２回に分けて行います。今回は１回目（前半）です。
平成２８年度１０月の情報セキュリティスペシャリスト 午後２試験の問題・解答はIPA公式ページからダウンロード出来ます。（以下リンク）
[H28秋 午後2 問題文]　　　[H28秋 午後2 解答]

[問題概要]

題材は、脆弱性対策についてです。

概要は以下の通りで、今回は前半部分の解説を行います。

（前半部分）P.14〜P.21上段　設問1〜3該当範囲

• ソフトウェア脆弱性を突いた攻撃増加に対応するため、社内横断的チームを組織し、脆弱性対策基準の策定など社内情報システムの脆弱性対策を強化した。
• あるWebアプリの脆弱性が公表され、対象機器を調査したところ、一次調査で漏れていた機器があったため再発防止策を検討した。
• その後、UNIX/Linuxのbashに関する重大な脆弱性が公表されたため、対象機器を調査し、直ちにパッチを適用することとなった。ただし、一部機器についてはパッチの適用では時間がかかり過ぎるため、WAFによる対策を行うこととなった。

（後半部分）P.21上段〜P.24上段　設問4〜5該当範囲

• bashの脆弱性について社外から直接アクセス出来ない機器も攻撃を受ける可能性があるという追加情報が公表されたため、改めて対象機器の調査・対策を実施した。
• より適切かつ運用負荷の少ない脆弱性対策とするために、脆弱性対策基準の見直しを実施した。

[設問1]

(1)

下線部①より公開Webサーバは、社外取引先との重要情報の共有が目的であるため、
・社外からアクセスできる
・重要情報を扱っている
となり、図4の1.機器の重要度レベルの定義より"重要度レベル高"となります。
また、P.17下段に「CVSS基本値は6.5であった」とあり、図4の2.脆弱性レベルの定義に「CVSS基本値が7.0以上の脆弱性を脆弱性レベル高とする」とあることから、X脆弱性は"脆弱性レベル低"となります。
従って、図4の3.リスクレベルの定義の表より、"リスクレベル2"となります。
[答] ウ

(2)

P.17下段〜P.18上段にあるようにX脆弱性への対応では、固定資産管理台帳にある機器についてソフトウェアM（バージョンZ）を適用しているかどうかを調査に手間取りました。そこで、新台帳にバージョンを含むソフトウェアの情報を記載することで、次回以降に同様の調査が必要になった際に対象機器を迅速に特定出来るようになります。
[答] 脆弱性が発見された特定のバージョンのソフトウェアが導入された機器を迅速に特定するため

[設問2]

(1)

Y脆弱性は、bashに関する脆弱性であり、図7よりWebサーバ上でbashを呼び出そうとしていることからも、Webサーバにbashが導入されている事が攻撃が成立する条件となります。
[答] ウ

(2)

Y脆弱性によって、catコマンドはbashを起動する際に実行されますが、このbashを呼び出す処理はWebアプリBから実行されるため、catコマンドの実行権限はWebアプリBの実行権限と同じになります。
[答] ウ

(3)

図7より、Webサーバ(httpd)は、WebブラウザからのHTTPリクエストを受けてWebアプリBを起動しています。
[答] HTTPリクエスト

(4)

P.19下段「典型的なWebサーバは、Webサーバ（httpd）がHTTPリクエストヘッダのフィールド値を環境変数として設定してからWebアプリBを起動する」とあるようにフィールド値にはY脆弱性を利用するために環境変数に設定する値を入れます。
図6の１行目が環境変数TEST2に対して、catコマンドを用いてファイル/etc/passwdの中身を参照するコマンドを設定している部分であるため、同様の記述をHTTPリクエストヘッダのフィールド値に指定すれば良いです。
[答] () { echo test; } ; /usr/bin/cat /etc/passwd

[設問3]

(1)

WAF(Web Application Firewall)は、Webアプリケーションを攻撃から防御する為のファイアウォールです。WAFはWebアプリケーションへのアクセスに対してヘッダやデータの中身を解析して、シグネチャ（攻撃や不正アクセスの特徴を定義したパターン）やホワイトリスト（正常な通信を定義したパターン）とパターンマッチング（照合）を行い、アクセスを拒否するかどうかを判断します。
[答] パターンマッチング

(2)

この設問はやや解答が思いつき辛い問題です。
パッチ適用の場合は、検証項目としてOSの起動・終了や業務で使用するアプリケーションの動作確認を一通りチェックしていく必要があります。一方、WAFの場合はOSやアプリケーション自体に変更を加える訳ではないため、Webアプリケーションの通信に絞って検証すればよいため、パッチ適用に比べて検証作業の試験項目が少なくて済みます。
[答] WAFの場合、検証作業の試験項目がパッチ適用のときよりも少なくて済むから。

(3)

これは知らないと解答が難しい設問です。
クラウド型のWAFでは、既存の機器へのソフトウェアのインストール等は不要で、DNSサーバのCNAMEレコードにサービス事業者指定のFQDNを追加する設定を行うだけで、Webアプリケーションの通信をサービス事業者のWAFを経由して行えるようになります。
[答] c) ウ　d) イ

(4)

P.20下段に「β製品本部のY脆弱性がある公開Webサーバには、新製品の発表時などに、購入希望社からのアクセスが通常時の100倍程度まで一時的に増大するものがあり」と記述されていることから、通信量の変動に流動的に対応出来ることが求められています。
ここで表1の各案の概要において
オンプレミス型：通信量の上限は導入機器の性能によって制限される。
クラウド型：通信料の上限は、サービス利用契約を随時変更し、切り替えられる。
となっていることから、上記の要件に適合するのはクラウド型であることが分かります。
また、クラウド型は新規の機器購入は不要で、設定・ログ解析もサービス事業者が実施してくれるため作業工数やコストの観点からも優位です。
[答] 通信量の上限の切替えでWAFの能力変更が随時可能、かつ作業工数やコストの観点から無駄がない。

上記の解説は問題と解答を元に自分なりの考え方を記述しており、間違っている部分もあるかと思いますので、ご了承願います。また、誤りについては正しい考え方をご指摘・ご教授頂けると助かります。