不審メール:緊急時の接続促す 出会い系サイトに登録も


http://mainichi.jp/select/news/20140827k0000m040059000c.html

不審メール:緊急時の接続促す 出会い系サイトに登録も
毎日新聞 2014年08月26日 19時52分(最終更新 08月26日 23時55分)
「通信テスト」としてネット接続を求める内容のメール=鈴木敦子撮影

 携帯電話会社を装い「緊急時の通信回線チェックをお願いします」などとネットへの接続を促す不審なメールが出回っている。情報セキュリティー大手、トレンドマイクロによると、本文中のURLに接続すると会員制出会い系サイトの登録画面につながることが確認された。国民生活センターは「災害が続けば不安をあおるようなメールが出てくる。接続しないでほしい」と注意を呼びかけている。

 「ドコモをご利用の皆様へ緊急時の通信回線チェックをお願いします」。東京都内の40代の女性のスマートフォンに、8月中旬から毎日こうしたメールが届くようになった。友人2人にも同様のメールが届いているという。文面は「災害時は他社の端末への通信は届きにくい」として「通信環境の確認」などを求めている。

 また、同じような文面で「ソフトバンクお知らせメール」と題したメールや、偽の地震速報も届いているという。一部の送信元は「災害速報放送局」と表示されていた。

 トレンドマイクロによると、本文のURLから出会い系サイトの登録画面につながった場合、ただちにウイルスに感染するなどの実害が出るかは不明という。これらのメールについて、NTTドコモ、ソフトバンク両社とも「当社とは関係ない」としている。

 不審なメールに関する通報・問い合わせは消費者ホットライン(0570・064・370)へ。【鈴木敦子】

http://mainichi.jp/select/news/20140827k0000m040059000c.html

.*.

日産サイト50日以上の改ざん放置事件がISMSに示唆すること


日産サイト50日以上の改ざん放置事件がISMSに示唆すること

日産自動車のセキュリティ事件がメディアに報じられていた。下取り見積もりを依頼した利用者の個人情報は盗み取られた可能性がある。内容はディーラーのセールスが欲しがる情報だから名簿業者に売られた可能性もある。




(2014/8/26 19:38)
  • 日産自動車株式会社は26日、同社ウェブサイトの一部が不正アクセスにより改ざんされていたと発表した。
  • 改ざんされたサイトは「下取り参考価格シミュレーション(tradein.nissan.co.jp)」で、改ざんされていた期間は 6月30日4時21分から8月22日23時22分まで。同期間中に該当サイトへアクセスすると、改ざんされたプログラムによって、第三者のサイトへ遷移す るほか、一部の人は意図しないファイルをダウンロードしていた可能性があるとしており、詳細を確認しているという。
  • 日産では、改ざんを確認した8月22日に該当サイトを運用するサーバーを停止。また、同一サーバーで運用していた「他メーカー比較 (comparison.nissan.co.jp)」も停止している。現在は、セキュリティ専門会社による詳細調査を行っており、他サーバーへの侵入や 個人情報などの情報漏えいは確認されていないという。
  • 日産は、改ざんされていた期間に該当サイトへアクセスした可能性のある利用者に、セキュリティソフトを最新バージョンにアップデート し、ウイルスチェックを実施するよう呼び掛けている。なお、同サーバーを使用するサイトのサービスは当面停止し、安全対策を実施した上で再開する予定とし ている。       


.*.

日産のISMS

以下の2組織がISMS認証取得している。今回の事件との直接的な関連は無いかも知れないが、ISMSを推進する上では少なからず影響を与えたであろうと考えるのが本来だ。先行取り組み部門だから参考にするのは当然。

しかし、残念ながら両組織とも認証はBSIジャパンから受けている。しかも10年近くも同じ審査機関だとすると、適切な改善がなされてきたか疑問が残る。不適合を出さないのがセールスポイントみたいな審査を幾ら受けても、経営者が望んだレベルに達成することは難しいでしょう。
  • 東京日産コンピュータシステム株式会社(2005)
  • 日産名古屋書庫運輸株式会社(2011)
.*.

何が問題か

発表内容だけでは本質的なこと・具体的なこと分かりようがないが、
  • 改ざんを受けたこと自体が先ず問題。
  1. 脆弱性管理はどうなっていたか?。
  2. 最新バージョンであったかどうか。最新の脆弱性情報の入手方法は適切か、活用方法は適切か。
  3. 外部からの模擬アタックによる検証の有効性評価と実施状況は適切か。
  4. 外部からアタックログ管理および分析は適切か。方法論~ツール。どのような攻撃を受けているか定性的定量的に評価する。
  • 改ざん検知が遅れたことも重大な問題。
  1. 改ざん検知のための適切な仕組みを持っているか?
  2. トレース&トレンド管理は適切か。今回は、今までアクセス実績があったページへのアクセスが止まっているはずだ。そのことを検知できていない。
  3. 完全性管理または変更管理は適切か。リリースしたコードと実装コードは一致するかなど。
  4. システムログ管理は適切か。
  5. 適切なモニターシステムを持っているか。エンドユーザーの権限で実際にユーザーのようにサイト全体を回遊してもらうモニター制度。これを使えば、改ざん問題以外に画面設計など基本的な改善課題も抽出できる。
  • ISMS改善のためのビジネスパートナー選定ミスも重要。
  1. 認証を得るなら審査機関も審査員もコンサルも選ぶべきだ。
  2. 自前でやるときもコンサルは選ぶべき。耳に心地よい汗をかかない提案をしてくるところはリジェクトすべき。よく騙されます。
  3. ISMSはワンフォオール、オールフォワン。全員参加、基本的職能、例外なし。これを回避する提案を持ってきたら塩を撒いてやりましょう。
