Research Survey and Memo

やはりセキュリティは人なり

これらの本を読んだ．「追跡! ネットワークセキュリティ24時 (1 / 2)」だ

技術的にどうこうという本でなく、実際に起きたインシデントをフィクション化した本なのだが、こういう実際の話を知る機会のない自分としては、非常に刺激的な本でした．

セキュリティは、技術で対応/対処できることも少なくありませんが、それ以上に人間系の処理(?)が多いこと．極論すれば、「セキュリティ対策において技術でできることなんでほんの一部」だと．それは口で言うのは簡単なのだが、この本にある話を読むと、「本当にそうだな〜」と妙に感じ入るばかりです．

「システム管理者の眠れない夜」1 | 2 | 3と同じ系統の本で、技術的な内容はほとんどなく、いわゆる読み物として読めるので、セキュリティになんらかの形で関わる人には、是非読んでいただきたい本だと思います．

いや〜、現時点では、システム管理者もセキュリティ管理者も本当に報われることの少ない仕事だと思います．少なくとも、何も起きなくて当然．つまり、その維持のために多大な努力を払っていたとしても、けっして褒められることがない．そのかわり(その上)、何か起きると、管理者の責任にされ、責められ、対応に365日24時間を問わず追われることになるという悲しい職種と言わざるをえません．少なくとも、将来的にはもっとその地位が向上することを個人的には願わんばかりですが、昨今の成果主義に照らすと成果として目に見えるものが出しにくいので、本当に厳しい職種と言えます．なんとかならないものかなぁ．ITインフラは一度導入したらメンテナンスフリーではなく、かつ世界中の敵と日々戦っているのは、まさにこれらの戦士(?)なのにな...

Paper: Command Line or Pretty Lines? Comparing Textual and Visual Interface for Intrusion Detection

Command Line or Pretty Lines? Comparing Textual and Visual Interface for Intrusion Detection
Ramona Su Thompson, Esa M. Rantanen, William Yurcik, Brian P. Bailey
Human Factors in Computing Systems(CHI2007), pp.1205 - 1214
ACM Digital Library

IDSの解析のためのインタフェースは、コマンドラインによるツールと情報視覚化によるツールのどちらがよいかをユーザ評価により検証した．その結果、現時点ではコマンドラインツールの方が好まれるという結果となったが、今後は、この双方が融合されたインタフェースが必要になるであろう．という論文

以下は論文内容のメモ書き

- Incident Analysis or Intrusion Detection作業は、次の4作業に分割
1. プリプロセス
2. ネットワークの監視
3. 攻撃の解析
4. 発見された攻撃への対応

- いまだもって専門家の知識とスキルに高度に依存した作業
- Visual Interfaceが提案され始めている
- Visual Interfaceがよいのか、それとTextual Interfaceとの比較がない
- 被験者による評価実験が行われていない．だから実施した
-- 結果としては、Textual Interfaceの方がよい結果(好まれる)という結果になった
- が、今後はVisual+Textual Interfaceが望ましいと考える

■ User Study
- ユーザ評価をした
- 2種類のInterfaceで比較
-- Textual Interface (Command-line interface)
-- Visual Interface (VisflowConnect)
- Netflowのデータを解析
- 対象データにはP2Pのログ、portscan、そして攻撃なしのデータを利用した
- 12(students)+2(expert)の合計14人の被験者 (年齢は18-over 40)

○ Time on Task
Textual Intefaceの方がVisual Interfaceよりも早かった

○ Total Number of Commands used
Visual Interfaceの方がTextual Interfaceよりもコマンド発行回数は多い
Textual Interfaceの方は柔軟にデータの絞りこみができるが、Visual Interfaceの方は>
そうはいかなかった

○ Accuracy
1. 攻撃があったことを認識できるか?
2. その攻撃の種別を判定できるか? の二点で測定

◎ General Identification if an Attack occurred
攻撃の認識に関しては、VisualもTextualも同様で差はなかった

◎ Specific Identification of the Attack
Textual Interfaceの方が優位
- 詳細まで調べられれば判定ができるが、Visual Interfaceでは推測までしかできない

○ Confidence
Textual interfaceの方が判定に確信が持てる．
詳細まで調べられるほど、その判定に確信を持てるようになるから

○ Discovery of Other Problems
Visual Interfaceの方が優位．気づくきっかけを与えられる

○ Rating of Preference
- Visual Interfaceを褒めるものの、どちらかというとTextual Interfaceを好む
- いろんな理由で双方のInterfaceを好んでいるが、現状ではTextual Interfaceを好むと
いう人の方が優位

