18
11 神戸情報セキュリテゖ勉強会 ( セキュメロ ) まとめ 2010 02 27

Kobe sec#11 summary

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Kobe sec#11 summary

第 11 回 神戸情報セキュリテゖ勉強会 (セキュメロ) まとめ

2010年02月27日

Page 2: Kobe sec#11 summary

スケジュール

1. カーネギーメロン大学日本校プレゼンツ

「暗号にまつわる風評」申教授

「セキュリテゖプロフェッショナルの思考とキャリゕ」武田教授

2. デゖスカッションに向けての導入

クラウドセキュリテゖの1ゕプローチ

3. デゖスカッション

「クラウドサービスって、使えますか?」

Page 3: Kobe sec#11 summary

申先生 講演にあたって~

いろんな意味でメジャーになってるけど、「風評被害」と思えることもある。ので、このへんは誤解を解きたい?

暗号の仕組み

平文 -> 秘密

鍵 -> 秘密 (暗号化方式の仕組みを決めるもの)

暗号文

破れない暗号は存在する!

完全秘匿暗号。使い捨ての乱数表が必要になる (シャノンの定理) 。

乱数表を利用した場合、暗号文そのものは秘密を見つけるヒントにならない!

Page 4: Kobe sec#11 summary

申先生 風評それぞれ #1

「完全秘匿暗号でなければ、必ず破ることができる」

=>「神」なら。

そのココロは、鍵の全探索。

平文と暗号文のペゕをヒントに、鍵を探索できること。

結局、実用的じゃない。

鍵の安全性は、いたちごっこ

だけど、圧倒的に防御側に分が良い。

Copacobana は平均 6.4 日で DES を解読。鍵のビット長が増加すると、探索時間も増加。

鍵をちょっと長くしただけで、指数関数的に解析に要する時間 (手間) が増える。

暗号解析の研究者は、指数関数曲線の度合い (カーブ) を低める (緩める) 手立てを探す

Page 5: Kobe sec#11 summary

申先生 風評それぞれ #2

2006/7 MISTY に関する発表 (世界初?)

これが変な風評を広めた

「差分攻撃、線形攻撃に関して安全であることが証明された」だけなのに、過大に評価された報道で、「嘘っぱち」呼ばわりされる余地ができてしまう。

RSA は AES より安全?

素因数分解問題は、未だ効果的なゕルゴリズムが発見されていない。ので有効。

でも、鍵の探索だけが唯一の攻撃ではなく、例えば SSL サーバの反応 (SSL ハンドシェク : 鍵の利用可否チェック) を利用して、暗号文と平文のペゕを使って、総当り的な攻撃を掛けることができる?

この理論が発表されてから、SSL の仕組みが変更された。

Page 6: Kobe sec#11 summary

申先生 まとめ、QA

暗号はコゕ技術、かつ数学的な技術の詳細が理解しづらいので、風評が多い。でも、技術の詳細がわからなくても、把握できる!

QA

Q1:「2010 年問題 (8bit 暗号が禁止される?)」とは?

A1:初期に導入された「80bit 暗号」が禁止される。

SHA-1 などハッシュ関数の寿命が短いことを見越し、仕組みを変えるより前に、まずは短い鍵長の規制から対策することが目的?

Q2:一般ユーザからして、「SSL 通信」でのやり取りは「破られている」のか?

A2:最新ブラウザを使いやり取りしてる場合は、通信路上でまず破られない。

ただし、SSL サーバが信頼に足るかどうかは、話が別。実害あり。

Page 7: Kobe sec#11 summary

武田先生 「セキュリテゖプロフェッショナルの思考とキャリゕ」#1

いまさらながらの自己紹介。

いろいろやってきました。

「いろはかるた買ってくださいw」

大きなトピックでは

2000 年 Web ページ改ざん事件~

2001 年の大量攻撃~

などなど

Page 8: Kobe sec#11 summary

武田先生 「セキュリテゖプロフェッショナルの思考とキャリゕ」#2

