情報処理安全確保支援士 2016年 秋期 午後2 問02

　 　A社は、従業員数3,000名の製造会社である。A社の組織構成は図1のとおりであり、全社を統括する経営管理本部、及び製品の製造・販売を行う三つの製品本部がある。三つの製品本部は、それぞれ取り扱う製品分野が異なっている。経営管理本部には、データセンタ部（以下、センタ部という）、総務部などがある。

　 〔A社の情報システムの構成〕 　経営管理本部では、センタ部に所属する20名の運用担当者が、A社内で共同利用される機器群（以下、センタ部機器という）を運用している。各製品本部では、情報システム担当チームが、各製品本部が独自に導入している機器群（以下、製品本部機器という）を運用している。 　A社の情報システムの構成は、図2のとおりである。

　各製品本部には、5～10台の公開Webサーバがある。 　センタ部機器のアップデート用サーバは、社内で利用しているソフトウェアパッケージのセキュリティパッチ（以下、パッチという）を含む修正プログラムをインターネットからダウンロードし、格納している。 　社内サーバセグメントと各PCセグメント上の機器からは、プロキシサーバを経由したインターネット上のWebサイトへのアクセスが許可されており、アップデート用サーバとPCにはプロキシサーバを経由するような設定がされている。一方、社内サーバセグメントと各PCセグメント上の機器からのプロキシサーバを経由しないインターネットへのアクセスは、FWによって禁止されている。アップデート用サーバからのアクセス先は、特定のベンダのサイトに限定されている。 　 〔脆弱性対策の立案〕 　最近、国内外でソフトウェアの重大な脆弱性が数多く報告されており、それらの悪用によって、製造業の複数の企業でも被害が起きている。そのため、センタ部では、A社の情報システムについて、脆弱性対策を強化する必要があると考え、脆弱性対策方針案を作成し、取締役会に提案した。脆弱性対策方針案を図3に示す。

　取締役会は、この脆弱性対策方針案を了承し、センタ部が中心となってVチームを製品本部横断的に組織することを決定した。Vチームの責任者には、センタ部のP部長が任命された。P部長は、部下のQ主任をチームリーダに任命した。他にセンタ部の3名と各製品本部の情報システム担当チームから2名ずつの計9名（以下、Vチーム員という）から成るVチームを発足させた。Q主任の役割は、情報システムの脆弱性対策の立案、Vチーム員への指示、及び脆弱性対策の実施状況のP部長への報告である。 　Q主任は、任命を受けてVチーム員を招集し、図3の業務を具体化するための協議をした。その中で、脆弱性対策適用の緊急度を機器ごとに判断するための基準（以下、脆弱性対策基準という）を作成した。脆弱性レベルの判断基準には、脆弱性情報に記載された共通脆弱性評価システム（CVSS）の基本値を利用することにした。Vチームが作成した脆弱性対策基準を図4に示す。 　機器の特定及び重要度の決定には、総務部が半年ごとに固定資産の棚卸を実施して記載内容を更新している、固定資産管理台帳を利用することにした。この台帳には、個人情報又はその他の秘密情報（以下、重要情報という）の扱いの有無と、社外に対して公開しているか非公開としているかの区分が記載されている。各機器に搭載されたOS、サーバソフトウェアやミドルウェアなどのソフトウェアの名称とバージョンは記載されていない。

