連載
» 2011年12月09日 00時00分 公開

リスクアセスメントとセキュリティポリシー策定Androidセキュリティの今、これから(最終回)(3/3 ページ)

[Android セキュリティ部,@IT]
前のページへ 1|2|3       

(3)バグ/セキュリティホールとマルウェアのリスク評価

 ここでは、バグ/セキュリティホールとウイルス/ワームを含むマルウェアによる情報漏えいのリスクを集約して記載しました。

表4 バグ/セキュリティホールとマルウェアによるリスクの評価例(クリックすると拡大します) 表4 バグ/セキュリティホールとマルウェアによるリスクの評価例(クリックすると拡大します)

 前述の(1)と重複する部分は除外し(原因は異なりますが対処は同じため)、現在までに報道されているAndroidでの情報漏えい事件を元に、あくまでサンプルとして項目を記載しています。

 バグ・セキュリティホールやマルウェアによる情報漏えいとして、ここに挙げたもの以外にリスク評価を行うべき項目があれば、それも含めて検討してください。対応方法が異なるかどうか不明瞭な場合には、個別に評価することを推奨します。

(4)人為的過失による情報漏えいのリスク評価

 ここでは、第3回の「人為的過失による情報漏えい」で列挙した内容を集約しています。

表5 人為的過失によるリスク評価例(クリックすると拡大します) 表5 人為的過失によるリスク評価例(クリックすると拡大します)

 メール経由のリスクとしては、Androidで送信される添付ファイルや誤送信を評価としました。

積算結果に基づく優先順位付け

 今回挙げたリスク評価例では、いずれも右端に積算結果を掲載しました。

 理想をいえばすべてのリスクに対応することが望ましいのですが、リスク対応にかかるコストを考えるとそうもいきません。そこで、積算結果に基づいて、優先順位を付けて具体的な対策を決定します。

 例として、仮想企業の情報セキュリティ責任者は、これらのリスク評価に基づいて、「(2)不正な情報持ち出し、内部犯罪の対策を実施する」と決定したと考えてみましょう。

 リスク評価では、(2)のリスク評価積算結果の最低値が「64」であったため、「64」以上のリスクを対策実施対象としました。リスク評価の積算結果で同値であることは、同じリスクであることを示します。

 またサンプルでは、評価積算結果が「64」未満の項目については、費用対効果の観点から、技術・製品の導入までは行わないこととしました。教育などで対応を行う、受容リスクであることを認めるという意味になります。

 なお、あらためて注意しますが、この記事に記した判断基準および評価結果はあくまでサンプルです。実際には、各企業ごとの企業文化、業務内容、情報価値、利用役職などの判断基準を検討し、評価を実施してください。

セキュリティポリシーの策定と教育の実施

 では、上記を踏まえたセキュリティポリシーの修正と教育について説明します。これも前述の通り、すでにセキュリティポリシーは策定済みで、そのセキュリティポリシーを修正することを前提として、Androidに限定した個所について説明します。

 なお、セキュリティポリシーの詳細なサンプル(注9)は、日本ネットワークセキュリティ協会のホームページにも掲載されています。経済産業省が発行する「情報セキュリティポリシーのガイドライン」の資料(注10)も参考にしてください。

 また、策定されたセキュリティポリシーについては、必ず経営者の承認を得てください。

セキュリティポリシー

 セキュリティポリシー策定を行う手順は以下の通りです。

図2 ポリシー策定手続きの手順(注11) 図2 ポリシー策定手続きの手順(注11)

 (4)の対策基準として、経済産業省が制定した「情報システム安全対策基準」を利用し、これに準拠した対策基準を策定します。対策基準が確定すれば、どのように基準を実現するかによって企業のセキュリティポリシーが決まります。

 ここでは、Androidにおける安全対策基準を検討する観点と、対策項目のみを抽出します。

表6 Androidにおける安全対策基準の例(クリックすると拡大します) 表6 Androidにおける安全対策基準の例(クリックすると拡大します)

 Android向け安全対策基準は、リスク評価の積算結果を鑑み、具体的な対策を通じてどのように実現するのか検討してください。

教育

 セキュリティリスクへの対策は、技術的対策、物理的対策、人的対策で構成されます。人的対策は主に、社員に対するセキュリティ教育(注12)を実施することで実現します。教育においては、Androidを利用する上での脅威を正しく伝えることが重要です。Androidにおける脅威については第3回を参考にしてください。

注11:首相官邸「情報セキュリティポリシーに関するガイドライン」より引用。

注12:一般的な情報セキュリティ教育については、IPA 情報セキュリティ読本 改訂版 -IT時代の危機管理入門-などを参考にしてください。


継続的なリスク評価の見直しを

 企業がAndroidを採用する場合、「業務システムの1つとしてどのように使わせるのか」が最も重要になります。正しい情報の下、正しく判断し、正しくセキュリティ対策を行うことが重要です。

 現実的には、第三者から見て最善であると想定される情報を基準とし、対策を行うことになるでしょう。社外の情報セキュリティ監査を利用することで、リスクアセスメントを行うこともできます。

 Androidを企業で利用する、しないにかかわらず、リスク評価を行ってきちんと状況判断することが重要です。

 普及期に入ったAndroidは、好むと好まざるとに関わらず、従業員が利用し、企業に持ち込まれていると考えられます。従業員からは、ビジネスで活用したいという要望が高まっているだけでなく、情報システム部門が知らないうちに勝手に、BYODの形で利用され始めているかもしれません。

 特にスマートフォンの進化スピードは速く、半年先にはどうなるのか、予想することすら困難です。従って、随時リスク評価の見直しが必要であることにも、情報システム管理者は留意してください。


 以上、第3回から今回まで3回にわたって、Androidをビジネスで活用する際のセキュリティ上の注意点について記載しました。

 今回でこの連載は終わりとなりますが、Androidセキュリティ部では、一般ユーザー、ビジネスユーザーなどさまざまな立場から、Androidにまつわるセキュリティに関して、情報交換やディスカッションができる場となることを目指しています。どうぞお気軽にご参加ください。

【関連リンク】
Android セキュリティ部

http://groups.google.com/group/android-security-japan


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。