■ Discussion
- インタフェースの様式(modality)は、ユーザの情報処理能力に影響する
-- どちらのインタフェースでも異常な振る舞いの存在には気づくが、Visual
インタフェースの詳細情報へのアクセス不能性は、攻撃の種類の判定を困難にし
結果として結果への確信度やユーザの好みに影響を与えることとなる
- パターンの認識(networkの正常利用の状況)などはVisual Interfaceでないと
認識不可能．Textual Interfaceでは認識が困難な異常を認識可能

■ Strengths and Weaknesses of each Interface
□ Textual Interface
○ 長所
- 詳細情報を直接アクセスできる
- 強力なフィルタリング機能により、データの見方を制御/カスタマイズできる

○ 短所
- 異常をしめすパターンの検知は困難
- コマンドの利用法を体得しなければならない

□ Visual Interface
○ 長所
- 概観がわかり、平時の状況が把握しやすい
=>異常時との見分けがつきやすい
- 目立つ(異常?)部分が見分けやすい
- 未知の攻撃発見を可能にする
- 簡単に使える

○ 短所
- 詳細が不明/詳細情報にたどり着くまでが面倒
- 対話処理に柔軟性がない/特定の方法を押しつける
- 認識の困難なある種の攻撃は視覚的表現では検知できない

■ A Hybrid Interface: Combining the Textual and Visual
効果的なインタフェース => これら二つの融合
初心者にも経験者にもメリットのあるIDS用インタフェースに

■ Conclusions

我々の貢献は、以下の3つである

1. 2つのインタフェースによるIDS作業のユーザ評価を行った
2. それぞれのインタフェースの利点/欠点を明らかにした
3. 今後望まれるインタフェースの要件を明らかにした

Article: Authentication in Transient Storage Device Attachments

USBメモリを紛失したりして情報漏洩につながる事件は、今をもって後をたちませんが、USBメモリーやメモりカードにおける技術的対策も進んでいるようです．まだ標準化のみにとどまっているようですが、現実世界での状況をかんがみると、一つの手段として有望だと思われます．

Donald Rich, SanDisk Corp.
Authentication in Transient Storage Device Attachments,
pp.102-104, Computer, IEEE, April 2007.

IEEE 1667という標準化の策定が進んでいるそうです．一言で言うと、USBメモリやメモリーカードといったTransient Storage Deviceとそれを接続して読み書きをする機器との間の認証に関する仕組みだそうです．

想定されているのは...

- 会社の特定計算機につないだ時のみ、USBメモリー内の内容を見ることができる
- 個人のデータは会社以外の計算機につないだ時のみ見ることができる
- このメモリーカードは、自分のデジカメでのみ機能する

などだそうです．

無線LANアクセスポイントの"所有者が意図していない"使われ方に関する違和感

うまく頭の中で整理できないでいたのだが、この3つの記事を見て「あ〜、モヤモヤしていたのはこういうことだったのかもしれない」と思った.

■ PlaceEngineのプライバシー懸念を考える
高木浩光＠自宅の日記

■ 草の根無線LAN「FON」のセキュリティ問題は解決できるか
ITPro
■ FONはどれだけ使える? セキュリティには十分注意を
ITPro

どちらにも言えることは、無線LANのアクセスポイント情報が、その所有者の意図しない利用法で第三者に使用されることであり、それがセキュリティやプライバシーの侵害になる可能性がないとは言えない．ということである．そして、このような問題に対する法律は、まったく調べていないが、多分、推測するに「ない」のではなかろうかと想像する．

仮に法律があったとしても、技術的にできてしまう以上、誰かがやるだろうことは自明であり、それは法律ではどうにもならない．技術的になんらかの対策がないのか? と思うのだが、現地点ではどちらの場合も技術的に対策をするのは難しいようで、知る範囲では有効な技術的対策はないようだ．これはゆゆしき事態だと思う．

「無線LANの情報は、誰でも取得できてしまう．だから、第三者が利用してもよい (PlaceEngine)」という主張はやはりどうかと思う．なぜなら、それを応用して、利益を得る可能性もあるとした場合．その無線LANアクセスポイントの情報を提供している人に対してなんのfeedbackもなくてよいのかという議論は当然出てくるであろう．そうしたことに対する回答が利用者と提供者側で共通認識としてないのではなかろうか?

