TALC: Using Desktop Graffiti to Fight Software Vulnerability,
Kandha Sankarapandian, Travis Little, W.Keith Edwards,
Proc. of the 26th annual SIGCHI conference on Human factors incomputing (CHI 2008), 'Am I Safe session', pp.1055-1064, (2008).
ACM Digital Library
簡単にいうと、自身が使っている計算機内に未パッチのソフトがあるかどうかをDesktop Imageに落書き風の文字で示すことで気づきを与える．という論文．TALCとはfor Threat Awareness, Learning and Controlの略．
パッと見た時は「それだけ?」と思ったが、読めば読むほど、なるほどな〜と読めるよい論文．興味のある人はぜひ論文中の図1を見ていただきたい．同じようなことを考えていただけに刺激になる論文でした
以下は、内容に関する走り書き
◆ Abstract
- ホームユーザにとって既知のソフトウェア脆弱性を知り対策をすることはまずます重要に
- しかし既存のup-to-dateはホームユーザには難しい
- TALC: ホームユーザがパッチを当てる作業を支援する
- パッチを当てる動機付けを与えるための"気づき"を与える
- 未パッチのソフトを探索し、その脆弱性に応じたいたずら書きをデスクトップ画像に描画
- ホームユーザはパッチを適用することでいたずら書きをきれいにする
◆ Introduction
- OSや種々のアプリケーションには様々な脆弱性があることは知られている．これらの多くはその修正方法が既に存在するにもかかわらず、多くのユーザはその存在や修正方法を知らない
- FirewallやAntiVirusを導入したとしても、ソフトウェアへのpatch適用はきわめて重要 <= Symantec
- 現状においては、OSだけでなく自身の計算機内に存在する全てのアプリケーションのパッチ適用もユーザの責任
- 種々の方法によるパッチ適用手段の存在がユーザによるパッチ適用を困難にしている
- 複数のベンダーやOSにわたったパッチ管理手法(全体論的なパッチ管理)がない
- まず、適用すべきパッチが存在することを気づかせる「気づき」を与える必要があるのでは?
- TALC: for Threat Awareness, Learning, and Control
- 出しゃばらず、一貫して視覚的なリマインダとして「気づき」を提供し、そのパッチの適用を促す
- そして対象とするソフトウェアに依存しないより簡単なパッチ適用の手段を提供する
◆ Related Works
- パッチ適用の改善を目指したシステムは、ベンダー特定のものかエンタープライズ向けしかない
- Windows UpdateやMac OS X software update: OSだけが対象
- ユーザが介在する必要なしにパッチを適用できるシステムは楽である一方で、ユーザが学習できないという欠点もある => 気づかせることが必要
- 自動でパッチを適用してしまうと、他のソフトウェアに悪影響を与える可能性もある
- やはり気付きが大事、脆弱性のあるソフトウェアが存在すること、そのパッチ適用による利点と問題点もユーザに通知した上で、パッチ適用の判断をさせるべき
- 対話的なツール => うっとおしく感じるようになる => Swich Offにしてしまう (すでに証明されている事実)
- しかし即座の判断が必要でないものであれば、対話的であっても良いという提案"attention manager"もある．文献[1]
- ということは、second taskとしてユーザとの対話性を持ちつつ、でもそれを完全に無視しないように十分な説明は必要だ
- エンドユーザには「対話性」と「積極性の導出」のバランスがとれたシステムが必要．そして過度の注意を必要としたり、集中している作業への集中を阻害しないような工夫が必要=>"calm notification"．pop-upはうっとおしとユーザに感じさせるためダメ
- TALC: エンドユーザ向け、システム全体に渡ったpatch適用喚起システム、
◆ Description
- 未パッチの存在をデスクトップ上の"落書き"として提示．=> low-distractionアプローチ、constant, but gentle reminder
- 1つの脆弱性に1つの落書き．デスクトップ上の表示位置はランダム．
- 落書きの大きさは、その脆弱性の重大さ(severity)を表現
◆ Why Graffiti?
- 何故、いたずら書き => 多くの文化において、落書きは腐敗や脅威を伝えるものであると認識されているから
- 自分の好きな画像の上にいたずら書きが出現したら、多くのユーザはどうにかしようと思うだろう => patch適用の動機付け
- 他の視覚化表現も試したが今ひとつだった．
-- 弾痕: 暴力的すぎる、単なる脆弱性ではなく、活発な攻撃活動を連想させる
-- ゴミやがらくたの山: 腐敗(脆弱性)の表現としては適切かもしれないが、無視してしまいそう
◆ Determining and Presenting Vulnerabilities
- どうやって脆弱性があることを検知しているのか?
1. システム監査でインストールされている全ソフトウェアのバージョンを収集
2. NIST NVDデータベースを参照し、パッチの存在するソフトウェアの存在を確認
- 落書きの上にマウスカーソルがきたら、その脆弱性の詳細を表示
- 脆弱性の詳細はheuristicな方法により、簡潔な表現にする => home user向け
- わからないにしても、周囲の詳しい人に質問できる体制作り => 学習支援
◆ Repairing Vulnerabilities
- patch適用支援もする．
- 落書きをマウス右クリックし"fix the program"を選択すると、patchダウンロード先のWebページか対処を指示したWebページが開く
- TALCはpatchの在処を見つけるまでを支援．実際の適用作業は2つの理由によりユーザにまかせている
1. あまりにもバリエーションが多く、すべてのpatch適用作業の支援は困難
2. patch適用が適切かどうかはcontext依存．やはりユーザの判断をへた上で適用すべき
◆ Implementation
- 4つのモジュールによる実装．モジュール構成になっているので拡張は容易
- 以下の4つのモジュールがCommunication Managerによって関連づけられる(message passing)
- Information source Module: 計算機、ネットワークそしてプロセスからのイベントを検出し、XMLとして記録
- Correlation Module: Information source Moduleから得られた情報とNVDからの情報の関連付けを行う
- Visualization Module: 視覚化処理担当．落書きの他、ゴミ溜め表示そしてpop up表示も可能
- Control Module: ユーザの操作に対応する．patchのdownload、Webページを開くなど
◆ Evaluation
- 気づきの効果、patch適用作業への動機付けができるかを評価
- 2週間ユーザに使用させ、その間の操作を記録．使用前と使用後にアンケート調査
- 被験者は大学とは関係のない人を採用
◆ The Participants
- 10人が実験を完了、7人が実験を開始したものの、いくつかの理由により実験を辞めた
- 年齢層は23-35歳、平均は26歳．実験を完了した被験者は男性6名、女性4名
- 被験者が少ないが、実環境での評価を行いたかったためこうなった
◆ The Pre-test Questionnaire
- オンラインで実施
- 3+11+8の質問
◆ The Study
◆ The post-test questionnaire
- オンラインで実施
- pre-testと同じ内容の質問+13のTALCシステム関連の質問
◆ Results
◆ Events tracked
- 記録されたログから、イベントを5つのカテゴリに分類
- Awareness: 脆弱性を発見し、表示をし始めた
- Learning: 落書きをclickした、脆弱性の内容を見た、vendorのWebサイトを開いたなど
- Control(Fixed): patchを当てて、修正し、menuで"Already Fixed"を選択した場合
- Control(Ignore): Ignore buttonを押した時
- Re-appear: patchを当てたと申告したのに、再びその脆弱性が発見された場合
◆ Usage Patterns
- 多くのユーザは落書きが表示されてから2日以内に対処
- 60%は2日以内にpatchを適用したが、39%はまだ無視していた (後日に適用?)
- 気づきの効果はあるようだ．脆弱性の詳細をWeb検索で探すという行為がかなり見られた
- patch適用は数日毎に実施する傾向がある．=> 意図した通りにユーザを誘導できている(?)
- patchを公開しているWebサイトの説明が、patch適用の気をそいでしまう場合も多い
◆ Discussion
- ツールの有効性: 安全という感覚が増したか? そして実際の安全性が向上したか?
- 後者を重視、前者は目的に対しては実質上何の意味もないから．
◆ TALC Effectiveness
- 結果、その効果は明らか．patchの存在に対する気づきとその適用に対する動機付けができている
- ただしpatchを適用された脆弱性の数が多いように感じられる．これは1つのpatchで複数の脆弱性が修正されたためかもしれない
- 実験開始時には、平均で47.6個もの脆弱性を発見．最小は5個、最大は64個だった
- 全ての脆弱性にpatchを適用したユーザは一人もいなかった
- 482個の脆弱性が未パッチのままだったが、そのうちの208個は重大な脆弱性、88個が中程度の脆弱性、186個が脅威の度合いが低い脆弱性であった．
- 半数(50%)のユーザが、securityにおける修正は難しい作業だと回答．NVDのwebサイトのユーザビリティが低いため? NVDに掲載されている対応情報へのリンクが切れている場合もあった
◆ User Perceptions
- 33%のユーザがTALCの通知はうっとおしくないと支持．しかし、これは残りの多数のユーザが通知のうっとおしさに問題を感じていないということにもなる
- TALCをoffにしたユーザは、システムが遅くなったように感じたからと理由をあげた
- 7人中4人が感覚的な安全性が向上したと回答
- 実感としての安全性を向上させたとは言いがたいが、それまでは何の脆弱性にも気づいていないことを考えれば大きな前進であると考える
◆ Future Work
- near-term: TALC frameworkの拡張と大規模ユーザでの評価
- Vendorのwebサイトの解説記載の複雑さ=> patch適用処理をTALCに統合したい
- 別の抽象化された脆弱性情報Webサイトが必要
- patchのない情報の表示をfilteringする仕組み
- 他のセキュリティツールの機能を情報収集の機能として統合したい(Nmap, Nessus)
◆ Conclusion
- 即座にしなければならないものではないタスクの通知/動機付けにおいて、awarenessとannoyanceのバランス問題に対する一つの回答
□ 気になる参考文献
9,10,15,27,30
□ 若干気になる参考文献
1,18