大山恵弘ブログ

上記の広告は１ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

In ACSAC 2003.
http://www.acsac.org/2003/abstracts/114.html

オンラインゲームを作るにあたって、どんなセキュリティ脅威を考えなければいけないか、また、それらの脅威への対策は何かを論じた論文。一般論を述べるのではなく、オンラインのトランプのブリッジを題材に、ケーススタディに徹しているのが特徴。

セキュリティといってもチート対策の話が主。オンラインゲームのサーバが乗っ取られるとかDoSされるなどの話を期待して読むと肩透かしを食う。

ていうかすごいなこの論文。図とグラフが一個も出てこない。ビブも特徴的。サイエンスにおける普遍的真理を追究した論文てよりは、問題提起しました的な印象。

In OSDI 2000.
http://www.usenix.org/events/osdi2000/strunk.html

攻撃対策機能を内包したストレージSelf-Securing Storage。
不正なファイル改ざんなどを発見して元に戻すなどの処理をするための機能が入っている。

といってもやることは単純で、要求を全部記録するような、log-structuredなストレージにするってこと。記録を利用して管理者は攻撃解析やリカバリを行ってくださいと。

このストレージはOSを信用しない。従来のOSレベルでの攻撃対策は、OSが乗っ取られたら、無力化やバイパスされてしまうことが普通だった。このストレージを使うと、たとえOSを乗っ取っても、バイパスすることは難しい。

どうやって攻撃と判断するかなどの運用面は主眼ではなく、性能オーバヘッドを小さくするという技術チャレンジに主眼があるようだ。確かにオーバヘッドはそれほど大きくない。

それより記録量が爆発してディスクがあふれることが心配になる。本論文によると、他の研究では、一日百数十MBを消費するとの報告があるという。なるほどこの程度なら、100GBを準備すれば500日はもつ。

In ACM Transactions on Information Systems Security, 9(1), 2006.
http://www.cs.ucsb.edu/~vigna/publications/

システムコール列に統計的な手法を適用して異常検知する新しい方法の提案。Forrestの論文から12年。2006年もまだこの手の研究は続いてますよ！

ポイントは、複数の検知手法を組み合わせて、システムコールの引数を検査するってこと。複数の手法を使うことにより、精度が上がる。複数の手法から得られた各異常スコアを全体異常スコアとしてまとめ、それにもとづいてイベントが攻撃かどうかを判断する。

複数の異常スコアを単に重み付けして加算するだけではうまくいかないので、ベイジアンネットワークを利用する（！）。

定石通り地道にやるべきことをやってジャーナルに通したって感じの論文。それにしても、この論文タイトルは何というか。ううむ。

In VEE '06
http://www.ecsl.cs.sunysb.edu/fvm/index.html

Windows上でSoftwarePotのようなFreeBSD jailのようなSolaris ContainersのようなLinux VServerのようなものを実現．

資源はcopy-on-writeで複製するので省資源ですむ。このへんはAlcatrazにも似ている。

仮想環境はsystem callの仮想化によって実現。Windowsなのでptraceやら/procやらは使えない。SSDT patchingとIAT書き換えでsystem callをフック。

LinuxなどのUNIXでこの手の話が出てきたら、やや「またか！」という気分にもなるが、Windowsでやった点がなかなか興味深い。

In USENIX Security 2005.
http://seclab.cs.sunysb.edu/seclab1/pubs/papers.htm

Sekarグループ最新作。

セキュリティポリシーの記述にtaint情報も付加できるようにしましたって話。たとえばフォーマットストリング攻撃を検出するポリシーでは、vfprintfの引数のフォーマット部分のマッチパターンに、「この文字列はtaintされている」みたいな情報を付加する。taintされてればマッチ。されてなければマッチしない。ていうか論文のFigure 4がすべてを物語るって感じ。

CILを使ってCプログラムを変換して、taintの流れを追跡。

Sekarさんは私が見たところ10年間芸風が変わっていない。これだけ同じ芸風を続けてもネタ切れにならず、一流学会に通せるネタを今も着々と編み出しているところがすごい。

In USENIX Security 2004.
http://www.usenix.org/events/sec04/tech/jiang.html