また無線LANのログとプライバシー問題も残されており、それに対する解決法は、多分提供者側によって一義的に決められるものではないであろうと推測する．現にこの種の研究をされている河口先生も「どう乗り越えたらいいんでしょう?」と回答に苦慮されているようである．
(詳細はこちら: 研究とビジネスのコラボが始まるか? - PLACE+)

また「誰でもご自由に御利用ください! という無線LANアクセスポイント: FON」 にも落し穴(問題)がないわけではない(詳細はこちら)．
もちろんだが、ある日、突然警察に踏み込まれて、計算機一式を押収されるのは誰だって困るはずである．またFONの場合には、その上流回線をISPと契約して使用している回線の場合、ISPの契約上の問題も発生する恐れがある(契約者以外の通信にその回線を利用することをは許容されないであろう．そういう契約がまだ多いのではないだろうか?)．これもまだ明確な答えがでていないと思われる(回線を通る通信が契約者によるものか、そうでない人の通信なのかが判別できないためと推測する)．

なお、この法治国家である日本で、その程度で警察が踏み込んでくるはずないだろう? なんて思っている人は考え方が甘いかもしれない．警察もサイバー犯罪に対して手をこまねいているわけではない．最近でもこんなニュースがあった．

日本通信、「bモバイル」製品に本人確認システムを導入
http://plusd.itmedia.co.jp/mobile/articles/0705/15/news127.html - ITmedia
日本通信、「bモバイル」で本人確認システムを導入
http://k-tai.impress.co.jp/cda/article/news_toppage/34469.html - ケータイwatch

これは、bモバイルが匿名での通信を可能にしてしまっているので、警察から「どうにかしなさい!」と協力要請(?)があり、結果としてこういう仕組みを導入することになったというニュースである．

なんにせよ、無線LANアクセスポイントの所有者が意図した通りだけの利用ができるよう「技術的対策または手段」が用意されることが望ましいと強く思う．FONの場合は、FONとプロバイダのログを付き合わせることで、本当に悪事を働いたユーザを特定可能にする．と、言っているが、FONの登録情報が本当に正しい情報であるか? また、FONの認証情報といっても、ユーザを複数(多数?)作ってしまえば、ある一定レベルの身元隠蔽ができてしまうのではないか? など、いろんな意味で疑問点は残る．

「セキュリティに完璧はない」のは常識であるが、なんの技術的な対策もできないのは問題であろう．どうにかしないといけない

悪さをするBotに興味があるなら必読か? - USENIX HotBots'07

悪さをするBotやBot-netに興味があるなら、是非とも読んでおくべき論文だと思います

HotBots'07 - First Workshop on Hot Topics in Understanding Botnets - USENIX

発表された論文は、無料で以下のWebページから入手可能です
http://www.usenix.org/events/hotbots07/tech/

なお発表された論文は、すべて招待論文だそうです．
なので研究論文という期待はあまりしないほうがいいかもしれません．が、示唆は得られると思います

時候ノ情景 - Chronicle Album 公開

Mac OS Xで利用できるiPhotoに登録している写真を、iPhotoで見るよりも気軽に見られるようにしたいという目的でDashboard Widgetを作成しました．
名付けて「時候ノ情景 - Chronicle Album」です．

その名の通り、写真に付与されている日時を写真の閲覧でも活用できるようにしたシステムです．また当初の目的通り、iPhotoを起動するよりも手軽かつ高速にiPhoto内の写真をブラウジングすることが可能です．

Mac OS XユーザでiPhotoを利用されている方は、是非一度お試しください
詳細は、以下のWebを御覧ください
時候ノ情景 - Apple Dashboard Widget

実は、少し前から公開はしていたのですが、ここには書いていなかったので、宣伝もかねて、ここにも書いておくことにする

# Appleのサイトには掲載されている こちら

Paper: Sharing motion information with close family and friends

Sharing Motion Information with Close Family and Friends,
Frank Bentley and Crysta Metcalf,
Human Factors in Computing Systems(CHI2007), pp.1361 - 1370
ACM Digital Library

Motion Presenseアプリケーションの提案．携帯電話の電話帳のようにユーザ名がリストとして表示されているのだが、各ユーザの横にそれぞれの「移動状況」を表示できるようしたというもの．親しい間柄でのプレゼンス情報共有を目指したものである．これを10人のユーザで二週間にわたりユーザ評価を行った．その結果、移動状況から場所や行動の推測などが可能であったことがわかった．またプライバシーの懸念を示す人もいたが、このアプリケーションの利用後にはそれほど気にしなかったという結果を得た．

以降は論文内容のメモ書き

