Rick Wash and Jeffrey K. MacKie-Mason,
Incentive-Centered Design for Information Security,
HotSec'06: 1st USENIX Workshop on Hot Topics in Security
論文は以下のURLから取得可能
http://hdl.handle.net/2027.42/49505
以下は走り書き
◆ Abstract
- 人間はシステムにおけるSmart componentである
-- よって、その振る舞いを直接プログラムすることはできない
-- それを問題視するのではなく、むしろその自律性は設計要件として尊重されるべきであり、システムが望むような行動をするように動機付けすることが重要である
- しかしその動機付けを誤ると、システムの欠陥となり攻撃者に攻撃される脆弱性を生むこととなる
- Incentive-centered designとはこのような問題を理解し、その問題を軽減するような設計原理を与えることにある
- この設計手法がセキュリティ問題に対して有効であることを示す (screening model)
◆ Introduction
- motivated behavior: 動機付けの結果として得られている行動
-- パスワードをスクリーンに貼付ける
-- パッチを当てない
-- botnetのzombieになる
-- criticalと書かれたpatchしかあてない
- これらはmotivated behaviorの一種
- Incentive-Centered Design (ICD)
-- incentiveをユーザに与えることによって、システムの効率を改善するような振る舞いを行うように導くことを考慮する設計手法
-- ICDは具体的な設計指針を与えることに注力しているという点で他のeconomics of security(セキュリティの経済学(?))とは異なる
- 多くのICD研究は情報セキュリティにおいて以下の二つの問題に焦点を当ててきた
-- getting the good stuff in (望ましい行為が行われるように)
-- keeping the bad stuff out (望ましくない行為はしないように)
- 良い行いによって他人に発生した利益が、まわりまわって自分に埋め合わせされない...という状況
-- worm-throttleという仕組みがその一例．そのシステムはネットワークの境界に設置し、自身のsubnetに感染したwormが他のnetworkに感染しないようにする仕組み(と推測)
--- ということは、自分たちにメリットがあるわけではなく、自分以外の人たちにとってメリットが発生するシステム．よってシステム管理者はその導入を能動的には行わない
- ある人の行為によって他人に迷惑がかかるが、それによって迷惑を被る側に直接的なコストがほとんど発生しない場合
-- spywareは感染者に大きなコストをかけるわけではない(若干のCPUサイクルとnetworkリソースを使うだけ)、もちろん自身の個人情報が危険に晒される可能性はある．しかしspywareを流布する側にとっては、spyware自体が他の計算機に感染したり、個人情報を暴露することについてはコストがほとんどかからない
-- どうやったらこのような行為に対し、行為者にコストをかけられるようにできるのだろうか?
-- "良い行い"をシステム管理者が進んで行うようにするためにはどのようにシステムを設計すべきか?
-- 悪い行いを攻撃者がしないようするためには、どのようにその行為に対してコストがかかるように設計すべきか?
- ICDの目指すところはこのような振る舞いに対するincentiveを見つけ出すこと
◆ Incentive Problems in Security
◆ Getting the Good Stuff In
- (Labeling Vulnerabilities) 脆弱性のランク付け:
hidden information問題の一例．ベンダーは問題の詳細を把握している．しかし、それを正確に公開することは、製品に対する悪評判になるとともに、ベンダーに対してコストを発生させることになる．これは正直に申告することによって埋め合わせされるのかもしれない．しかしそのトレードオフゆにえ、ベンダーは脆弱性の緊急性を過小評価して発表することがある．
ICDの視点としてできることは、より詳細に脆弱性を発表し、ラベル付けをすることによってベンダーにもincentiveを与えることのできる評判サービスの設計であろう．
- Knowledge Worker
Principal agent問題の一例．雇用主と社員との間で生じる興味の違いに発生することがある問題．
知識労働者に対するincentiveは十分に注意を払う必要がある．
hidden action問題もある．セキュリティにおける望ましい行為というのは、その検証が難しい．よってそういった行為に対してincentiveが払われるのではなく、そういった行為につながる観察可能な行為(proxyの利用といったこと)にincentiveが払われてしまう．
ボーナス査定がセキュリティの問題を発見することより、プロジェクトの工期内での完了の方に重きがあった場合、誰がセキュリティ問題の指摘に奔走するだろうか?
- BotNet:
botnetに感染され、悪用されたとしても、悪用されているコンピュータユーザが困ることはほとんどない．
あったとしても少しシステムが不安定になるかネットワーク回線の反応が悪くなるだけで、それは他の外的要因のせいだと思い込める程度である．またそれを検知し、駆除することに対してメリットはない．むしろbotnetを検知した結果として必要となる作業(Operating Systemの再インストール)などを考えると、その方が負担が大きいと言える．
Botnetの攻撃により被害者となってもユーザが被るコストはほとんどない．
private provision of public goodsという問題．
これはシステム管理者が外部ネットへのワーム感染防止措置を行うことに対して、その動機がないのと同様の問題．
公的に良いと思われる行動を個々人に動機づけるために設計として何ができるのか? という問題
- Privacy-enhancing technologies:
プライバシー保護の目的で匿名性を与えるシステムは、多数の中継サーバにより成り立っている．
もちろんそのためには、自ら中継を進んで名乗り出るノードが多数必要になるが、これもその行為に対するincentiveがない．それどころかネットワークリソースをそのために提供し、かつそれ以外のリスクを被る可能性もある．
それゆえただ乗り(free-ride)の人が多くなってしまい、中継ノード不足になってしまう
◆ Keeping the Bad Stuff Out
- Spam
典型的なhiddden information問題．
spamかどうかを隠蔽し、技術的/人為的フィルタをかいぐぐらせ、受信者にメールを読ませることができる．
E-mailはbackdoorの一つでもある．E-mailを経由してvirusやtrojanが運ぶことができるから．
- Spyware
悪意のあるインストールプログラムは、まさにhidden action問題．
設計における対応策としては、期待していない振る舞いを発見したら、それを把握しておけるようにするか、incentiveによって望ましくない振る舞いを選別できるような仕組みの提供である．
それにより正規ユーザはその行為を不正なinstallerによるものと区別できるように操作するようになる．
◆ Screening
- keeping bad stuff out問題の1つは、
- 誰かがリソースを持っている
- ユーザがそのリソースにアクセスする権利を持っている
- が、それが正規のユーザか悪意のあるユーザかが見分けられない
-- ユーザが正規ユーザと悪意のあるユーザを知っているのなら、それはhidden information問題
- ...
◆ Discussion
- セキュリティ問題の多くは、少なくともそれを解決することについてユーザに対するincentiveがないという問題を抱えている
- 鍵となる洞察は、人間の振る舞いにある．
- 制約は問題を改善しない．ユーザに目的を持たせ、その目的を達成するために必要な振る舞いを選ばせるようにすることが重要
- これまでの情報セキュリティ対策は、悪いことをしないようにすること(Keep the bad stuff out)ばかりであった
- しかし、get the good stuff inには失敗している
- passwordはいい例．推測攻撃に強い長くて複雑なパスワードを使うことに対するincentiveは不十分
- それだけではなく、これからはさらにユーザが望ましい行為をするように動機付けのできるシステムが必要になってくる．
- 今後の課題は、"getting the good stuff in"問題のモデル化である．それによりこの種の問題に対する設計原理を提案する
◇ コメント
- 概念(思想)はよく理解できる
- これはSecurityに限らない気がする．公衆道徳や犯罪対策などにも適用できることではなかろうか?
- よく言われることだが、攻撃者にとってその作業は大変だが、正規のユーザにとっては簡単であるべき．
CAPTCHAはそれを既存のシステムよりもよりよいレベルで体現した例と言えるのでは
(人間にとっては簡単だが、攻撃botにとっては困難)．
- これを設計段階でうまく取り入れられるようにすることが大切という理解．
- 個人的には、How toが欲しい．定説がないだろうにしても、サンプルがあってもいいかなと....