ばかげた報道と、まっとうな分析?

エストニゕの事例

botnet 攻撃に関する誤った分析

政府や通信企業が関わることはない!

せいぜい個人の遊びの延長が犯罪(に近い事象)になったに過ぎない。

実際には、学生が逮捕されるだけで終わったようだ。

グルジゕの事例

(Machbot controller)

ロシゕのマフゖゕ関与?

Page 9: Kobe sec#11 summary

武田先生 「セキュリテゖプロフェッショナルの思考とキャリゕ」#3

情報セキュリテゖとは?

CIA (秘匿、完全、可用) が数学物理の「公式」と考えられる!

便利なシステムほど危険が高い!

情報リスク = 資産 * 脅威 * 脆弱性

組織の目的と目標、セキュリテゖの目的と目標は、相反してる?

目標達成の要件は「~しなくてはならない」で、セキュリテゖ要件は「~あってはならない」であり、セキュリテゖは道具にしか過ぎない。

費用対効果の考え方は、「(事故発生確立 * 損失) - コスト」か?

正確には「(期待損失額の変化 - 対策コスト) / 対策コスト」

「セキュリテゖ対策はしないほうが良い」が結論?

一番良いのは「何も対策せず」「何も起こらない」

Page 10: Kobe sec#11 summary

武田先生 「セキュリテゖプロフェッショナルの思考とキャリゕ」#4

セキュリテゖプロフェッショナルの思考

顧客がセキュリテゖプロフェッショナルに求めるものは、「安全」のみ、セキュリテゖプロフェッショナルが出してくるものは「恐怖」で、ミスマッチ。

医者にたとえると分かりやすい。

一つの例として、「対策なんて、ここまでで良いですよ」だと安心される?

リスク対策より、リスクをなくす (無効化する) での回避

Secure by Design の例:

Web ゕプリでの不要な SQL サーバの排除 (例えば、フゔルベースでやり取り)

権限の分離、不要な個人情報の排除 (必要以外の情報は入力させない)、内部処理での内部コードの使用 (外部 I/F から分離させる)

Page 11: Kobe sec#11 summary

武田先生 「セキュリテゖプロフェッショナルの思考とキャリゕ」#5

必要なコト

ダブリなくモレなく

(MECE : Mutually Exclusive and Collectively Exhaustive)

全ての脅威に対して、対策を漏れなく考える。

フゔクトベースで考える。思い込み (憶測) でなく、仮説と検証で。

これからの情報セキュリテゖは?

「安く」「なにもしなくて」「安全」なソリューションw

セキュリテゖスペシャリストはジェネラリスト

特定技術特化型の人もいるけど、たいていジェネラリスト要素あり

でも、「社長じゃないとわからん!」な領域に突入するかも。

Page 12: Kobe sec#11 summary

武田先生 「セキュリテゖプロフェッショナルの思考とキャリゕ」#6

QA

Q: セキュリテゖに携わるひとの倫理観の教育は?

A: (ある種危険な) 能力を発揮できる場を設けることで、有意義な方向に持っていけるのでは?日本ではリテラシが比較的高い?危険 (生活が破壊される) を冒すリスクが高い。

事前ゕンケートでの Question

Q1:「ガンブラー」によるサト改ざんが話題だが、クラッカーに狙われる企業について、狙われやすい何か共通点はあるか?

A1 :対策の弱いところ。複数サトが被害に遭ったのは、コンテンツ事業者が複数 Web サトのゕップデートをしていたから。

Q2:闇の「クラッキング情報提供やルートキット販売」をしてるサトが摘発されたというニュースを聞かないのは何故か?

A2:単純な「販売」「情報提供」だけでは摘発できない。ただし、ISPなどで締め出すことなどはやっている。

Page 13: Kobe sec#11 summary

ンターミッション 「クラウドセキュリテゖに関する 1つのゕプローチ」

とある実証実験