.*.

リパック:偽人気アプリにご用心 情報抜き取られる恐れ



http://mainichi.jp/select/news/20140817k0000m040129000c.html

リパック:偽人気アプリにご用心 情報抜き取られる恐れ

毎日新聞 2014年08月17日 08時30分


 スマートフォンなどに搭載されているグーグルの基本ソフト(OS)「アンドロイド」のアプリに、ウイルスを紛れ込ませるソフト(キット)が、ネット上で無料配布されていることが分かった。アプリをいったんバラバラにし、ウイルスを仕込んで組み直す「リパック」と呼ばれる動作を行うキットで、リパック後の偽アプリをインストールすると、感染に気付かないまま個人情報を抜き取られる恐れがあり、セキュリティー会社が警戒を呼びかけている。【関谷俊介】
 ◇組み込みソフト出回る

 アンドロイドのアプリは、幅広く使われているプログラム言語「Java」で開発されているため、改良しやすい半面、改ざんもされやすい。リパックはアプリをパーツと呼ばれる単位まで分解したうえで、ウイルスを忍ばせ再構成する仕組み。情報セキュリティー大手・トレンドマイクロが確認したところ、リパックを可能にするキットは昨年6月には約4000円で売られていたが、同11月以降、無料化されている。

 同社や情報セキュリティー会社・アンラボによると、リパックされた不正な偽アプリは、人気無料通信アプリ「カカオトーク」や、世界的な人気ゲーム「モンキー・ジャンプ2(正式名=Monkey Jump 2)」など少なくとも8種類で見つかっている。正規のアプリ同様、通話したりゲームを楽しんだりすることができ、感染に気付かないのが特徴だ。

 偽アプリ作成者の狙いは、主に個人情報の入手にあると見られる。インストール時に公式アプリにはない確認画面が現れ(1)通話履歴(2)連絡帳(3)位置情報などへの外部からのアクセスを認めるよう求められる。悪質なケースでは、遠隔操作機能のあるウイルスを忍ばせ、通話音声の盗聴やメールの内容などを盗み見されてしまうものもあるという。

 偽アプリは、メールやソーシャル・ネットワーキング・サービス(SNS)に張られたリンクから誘導されるサイトに置かれているケースが多い。正規のアプリと同じアイコンを利用し、本来なら有料なのに「無料」をうたうものもある。

 トレンドマイクロの岡本勝之シニアスペシャリストは「偽アプリがインストールされる恐れのあるサイトにアクセスしないことが大切。アンドロイドユーザーへの攻撃は増えており、セキュリティー対策ソフトを導入し、インストール時に個人情報への多くのアクセスを求められた場合は疑ってほしい」と話している。

◇公式サイト以外で配布

 リパック以外の手口で生み出される偽アプリも数多く存在する。トレンドマイクロが7月に、アンドロイドの公式マーケット「グーグルプレイ」上にある、人気上位50位までの無料アプリの全バージョン336件を調べたところ、77%に当たる259件で偽アプリが確認された。すべて、公式マーケット外のサイトに置かれ、大半がインストールしても正規アプリのように動作せず、個人情報を抜き取るタイプだった。

 過去にはグーグルプレイ上に不正アプリが置かれていたこともある。昨年はメールアドレスなどを盗み取られる不正アプリが見つかり、5万回超インストールされたことが確認された。グーグル広報部は「不正アプリの数は公表していない。アプリのなりすましや知的財産の侵害については、開発者向けガイドラインで禁止している」とコメントした。

 一方、アップルジャパン広報部によると、iOS向けアプリは、配布が公式マーケットに限られ、ウイルスが仕込まれた事例は確認されていない。

 【ことば】アンドロイド

 グーグルが提供するスマートフォンやタブレット端末向け基本ソフト(OS)。アップルのスマートフォン「iPhone(アイフォーン)」などに搭載されているOS「iOS」は同社製品専用なのに対し、アンドロイドはどのメーカーの製品にも搭載できる。米調査会社IDCによると、世界のスマホにおける2013年のシェアは、アンドロイドが78・6%とトップで、2位がiOSの15.2%。グーグルによると、アンドロイド向けアプリは100万種類以上あり、延べ500億回以上インストールされている。


http://mainichi.jp/select/news/20140817k0000m040129000c.html

.*.

絶対おすすめ!?会社でISMS担当になったら読むべし「蔵本雄一の社長に説明できるセキュリティ」