　 〔脆弱性の公表と対応〕 　脆弱性対策基準の運用を開始して間もなく、あるWebアプリケーションのソフトウェアパッケージ（以下、ソフトウェアMという）のバージョンZにSQLインジェクションの脆弱性（以下、X脆弱性という）があり、パッチが提供されているという情報が公表された。CVSS基本値は6.5であった。Q主任は、A社の機器にソフトウェアMが導入されているかどうかが分からなかった。そこで、Vチーム員に次の対応を指示した。 　・固定資産管理台帳に記載がある機器について、ソフトウェアMを導入しているかどうかを調査すること 　・導入している機器について、X 脆弱性に対する脆弱性対策適用の緊急度を判断すること 　 　Vチーム員は、ソフトウェア M を導入しているかどうかの確認に手間取り、1 週間後に Q主任に調査結果を報告した。ソフトウェア M を導入した機器はないとの調査結果だったので、Q主任は、X 脆弱性への対応を終了し、P 部長に報告した。ところがその 2 週間後、α 製品本部の Vチーム員から、①社外の取引先と重要情報を共有するための公開Webサーバにソフトウェア M のバージョン Z が導入されていることが分かり、対応したとの報告が入った。 　当初の調査に見落としがあったことを問題視し、Q主任は、α 製品本部の Vチーム員に見落としの原因を調べさせた。原因は、当該機器が先月導入されたばかりで、固定資産管理台帳に記載がなかったことにあった。Q主任は、Vチーム員に対して、固定資産の棚卸以降に導入された機器がないかの確認を指示した。他に見落とした機器はなかったことが分かり、Q主任は P 部長に報告した。 　報告を受けた P 部長は、当初の調査のような見落としの再発防止策を検討するよう Q主任に指示した。Q主任は、まず、固定資産管理台帳を基に、機器の新たな管理台帳（以下、新台帳という）を Vチームで作成することにした。②新台帳にはバージョンを含むソフトウェアの情報も記載することにした。また、機器の新規導入や構成変更の際には、新台帳を速やかに修正する手順にした。Q主任は、これらの改善策について P 部長に報告し、承認を得て実施した。 　 〔新たな脆弱性の公表と対応〕 　改善策を実施して 1 か月後、UNIX/Linux で利用される shell の一つである bash に重大な脆弱性（以下、Y脆弱性という）が存在するという脆弱性情報が公表された。CVSS 基本値は 10.0 であった。Y脆弱性の概要は次のとおりである。 　Y脆弱性が存在する bash では、環境変数の値が “() {” という文字列で始まる場合、関数として解釈され、実行することができる。例えば、図5のように、export コマンドを使って環境変数として TEST1 を設定し、bash で呼び出すと “echo test” が実行される。

　Y脆弱性は、例えば、図6のように環境変数として TEST2 を設定すると、bash を起動しただけで、TEST2 を呼び出さなくても、bash が起動されて環境変数を引き継ぐ際、区切り文字“;”の後に書かれたコマンドを実行してしまうというものである。図6の例では、cat コマンドが実行されてしまい、ファイル /etc/passwd が表示される。

　Webサーバにおいても、③ある条件を満たす場合には、この Y脆弱性を悪用される。図7は、CGI を利用した、ある Webアプリケーションプログラム（以下、Web アプリ B という）が呼び出される際のフローである。

　典型的なWebサーバでは、Webサーバ（httpd）がaヘッダの④フィールド値を環境変数として設定してからWebアプリBを起動するので、攻撃者は、Y脆弱性を悪用してWebサーバで任意のコードを実行することができる。例えば、図6の例と同様の場合であれば、catコマンドが実行され、このとき、catコマンドの実行時の権限によっては、攻撃者にどのようなファイルでも参照されてしまう。 　Q主任は、直ちに Y脆弱性への対応を開始した。新台帳を基に、Y脆弱性が影響する機器があるかを Vチーム員が確認したところ、公開Webサーバのうち、重要度レベル高のサーバ 8 台と重要度レベル低のサーバ 5 台が該当していることが分かった。

　Y脆弱性が悪用されると公開Webサーバが改ざんされるおそれもあり、事態を重く受け止めた Q主任は、重要度レベル高のサーバだけでなく、該当する重要度レベル低のサーバ 5 台に対しても直ちに脆弱性対策を適用するよう Vチーム員に指示した。 　　 〔WAFによる脆弱性対策〕 　Y脆弱性への対応指示に対して、β製品本部の Vチーム員からは、β製品本部機器は、パッチの適用作業に 1 か月が必要なので、代替策を検討する必要があるとの報告を受けた。Vチームでは、シグネチャによるbという手法で攻撃を検知できる Webアプリケーションファイアウォール（WAF）が代替策になるかどうか、セキュリティベンダの G氏に相談することにした。 　G氏によれば、WAFによる対応は、サーバへのパッチ適用に比べて、⑤対策を実施するまでの期間が短いといわれており、Y脆弱性への対応も既に可能になっているとのことであった。そこで、Q主任は、WAFの導入について、導入形態が異なる表1のような 2 案を作成した。

　

　β製品本部の Y脆弱性がある公開Webサーバには、新製品の発表時などに、購入希望者からのアクセスが通常時の 100 倍程度まで一時的に増大するものがあり、かつ、次の新製品発表が 3 週間後に予定されている。このため、Q主任は、案 2 を選び、⑥クラウド型の WAFを 1 週間後に導入し、β製品本部での Y脆弱性に対する代替策とする案をP部長に提案した。P部長は、この提案を承認し、センタ部に作業を指示した。 　 〔Y脆弱性への追加対応〕 　WAF導入後、β製品本部でのサーバへのパッチ適用前のある日、Y脆弱性について、社外から直接はアクセスできない機器も社外から攻撃を受ける可能性があるという追加情報（以下、Y追加情報という）が公表された。A社の情報システムの構成では、FWによって社外から社内Webサーバへのアクセスを防いでいる。しかし、Y追加情報によれば、図8に示すような、社外から社内Webサーバに対するY脆弱性を悪用した攻撃が考えられるという。

　次の条件1～3が全て成立すると、この攻撃は、成功する可能性がある。 　 　条件1　攻撃者がfを知ることができ、その情報を図8の(2)の攻撃コードに組み込むことができること 　条件2　社内Webサーバにおいて、CGIを利用したWebアプリケーションプログラムが、bashを呼び出すこと 　条件3　図8の(4)のHTTPレスポンスにヘッダとしてgが付加されていること

　A社内のWebブラウザが攻撃者のサイトにアクセスしてしまうと、eを使った攻撃コードがダウンロードされ、実行される。攻撃コードが実行されたとしても、条件3が成立していない場合、現在A社で利用を許可しているWebブラウザでは、hポリシによって、攻撃コードが社内WebサーバからのHTTPレスポンスを読み取ることはできない。しかし、条件3が成立している場合、攻撃コードが社内WebサーバからのHTTPレスポンスを読み取ることができ、その内容を攻撃者のサイトへ送信することで、社内Webサーバに対する攻撃が成功する。 　A社では、社内Webサーバは、クロスオリジンリクエストに対する図8中の(4)のHTTPレスポンスに、ヘッダとしてgを付加していないことが調査の結果分かった。このため、Q主任は、社内Webサーバ上のデータが操作される可能性はあるものの、Webブラウザ経由で情報が攻撃者のサイトに送信される可能性は低いと判断した。 　Q主任は、Y追加情報による対策の変更は必要ないことをP部長に報告した。P部長は、念のため社外のセキュリティ専門業者のF氏にレビューを依頼するようQ主任に指示した。 　Q主任から説明を受け、F氏は、攻撃者がA社のプロキシサーバを利用するために必要な情報を知ることができた場合には、図8中の(4)、(5)とは別の手法を用いることで、社内Webサーバの情報が攻撃者のサイトに送信されるおそれがあると指摘した。そして、F氏は、⑦どのような機能をもつOSコマンドが社内Webサーバで利用できる場合に、それが可能かを説明した。Q主任は、直ちに対策する必要があるとP部長に報告した。P部長は、対策を追加するとともに、Y脆弱性への対応を振り返ると、脆弱性レベル高の脆弱性については、重要度レベル低の機器であっても、直ちに脆弱性対策を実施すべき場合があるとして、Q主任に脆弱性対策基準の見直しを指示した。 　 〔脆弱性対策基準の見直し〕 　Q主任は、重要情報を扱ってはいないが社外からアクセスできる機器、及び社外からアクセスできないが重要情報を扱っている機器も、場合によっては直ちに脆弱性に対応する必要があると考えた。ただし、情報システム担当者の作業負荷の観点から、図4において対策が不要となる機器については、引き続き、対策を行わずに済むようにしたい。そこで、脆弱性対策基準の中の“4. 脆弱性対策適用の緊急度判断基準”の修正案（図9）を作成した。

　この修正案について、F氏は、⑧Vチームによる評価が必要な場合の数を減らすことができると指摘した。Q主任による修正案（図9）の代わりとして、F氏は、次の2点を提案した。 　・重要度レベルの定義を修正する。 　・リスクレベルの定義を修正する。 　 　Q主任は、この提案を基に、脆弱性対策基準の別の修正案を作成した。修正箇所を図10に示す。

　Q主任は、脆弱性対策基準の修正箇所をP部長に説明し、承認を得た。承認された脆弱性対策基準は、即時、Vチーム内に周知された。その後、WAFの導入を含む対応作業も完了し、Y脆弱性対応が終結した。