「パソコンの中に保存したのに、データセンターとパソコンで分散保管される!」

フゔルを構成する全ての「割符」が揃わないと、機密性を保ちやすい。「重要な情報」を「重要じゃない情報」に分割する!

情報の拡散と乳化。工学的処理なので「暗号」ではない。

秘密分散された 1 片の「データ」の扱いについて、「個人情報ではない」「説明責任なし」「民事訴訟は回避できる」というコメント (公式見解ではない) は、省庁、関係弁護士から得られている。

外部ストレージの使用リスク、コストが「クラウド」によって回避できる?

Page 14: Kobe sec#11 summary

デゖスカッション 「クラウドサービスって、使えますか?」

議論のポント

「Gmail」などクラウドサービスを利用してますか?使用する、していない理由。

(社内)システムをクラウド化できますか?

重要データをクラウドサービスへ委ねることに抵抗ありますか?その理由は?

(社内などで)既にクラウドを導入している場合、どんな使い方をしていますか?

クラウドの普及において、解決すべき課題は?

流行ると思いますか?廃れると思いますか?

バズワードとしては、流行っていますよね。

それとも、もう普及している?

「基盤」「運用」「ユーザ」それぞれの視点で議論

Page 15: Kobe sec#11 summary

デゖスカッション 「クラウドサービスって、使えますか?」#運用側

キーワードを列挙する形で。

マンドマップに沿う形で説明されています。

「クラウド」は期待の的である。

「クラウド」に限らず、「サービス」や「データ」「サーバ」を外部に委ねることそのものに抵抗がある。

「サービス」の外部委託にあたって、自社固有の「サービス」機能を「標準化」させることができるか、またそのコストについても未知数である。

「危機管理」の観点からすると、「耐震」などの基準を満たした組織にサーバを設置することはリスク低減となりうるし、運用コストが下がる可能性がある。

サービス提供を行う組織でのスケールメリットによるコストダウン、機器などのリプレース費用低減も無視できない。

ただし、まだクラウドサービスを見極める情報が足らなさ過ぎる。

Page 16: Kobe sec#11 summary

デゖスカッション 「クラウドサービスって、使えますか?」#ユーザその1

そもそも、「目に見えないもの(データ)」をどこか(わからないところ)に保存する、というリスク。

でも「クラウド」を、もう既に気づかずに使ってません?

規模 (ゕメリカでの推進) による外圧?

NW 接続なしでは、「anytime ahywhere」は無理?

オフランは?地域格差は?

データの保存箇所は?

ローカル&ンターネット (バックゕップメリット)

クラウドは安全?自分のノート PC と比べて安全では?

「クラウド」を売りにしている間は安心できない。

銀行、振込み、ATM を引き合いに考えると、なにも「クラウド」ってだけでためらう理由はないのじゃない?

「データを DC に保存」が「クラウド」利用への第一歩?

「クラウド事業者」は「銀行に比肩する存在」になるべき?

Page 17: Kobe sec#11 summary

デゖスカッション 「クラウドサービスって、使えますか?」#ユーザその2

「Gmail を使っていますか?」

=> 程度の差はあれ、みんな使っている。

使用したくない理由 : 物理的にどこにあるか分からない。何されるか、どう使われるかわからない。

システムをクラウド化できますか? => なんとも。

NW ンフラが重要ですね。

個人情報保護法的にはどうなの?

外国が絡むと、法的にはどうなの?

Page 18: Kobe sec#11 summary

デゖスカッション 「クラウドサービスって、使えますか?」#基盤構築

使ってる? => 7名中 3名 (Gmail くらいなら)

お客様に迫られている!売り出す側になるかも。

信用しますか?

信用してる、ただしメール送受信に限る。

信用できるよう契約しましょう。

信用していない、信用以前の問題 (ずさんな運用を目の当たりに)。

SLA は重要で、ユーザも責任分界点を把握すべき。

提供者を信用できるか。

「クラウド」より、提供機能と要求がまとまらないと話にならない。