http://itpro.nikkeibp.co.jp/atcl/column/14/511845/073000001/?ST=security&P=1 

http://itpro.nikkeibp.co.jp/atcl/column/14/511845/073000001/?ST=security&P=1


絶対おすすめ!?会社でISMS担当になったら読むべし「蔵本雄一の社長に説明できるセキュリティ」

興味深い良く出来た記事に遭遇したので紹介します。蔵本雄一さんの斬新な発想や見識の一端が理解できて組織内でセキュリティを担当する人にとっては貴重なリソースになるかも知れません。「社長に説明できるセキュリティ」だけでも相当ボリュームのある連載でいずれも読みごたえがありそうですが、この方の記事・執筆のものは他にも多くありそうですね。いろいろ読んでみることをお勧めします。講演もやられています。機会あればライブで息吹を感じてみたいものです。

以下は割と最近のものを抜粋しています。ISMSの基本的な事項を抑えているのでとても読みやすいので、是非原文を通読されることをお勧めします。

.*.




社内営業で経営層の判断を促す(前編) 「危険である」では効果なし
  2014/08/07

 最近のサイバー攻撃はますます狡猾になってきている。例えば攻撃者が身元を隠ぺいするために、自社が踏み台にされるようなケースも目立つようになってきた。このことはセキュリティ対策が自社だけの問題ではなくなってきていることを示している。単に自社のみの問題であれば、「重要な情報などウチにはない」「ハッキングされても困ることはない」と言っていられるものの、他社や世間に迷惑をかけてしまう可能性がある以上、ITのセキュリティ対策はCSR(企業の社会的責任)の一環として社会的な責任の範疇(はんちゅう)に入ってきていると言っても過言ではないだろう。

 こういった状況下において、セキュリティ対策に「投資するのか」あるいは「投資しないのか」という意思決定は極めて悩ましく、慎重を期す必要がある。経営層がこの意思決定を下すためには、そのための材料が必要となるが、あなたがやみくもに「危険です」と言ったところで十分ではない。あなたが経営層に対して一種の“社内営業”を行い、投資の決断をしてもらうことが重要になる。

 あなたがこのミッションを成功させるには次の2つが鍵となる。一つは「購買意思決定プロセスに従った提案」、もう一つは「経営層に見えるリスク分析」である(図1)。この2つの鍵を実践することで、経営層に対して効果的な意思決定材料を提供できるのだ。今回はセキュリティ対策への投資における意思決定に注目して、前者の「購買意思決定プロセスに従った提案」について解説する。後者の「経営層に見えるリスク分析」の解説は次回以降に譲る。

図1● ミッション成功の鍵


購買プロセスの5段階モデル

 まずは投資する側がどういうプロセスを経て購買に至るのかを考える必要がある。ここではベースとなるプロセスモデルとして、フィリップ・コトラーの提唱による「購買プロセスの5段階モデル」を紹介する。これはBtoC、BtoBに関わらず、ある程度汎用的に利用できるプロセスモデルである。以下では「このプロセスモデルはどういったものか」「このプロセスモデルの各フェーズで何をやるのか」について解説する。



 コトラーの「購買プロセスの5段階モデル」は、「問題認識」「情報探索」「代替製品の評価」「購買決定」「購買後の行動」の5つのフェーズで構成される(図2)。各フェーズの目的とその流れは次の通りである。
http://itpro.nikkeibp.co.jp/atcl/column/14/511845/073000001/?ST=security&P=2
図2●購買プロセスの5段階モデル


    (1)問題認識:ニーズの引き起こし
     ↓
    (2)情報探索:ニーズを満たす製品(方法)の調査
     ↓
    (3)代替製品の評価:ニーズを満たす製品(方法)の比較
     ↓
    (4)購買決定:他人の評価等を参考に、購入を決定
     ↓
    (5)購買後の行動:自身の判断の正しさの検証

これを情報セキュリティに応用してみると下記のように考えることができる。

    (1)問題認識:課題(リスク)の明確化
     ↓
    (2)情報探索:(1)の「問題認識」で明らかになった課題(リスク)に対する対応策について調査
     ↓
    (3)代替製品の評価:(2)の「情報探索」で列挙された対応策の検討
     ↓
    (4)購買決定:他社の評価や事例などを参考に購入を決定
     ↓
    (5)購買後の行動:課題(リスク)を解決できているかどうかを継続してモニタリング

 「投資する」という意思決定に至るまでのプロセスを5段階に分解するとこのようになる。こうすることで、各フェーズで何をすべきかがより明確になり、構造化された提案が可能になるということが分かる。また同時に、単に「危ない」と言うだけではその提案が経営層に届かないということも理解できるのではないだろうか。

 ではここからは、それぞれのフェーズを順に解説していく。

(1)問題認識:課題(リスク)の明確化

 (1)の問題意識は課題(リスク)を明確化するフェーズである(図3)。方法はいくつかあるが、例えば「リスクA:2点」「リスクB:5点」「リスクC:7点」などとリスクを数値化すると分かりやすい。その結果に応じて対策の優先度を決めることになる。なお、具体的な方法の解説は長くなるので次回以降に譲り、今回は「リスクを点数化して明確にする」という方針だけ押さえて先に読み進めてほしい。