■ Introduction
- より簡単に、かつよりわずらわしくない方法で人々をつなぎ、状況を知らせたい．
- GSMのCell IDを利用し、移動しているかいないかを判定、その情報を共有する
- ある程度のあいまいさ加減がプライバシー問題を回避可能にする
- 状況は "moving(10)"という形式で、移動しているか否かと、その状態での経過時間が格外等ユーザの隣に示される(単位は分)
- そのユーザ名から直接電話やSMSの送信が可能

- フィールド評価をした
- 評価項目は以下の5つ
1. 親しい間柄では、motion presense情報は移動状況以外の何かを推測するのに使われるか? もし使われるのならば、何の推測に使われるか?
2. 電話やメールをしようとする際に、通信相手の移動状況はなんらかの影響をおよぼすか?
3. 連絡相手の移動状況は、連絡をとろうとする際の連絡手段選択になんらかの影響をおよぼすか?
4. 移動情報の正確さが、アプリケーションの価値にどのように影響するか?
5. 親しい間柄では、どんなプライバシー上の問題が起こりうるか?

■ Related Work

■ Methods
- 二週間にわたる実験を二回実施
- アプリケーションが動作する携帯(Motorola A780)を渡し、通話をSDカードに記録させた
- アプリケーションは、自身の利用状況を記録、毎晩、指定先に電話をしてもらい、motion presenseアプリをどのように使い、かつどのように対応したかを残してもらった
- 実験終了後にインタビューを実施．インタビューはSDカード内の通話内容に応じてカスタマイズ
-- 体験したこと、推測したこと、アプリの利用による反応などを質問

■ Implementation
- SMSによる状態通知を利用したP2Pシステムとして実装

- Motorola A780, E680iを対象
- 移動状態を検知するdaemon(Motion Presense Daemon)とJ2MEによるユーザインタフェース(Motion Presense App.)から構成
- daemonはC++で実装．Linuxのdaemonとして携帯電話の起動と同時に起動し、バックグラウンドで動作しつづけ、移動状態を検知すると共に、状態通知メッセージの送受を行う
-- 移動状態が変化したら、SMSメッセージをリストアップされているユーザに送付する
-- メッセージを受け取ったdaemonは、それをファイルに書き出す．またすべての状態変化をログに出力する

- Javaアプリはユーザインタフェースを提供．daemonによって記録されたファイルを読み、画面に提示すると共に、各ユーザに対してSMSまたは音声通話をすることができる
- ユーザリストの一行目は自分自身の状態を表示．共有されていることを意識させ、かつアプリが正常に動作していることを示すため
- すべての操作はログに記録される
- 課題: バッテリーのもち．SMSの配送、ユーザリストが大きくなるとSMSの配送が困難に．

■ Findings
- ユーザは、移動状態と対象ユーザに関する知識からいろんな推測をしていた
- 移動状態というあいまいな情報でもユーザにとって有用であるように思われる

□ What was inferred from motion data?
- 移動状況から、居場所や何をしているかを推測．待ち合わせや連絡をとってもよいかの判断に利用

- 連絡をする前に相手の状況を確認し、それに応じて連絡手段を選択したり、連絡を後回しにしたりしていた
- 会おうとする相手の状況を把握するため
- micro-coordinationの支援．状況を把握し、会う場所や時間を決定する
- 相手の状況に応じて、その場でもうしばらく時間をつぶすか、移動し始めるかの判断に利用
- 待ち合わせにてまちぼうけをしないようにするために利用
- スケジュール通りに用事が進んでいるかどうかを確認するのに利用 (Security用途としても使える)
-- しかし、相手方の監視にもつながりかねない．データがあいまいであっても問題になることがある．
- 助けを求めるのに利用．「会社から帰り始めているな、途中で牛乳買ってきてもらおう」「子供を迎えに行っているはずなのに、移動していない! 電話しよう!」

□ How did motion data after feelings of connectedness?
-「つながっている」という感覚の提供、社会的意識の提供

- カップルが忙しくて実際に会えない時に、このアプリケーションを見ていた
-- 仮想的につながっている感覚を提供
- 安全確認のために利用
-- 異常検知に利用されていた「移動しているはずなのに、長い間移動していない...」

- 友人同士での利用では，社会的意識を維持するために使われていた
-- 互いの生活パターンを知る「友人が朝早くから働いていることは知っていたが、こんなに早いとは知らなかった．悪いなと思うようになった」
- 特定行為の推測や何をしているかを気づくのに利用
-- 「車で来るって言っていたのに動いていない．渋滞にはまったか?」

