K 社は，従業員数 5,000 名の情報システム会社である。K 社では，モバイル PC に加えて，スマートフォン（以下，スマホという）から，従業員が電子メールやグループウェアなどの社内システムへアクセスできるシステム環境（以下，B システムという）を昨年導入した。B システムの利用に先立ち，従業員が電子メール用やグループウェア用のアプリケーションソフトウェア（以下，アプリケーションソフトウェアをアプリという）をスマホにインストールする。また，B システムの導入に当たっては，スマホを遠隔で管理するシステム（以下，M システムという）を追加で導入し，スマホの OS やアプリのバージョンなどの構成情報の管理や，スマホの紛失時のデータ消去などのセキュリティ対策を実現した。さらに，“個人の所有物であるスマホから B システムを利用する際は，事前に，利用者の氏名に加えてスマホの製品名や電話番号といった情報を K 社に申請すること”などを定めたスマホ利用規程を策定した。
B システムの導入から 1 年が過ぎたので，K 社では，セキュリティ対策及びスマホ利用規程が有効であったかについて確認することにした。その際に，スマホに関するセキュリティ対策を改めて議論することにした。
〔ルート特権の利用について〕
スマホのルート特権を利用者が利用できる状態にする行為（以下，ルート特権化という）について，セキュリティ上の問題がないかを検討することになった。スマホの多くは，利用者がルート特権をもたず一般利用者の権限だけで利用することを前提にしている。そのため，ルート特権をもつ個人の PC と違い，OS の設定の一部を自由に変更できないという制約や，スマホのベンダによってあらかじめインストールされているアプリを削除できないという制約などがある。そのような制約を嫌う利用者の中には，ベンダが想定していない手段で，ルート特権化を自ら行う者もいる。
K 社で調査したところ，ルート特権化は，主に，バッファオーバフロー攻撃を用いて実現されることが分かった。
〔バッファオーバフロー攻撃の詳細と対策について〕
バッファオーバフロー攻撃に関するセキュリティホールは，スマホ用の OS だけではなく，PC 用 OS やサーバ用 OS においても報告されている。通常，OS やライブラリのセキュリティホールが公表された場合，PC やサーバを管理する者は，開発元から提供される a の適用やソフトウェアの更新によって，セキュリティホールに対処する。他方，Web サーバにおいては，a の適用やソフトウェアの更新をしなくても，①通信路上に IPS や WAF を設置することによって，インターネットから Web サーバへのバッファオーバフロー攻撃を防止することもできる。
バッファオーバフロー攻撃としては，スタックバッファオーバフロー攻撃，b バッファオーバフロー攻撃や，静的メモリ領域を対象としたバッファオーバフロー攻撃が知られている。いずれのバッファオーバフロー攻撃も，主に C や C++で作成されたプログラムが狙われる。スタックバッファオーバフロー攻撃は，スタック領域を破壊するので，スタック破壊攻撃とも呼ばれる。スタック破壊の挙動をプログラム実行時に検知して停止する機能（以下，スタック破壊検知機能という）を含むコードを生成するコンパイラも普及している。
しかし，プログラム実行時に共有ライブラリがメモリ上にロードされていることを利用して，データ実行防止機能を回避する新たな攻撃法が登場した。これは，共有ライブラリ内の関数であって，かつ，任意のプログラムを実行できる関数を，スタックバッファオーバフロー攻撃時に利用するものである。libc 共有ライブラリを利用する場合，この攻撃は d 攻撃と呼ばれる。
最近の OS では，こういった攻撃が成功することを抑制するため，アドレス空間配置ランダム化技術が実装されている。アドレス空間配置ランダム化技術を用いると，スタック破壊検知機能を含めずにコンパイルしたプログラムであっても，スタックバッファオーバフロー攻撃の成功を抑制することができる。
〔K 社での対策〕
K 社の調査の結果，スマホの OS のあるバージョン（以下，バージョン V という）以降ではデータ実行防止機能及びアドレス空間配置ランダム化技術が実装されていることが分かった。また，バージョン V 以降では，その他様々な点でセキュリティ対策が強化されていることも分かった。
その上で，ルート特権化されたスマホから B システムを利用することについて改めて検討したところ，ルート特権化されたスマホは，ベンダの保守サポートの対象外になること，及び M システム用のアプリや B システム用のアプリが動作しなくなることが分かった。さらに，ルート特権化されていないスマホと違い，ルート特権化されたスマホでは，“データを盗み出すタイプのマルウェア”が侵入してしまうと，それがルート特権を取得して，③スマホ内に保存されているアプリのデータを不正に読み出してしまうリスクが高まることも分かった。そのため，K 社では，スマホ利用規程で，ルート特権化されたスマホからの B システムの利用を禁止することにした。
しかしながら，④それだけでは，従業員がスマホ利用規程を守ったとしても，“意図しないルート特権化”のリスクが残存する。K 社は，B システムのセキュリティを確保するために，スマホでは，バージョン V 以降の OS を利用することが必要であるとの結論に至った。そのため，⑤スマホの OS のバージョンを K 社が確認する運用策を実施することにした。
a は，OS やライブラリのセキュリティホール（脆弱性）に対して開発元が提供する修正プログラムで，“セキュリティパッチ”。パッチを適用するかソフトウェアを更新して脆弱性そのものをなくすのが通常の対処である。b は，攻撃対象のメモリ領域による分類で，図2のメモリ配置にはスタック領域・ヒープ領域・BSS 領域・データ領域・テキスト領域がある。本文はスタック，b，静的メモリ領域（BSS 領域・データ領域）を並べているので，残るのは“ヒープ”である。d は，共有ライブラリの関数を呼び出させてデータ実行防止機能を回避する攻撃の名称で，libc を使うものは“return-to-libc”と呼ばれる。
本文は，データ実行防止機能がスタック上のコードの実行を禁じるので，攻撃者が自分のコードを置いて実行させる方法が使えなくなり，メモリ上に既にある共有ライブラリの関数を使う攻撃法が登場した，という流れで書かれている。この“既にメモリ上にある関数を使う”という点を手掛かりにすると，d が何を指すか絞り込める。講評は b と d を OS のセキュリティ技術に関する問題と位置付けている。
字数制限は a が15字以内，b が5字以内，d が20字以内。解答例は“セキュリティパッチ”（9字），“ヒープ”（3字），“return-to-libc”（14字）で，いずれも制限内に収まる。用語は解答例の形で覚えておくとよい。
スマホ利用規程は，従業員が自ら行うルート特権化を前提にした決まりで，ルート特権化したスマホから B システムを使うことを禁止するものである。これを守っても，バッファオーバフロー攻撃を用いるマルウェアに感染すれば，従業員が意図しなくてもルート特権化される。解答例は“ルート特権化するマルウェアに感染したとき”。
スマホの OS やアプリのバージョンなどの構成情報の管理や，スマホの紛失時のデータ消去などのセキュリティ対策を実現した。
本文の冒頭
事前に，利用者の氏名に加えてスマホの製品名や電話番号といった情報を K 社に申請すること
〔K 社での対策〕
スマホの OS のバージョンを K 社が確認する運用策を実施することにした。
K 社が OS のバージョン V 以降であることを確認するには，利用者の申告では足りない。本文の申請事項は氏名・製品名・電話番号で，OS のバージョンは含まれていない。申請の後に OS が更新されても，申告だけでは K 社には分からない。M システムは，スマホの OS やアプリのバージョンなどの構成情報を管理するシステムで，K 社が導入済みなので，このシステムで構成情報から OS のバージョンを確認できる。解答例は“Mシステムを使って確認する。”。
“従業員に申請させる”“定期的に報告させる”といった自己申告の方法では，確認の確実さが運用に左右されるので，本文が既に導入している M システムを使う方法が最も具体的である。
C さんは，表1の設計方針のうち，利用者の認証及び端末の限定についての実現方法として，Q システムへのアクセス時に，従来の利用者 ID とパスワードでの認証に加え，SSL クライアント認証を行う方法を提案した。SSL クライアント認証では，あらかじめディジタル証明書（以下，証明書という）を代理店の端末に配布しておき，その証明書を用いた認証によって端末の限定を行う。
B 課長は，C さんが提案した方法について説明を受け，了承した。その上で，暗号技術について，情報セキュリティ室の R 主任に相談するよう助言した。
〔暗号技術の検討〕
次は，C さんが暗号技術について R 主任に相談したときの会話の一部である。
C さん：Q システムで使う暗号技術について，どのように検討を進めるのがよいでしょうか。
R 主任：SSL クライアント認証の場合には，まず，認証に使う公開鍵の鍵長，証明書に施されるディジタル署名の仕様，それから，通信の暗号化に使う共通鍵暗号の仕様などを選択する必要があるね。
C さん：何を基準にして選択すればよいのですか。
R 主任：表2は，米国国立標準技術研究所（NIST）が発行したセキュリティ文書を基に，攻撃の困難性の視点から，暗号アルゴリズムの安全性を整理したものだ。最も効率が良い攻撃手法で暗号を解読するときに必要な計算量を指標とし，同程度の耐性をもつものを同じ“セキュリティ強度”としている。また，“利用終了時期の目安”の行は，そのセキュリティ強度の暗号アルゴリズムについて，利用を終了することが望ましい時期を示している。
C さん：なるほど。例えば，鍵長 256 ビットの AES アルゴリズムは，鍵長 a ビットの RSA アルゴリズムや，b ビットのハッシュ関数などと同じセキュリティ強度ということですか。Q システムの場合は，少なくとも c ビット安全性と同等又はそれ以上のセキュリティ強度をもつ暗号アルゴリズムを採用すべきですね。頂いたアドバイスを参考に，更に検討します。
表2 暗号アルゴリズムの安全性
〔Q システムのセキュリティ設計〕
C さんは，R 主任のアドバイスを参考に，Q システムのセキュリティ設計について検討を進めた。証明書の新規発行手順案を図1に，証明書についての補足情報を図2に示す。代理店に遵守を求めるガイドラインには，顧客情報の取扱要件に加え，①Q システムにアクセスしていた端末を交換及び廃棄する場合に代理店が実施すべき処理などの事項を盛り込んだ。
図1 証明書の新規発行手順案図2 証明書についての補足情報図2 証明書についての補足情報（続き）
〔セキュリティ設計の修正〕
C さんは，セキュリティ設計の検討結果について R 主任にレビューを依頼した。R 主任は，証明書の新規発行手順，利用停止手順及び更新手順について一つずつ問題を指摘した。
R 主任は，証明書の新規発行手順については，代理店の担当者が不適切な行為をした場合，表1中の“端末の限定”の設計方針が満たされず，代理店の管轄下にない端末で Q システムにアクセスできる可能性があると指摘した。②この問題については，Q システムでは対策をとらず，代理店側で対策をとってもらうように，代理店に要請することにした。
R 主任は，証明書の利用停止手順については，実際には行うことができない場合が多いと推測されるので，見直さなければならないと指摘した。C さんは，この問題について，表3に示す修正案を考えた。検討の結果，設計方針への適合性と運用の柔軟性確保の視点から，案(2)を採用することにした。
表3 証明書の利用停止手順の修正案
R 主任は，証明書の更新手順については，利用停止された証明書の取扱いを担当者が誤った場合などに，③本来発行されるべきでない証明書が発行される可能性があると指摘した。C さんは，この問題についても修正案を考えた。
C さんは，これらの修正案を基に図1及び図2の修正版を作成し，再度 R 主任のレビューを受けた後，B 課長に説明した。B 課長は修正版を了承し，Q システムの開発が進められることになった。
図1中の d 及び図2中の e～h に入れる適切な字句を，図1又は図2中の字句を用いて，それぞれ 10 字以内で答えよ。
〔d〕解答例
公開鍵
〔e〕解答例
シリアル番号
〔f〕解答例
受付拒否リスト
〔g〕解答例
入力された利用者ID
〔h〕解答例
利用者ID
解説
本文の根拠
図1
(4) 担当者の端末から登録サーバへ，利用者 ID，パスワード及び登録用 PIN を入力する。同時に，端末で鍵ペアを生成し，生成した d を送信する。
図1
注記 証明書には，証明書のシリアル番号，利用者 ID，公開鍵，識別番号などを登録する。
図2
(1) 利用を停止する証明書の利用者である担当者が，受付サーバにログインし，利用を停止する証明書の e 又は識別番号を入力する。
図2
証明書中の識別番号が f に登録されていないこと
図2
g が，証明書中の h と一致すること
d は，端末で生成した鍵ペアのうち登録サーバへ送るもの。証明書には公開鍵を登録する（図1の注記）ので，送るのは“公開鍵”である。秘密鍵は端末が保持する（図2の検証項目“証明書に対応する秘密鍵を，端末が保持していること”）ので，送らない。
e は，利用停止する証明書を指定するために入力する項目のうち，識別番号以外のもの。証明書に登録する項目は，シリアル番号，利用者 ID，公開鍵，識別番号で，ログイン済みの担当者に発行された証明書を特定できるのは“シリアル番号”（識別番号の代わりに入力できる，証明書を特定する項目）。f は，利用停止した証明書の識別番号を登録した“受付拒否リスト”で，ログイン時にここに載っていないことを確かめる。g・h は，ログイン時に入力された利用者 ID が，証明書に登録された利用者 ID と一致すること，という検証で，g は“入力された利用者ID”，h は“利用者ID”。
10字以内の制限に対して，“入力された利用者ID”は 10 字で，10字以内に収まる。“入力された”を落として“利用者ID”（5字）だけにすると，証明書側の h と区別がつかなくなる。図1又は図2中の字句を用いるという条件なので，図2の字句をそのまま使う。
M 社のネットワークでは，ファイアウォール（以下，FW という）とレイヤ 3 スイッチ（以下，L3SW という）でネットワークのアクセス制御を行っている。FW のフィルタリングルールを表2に，L3SW のフィルタリングルールを表3に示す。
図1 M 社のネットワーク構成表1 M 社のサーバの機能一覧（抜粋）表2 FW のフィルタリングルール表3 L3SW のフィルタリングルール
情シ部員は，運用サーバセグメントの管理を，自席の PC のブラウザから行っている。開発サーバには，M 社の機密情報であるソフトウェアパッケージのソースコードを保管している。
営業部では，SaaS 型クラウドサービスであるサービス X を利用して顧客管理を行っている。サービス X には，営業部の PC から，HTTP の CONNECT メソッドを使用してプロキシサーバ経由でアクセスしており，プロキシサーバからサービス X へのアクセスにはポート番号 2560 を使用している。また，サービス X 内のメールサーバ Z は，M 社専用であり，製品紹介のメールを M 社の顧客に対して自動送信すると同時に，メールの写しを M 社営業部員全員に送信している。送信の際には，送信者メールアドレスとして M 社のメールアドレスを使っている。
〔情報セキュリティインシデントの発生〕
営業部の D さんから情シ部の S さんに，D さんの PC でマルウェア Y が検出されたとの報告があった。S さんが確認したところ，マルウェア Y は，既に正常に駆除されていた。S さんは，マルウェア Y について調査した。マルウェア Y の特徴は図2に示すとおりであった。
図2 マルウェア Y の特徴
〔情報セキュリティインシデントの調査〕
情シ部で，他の全ての PC とサーバを調査したが，マルウェア Y に感染したものはなかった。
次に D さんに確認したところ，送信者メールアドレスが総務部の F さんであるメールを受信した際に，マルウェア Y が検出されたことが分かった。ところが，F さんにはそのようなメールを送信した覚えはないとのことであった。そこで，当該メールのメールヘッダを調査したところ，当該メールは，送信者メールアドレスを F さんのメールアドレスに偽装した上，外部のメールサーバから送られてきたことが分かった。添付ファイルは，PDF ファイルに偽装したものであった。
次は，受信メールの制限についての，情シ部の K 部長と部下でセキュリティ担当の S さんの会話である。
K 部長：送信者メールアドレスのドメイン名が当社のものに偽装されていた場合は，受信者は開いてしまう可能性が高い。良い対策はないだろうか。
S さん：外部メールサーバにある，外部からのメールのフィルタリング機能を使用しましょう。具体的には，フィルタリングルールとして，送信ドメイン名のブラックリストに当社のドメイン名を指定します。
K 部長：それだと，①正規のメールも一部届かなくなるね。
S さん：そうですね。②フィルタリングルールを追加します。
〔バックドア通信の遮断〕
続いて，K 部長と S さんは，マルウェア Y と C&C サーバとのバックドア通信の遮断について検討した。次は，そのときの会話である。
S さん：マルウェア Y は，2 通りの方法で C&C サーバとの通信を試みます。一つ目は，プロキシサーバを経由しない方法であり，既に③防ぐことができています。二つ目は，マルウェア Y が，HTTP の CONNECT メソッドで任意のポート番号を用いる方法です。これについては，表4に示すアクセス制御ルールをプロキシサーバに設定すれば，許可するポート番号以外の通信を防ぐことができます。
表4 プロキシサーバのアクセス制御ルール
K 部長：表4でアクセスを許可する通信をマルウェアが使用する場合の対策については，別途検討しよう。ところで，表4の設定では④業務に支障が出るので，⑤項番1と項番2の間に設定を1行追加する必要があるな。
〔マルウェアからサーバへの不正アクセスリスクの軽減策〕
次に，情シ部では，マルウェアから社内のサーバへの不正アクセスリスクの軽減策を検討した。開発サーバについては，現状，開発部の PC がマルウェアに感染してしまうと，そのマルウェアからアクセスされるリスクが高い。そのため，開発専用 PC を数十台，開発サーバセグメント内に置き，ソフトウェアパッケージの開発を開発専用 PC 及び開発サーバだけで行うようにし，かつ，⑥L3SW のフィルタリングルールを変更することによって，開発サーバがマルウェアからアクセスされるリスクを軽減することにした。さらに，開発専用 PC 自身がマルウェアに感染するリスクを軽減する対策も行うことにした。
一方，運用サーバセグメントのサーバについては，運用管理を行う PC がマルウェアに感染してしまうというリスクに絞って軽減することにした。具体的には，運用管理専用 PC を運用サーバセグメントに 1 台設置し，従来，情シ部の PC で行っていた運用サーバセグメントの管理を，そこで行うことにした。さらに，その運用管理専用 PC では，a を禁止することにした。
S さん：OS のパスワードのハッシュ値が入手できた場合に，14 字までのパスワードを総当たり攻撃で解析することを考えてみましょう。L1 ハッシュでは，前半 b 字までについて，最大で（Σi=1bc）個のハッシュ値を求めれば，同じものを後半 b 字までについても使うことができます。一方，L2 ハッシュでは，最大で（Σi=1de）個となり，同一のパスワード長であっても，L1 ハッシュに比べ格段に増加します。
K 部長：なるほど。L1 ハッシュを格納しないように設定を変更しよう。ところで，表5にあるソルトを使用するとどのような効果が得られるのか。
S さん：ソルトを使用するとハッシュ値からパスワードを特定しにくくなります。
K 部長は，検討した対策案についての実施計画と，別途検討する項目についての検討時期を経営陣に報告し，対策を進めた。
メールサーバ Z は，M 社専用であり，製品紹介のメールを M 社の顧客に対して自動送信すると同時に，メールの写しを M 社営業部員全員に送信している。送信の際には，送信者メールアドレスとして M 社のメールアドレスを使っている。
表1
外部からのメールフィルタリング機能（現状は無効）
外部メールサーバのフィルタリングで送信ドメイン名のブラックリストに M 社のドメイン名を指定すると，外部から届くメールのうち，送信者メールアドレスが M 社のドメインのものは全て拒否される。偽装メールには有効だが，外部から M 社のメールアドレスで届く正規のメールも同じ扱いになる。M 社の本文でそれに当たるのは，サービス X 内のメールサーバ Z が，送信者メールアドレスに M 社のメールアドレスを使って，営業部員全員に送る写しのメールである。解答例は“メールサーバZから営業部員宛てに送られるメール”。
メールサーバ Z は M 社の外（サービス X 内）にあるので，営業部員宛ての写しは外部から届くメールで，偽装メールと同じ“外部から来る M 社ドメインのメール”として扱われる。
ホワイトリスト及びブラックリストには，送信元メールサーバの IP アドレスのリスト及び送信ドメイン名のリストがある。
本文（サービス X）
メールサーバ Z は，M 社専用であり，
表1のフィルタリング機能では，ホワイトリストとブラックリストの両方にマッチしたメールはホワイトリストが優先され，許可される。ブラックリスト（送信ドメイン名が M 社）を残したまま，メールサーバ Z からのメールだけをホワイトリストに入れれば，正規のメールを届けつつ偽装メールを拒否できる。ホワイトリストには，送信元メールサーバの IP アドレスのリストと送信ドメイン名のリストがあるが，ここは送信元メールサーバの IP アドレスのリストに，メールサーバ Z の IP アドレスを入れる。解答例は“送信元メールサーバのIPアドレスのホワイトリストにメールサーバZのIPアドレスを追加する。”。
送信ドメイン名のホワイトリストに M 社のドメイン名を入れると，偽装メールの送信ドメイン名も M 社なので，ブラックリストの設定が意味を失う。講評も，設問1(2)はフィルタリングルールの仕様を正確に記述していない解答が散見された，と述べている。メールサーバ Z は M 社専用で，IP アドレスで特定できる。
50字以内の制限に対して，解答例は45字。“送信元メールサーバの IP アドレスの”“ホワイトリスト”“メールサーバ Z の IP アドレスを追加”の三つを，仕様の用語どおりに入れる。
開発専用 PC を数十台，開発サーバセグメント内に置き，ソフトウェアパッケージの開発を開発専用 PC 及び開発サーバだけで行うようにし，
表3
項番1：利用者セグメント2，開発サーバセグメント，全て，許可。
表3
注記 項番の小さいものから順に，最初に一致したルールが適用される。
開発専用 PC を開発サーバセグメント内に置いて，開発を開発専用 PC と開発サーバだけで行うので，開発部の PC（利用者セグメント2）から開発サーバへのアクセスは不要になる。表3の項番1は，利用者セグメント2から開発サーバセグメントへの通信を全て許可していて，開発部の PC がマルウェアに感染した場合に，マルウェアが開発サーバにアクセスできる原因になっている。この項番1の動作を“許可”から“拒否”へ変更する。解答例は“利用者セグメント2から開発サーバセグメントへの通信を拒否にする。”。
ブラウザ又は PDF 閲覧ソフトの脆弱性を悪用して感染し，PC の起動時に自身が起動されるようにシステム設定を変更する。
〔マルウェアからサーバへの不正アクセスリスクの軽減策〕
運用サーバセグメントのサーバについては，運用管理を行う PC がマルウェアに感染してしまうというリスクに絞って軽減することにした。
マルウェア Y の感染経路は，ブラウザ又は PDF 閲覧ソフトの脆弱性の悪用と，偽装メールの添付ファイルである。運用管理専用 PC は運用サーバセグメントの管理だけに使う PC なので，管理に必要のないソフトウェアを使わなければ，感染のきっかけが減る。例えば，インターネットの閲覧，メールの送受信，PDF の閲覧などが，管理に必要のないソフトウェアの利用に当たる。禁止するのは，管理に必要のないソフトウェアの利用である。解答例は“運用サーバセグメントの管理に必要のないソフトウェアの利用”。
運用サーバセグメントについては，リスクを“運用管理を行う PC が感染すること”に絞っているので，運用管理専用 PC は管理に特化し，感染経路になるソフトウェアは使わない，という方針になる。
![C 言語のプログラム（行番号付き）。1: （省略），2: int main(int argc, char *argv[]) {，3: char *a;，4: （省略，ここで a がポイントする領域にインジェクションベクタが挿入される。），5: foo(a);，6: （省略，ここでその他の必要な処理をする。），7: }，8: int foo(char *b) {，9: char c[24];，10: （省略），11: strcpy(c, b);，12: （省略，ここで c を利用する。），13: return 0;，14: }](/data/figures/2014h26a-sc-pm1/q1-f1.png)
![メモリ配置図。上から順に，アドレス ffffffff（上端），省略記号，アドレス c804805e から c8048026 までが“（ここに shell コードが入る）”，その下の c8048026 の位置から“リターンアドレス X”，“ebp レジスタ保存値”，省略記号，“char c[24]”，その下の小さな領域，アドレス c8047fe6 までが“スタック領域”である。省略記号をはさんで“共有ライブラリ”，その下の領域が“ヒープ領域”，省略記号をはさんで“データ”の領域が“BSS 領域”，その下の“データ”の領域が“データ領域”，その下の“Vuln”の領域（アドレス 08048026 から）が“テキスト領域”である。注記 メモリアドレスは 4 バイトの 16 進数表記である。](/data/figures/2014h26a-sc-pm1/q1-f2.png)