http://itpro.nikkeibp.co.jp/atcl/column/14/511845/073000001/?ST=security&P=3
図3●問題認識


(2)情報探索:(1)の「問題認識」で明らかになった課題(リスク)に対する対応策について調査

 (2)の情報探索は(1)の「問題認識」で洗い出したリスクに対して対応策を検討していくフェーズである(図4)。洗い出されたリスクへの対応策には、「リスクの回避」「リスクの低減/軽減」「リスクの移転」「リスクの分散」「リスクの受容」など様々な方法がある。このうち今回はよく使用される「リスクの回避」「リスクの低減/軽減」「リスクの受容」の3つの概念について解説する。

図4●情報探索


 まずは全体の流れを時系列で見ていこう。

 「リスクの回避」→「リスクの低減/軽減」→「リスクの受容」という流れは、まずリスクを回避するかどうかを検討し、回避しないならリスクの低減/軽減策を検討、最後に残ったリスクを受容するかどうかを考える――というステップになることが多い。リスクを受容できない場合は再度「回避」「低減/軽減」を検討する。以降では「回避」「低減/軽減」「受容」の各ステップで何をすべきかなど、ポイントを解説する。



リスクの回避

 リスクの回避では、そもそもリスクが発生しないようにする方法を検討する。誤解を恐れず言えば「危ないことはやらない」という表現になる。以下が分かりやすい例だろう。

    (A1)個人情報の漏洩を防ぐために個人情報を保有しない
    (A2)インターネットからのウイルス侵入を防ぐためにネットに接続しない

 上記の2例からピンとくるかもしれないが、この場合には注意点が2つある。一つは「資産が利用できない」、もう一つは「確実に実施しなければ極めて危険」である。

 例えばAのケースであれば、個人情報を保有しないから、個人情報を基にしたマーケティング活動はできない。Bのケースであれば、インターネットに接続しないから安全と考え、ウイルス対策ソフトのインストールや更新を怠けていると、別のインターネットに接続されている端末からUSBメモリなどの物理媒体を経由してウイルスが侵入するようなセキュリティ事故は珍しくない。

 ネットワークや物理媒体を利用したデータのやり取りが一切ないというならまだしも、「インターネットと接続しない」というのは単にデータの流入出経路の一つを断ったにすぎない。経路を断ったから大丈夫だと安心していると、セキュリティ対策がなされていない状態でウイルスなどに侵入されてしまい、抵抗する術がないので被害が大きくなってしまう。これは少なからずあることなので気を付けたい。経路を断つことでリスクの回避を狙うのであれば、しっかりと経路を洗い出して考えたい。

 また、この「リスクの回避」は本連載の第一回にも述べたが、ビジネス上のリスクへと昇華してしまう可能性がある。

 例えば、「社外に端末を持ち出して仕事をする」というケースを考えると、盗難紛失などのリスクがある。そのリスクを回避しようとして、社外への端末持ち出しを禁止すると、ビジネスの機動力が落ちてしまう。ビジネスのスピードを加速するためのITであったはずなのに、これでは本末転倒だ。

 「リスクの回避」を選択することでビジネス活動に支障が出ると思われる場合は、それによって懸念されるビジネス上のリスクを経営層に伝えることも意識しておきたい。


リスクの低減/軽減

 次に「リスクの低減/軽減」を解説する。このステップでは、リスクが発生する可能性を下げたり、リスクが発生した際の被害を小さくしたりする、いわゆる「セキュリティ対策」を実施すると考えれば理解しやすいだろう。具体的には「ウイルス対策ソフトを導入してウイルス感染リスクを下げる」「ファイルを暗号化して情報漏洩リスクを下げる」などが該当する。本連載でこれまで述べてきたセキュリティ対策の知識を存分に活用してリスクを下げる方法を検討してほしい。

 リスクの低減/軽減ステップでは次の2つがポイントとなる。

    (B1)リスクをゼロにする必要はない
    (B2)次のステップである「リスクの受容」で許容されるレベルにまでリスクを下げる

 よくある誤解が「リスクはゼロにしなければならない」と考えてしまうこと。前のステップでも述べたように、リスクをゼロにすることは相当にハードルが高い。例えば個人情報の漏洩を防ぐために個人情報を持たないといった、保護対象となる資産自体を破棄するほどのかなり極端な対策を実施する必要がある。それによるビジネスへの弊害の可能性も前述した通りだ。

 保護対象となる資産を抱えた時点で既にリスクは発生していると考え、リスクを受容可能なレベルに低減/軽減する方針で現実的な対策を実施したい。

リスクの受容

 最後に、「リスクの受容」について解説する。前ステップで様々な対策を実施し、リスクを低減/軽減しているはずなので、このステップでは残存しているリスクを受け入れるか否かを検討する。

 極端な話だが、例えばウイルス感染リスクを下げることを考えたとする。この際のセキュリティ対策として10社のウイルス対策ベンダーの製品をすべて利用したとしても、ウイルス感染のリスクはゼロにはならない。この残ったリスクを受容するか否かを検討するのがこのステップだ。