最近VMおよびセキュリティ方面でよく名前を見るシューシアンさんによる、ちょっと前の論文。

VMによる仮想環境をハニーポットに利用する。VMベースハニーポットをたくさん作り、集中管理するためのシステムの提案。全部の仮想環境がLAN内にあったとしても、攻撃者からは、それらは分散環境に散らばっているように見える。複数のハニーポットから得られる情報を関連づけ・データマイニングすることもできる。

このアイデアは多くの人が思いつくような気がするが、複数のVMM/OS向けに実装を作り、性能評価・実際の攻撃コードを用いた解析までこのタイミングで終えられる人は、なかなかいないのではないか。

In USENIX Annual 2004.
http://www.usenix.org/events/usenix04/tech/freenix/clark.html

SOSP 2003に出たXenの論文の性能を追試した。さらに、SOSP論文にはなかった実験も加えた。以下の質問を提示し、それへの回答を与えている。

・SOSP論文の性能測定結果を再現できるか？
・仮想ウェブホスティングにXenを現実的に利用可能か？
・Xenを効果的に動作させるには高価なサーバが必要か、3年もののPCでも十分か？
・コモディティPC上のVMの性能は、仮想化を意識したメインフレーム上のVMの性能と比べてどうか？
・「繰り返し研究」から何が得られるか？

答は論文を参照。

何か新しい手法を提案しているわけではない。何かを作ったわけでもない。

でも、こういう研究は評価すべきだと思います。パフォーマンススタディをおろそかにすべきではない。現実問題として、この論文は世の中の多くの人の役に立っていると思うし。地道に良い仕事してます。

In ICSE 2000.
http://www.cs.virginia.edu/~evans/pubs.html

アスペクト指向でセキュリティ処理のコードを挿入して安全性を高めましょうという話。ビッグネーム揃い踏みの論文。ていうかポジションペーパ。

セキュリティ処理のコードは関心事分離するのがいいのか、ソースに埋め込むほうがいいのかは、まだはっきりしない問題だし、そもそも時と場合によるので一概に言えなかったりする。アスペクトの素人の個人的意見としては、セキュリティ処理は本処理と一緒に書かれていてほしいと思います。開発段階から分離して書くのはなんか肩がこりそうだし危なそうだなと。既存のコードをいじりたくない場合にアスペクト指向でセキュリティコードを突っ込んで急場をしのぐって用途はありなんじゃないかと思います。

2000年の論文なので、今読むと牧歌的な雰囲気が漂っている。セキュリティを研究してると、もうやること残ってないんじゃないかと思うことがある。でも、2000年から2006年の間に、技術は確実に進歩した。技術の進歩に終わりなし。今後の6年にも、セキュリティ技術は進歩するはず。

In DSN 2001.
http://dependability.cs.virginia.edu/info/Publications

信頼できないホスト上でソフトウェアを動かすときに、ソフトウェアが何をするかをホストが解析しにくくする。要するに難読化。

制御フローがデータに依存するようにプログラムを書き換える。制御フロー解析とデータフロー解析が相互に依存するようになるので、ソフトウェアの解析に時間がかかったり、解析精度が落ちたりする。

無駄なif-thenを入れるとか、gotoの飛び先を動的に計算する（switch文で実現）とか、変数のnon-trivial aliasを入れるとか。

この方法で難読化された間接ブランチ飛び先を決定する問題はNP-hardだという定理と証明が述べられている。

性能だが、半分のブランチを変換すると、実行時間が10倍くらいになる。

In ACSAC 1998.
http://www.acsac.org/1998/abstracts/wed-a-330-jajodia.html

IDSによって、ある人間を怪しいと判断しても、すぐ何か過激な対応をするのははばかられる。判断ミスをしているかもしれない。なので、そのユーザを「隔離」して、さらに調査を続けるのが有効。本論文はデータベースの文脈でその方式を提案。

DBだと、隔離された側と元の側でデータのinconsistencyが生じるので、それを考えて隔離する必要がある。元の側は隔離に関係なくトランザクションを行いたい。

詳しくは読んでないが、隔離機構が存在する状況下での読み出しや更新のプロトコルを提案しているようだ。