- 会話のネタや互いが親しくなるのに有用かもしれない

□ When was the application used?
- 平均して日に5回アプリケーションを見ていた
- 友人間での利用の場合はそれ以上になる傾向にあった

- 暇な時に見ていた．気分転換．ゲーム代わり．娯楽として
- 特に使う理由がないので使わなかった
- 自分自身の記録を見ていた．過去の自分の行為を思い出すため

□ How were ambiguities/errors dealt with?
- 提供している情報があいまいなので、反論に対する言い訳ができると思っていた
- ニセの行動を提供するといった行為をする人はいなかった

- この種の情報は、相手のスケジュールを知っていなければ意味がない
- より詳細な情報が必要だという人もいた．移動状況の解釈を誤ることもあった
- 移動状態の検知ミス(精度)の問題

□ Privacy concerns
- 親しい間柄同士なら、プライバシー問題は起こりにくいと思いたいが、やはり起こる
- しかし、予想以上に少なかった．そういう間柄ならば情報共有したいと思うようだ

- 地図上に自分の位置が表示されるのはまさにBig Brotherだが、この程度の情報なら問題にしないな
- まったくの他人とは、移動状況とは言っても共有したくない
- なんとなく不安になるユーザもいたが、使ってもらったらあまり気にならないかもと言っていた
- 常時共有することに違和感を覚えるユーザもいた
- やはりより詳細な情報を欲しがるユーザはいた．正確な位置、住所名、移動方向
- 移動履歴を使いたいという人がいた

■ Discussion
- あいまいなプレゼンス情報でも有用
-- ユーザ間の関係によっては、こんなあいまいな情報でもさまざまな状況が推測可能
- 共有情報があいまいゆえにプライバシーの問題も回避できそう

- ユーザ間で互いの予定や行動パターンを知っていなければ、この種の情報は有用ではない．これがプライバシー上の懸念を低くしている
- 正確な位置を共有したいときには、ユーザが共有相手を指定して位置情報をpushすればよい．まさにユーザの意志による共有

■ Future Work
- 3つ．移動検知アルゴリズムの改善．他のプレゼンス情報の研究．プレゼンス情報の組み合わせの探求

- 他のプレゼンス情報として考えているもの: 再生中の音楽、携帯電話のアイドル画面、ライト(?)

■ Conclusion
- 親兄弟や親しい友達ならば移動情報から行動や居場所が推測できる
- 移動情報は、実際の通話にて居場所と活動状況を話す際に使われた
- 人に電話をする際に役に立つというような評価はされなかった
- 電池の持ちの改善は必須
- この手のアプリケーションは、日常的にユーザが便利であると感じるものではなく、長期間利用することによって、他人の行動パターンを学習し、電話してよい時間帯や見計らったり、より不定期な活動で人と会う場合などに使われた

- より親しい関係を築くため、そして家族や友人と頻繁に連絡をとるようになるためには、どのようなpresense情報が有用であり、そしてそれらをどのように提示するべきかを今後も模索する．

「移動情報」しか共有せず、それが親しい間柄の人間でしか意味をなさないという論拠からプライバシー問題の回避を狙いつつ、かつそういった個人の状況共有を目指している点は興味深い．が、やっぱり、それでも無制限の共有はプライバシー侵害と受け取られるのはそうだと思う．情報共有は、情報を提供する側の制御の基に行われるべきだというのは賛成できるが，でも、それでも問題になることがある．情報共有ができるという状況になってしまうと「情報共有できるのに、なんで情報共有しなかった/しないんだ!?」という事態になり、状況によっては相手に対して疑念を生んでしまうからだ．というわけで、こういったシステムは本当に難しい．慎重にならないといけない側面があるということを認識しておかなければいけないと思う．

システム管理者がし忘れること - トップ7

セキュリティとも大いに関係があることなので書き残しておく

O'Reilly Networkの記事 - Top 7 Things System Administrators Forget To Doから抜粋

1. 以前まで存在していたユーザのアカウントを削除し忘れる

2. Rootkitの定期的な監査をし忘れる

3. トラブルチケット管理システムの利用を忘れる

4. 技術文書の生成と知識ベースの構築をし忘れる

5. Flash Memoryドライブの危険性を無視してしまう

6. 部分的なルート権限付与に関する管理を忘れてしまう

7. 礼儀を忘れてしまう...

システム管理者ならば読んでおいて損はない記事だと思います．
しかし、研究となると、この分野はセキュリティとは別の分野で扱われたりするんですよね〜