リスクの受容ステップにもポイントが2つある。

    リスクがゼロでなくとも許容範囲であれば受容する
    最終的にリスク受容を承諾するのは経営層である


 前述の10社によるウイルス対策のたとえ話からも、リスクがゼロにならないと受容しないという方針は現実的ではないと言える。このため、リスクがゼロでなくても許容範囲であれば受容する方針で検討する必要があることを意識しておこう。また、リスク受容の最終的な承諾者は経営層となる。だからこそ、なるべく経営層が理解できるような表現やリスクの点数化を意識する必要がある。今回と次回の内容をしっかりと理解してほしい。

 なお第1のポイントである「リスクがゼロでなくても許容範囲であれば受容する」に関しては、点数化したリスクが何点以下であれば受容するのかという話になるのだが、この部分はかなり経験値の高いCIO/CISOであったとしても事前に定義しておくのはほぼ無理だと言える。そのため、現実的には一旦リスクを洗い出した後に許容範囲を定義していく流れになる。

 また、このフェーズにおいて残存リスクの程度が許容範囲を超えており、リスクを受容できない場合は、再度「リスクの回避」や「リスクの低減/軽減」によってリスクを受容可能なレベルに低減/軽減できないかを改めて検討してみよう。

代替製品の評価と購買決定

 このフェーズでは「情報探索」で列挙したリスクへの対応策について対応策を順位付けして、最終的に購買を決定する(図5)。情報セキュリティ対策の場合、「リスクの対応策=具体的な製品」となることも多いため、製品選定のフェーズにもなる。当然ながらコストとの兼ね合いも検討する必要がある。

http://itpro.nikkeibp.co.jp/atcl/column/14/511845/073000001/?ST=security&P=6
図5●代替製品の評価と購買決定


 そもそもこういったプロジェクトには最初からCIO/CISOを巻き込み、密な連携しつつ進めたいところ。特にこの「代替製品の評価」と「購買決定」のフェーズに関しては必ずCIO/CISOを巻き込みたい。本連載でも繰り返し述べているように、セキュリティ対策の全体像を把握しているCIO/CISOを巻き込むことで、多層防御による各層の防御や、全体最適を考慮した対策が可能になる。またライセンス調達においても、現在保持しているライセンスや今後導入予定のライセンスを考慮に入れ、各社の包括ライセンスやボリュームディスカウントによる安価な調達コストも期待できる。本連載の第3回「ムダだらけのセキュリティ投資を防ぐ4つのポイント」なども参考にしてもらい、ムダのない対策を検討してほしい。

 またこのフェーズでは、リスクへの最終的な対応策の選定やセキュリティ対策製品を選定する際に他社の事例も参考にする。

 そのため、同業種の他社と情報を共有するような仕組みを構築しておくと、事例以外にも、実際に困っていることや注意しておくべき点などのより実践的な内容も入手できるようになり、自社におけるソリューションを選択する際にはとても有力な情報源となる。同業種でなくとも参考になるところはありそうだが、事業特性が類似しているほうがワークスタイル、ワークフローや困っているポイントなども類似する傾向にあるため、より参考になるだろう。他社とのフェース・ツー・フェースでの情報共有だけでなく、各種メディアへのアンテナも高くしておきたい。

 予算の話をする際には、仮想評価法も活用したい。仮想評価法は、現在の環境を保護するために支払ってもよいと思う金額を訪ねる方法。定性的な手法ではあるが、環境を悪化するシナリオと併せてヒアリングすると、効果的に機能する場合もある。セキュリティ事故が発生した企業で緊急対策予算がつくことがあるが、あれは仮想評価法の究極とも言える。また、冒頭で述べた通り、昨今のセキュリティ対策はCSR的な側面を持っていることも忘れずに提案したい。


購買後の行動

 最後のフェーズは「購買後の行動」だ(図6)。導入した製品でしっかりと課題を解決することができているかを継続してモニタリングするフェーズである。導入した製品で十分防御できているのか、それともさらなる対策の追加や導入した製品のリプレースが必要なのかといった判断を継続して行う。特にセキュリティ対策の場合、ウイルスの進化や攻撃方法の変化といった外部環境の変化により、現在は対応できていても、次第に十分な対応が難しくなってくることが考えられる。このように対策が十分に機能していない状態になってしまった場合は、「問題認識」から再度検討し、リスクの対応策を練り直す。また、セキュリティ対策機能の効果測定という側面意外に、投資の正当性の証明と言う観点からもこのフェーズが重要であると覚えておこう。

図6●購買後の行動

【まとめ】

 本連載でこれまで繰り返し強調している通り、経営層への提案において単に「危険である」と言っても効果は期待できない。そのため今回解説したコトラーの「購買プロセスの5段階モデル」に従って、経営層の購買意思決定プロセスを意識した効果的な提案を行ってほしい。またリスクへの対応の中でも、特に今回紹介した「リスクの回避」「リスクの低減/軽減」「リスクの受容」について理解しておくと、リスクが判明した際の立ち回りがスムーズになるため、ぜひ理解しておいてほしい。

