前回の記事はあくまでRAWデータという事で、雑感等をとりまとめてみたいと思います。
-----
【Session1：「願い」～ペネトレーションテスターからセキュリティ担当者へ～(NTTD 辻さん)】
「ペネトレーションテスト」とは何か、そして何をする(している)のかからスタートし、作業の省力可に用いるツール(脆弱性スキャナ)の紹介と、ツールの弱点(False PositiveとFalse Negativeの発生)と、それを踏まえた上での対策(意志と思考を持つ人の力)について紹介されていました。
ツールについては、以前紹介したNessusのように色々なツールがあり、いずれも一長一短(ツールの癖)があります。
(例えばNessusだと以前はSSH系の調査がやや苦手という癖を持っていました……今は大分良くはなりましたが。)
このツールの癖というのは、調査対象によって調査し易い・し難いという形で表れるので、その辺は日頃からツールに関する情報収集を行い、この調査対象ならこのツールという形に持ち込むのが「輝手」かと思われます。
またツールはその性質上、False PositiveとFalse Negative(「ツールの嘘と沈黙」という言葉で表現していました)が発生してしまうのですが……
False Positive→検査する側が精査し本当に脆弱か否かを判断、その上で時としてレポートから除外する(または深刻度を下げる)などの対応を図る
False Negative→前述のツールの癖を把握し、その上で「他に類似する侵入口は無いか?」などを推測し、実際に手を動かして検証する事で対応を図る
……という事で対応を図る必要があるでしょう。
(質疑応答の時に、False Negativeに関する情報の共有について質問させて頂きましたが、NTTDではマインドマップを活用し、ある対象についてはこのような脆弱性が発生し易く、それに対する検査項目を整理した上で技術者間で情報共有しているとの事だそうです。)
最後に「調査するのは『人』である」という事、結局ある程度ツールでの自動化が図れるようになったとは言え、ツールは「自分の判断で任意に調査項目・方法をツール自身が変更する」というのは出来ない事から、調査漏れというのはどうしても発生してしまいます。そこは人の英知と柔軟性でカバーしましょうという事で。
(この事を「攻める側も守る側も、システムの後には人が存在している」という言葉でまとめていました。)
-----
【Session2：LTセッション】
［LT1：ペネトレーションテスターより愛を込めて part2(辻さん)］
Session1に引き続き、LTにも辻さんが登場。実際にペネトレーションテストをしていてよく遭遇する脆弱性を3種類紹介していました。
先に言ってしまうと、いずれもシステムを構築・運用する側が自ら検査する事で防ぐ事ができる「ついウッカリミス系」が多いとの事。第三者による検査を受ける前に自己診断を行う事で余計な指摘をされる事も防げますし、何より検査する側も検査対象・範囲・項目の削減が図れる事によって工数を削減できますよね。
1位は「推測されやすいパスワード」として「パスワードが空」「Joeアカウント」「デフォルトパスワードのまま」というのを挙げられていました。対象はSSH、Telnet、SNMP(コミュニケーション名)、SMB、VMC、DBMSなどと様々。
2位は「SSL関係」という事で「今更ながらSSL2.0が有効になっている」「鍵長が128bit未満」というのを挙げられていました。なお特に128bit長未満の鍵の件についてはPCIDSS 要求項目4.1が関連します。
3位は「Apache関係」という事で「Expect リクエストヘッダにおけるXSS」413エラーメッセージにおけるHTTPメソッドを適切に処理しない問題」を挙げられていました。Apacheについてはプロダクトの中に含まれているにも関わらず、システム運用側がそれを把握していないというケースがあるとの事……皆さんご注意を……。
-----
［LT2：とあるシステムの脆弱性」(totoroさん)］
相変わらず黒いのでオフレコ、一言で言うと「それは仕様です」。
まぁ強いてツッコミすると、確かに今のままなら仕様と言われても仕方がないかと。
と言うのも、「ソレ」を突く悪意有る行為のシナリオを挙げても、それが成立する前提条件が「客観的でない(統計的なデータが無い)」以上、受ける側としては納得できないのではないかと……。まずはその辺(客観的なデータを取り、確かにそれは成立するというのを証明する)を解決しない事には進展はしないのではないかと思います。
---
［LT3：Google Chromium OS Forensics(Oroさん)］
フォレンジクスを行う者として、今後出てくるであろう「Google Chromium OS」を搭載する機器に対する検証結果を紹介していました。
結論から言うと、現時点では通常の手法では技術的もそうでうが、法的にも難しい部分があるという事だそうです。
簡単に説明すると……
Google Chromium OSにはセキュリティ対策、特に機器盗難時などにディスクイメージを取られて解析されてしまう事への対策の1つとして、ユーザデータ格納部分については、ユーザ毎に暗号化されている
その暗号化に用いる鍵の1つとして「Googleアカウントのパスワードハッシュ」が挙げられる
問題なのはその「Googleアカウントを如何に特定するのか?」という事
現在Googleアカウントは、Googleのサーバ(Internet上にある)に保管されている……誰が使ったのか分からない機器を調査するために、どのGoogleアカウントなのかを如何に特定するかが問題となる
下手にGoogleのサーバにアクセスしたら、それこそ不ア禁法が適用される可能性も無くは無い……
……という事だそうです。
---
［LT4：WASF conf 2010報告会(ikepyonさん他)］
時間が余った事もあって、急遽先日開催された「Web Application Security Forum カンファレンス 2010」の報告会が行われました。
まぁこの件については各所に記事があるので、ココでは割愛させて頂きます。
-----
最後に、いつもながらですが「美味しかった」です(笑)。
相変わらずスタッフ(まーさん)が選ぶお菓子は美味しいという事で(ヲ
-----
【Session1：「願い」～ペネトレーションテスターからセキュリティ担当者へ～(NTTD 辻さん)】
「ペネトレーションテスト」とは何か、そして何をする(している)のかからスタートし、作業の省力可に用いるツール(脆弱性スキャナ)の紹介と、ツールの弱点(False PositiveとFalse Negativeの発生)と、それを踏まえた上での対策(意志と思考を持つ人の力)について紹介されていました。
ツールについては、以前紹介したNessusのように色々なツールがあり、いずれも一長一短(ツールの癖)があります。
(例えばNessusだと以前はSSH系の調査がやや苦手という癖を持っていました……今は大分良くはなりましたが。)
このツールの癖というのは、調査対象によって調査し易い・し難いという形で表れるので、その辺は日頃からツールに関する情報収集を行い、この調査対象ならこのツールという形に持ち込むのが「輝手」かと思われます。
またツールはその性質上、False PositiveとFalse Negative(「ツールの嘘と沈黙」という言葉で表現していました)が発生してしまうのですが……
……という事で対応を図る必要があるでしょう。
(質疑応答の時に、False Negativeに関する情報の共有について質問させて頂きましたが、NTTDではマインドマップを活用し、ある対象についてはこのような脆弱性が発生し易く、それに対する検査項目を整理した上で技術者間で情報共有しているとの事だそうです。)
最後に「調査するのは『人』である」という事、結局ある程度ツールでの自動化が図れるようになったとは言え、ツールは「自分の判断で任意に調査項目・方法をツール自身が変更する」というのは出来ない事から、調査漏れというのはどうしても発生してしまいます。そこは人の英知と柔軟性でカバーしましょうという事で。
(この事を「攻める側も守る側も、システムの後には人が存在している」という言葉でまとめていました。)
-----
【Session2：LTセッション】
［LT1：ペネトレーションテスターより愛を込めて part2(辻さん)］
Session1に引き続き、LTにも辻さんが登場。実際にペネトレーションテストをしていてよく遭遇する脆弱性を3種類紹介していました。
先に言ってしまうと、いずれもシステムを構築・運用する側が自ら検査する事で防ぐ事ができる「ついウッカリミス系」が多いとの事。第三者による検査を受ける前に自己診断を行う事で余計な指摘をされる事も防げますし、何より検査する側も検査対象・範囲・項目の削減が図れる事によって工数を削減できますよね。
1位は「推測されやすいパスワード」として「パスワードが空」「Joeアカウント」「デフォルトパスワードのまま」というのを挙げられていました。対象はSSH、Telnet、SNMP(コミュニケーション名)、SMB、VMC、DBMSなどと様々。
2位は「SSL関係」という事で「今更ながらSSL2.0が有効になっている」「鍵長が128bit未満」というのを挙げられていました。なお特に128bit長未満の鍵の件についてはPCIDSS 要求項目4.1が関連します。
3位は「Apache関係」という事で「Expect リクエストヘッダにおけるXSS」413エラーメッセージにおけるHTTPメソッドを適切に処理しない問題」を挙げられていました。Apacheについてはプロダクトの中に含まれているにも関わらず、システム運用側がそれを把握していないというケースがあるとの事……皆さんご注意を……。
-----
［LT2：とあるシステムの脆弱性」(totoroさん)］
相変わらず黒いのでオフレコ、一言で言うと「それは仕様です」。
まぁ強いてツッコミすると、確かに今のままなら仕様と言われても仕方がないかと。
と言うのも、「ソレ」を突く悪意有る行為のシナリオを挙げても、それが成立する前提条件が「客観的でない(統計的なデータが無い)」以上、受ける側としては納得できないのではないかと……。まずはその辺(客観的なデータを取り、確かにそれは成立するというのを証明する)を解決しない事には進展はしないのではないかと思います。
---
［LT3：Google Chromium OS Forensics(Oroさん)］
フォレンジクスを行う者として、今後出てくるであろう「Google Chromium OS」を搭載する機器に対する検証結果を紹介していました。
結論から言うと、現時点では通常の手法では技術的もそうでうが、法的にも難しい部分があるという事だそうです。
簡単に説明すると……
……という事だそうです。
---
［LT4：WASF conf 2010報告会(ikepyonさん他)］
時間が余った事もあって、急遽先日開催された「Web Application Security Forum カンファレンス 2010」の報告会が行われました。
まぁこの件については各所に記事があるので、ココでは割愛させて頂きます。
-----
最後に、いつもながらですが「美味しかった」です(笑)。
相変わらずスタッフ(まーさん)が選ぶお菓子は美味しいという事で(ヲ