今回の内容が経営層への効果的な提案の一助となれば幸いである。

蔵本雄一(くらもと ゆういち)
日本マイクロソフト ビジネスプラットフォーム統括本部
前職でアンチウイルスソフトの開発などに携わり、2005年、マイクロソフト株式会社(現・日本マイクロソフト株式会社)に入社。以来、セキュリティエンジニアとして、主に大規模な顧客環境のセキュリティ向上活動に従事している。プログラミングやハッキングといった下流の技術要素から、情報セキュリティ監査やコンサルティングなどの上流要素まで幅広くカバー。教育、人材育成、記事執筆、セミナー講師などの活動を通して、情報セキュリティの普及に携わる。筑波大学非常勤講師、日本CISO協会 主任研究員、公認情報セキュリティ監査人、CISSP。

.*.




社内営業で経営層の判断を促す(後編)リスクを点数化して優先度を付ける

2014/09/16

 前回に続き、コトラーの「購買プロセスの5段階モデル」に従った経営層へのセキュリティ対策訴求について解説する。まずは前回のおさらいから始めよう。

 経営層に対してセキュリティ対策の必要性を訴求するには、「危険だ」と定性的に訴えるだけでは効果がない。経営層が意思決定をしやすいように「購買プロセスの5段階モデル」に従って必要性を訴求し、「各フェーズでそれぞれ何をすべきなのか」をしっかり説明することが重要だ。特に最初のフェーズである「問題認識」については、リスクを定量的に点数化して明確化することが欠かせない。ここまでが前回の要点だ。

 今回のテーマは、この「問題認識のフェーズにおいてどのようにリスクを点数化すればよいのか」である。今回の内容を把握することで経営層の説得に向けて大きな一歩を踏み出せる。その分、難易度が少々高いかもしれないがぜひ理解してほしい。

FMEAを応用したリスクの点数化

 リスクを点数化する方法はいくつかある。ここではFMEA (Failure Mode and Effect Analysis : 故障モードと影響解析) をベースにしたリスクの分析について解説する。情報セキュリティと相性の良い方法で、信頼性工学で使われている。

 FMEAには「リスクの定量化」と「想定外の防止」という大きく2つの効用がある。

 FMEAを使うと、危険度を「リスク優先度」という値で算出し、危険度を視覚的に分かりやすくすることができる。「どれくらい危険なのか」に対する認識のズレをなくし、定量的にリスクを分析する。これが「リスクの定量化」である。

 もう一つの「想定外の防止」もFMEAの効用だ。FMEAはシステムをその構成要素へ分解し、各要素に対して何が起こったらシステム的にどういった影響があるのかをボトムアップで考えていく。

.*..



 「情報漏洩対策」を例にとれば、普通は多くの方が「情報が漏洩しないようにするにはどうすればよいのか」とトップダウンに考えるだろう。これに対しFMEAでは各構成要素に対して発生する事象からボトムアップで考える。「クライアントがウイルスに感染したら?」「サーバーがハッキングされたら?」から始まり、「ここがこうなると最終的にシステムにはこういった影響が出る」という結論を導き出す。これでシステムに想定外の事象が発生することを防止できる。
後述の通り、もっと詳細にアプリケーション単位や、実行ファイル単位でのボトムアップを行うと結果の精度は向上するが、その分手間がかかることを意識しておこう。

 ここで気を付けてほしいことが一つある。抜け漏れの精度にこだわり過ぎないことだ。もちろん、抜け漏れのない精度の高い分析結果のほうが良いに決まっているのだが、この結果をセキュリティ対策の抜け漏れを考える意思決定材料とするのか、経営層の投資判断の意思決定材料とするのかで、抜け漏れの重要度は変わってくる。こだわり過ぎると時間ばかりかかってしまうので、結果の利用目的で精度の合格点を変えよう。

リスク点数化作業の流れ

 ではリスクを点数化する作業を具体的に説明しよう。大まかには次の3ステップとなる(図1)。


図1●リスク点数化作業の流れ


(1)ワークシートの作成
(2)システムを構成要素に分解
(3)ワークシートの各項目に記入

以降では例を挙げながら上記の3ステップを順に解説していく。

.*.



ステップ1:ワークシートの作成

 最初のステップはワークシートの作成である(図2)。今回は図3に示したワークシートを例として使用し、各項目を説明する。なお、実際に作成する場合は必要に応じて自社で使いやすいように編集してほしい。


図2●ワークシートの作成

図3●ワークシートの項目の例


「アイテム」
後述するステップ2で分解したシステムの構成要素についての記述

[アイテム名]
ステップ2で分解したシステムの構成要素の名前

[カテゴリー]
サブアイテムのカテゴリー



[サブアイテム名]

アイテム欄に記述したシステムの構成要素をさらに分解したアイテム名

「セキュリティ事故」
サブアイテムやアイテムに発生するセキュリティ事故についての記述

[内容]
セキュリティ事故の内容

[原因]
セキュリティ事故が発生する原因

[影響]
セキュリティ事故が発生した際にシステムなどへ及ぼす影響

「評点」
リスク分析の点数化のキモとなる部分であり、「発生頻度」「影響度」「防止困難度」「リスク優先度」をそれぞれ採点

[発生頻度]
セキュリティ事故が発生する頻度を点数で定義

[影響度]
セキュリティ事故が発生した際にシステムなどへ及ぼす影響を点数で定義

[防御困難度]
セキュリティ事故を防止することの難しさを点数で定義

[リスク優先度]
以下の算出式で求める。
リスク優先度=発生頻度×影響度×防御困難度




 発生頻度や影響度、防御困難度についてはまず点数の上限(満点)を決める。10点満点や4点満点などが使いやすいだろう。また、ファイルやデータベースといった情報資産に対する重要度があらかじめ定義されていれば、それらを参考に影響度を定義するのも一つの手だ。情報資産の重要度は4段階に設定している企業が多いことから、4点満点に落ち着くケースがよく見受けられる。これよりも細かく数値を定義すると、いざ事象を数値に割り当てる際に悩んでしまうという事情もあるだろう。

 点数の上限を決めると同時に、それぞれの点数に対する定義を決める必要がある。図4に、4点満点とした場合の「影響度」「発生頻度」「防止難易度」それぞれの定義例を示した。既に自社で何らかの指標を持っている場合はそちらを流用するほうがよいだろう。セキュリティ対策を検討する際の意思決定指標に統一感が出るため、分かりやすくなるはずだ。


図4●「影響度」「発生頻度」「防止難易度」の定義例





 ステップ1の最後はリスク優先度の算出となる。前述した算出式「リスク優先度 = 発生頻度×影響度×防御困難度」を使って求める。例えば「年に1回程度」発生するセキュリティ事故が、「防御が難しく」「基幹業務の停止」につながる場合、そのリスク優先度は36(=3×3×4 )となる。もちろん、数字が大きいほど優先度は高くなる。

ステップ2:システムを構成要素に分解

 次のステップは、システムを構成要素に分解すること(図5)。まずはサーバーやクライアント、無線LANアクセスポイント、ルーターといった大きな単位で、ざっくりと分解しておこう。さらに詳細な単位はワークシート上で別カテゴリーとして記述する(具体例は後述)。


図5●システムを構成要素に分解


 当然ながら、詳細な構成単位に分解したほうが精度は高まる。例えば「メモリー」「ハードディスク」といったハードウエア構成要素、「JAVA」「Excel」などインストールされているアプリケーション構成要素まで落とし込むといった具合だ。ただそうすると時間がかかるというマイナス面が生じる。全体の効率を考えれば、最初から全項目を詳細まで落とし込むよりも、注力する部分を絞り込んでから詳細に落とし込むほうがよい。

.*.



ステップ3:ワークシートの各項目に記入

 最後のステップがワークシートの各項目に記入することだ(図6)。ステップ2で分解したシステムの構成要素に対して、ステップ1で作成したワークシートの項目内へ記述する。クライアント端末について記述した具体例を図7に示したので参考にしてほしい。


図6●ワークシートの各項目に記入

図7●ワークシートの例





 既に気付かれた方もいるかもしれないが、このステップ3ではセキュリティ専門家の協力が不可欠だ。今回紹介したFMEAは分野を問わずに使われているが、例えばランプをフィラメントや口金といった構成要素に分解してインシデントを「フィラメントが寿命で切断」といった形で直感的に進めることができる。ところがITの場合、発生するインシデントやその原因が極めて多岐に渡る。特にインシデントが発生する原因については専門的な知識が欠かせない。それがないとかなり頼りないシートが出来上がってしまう。
従来のFMEAではランプにおけるフィラメント切断などの構造の破壊を「故障モード」と言う。ただ、この概念だけでITセキュリティへ全適用することは難しい。ITで使いやすくするため、図3や図6のワークシートでは項目名などを変更している。この手法を適用する場合は、自社で利用しやすいように項目を追加したり編集したりしてから利用することをお勧めする。

 図6のシートで言えば、「重要度高のファイル」が従業員に持ち出される経路として、USBメモリーのみが挙げられている。少し考えてもらうだけで、DVD/CD、インターネット上へのアップロード、メールに添付、自宅/オフィスへのVPN接続、ファイル共有ソフトなどの様々な経路/手法が思い浮かぶだろう。こういった経路/手法に関する知識は、言うまでもなく専門家が豊富な知識やケーススタディーを持っている。リスク分析の点数化を進める際にはぜひともセキュリティの専門家をプロジェクトに加えたい。

対策の方針

 ここまででリスクを点数化できたわけだが、その対策はどういう方針で考えればよいのだろうか。まずは算出したリスク優先度の高い順に項目を並べて、対策を練っていくことになる。ここでリスク優先度の算出式でパラメーターとして使った「発生頻度」「影響度」「防御困難度」を思い出してほしい。リスク優先度を下げるには、この3つのパラメーターを下げればよい。以下、順に見ていこう。
実際の対策としては、「発生頻度」「防御困難度」のパラメーターは二の次にして、まずは「影響度」のパラメーターで大きい部分をなくしていくというアプローチをとることがある。機密情報の漏洩など影響度の大きなトラブルが発生した場合、ビジネスに深刻なダメージを与えるからだ。



「発生頻度」
 ここでは脅威にさらされる頻度を下げる方法を考える。注意力の向上など人に依存した対策を考える場合はほとんどこのパラメーターに関係する。例えばメールの宛先間違いによる情報漏洩の発生頻度を下げるアプローチでは、2人以上で宛先を確認したり、メールに添付されている疑わしい添付ファイルを開かないように教育したりといった対策になる。

 ただし社外へ公開されているサーバーや社外からインターネット経由で接続している端末などがある場合、攻撃される回数を意図的に減らすことは現実的には難しい。大きな構成変更や業務フローの変更を伴うことがあるからだ。そのため、このパラメーターを向上することで対策強度を高めるよりも、以降の「影響度」「防御困難度」の観点から対策を強化するほうが得策だ。

「影響度」
 セキュリティ事故が発生した際の影響度合いを下げる方法を考える。分かりやすい例としてファイルの暗号化がある。図6に示したワークシートの中にも記述があるが、重要度の高いファイルが平文で流出した際の影響は非常に大きい。解読しない限り中身を読めない暗号化ファイルが流出したとしても影響は抑えられる。

 最近では高度化された攻撃やターゲットを特定した攻撃が増えているため、「発生頻度」や「防御困難度」からのアプローチが難しい局面が少なくない。セキュリティ事故が発生することを前提にその影響度を小さくするというアプローチは、費用対効果の高く現実的な解の一つとなる。

「防御困難度」
 ここではセキュリティ事故の発生につながりかねない脅威に対する、防御強度の向上方法を考える。現状の対策に抜け漏れが多く、十分に対策ができていない場合はこのパラメーターの向上は比較的容易である。脆弱性を狙った攻撃の多くは、当該のプログラムのバージョンを最新のものに更新するだけで防御困難度を高められる。このパラメーターの向上を検討する場合はしっかりと情報収集して対策に取り組みたい。



 ただし防御困難度を向上する方向で対策を検討するのか、発生頻度や影響度を下げる方向で対策を検討するのかは、意思決定の難しいところではある。特に、標的型攻撃で使用されるウイルスのようにサンプル数が極端に少なくウイルス対策ソフトでの防御が難しい脅威に対してはなおさらだ。多くの企業では「影響度」「発生頻度」を下げる対策の検討が十分ではないケースが散見される。こういったケースでは、「影響度」や「発生頻度」を下げるほうが費用対効果の高い対策をとれるだろう。

 先回と今回の内容を通じて、「危険だ」と言うだけでは経営層には伝わらないことを理解してもらえたのではないだろうか。経営層に投資の意思決定をしてほしいのであれば、プロセスに従った提案を行い、リスクを定量的に示す必要がある。リスクの点数化とコトラーの購買プロセスの5段階モデルに従ったシステマティックな提案が、よりよいセキュリティ投資の意思決定の一助となれば幸いである。

蔵本雄一(くらもと ゆういち)
日本マイクロソフト ビジネスプラットフォーム統括本部
前職でアンチウイルスソフトの開発などに携わり、2005年、マイクロソフト株式会社(現・日本マイクロソフト株式会社)に入社。以来、セキュリティエンジニアとして、主に大規模な顧客環境のセキュリティ向上活動に従事している。プログラミングやハッキングといった下流の技術要素から、情報セキュリティ監査やコンサルティングなどの上流要素まで幅広くカバー。教育、人材育成、記事執筆、セミナー講師などの活動を通して、情報セキュリティの普及に携わる。筑波大学非常勤講師、日本CISO協会 主任研究員、公認情報セキュリティ監査人、CISSP。

.*.

この記事も面白い。 

.*.

ムダだらけのセキュリティ投資を防ぐ4つのポイント
2013/12/26
蔵本雄一=日本マイクロソフト (筆者執筆記事一覧

.*.

<必ずお読みください>

◆コメントについて

内容見直しの機会としてコメント可能としています。但し、採否・削除は勝手に行いますので予めご了解ください。

◆注意事項

当ブログは独断と偏見を排除しない私用目的のものです。不適切な内容を含む可能性がありますので注意してください。

組織・個人・商品・サービス等について固有名詞が引用されますが、関連考察は誹謗中傷を意図したものでは有りません。また内容の真否は一切確認しておりません。鵜呑みにしないでください。

記事は同じような内容が繰り返し記載されたり、矛盾することが記載されたりします。事実誤認もあります。これらの修正は必ずしも行うものではありません。

◆禁止事項

ブログ訪問者は直接閲覧すること以外の行為は遠慮してください。ブログ内容の一部または全部に関わらず、印刷、コピー、ダウンロード、保管、編集、利用、及び他の人への紹介・情報提供等を禁じます。

2004/04/01

人気の投稿:月間

人気の投稿:年間

人気の投稿