2008年7月
2008年7月30日(水曜日)
Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ
いただきものの本を読み終わったのでメモ。
- Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ (www.amazon.co.jp)
「Dr.きたみりゅうじの“IT業界の勘違い”クリニック (rikunabi-next.yahoo.co.jp)」の書籍化 + 書き下ろし。おおむね読んだことあるネタだったので、感想としては「本になっていると読みやすいよね」といったところでしょうか。
- 「Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ」にコメントを書く
トレンドマイクロのサイトの脆弱性が修正された
IPAの方からこんなメールをいただきました。
トレンドマイクロの件につきまして、ウェブサイト運営者より、再指摘頂きました脆弱性に対する修正が完了したとの報告がありましたのでご連絡いたします。
このメール2回目ですけれど。前回の修正完了報告のときはあっさり貫通して残念な思いをしましたが、今度はちゃんと直っているようなので、「とある改竄報告ページにあった脆弱性の話」の非公開にしていた部分を復活させました。
関連する話題: Web / セキュリティ / クロスサイトスクリプティング脆弱性 / 情報セキュリティ早期警戒パートナーシップ
2008年7月28日(月曜日)
殺人の門
読み終わったのでメモ。
- 殺人の門 (www.amazon.co.jp)
……いや、なんというか……これ悪徳商法の本ですか?
倉持のキャラクターは強烈。こういう、アウトが異常に強いタイプの人っていますよね……。
※ここで言う「アウト」というのは、顧客に断りの台詞を言われたとき、その断りの理由を打ち消すセールストークのこと。一般には聞かないので、特定の通信系代理店の営業に伝わる隠語かもしれません。……たまに、顧客に何を言われても即座に強力なアウトを返し続けられるタイプの人がいて驚きます。顧客はやがて断る理由を全て失ってしまい契約してしまうのですが、解約率も高いという諸刃の剣です。
2008年7月25日(金曜日)
日常3
待望の「日常」三巻が出ました!
- 日常 (三) (www.amazon.co.jp)
三巻はいきなり表紙で少し笑ってしまいました。しかも、帯をめくったらさらに凄いことになっており、カバーの折り返し部分でもっと大変なことが……。
中身のネタも充実。「黒いの」とか、細かいところで笑わされます。あと、みおvsゆっこの白羽取りとか、「ブゴッ」とか。
※そして今回、ついに「男たちの宴」が白日の下に……。
2008年7月24日(木曜日)
IPAからの指摘を教訓にできなかったアイリスプラザ
うわぁ。これは大ショックです。
- アイリスプラザに不正アクセス、カード情報2万8105件流出か (internet.watch.impress.co.jp)
- カード番号2万8000件流出の恐れ アイリスプラザのECサイト、SQLインジェクションで (www.itmedia.co.jp)
- アイリスプラザ、古いプログラムを突かれカード情報2万8000件を漏洩 (itpro.nikkeibp.co.jp)
そしてお詫びとご説明 (www.irisplaza.co.jp)、FAQ (www.irisplaza.co.jp)。
Q.不正アクセスに対する対策はしていたのか？
A.ファイヤーウォールやＳＱＬインジェクション対策はしておりましたが、既に使われていない古いプログラムは対策されておらず、結果的にそのプログラムから攻撃を受けています。
「ＳＱＬインジェクション対策はしておりましたが」って言い切られてしまいましたが、2年前にIPAから指摘を受けて初めて対策したのですよね? 2006年8月24日の時点では、アイリスプラザのトップページにある検索フォームで単引用符を検索したとき、以下のようなメッセージが表示されていました。
Microsoft OLE DB Provider for ODBC Drivers エラー '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]データ型の演算子が無効です。データ型演算子は modulo、データ型は varchar です。
/Meisai.asp, 行 45
そして、商品ページのURLのID部分に%27を付けるとこんなメッセージが。
Microsoft OLE DB Provider for ODBC Drivers エラー '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]文字列 '' の前で引用符が閉じていません。
/OyaSet.asp, 行 12
実際に任意のSQL文が実行できるかどうかまでは確認しませんでしたが、状況証拠としては十分でしょう。
IPAからの指摘を受けた後の動きは非常に素早く、即日修正されたようです。その素早さ自体は評価したいところですが……。
私が見たのはトップページと商品ページという、これ以上目立ちようがないようなページだけです。それらがことごとく脆弱だったわけですから、指摘されたポイントを修正して終わりにするのではなく、「他のページも危ないのではないか」と思ってほしいところです。そこで棚卸しと総点検を行っていれば、「既に使われていない古いプログラム」が放置されることもなかったのではないかと思います。
IPAから指摘を受けたという事実は、経営に伝わったりしているのですかね? 現場レベルで修正して終わりにしてしまったりすると、棚卸しの機会なんて得られないわけでして。こういう事件が起きないことを願って届け出ているのですから、指摘された側でもちゃんといろいろ考えてほしいところではあります。
関連する話題: セキュリティ / SQLインジェクション / 情報セキュリティ早期警戒パートナーシップ
マール王国の人形姫 天使が奏でる愛のうた
Wiiの「みんなのニンテンドーチャンネル」が更新されて機能強化されたということでいろいろ見ていたのですが、こんなのを発見。
- マール王国の人形姫 天使が奏でる愛のうた (www.amazon.co.jp)
DSで出るのですね……。PS版は、魔法一発で終わる単調な戦闘、同じ景色がひたすら続くダンジョン、役に立たないモンスター仲間システム……など、システム面にいろいろ課題はあったものの、ストーリーは悪くない感じでした。リメイクでシステム面が改善されていれば、だいぶ良いゲームになりそうな気がします。
2008年7月23日(水曜日)
ハッカーセーフのサイトの脆弱性が修正された
IPAの方から、以下のようなメールをいただきました。
IPA セキュリティセンターです。
HACKER SAFE の件につきまして、ウェブサイト運営者より、届出いただきました脆弱性に対する修正が完了したとの報告がありましたのでご連絡いたします。
HACKER SAFE（ハッカーセーフ）無料脆弱性診断（お試しスキャン） (www.hackersafe.jp)のページからリンクをたどると申し込みフォームが表示されるのですが、そのURL は以下のようなものになっています。
- https://ssl.sct.co.jp/servlet/XS3/hxml/contact/check1.hxml
その筋の人(?)なら ".hxml" って何だろう? と思い、何となく拡張子を消してみたりするかもしれません。私がこのページを見ていたのはWASForum Conference 2008の2日前ですから7月2日のことなのですが、当時は以下のようなメッセージが表示されるようになっていました。
ERROR:
[sysXS3.system.m]
ID : ERR_FILE_NOT_FOUND
メッセージ: 要求されたファイルまたはパス: "/hxml/contact/check1" を見つけることができませんでした。
これが今は以下のようなメッセージに変更されています。
ERROR:
[sysXS3.system.m]
ID : ERR_FILE_NOT_FOUND
メッセージ: 要求されたファイルまたはパスを見つけることができませんでした。
というわけで、私が発見したクロスサイトスクリプティング脆弱性については修正されていることを確認しました。
当該フォームにもハッカーセーフのシール(?)が貼ってあったので、ハッカーセーフでチェックされていたのだと思うのですが、このような単純なXSSが見つからないものなのですね……。思うに、ハッカーセーフはリンクがつながっているページは検査できるけれども、URLを書き換えてアクセスするようなタイプのものは検出できないのかもしれません。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性 / ハッカーセーフ / 情報セキュリティ早期警戒パートナーシップ / WASForum Conference / シール
2008年7月18日(金曜日)
さまよう刃
読み終わったのでメモ。
- さまよう刃 (www.amazon.co.jp)
社会派小説と思わせておきながら、ちゃんと叙述トリックが仕込まれているというのが素晴らしいですね。まさか中間者攻撃が行われていようとは……。
2008年7月17日(木曜日)
ベリサインのセキュアドシールは役に立つのか
セキュリティホールmemo (www.st.ryukoku.ac.jp)より、「Adobe Flash Player バージョン9.0.124.0導入環境においてベリサインセキュアドシール(Flash形式)の検証ページが表示出来ない事象について (www.verisign.co.jp)」。
Flash版のセキュアドシールが表示できないそうで。
……しかしこれ、誰が困るのですかね。いつも思うのですが、そもそもこの「セキュアドシール」って何の意味があるのでしょうか。
ベリサインのサイトを見ると「毎日世界で約1.5億回表示」なんて書いてあるようです。シールを表示する際のログはきっちり記録されていて、それがベリサインのマーケティングに役立っているのでしょう。というわけでベリサイン側にはメリットがあるのでしょうが、これを貼る側にどういうメリットがあるのか分かりません。
ベリサインのサイトには以下のように書いてあるのですが……。
エンドユーザはシールが掲載されているサイトが実際に存在しており、SSLにより暗号化されていることを検証することが可能です。お客様のサイトにシールを掲載することで、セキュリティに対する取り組みをアピールし、エンドユーザに安心感を提供します。 シールをクリックすると検証ページにサイト運営主体（お客様）の詳細情報が表示され、お客様のサイトへの信頼を高める一助となります。
以上、ベリサインセキュアドシールについて より
わかりやすい信頼の証があると良いよね、という話は理解できるのですが、気になるのは、その「信頼の証」が本物かどうかという点です。このシールは普通にWebページに貼られているに過ぎませんから、攻撃者は偽サイトに本物そっくりのシールを掲載することができます。シールをクリックしたときに現れるリンク先のページも用意することができます。利用者がシールをクリックし、何かが表示されたとして、その内容は本物なのでしょうか。
それを確認することはいちおう可能です。ブラウザのアドレスバーを見てベリサインのドメインであることを確認し、SSL/TLSが有効であることを確認すれば良いのです。逆に言うと、ユーザが「シール」を利用する際は、こうやって確認しなければならないということです。そして、それができる利用者は、シールが無くても元サイトの安全性を自分で確認できるでしょう。
※もっとも、これはベリサインのサイトに脆弱性が無いという前提での話です。昔はホントに脆弱だったので、この確認をしてさえ本物かどうかは分からない状態でした。さすがに今は大丈夫だろうと思いますが……。
さらに言ってしまうと、ベリサイン側では Referer チェックなどはしていないようですので、偽サイトから本物のシールのリンク先にリンクすることも可能です。ですから、たとえリンク先の内容が本物だと確認できたとしても、リンク元が本物だという事にはなりません。
要するに、シールをクリックしても、サイトの安全性を確認することはできないのです。ユーザが安全にサイトを利用するためには、元サイトのドメインを確認したり、鍵マークを見て SSL/TLS が有効であるかを確認したりして、本当に信頼できるサイトと通信しようとしているのかを確認しなければなりません。シールがあったとしてもこの手順を欠かすことはできませんし、シールが無くても、この手順さえ踏んでいれば大丈夫なはずなのです。
このシールでいちばん心配に思うのは、利用者が上記のようなことをきちんと理解できるのかどうかという点です。このシールを見た利用者の何人かは、「このシールをクリックすれば安全を確認できるのだ」と思ってしまうのではないでしょうか。そんな利用者は、攻撃者のフィッシングサイトに置かれた偽のシールをもあっさり信用してしまうでしょう。
このシールを使うこと自体が危険だとまでは言いませんが、シールを貼る場合は、利用者がシールを信用してしまわないように、以下のようなことが伝わるようにしたいものです。
- シールが貼ってあるからといって安全というわけではない
- シールをクリックしても、そのサイトの安全を確認することはできない
- シールとは別に、ブラウザの機能を使ってサイトの安全確認を行う必要がある
……そもそも、こういうシールが出てきた背景には「サイト運営者が誰なのか分かりにくい」といった話があると思うので、EV SSL が普及してくると、このようなシールの必要性も無くなってくるのではないか、と希望的に考えていたりもします。
2008年7月13日(日曜日)
この世界の片隅に(中)
購入。
- この世界の片隅に(中) (www.amazon.co.jp)
上巻は結構のんびりした感じでしたが、なかなかシリアスで複雑な展開になってきました。ここからどう展開するのか……。
関係ありませんが文庫本も購入。
- さまよう刃 (www.amazon.co.jp)
2008年7月12日(土曜日)
2008年7月10日(木曜日)
2008年7月6日(日曜日)
何でもエスケープすれば良いというものでは……
「無料でWebアプリにありがちな脆弱性を調べて治す (www.atmarkit.co.jp)」。なんだこりゃ。
一般的によく狙われる文字は以下の表にまとめてあります。内容に変換するようにコードを変更すれば、対策可能です。
変換する文字 変換後の文字 < < > > ‘ ' “ " （スペース）
「一般的によく狙われる文字」という観点が意味不明な上に、スペースを に変換しているのが凄い。意味が違ってますけど……。
というかこれ、セキュリティのためではなくて、ユーザが入力したスペースを表示上も維持したくて変換しているのでは? 話の趣旨と全然違うと思うのですが。
今回のチャットアプリケーションでの対応はここまでにしますが、利用する言語やケースに応じて以下の文字についても対応することを検討した方がよいでしょう。
変換する文字 変換後の文字 ( ( ) ) # # & &
「ケースに応じて」と言われても……。変換する意味が分からない上に、& の変換が「ケースに応じて」で良いとされているという。まあ、スクリプトさえ動作しなければ HTML が invalid でも OK というスタンスなのでしょうが。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性
2008年7月5日(土曜日)
WASForum Conference 2008: Webセキュリティのマルプラクティス – 思い込みによるソフトウェアエラーをなんとかしろ
法律っぽい話の後は、最後のセッション「マルプラクティス」。まあ、早い話が「あるある」ネタなのですが、携帯サイトから投票できる仕組みがあったりいろいろ面白い仕掛けが。
生の雰囲気が伝わらないといまいち面白くないかもしれない上、進行が速かったのでメモがついて行けていないところが多く、情報欠落気味です。
マルプラクティスとは
- mal-practice
- 間違ったプラクティス
- 辞書を引くと「医療過誤」とあるが、ちょっとイメージ違うかも
- 「ベストプラクティス」の反対語みたいな感じ
マルプラクティス
プログラミング・マルプラクティス
- サニタイズのみ
- フィルタのみ
- コードレビューしない
- ソースコード検査しない
オープンソース・マルプラクティス
- コスト0だから選び放題
- ASP.NET / Java+Struts / Ryby+RoR …… 組み合わせ無限
- Webサーバ×ミドルウェア×DBの順列組み合わせが無数に
- その組み合わせは誰も知らない?
- 「バルカン化」……みんなラテン語語源なのに微妙に違う
※ASP.NET はオープンソースではないと思いますが。
ブランド・マルプラクティス
- 「データベース業界トップシェアのA社製品だから、問題があるはずがない!」
情報マルプラクティス
- 「脆弱性情報さえウォッチしておけばよいのだ!」
- CVE/JVNに載っていないものは脆弱性ではない?
- 情報に頼りすぎるのは……
- 例:「お上が言えば良いのだ!」
このあたりから、中島社長へのリスペクトが感じられるようになってきます。
GUIマルプラクティス
- とりあえず「グイ」を作成
- マネージャに見せる!
- できあがったように見える!
- (もうできてるじゃん、すぐ完成だよね→納品早まる)
- ちゃんと作る時間なし!
カタカナで「グイ」と書かれると面白いですが、それよりも……。
WAFマルプラクティス
- とりあえず「ワフ」入れておけば良いですよ
- よし買った!
- だけど結局、電源入れてない
- WAFの機能を使うとアプリケーションが動かなくなるので、ロードバランサーとしてしか使っていない :-)
これですよ。カタカナで「ワフ」と書かれると、すごく間の抜けた何かに見えてきますね。
監視マルプラクティス
- アクセスログでかすぎ! 全部見ていられないよ!
- カスタムのログ解析ツール? なにそれ?
- SQLインジェクションに気づかない
- 急にサイバー戦争の渦中に放り込まれる
- 異常アクセスを報告したことがない
中島社長へのリスペクト。ちなみにこのとき、「皆さんはログどうしてますか?」という話に対して「放置で /var あふれた」と書き込んだのは私です。これ某所の実話でして、フォレンジックどころじゃないですね。
永遠のβマルプラクティス
- 問題あるかもしれないし!
- とりあえずβとか謳っとけ
- ずーっとβ
- →品質に対するコミットメントを下げている?
ドキュメンテーション・マルプラクティス
- 「ここはWebアプリケーションでACL書けば良いからプログラムではチェック不要ね。」
- 「はい」
- →あれ、そんなことドキュメントのどこにも書いてないぞ?
- 開発:「Webサーバでチェックするはず」と思ってチェック機能を省略
- SI:「Webアプリでチェックするはず」と思って設定を省略
テスト・マルプラクティス
- 開発の早い段階でソースコード検査を実施!
- でも運用前に動的検査やってない
- 上司曰く「一度テストしたじゃない」
- (色々あるテストの違いをどうやって説明したものか。テスト費用の見積もりの説明が必要)
他人事マルプラクティス
- 開発・インテグレータ・運用者が火花を散らす
- 「それは開発の品質問題でしょ!
- 「いや現場で監視で何とかしろ!
- 「インテグレータがワフ入れてないから!
- Not our problem!
沈黙のマルプラクティス
- 顧客を前に、言えない!
- うちのWebアプリにはあんな問題やこんな問題が……
ミーティング・マルプラクティス
- 「セキュリティはちゃんとしていますよね」
- 「……」
- 「大丈夫ですよ、ガハハ」
- セキュリティに関するミーティングのはずが、和やかに過ごそうとして
報告マルプラクティス
- 「先週の問題はつぶしましたが、今週新しい問題を直しています」
- 「いったいいつになったら仕上がるんだ!」
要約マルプラクティス
- 「要するにどういうことだ」
- 要してはいけない!
- Webセキュリティの問題は複雑なのだ、勉強しろ!
調達マルプラクティス
- 「これだけの予算で何とかしろ」
- 「前にワフを買ったが、今度はチェッカーか。いったいいくつ買えばいいんだ」
- 製品ではない、プロセスと人なのだよ!
営業マルプラクティス
- 「この製品さえ買えば安心です!」
- 発火セーフ!
- そんな製品ないって……
仕様マルプラクティス
- 仕様なのか脆弱性なのか
- 新しい脆弱性……瑕疵担保でやっちゃって良いのか
- 悪徳車検業者
- スキャン、以上!
- どんなテストをやったのかの情報がない
- なにがしか問題が発見されたらテスト終了?
スケジュール・マルプラクティス
- 「月曜までに直してください」
顧客対応マルプラクティス
- とりいそぎ、お客様情報が漏洩した可能性が……。
- (ぶっちゃけ2000人以下だ)
- 調査の結果カード番号も……
- 3%還元します
- 状況を勘案し、1,000円相当を
- ※二転三転する、noticeになっていない
メンテナンス・マルプラクティス
- 「新たな脆弱性が出てきたので修正工数を……」
- 「そんなの予算に積んでないから無理」
- 「駄目な計画立てておいて涼しい顔」
- 年度計画に盛り込んでおくべき
インベントリ・マルプラクティス
- 「当社には脆弱なWebアプリはいくつあるんだ」
- 「それは分かりません、ただ対策は……」
- ※アプリは2000個ある
- リスク資産を棚卸しできていない
- 開発した資産を把握できていない
- 古いアプリケーションを捨てていますか?
コンプライアンス・マルプラクティス
- PマークとISMS……
- 内部統制……
- 文書化、文書化
- ※現場の問題が別にある
マルプラクティスの話はここまで。ここからは、名前に「マル」とつけば何でもありの「●プラクティス」の世界に突入して行きます。
●プラクティス
- Webアプリケーションに詳しくもないプログラマを丸抱え
- インハウスで開発したものの、まるでだめ
- 結果、はまる
- まるでだめ
- コピペで丸写し
- エスケープコードを丸呑み
- 業者に丸投げ
- 買ったけど電源入れてないから丸損
- 発火セーフ入れても丸腰
- やってることがまるでちがう
- でもそのことはマル秘
- 注入工具で丸出し
- 面目は丸潰れ
- 会社は丸焼け
- 社長は丸坊主
- やったやつは丸儲け
- 困る
この後、会場からも「マル」のネタがいくつか提供されましたが、メモしきれず。
最後に
最後に、以下の言葉で締めくくられました。
- 「失敗のパターンから学ぶ、成功への一筋の光」
感想
1日目の中島社長のセッションを聞いていると2倍楽しめるセッションとなりました。まあ、そうでなくても、何のことを言っているのか全く分からないという人は少なかっただろうと思いますが。
本人に直接言ってあげたほうが……と思わなくもなかったのですが、これは特定個人の問題ではないわけでして。ありがちな失敗のパターンをいかに共有していくのか、というところが課題になるでしょう。
関連する話題: WAF / セキュリティ / ハッカーセーフ / WASForum Conference
WASForum Conference 2008: Security Wars EpisodeⅢ
SDLの話に続いて、高橋郁夫弁護士によるお話。
スライドが英語と日本語のチャンポンで、非常にメモがとりづらかったです。というわけで、申し訳ないのですがメモの精度は低いです (いや、他が精度高いかと言われるとつらいですが)。最後の方はホントにただの羅列で全然まとめられていません。
登場シーン
謎のハミングとともに黒マスク、黒マントの人物登場。まあ、タイトルから分かると思いますが。
- 自分のハミングなら著作権侵害は大丈夫だろう
EpisodeⅠ: ハッカーの暗黒面
- 怒り、恐れ→フォースの暗黒面
- 限界を超えたくなる
office氏事件
- 2003年11月、AD2003
- Excelファイルに伏せ字ではなく個人情報が掲載
- 12名がダウンロード
- full-disclosure vs 責任ある開示
- なぜ伏せ字にしなかったのか? → 自分のプレゼンをインパクトのあるものにしたかったのでは
- 最後の行為はアドレスバーへの文字の入力
※そのままメモしていますが、ちょっと事実と異なるかもしれない気がします。
ツナミハッカー事件
- 2004年12月、インドネシア津波災害
- Daniel Cuthbert という大学の先生が、津波災害の寄付
- サイトが怪しいので、URL に ../../../ をつけてみた
- IDS が反応
- 逮捕、有罪!?
Winny事件
- 1審→150万円の罰金
- あくまで技術は中立的なものと認定。具体的な状況と本人の主観を合わせて判断している
- 「Winnyが侵害に使われていることを認容しつつ新バージョンを公開した」ということが問われている
- 開発したことではなく、新バージョンをアップロードしたことが問われている
- ソースコードの分析は何もなし
原田ウイルス事件
- ウイルス作成罪はまだない
- 2008年5月16日有罪判決、懲役2年執行猶予3年
※そのままメモしていますが、ウィルス作者のつけた「原田ウィルス」という名称をそのまま使うのは良くない、という議論がある事を付記しておきます。もっとも、他の名前で呼ばれてもぴんと来ないと思いますが……。
- 古き良き時代: 実害がなければ良い
- 現代社会: 本当に悪いことをしていないかどうか分からない、アクセス制御の信頼性が重要
Information Security Early Warning Partnership
この制度の日本語での名前は何でしたっけ、という話が出ていましたが、正解は「情報セキュリティ早期警戒パートナーシップ」。覚えにくい以前に分かりにくい名前で (パートナーシップって言われても……)、知らないという人が多いはず。
サイバー犯罪条約6条 ハッカーツールの禁止
- dual use tool
- 英国コンピュータミスユース法のガイドライン: ちゃんとした会社なのか、違反の意図があるのか、etc. で判断
- ベネトレーティングテストの業界標準、工業標準として認定
EpisodeⅡ: 匿名軍団の攻撃
最近の攻撃
- 組織犯罪
- 国境をまたぐ
- ボットネットを介しての攻撃
- 闇のロングテール: 普通の人は詐欺に遭わないが、大勢に送ると中には詐欺に遭う人が一定数いる
フィッシング対応
- Yafoo! 偽サイト
- 不正アクセス禁止法違反・著作権法違反
- フィッシング詐欺団男女8名検挙、首謀者に懲役8年、罰金300万円
伝統的手法の限界
- 被害が発生しないと何もできない
- 攻撃者が突き止められる前提
- これでは、国際的な組織犯罪には対応できない
- 「大衆インターネット社会」へのパラダイムシフト
- 国際性・匿名性
- これは「戦争」なのか?
- 振込詐欺救済法 (金融機関の原則との相克)
- 弁護士に言われたところで口座凍結なんて……
- 攻撃の検知と通信の秘密との兼ね合い
- 情報共有できない?
- ドグマの肥大化
- コンテンツと通信データの区別がない
- 通信データの過剰な保護
- ISPの保護者としての役割
- 攻撃トラフィック、フィッシングメール、名誉毀損メッセージetc
- 著作権制度: フランス 三振法 ISPから警告3回で遮断
感想
話の本筋とは関係ない部分ですが、officeさんの事件に関する話が微妙に不正確なのが気になりました。「アドレスバーに文字を入れた」と言われていましたが、csvmail.cgiには以下のようなコードが書かれていたので……
if ($ENV{'REQUEST_METHOD'} eq "POST") {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
} else {
print "Content-type:text/html\n\n";
print "<html>\n";
print "<head><title>ANTI SPAM</title></head>\n";
print "<body>CAN NOT ALLOW GET METHOD.</body>\n";
print "</html>\n";
exit(0);
}
GETアクセスされたら「ANTI SPAM」という謎のメッセージを表示して終了し、何も起きません。javascript: で始まる文字列を入れて POST すれば良いという話もありますが、officeさんがわざわざそんな面倒なことをしたとは思いにくいですし。
事件からずいぶん年月も経ったことですし、技術的な部分については情報を公開した方が良いのかもしれないと思ったり。
「Webセキュリティのマルプラクティス – 思い込みによるソフトウェアエラーをなんとかしろ」に続きます。
関連する話題: セキュリティ / WASForum Conference
WASForum Conference 2008: セキュリティの作り込みはどのように行われているのか？
「OpenIDのセキュリティ」の後、お昼休みを挟んで、午後からは少し毛色の違うお話に。まずはマイクロソフトの加治佐さん、ソニーの松並さんによる、ソフトウェアの SDL (Security Development Lifecycle) についてのお話。
最初にマイクロソフトのお話から。
Microsoft の Security Development Lifecycle
- 「MSのSDLは重い。君たちにできることを簡単に言わないで」と良く言われる
- SD3+C = "Secure by design, by default and in development" + Communications
- 脅威モデル : バグ以外の脅威、STRIDE分析
- SDLは開発のライフサイクルではない。ウォーターフォールの中に組み込まれたり、併存する
Microsoftのセキュリティの歴史
- 1990年初頭 : シングルユーザOS、セキュリティに関する要求はあまりなかった
- 1994年 : NT3.1がマルチユーザOSとなる。セキュリティ上の脅威、ユーザを他のユーザから、プロセスを他のプロセスから守る必要
- 1998年くらいまで : 各製品チームが個別に対応していた。脆弱性が見つかったらマーケティング部門が対応
- 1997年 : 脆弱性の発見と公表が日常的に。ping of death とか INN とか phf とか
- 1998年 : MSRC設立(Security response center)。脆弱性受付のメールアドレスができる。アップデートリリース、メディア対応の一本化。内部の有志によるボランティアっぽい運営。
- Internet Security Task Force 設立、STF推奨事項、経営の関与etc
- Windows 2000 : 多くのセキュリティ機能を実装。増加するバグレポートが問題に。
- SGIP STOPPER SWIの設立(secure windows initiative)
- Windows XP : 魚を釣るかわりに魚の釣り方を教える。"PREfirst"
- 2001年 : codered/nimdaの大流行。2002年1月、有名なゲイツのメール
- first security push を .NET Frameworkに実施
- Windows Server 2003 : 予定出荷日間近に8000人の開発を停止して security push を実施
- 2004年7月から SDLの実施
まとめ
- セキュリティテストは重要だが十分ではない
- セキュアコーディングも重要だが十分ではない
- エンジニアの啓発とトレーニング etc. が必要
この SDL を他社に適用できるのか? という話で、ここからソニーの話に移ります。松並さんがソニーの子会社 (ソニーデジタルネットワークアプリケーションズ、でしたっけ?) でライトウェイトな取り組みを始めて、その取り組みがソニー全体に広がって行っているというお話。
ソニーの製品セキュリティへの取り組み
- 家電製品のセキュリティ……被害は多発していない、対策の価値がエンドユーザに認知されていない
- セキュリティ対策のために製品の価格を上げることは許されない (多くのコストはかけられない)
ライトウェイトアプローチ (LWSSA)
- 費用対効果を高める工夫をする
- 費用対効果の大きいものから初めて、できるところまでやる
- 事後に発覚する1脆弱性につきパッチ作成費用100万円 (広報費含まず、安い事例)。131件の脆弱性を事前に発見 = 1億3000万コスト削減と考えられる
- 計画・設計～実装段階で個々に脆弱性が入り込む
- セキュリティを考慮した設計の実施、脆弱性検査→有効だが、費用対効果が悪い
- プログラマにセキュアプログラミングセミナーを実施 (4時間の座学、必修)。これにより、脆弱性の指摘内容を理解できるようになる
- 少数精鋭のセキュリティ専門組織が、ドキュメントレビューとコードレビューを行う (4ヶ月のトレーニングプログラムを受講)
ドキュメントレビュー
- 脅威分析表を準備する。簡素化したエクセルシート1枚
- 全てを見るのではなく、セキュリティに関連する部分だけ見る。これはドキュメントのほんの一部
- 気になるキーワードを見つける。たとえば、「検索ボタン」というキーワードからSQLインジェクション、XSSが連想される
コードレビュー
- 静的コード解析ツールを使い、結果を分析・整理
- 警告が脆弱性につながるかどうかを判定すると、判定コストが修正コストを上回る場合がある
- 簡単に修正できる場合は無条件に修正する
LWSSA2.0
- LWSSA1.0の限界 : 専門組織が全ての製品をチェックするのは無理。技術分野が広すぎる(ブルーレイとか)
- LWSSA2.0 では……
- 開発者自身にセキュリティレビューを実施してもらう
- 核技術領域の開発者にセキュリティを教える
- 専門組織の中でセキュリティレビュアートレーニングプログラムを受ける。年間10名ほど、セキュリティレビューOJT
問答など
- SDLはどのくらい大変?
- 大変です。日本にいても英語で書かないといけない。携帯の端末IDについて本国に説明したりとか……。
- 超大変。ドキュメント間の関係性とか分からない
- 「脅威分析があまりに大変で仕事にならない。ホントにやってるのか?」と聞かれたこともある。
- インセンティブはあるのか?
- ない
- スキルを身につけたい人が自ら実践
- これをやっていないと製品を出せない決まり。製品が出せないということは、開発者の存在意義がなくなるということ (やらざるを得ない)
- レガシーコードはどう取り扱う?
- 最近になって着手 (費用対効果が高い、現在のコードから着手)
- 古いコードは問題が出やすい、10年前のコードとかもう意味が分からない
- Windowsは互換性を重視している。「メモリリークするけど動かなくなるから仕方ない」とかコメントが書かれていたりする。:-)
- 分からないコードは入れない、ばっさり捨てる覚悟で
- 失ったものは?
- 楽しいプログラミング、簡単なツールの提供ができない (外には出せない)
- Webアプリ開発に応用できそうか?
- できるんじゃないか
- 会社自体が数名の場合はできそう
- パッチのコストの話が興味深かったが、MSでは?
- 各国語版でのテストプロセスがとても大変
- 具体的には言えない (が、高い)
感想
Webの話じゃないじゃん!
とはいえ参考になりました。「後から脆弱性が発覚してパッチをリリースする」ということになるとコストが高くつくので、事前にやっておくことでコストが抑えられる……という話は説得力があります。
MSの真似をするのは難しいでしょうが、軽量版でできるところまでやる、というアプローチは面白いですね。どこまでやるのかがポイントでしょうが……。
「Security Wars EpisodeⅢ」に続きます。
関連する話題: セキュリティ / WASForum Conference
WASForum Conference 2008: OpenIDのセキュリティ
「携帯電話向けWebのセキュリティ」に続き、ZIGOROuさんによる「OpenIDのセキュリティ"」。こちらもスライドが公開されている (d.hatena.ne.jp)ようなので、感想のみ。
……「ピアノを弾く」は「ひく」で良いのですが、「アクセスを弾く」などは「はじく」と読むのが一般的なのではないかと思いました。
※それだけかよ! という声が聞こえてきそうですが、申し訳ないことにOpenIDってよく知らないのですよね。勉強しないとですね。
「セキュリティの作り込みはどのように行われているのか」に続きます。
関連する話題: セキュリティ / WASForum Conference
WASForum Conference 2008: 携帯電話向けWebのセキュリティ
「SQLインジェクション対策再考」に続いては「携帯電話向けWebのセキュリティ」。GREEの藤本さんによるお話です。
自転車とGREEについて
- 自転車はGIANTがオススメ
- GREEは2006年11月に携帯にシフト、携帯からのアクセスがぐんぐん増加
携帯の諸々
- Referer来ないかもしれない。auとSoftbankはおおむね来る。来ないなら来ないで統一されていれば良いものを……
- Cookieは、au来ます、Softbankは来ないかも。
Referer漏洩問題について
- そもそも他サイトにリンクしないこと。ドコモ公式では必須
- 端末不具合によって、何故かメールから叩いたURLに前のサイトのRefererが出ることが……
- セッション格納情報でチェックする? UA……Referer漏洩時点でばれている。端末固有情報?
- SIDを変えまくるという対策だと、戻ると死んだりする
- ユーザがGREEにGREEのURLを貼ることは多い (URLにはセッション追跡情報がついている)。GREEではURLをパースしてがんばっている
- 携帯ではHTMLソースは読めない? →スマートフォン経由だと読める場合があるので油断してはならない
携帯ネットワークの特徴
- 位置情報が取れる
- 課金システム
- IPアドレス帯域が固定(重要、絶対チェックした方が良い)
端末固有IDの偽装は可能か?
- 今のところ難しいようだ。ただしIPアドレス確認が必須。Softbankスマートフォン+iモードiDなどのパターンに注意
- ARP Spoofingのような手法による IP Spoofing はどうか?
- キャリアによって100%保証されているわけでもない
端末固有情報は一意?
- iモードIDは再使用されないことになっているのでユニーク
- 他の端末はどうだろう……
- メールアドレスの場合、別のユーザに再取得され得る
- SIMカードを入れ替えると別のUAからその端末情報が送られてくることがある
常識が通用しない
- パスワードは adgjmp 123456 などがほとんど
- ソーシャルハックにはとても脆弱
- 携帯の貸し借り、SIMカード貸し借り、簡単にパスワード教えたり……
凄いユーザがいる
- 総当たりフォースフルブラウジングとか普通に来る
- 8桁とかでも破られる。たとえば、着うたダウンロードのURL末尾が 1.mmf?dfX38fJu だった場合、8桁をひたすらブルートフォースでアクセスしてくるユーザがいる
質問
- 携帯キャリアのIPアドレス範囲のチェックはどうしているか?
- アンテナでキャリアのサイトをチェックしたりして頑張っている
- 逆引きするのはどうか?
- それは良いかもしれない
感想
質疑応答の「逆引きで見る」という話は瞬間的に「ヤバイかも」と思いましたが、高木さんが「そのDNSが安全かどうかという問題がありますが」とナイスフォロー。逆引きで判断する場合、PTRの値はそもそも信用できないのでパラノイド検査が必須になりますが、それでも大丈夫かどうかは怪しい感じがしますね。
※ちなみにパラノイド検査というのは、逆引きで得られた名前をさらに正引きして、元のIPアドレスと一致するか確認すること。
パスワードの話は興味深いですね。携帯端末からパスワードを入力するのはしんどいので、入力しやすいものをと考えると、どうしたって脆弱なものにしかなりません。普通に考えると、こまめにログアウトさせてパスワードを入れさせて……という方が安全そうですが、携帯サイトの世界では、パスワードに依存した認証は逆に危険なのかもしれません。
「OpenIDのセキュリティ」に続きます。
関連する話題: セキュリティ / 携帯電話 / WASForum Conference
WASForum Conference 2008: SQLインジェクション対策再考
2日目、「EV SSL の意義と課題」に引き続いての2発目は、徳丸さんによる「SQLインジェクション対策再考」。資料が公開されている (www.hash-c.co.jp)ので、私のメモとか必要ないですね。
若干補足すると、資料のp5～p6あたりの「セミコロン削除」「SQL構文に用いるような文字列はユーザーの入力としてはありえない」という部分ですが、ブログの記事を DB に格納するときにどうするのか、という話が出ていました。プログラムの話題を書いたときにセミコロンが全部消えてしまったら困りますから、セミコロンだろうとSQL構文だろうと、きちんと格納しなければならないのです。
質問として、「過剰エスケープはどうなのか」という話が出ましたが……。「セキュリティ的にはたぶん問題ないが、\が2重に表示される」。まあ、ぶっちゃけて言えばバグですね。実際、この手のバグはけっこうあちこちにあると思います。
私の感想
「ライオン・エスケープ」ですが、楽天テクノロジーカンファレンス2007「Web開発者のための最新セキュリティ動向」で出てきた「安心クッキー」のリスペクトですね。しかし、今回の話の流れの中で出すのであれば、カカクコムで探した方が良かったのではないかと思いました。
※サウンドハウスでも良いのですが、「エスケープ」で検索しても何もヒットしなかったのです。カカクコムにはいろいろありそうです。
※「感想ってそこだけかよ!!」とつっこまれそうですが、笑いのネタは気になるので。
「携帯電話向けWebのセキュリティ」に続きます。
関連する話題: セキュリティ / SQLインジェクション / WASForum Conference
WASForum Conference 2008: EV SSL の意義と課題
2日目のセッションは技術的なお話が中心になりました。まずは「EV SSL の意義と課題」についてのメモ。
SSLの課題
- 利用範囲の拡大とともに発行基準が多様化、匿名でも取得可能になった。
- 一般のエンドユーザが確認することは困難 (一般ユーザがCP/CPSを読むというのは現実的でない)
- 鍵マークへの信頼を逆手にとって、フィッシングサイトに悪用されるようにもなってきた
EV SSL
- SSL証明書の発行審査基準の標準化 + 一般ユーザに分かる仕組み
- CA/Browser Forum (CABF) による EV ガイドラインの制定 (2006/10) Vista登場の2ヶ月前
- 日本企業では発行できないガイドライン (組織名は登記簿謄本に記載のものと完全に一致しなければならないとされているが、日本の場合はたいてい漢字で書かれている……)
- JCAF: 日本語版ガイドラインの作成、日本の法体系沿う運用の提案 (Appendix F)
- これまでのSSL=南京錠ひとつ
- EV SSL = 暗号:南京錠、実在証明は別途表示
審査基準
- 各社によって何を「実在」とするかが異なっていた
- 実在証明とは?
- 法的実在
- 物理的実在
- 運用実在 (実際に企業活動を行っているか。海外:金融取引はあるのか、日本:帝国データバンク)
- 審査発行に関する外部監査が義務づけられている。第三者の監査法人によるチェックが入るため、例外運用が勝手にできない
課題
- 暗号アルゴリズム世代交代への対応
- 対応ブラウザの普及: 対応ブラウザがないと無意味。PCは良いが、携帯などが対応していない。実は、ブラウザの実装に関するガイドラインがない
- 日本語の取り扱い: UTF-8の文字をどう格納するのか
- 企業におけるドメインの管理: 大企業でもドメインの管理がルーズな場合が多い。ドメインの所有者とサイト管理者が異なる場合がある。これは認証局にとっても悩みのタネ、二重・三重の確認が必要。ドメインは企業の知的財産なので、ちゃんと会社で管理してください!
- 費用対効果の理解が得られるか: EV証明書は高い。普及すれば安くなるが、安くならないと普及しない。「フィッシング対策ソリューション」と比べると安いはずだが……。
暗号アルゴリズムの2010年問題
- 1024bit RSA は 2010年末までに 2048 bit に移行するべし。MD5はもちろん、SHA-1 も非推奨となる(SHA-256以降を推奨)。ただし SHA-256などはまだブラウザも対応していない
- 携帯などは1024bit のみ対応だったりする。携帯・PCふたつのサイトを立てなければならなくなる
- 移行を遅らせるべき、という提案をしている。1024bit解読には10ペタflopsが必要とされる、もう少し大丈夫。2012年まで待てば、ショボイ携帯は淘汰されて影響が最小限になると推察
質問
- EV for mobile というのがあるが?
ルートがふたつある特殊な証明書。ルートの片方は1024bitのみで辿れるようになっている。おそらく日本でしか発行されていない。
- Firefox3 で緑にならないのは?
原因はふたつ考えられる。
- ルート証明書の普及がまだかもしれない。
- XP と Vista で違う。Vista は EV を見つけると新しいルートを自動的に拾ってくる。XP でも何とかする技があるが、Vista の Firefox ではうまく行かないかもしれない。
私の感想
「EV SSL は高いけど、フィッシング対策ソリューションよりは安いでしょ」という話が印象に残りました。高いお金を払って使いにくいフィッシング対策を導入し、あげくそのソフトウェアが脆弱……なんて話もあったような気がしますが、ブラウザの基本機能で確認できるのが一番ですね。
「SQLインジェクション対策再考」に続きます。
関連する話題: セキュリティ / SSL/TLS / WASForum Conference
2008年7月4日(金曜日)
WASForum Conference 2008: パネル・ディスカッション「デファクトCIO、CTOのためのWEBサイトにまつわるITガバナンスの品格」
1日目の最後のセッションはパネルディスカッション。あまり網羅的にメモできていないので、やりとりの一部のみの抜粋という感じになっています。
※実はPCのバッテリがピンチでメモ回数をセーブしたため、ほとんどメモしていませんでした……。orz
ちなみにパネリストは、サイオステクノロジーの山崎靖之氏、サウンドハウスの中島尚彦社長、ライフネット生命保険の中川達彦氏、奈良先端科学技術大学院大学の門林雄基氏、そしておなじみ、産総研の高木浩光氏。以下のメモでは発言者名の敬称は略させていただいています。
Webを活用したビジネスでの心構えとは?
- 中島
お上からの言葉が分かりやすい。行政から「セキュリティ大事ですよ」と言われちゃったらやるだろう
- 高木
今まで2回くらい出てはいるのですが……。
2001年にXSSの問題を経産省の審議官に説明したとき、「これはワームのように広がるのか?」と聞かれた。広がらないよなぁと思いつつもいろいろ説明した。
経産省からプレスリリースは出ている。IPAセキュリティセンターの取り組み、情報セキュリティ白書などもある。しかし、中島社長の耳には届いていない。
認識のある人は注意してくれるのだが、認識のない人の耳には届かないという問題がある。
- 高木
サウンドハウスには、SQLインジェクションを知っている技術者がいたのか。
- 中島
2006年の時点でも最低2人はいた
- 高木
カカクコムの話で「技術が大切だということを知った」と言っていた。ちゃんとやれば守れると言うこと。
穴さえなければ良いのだと言うことを知っているかどうかがキーになる。
ベンダーはソリューションを売ろうとする。ハッカーセーフは有効か。
- 中島
……(何も言わず)。
この後、中島社長はしばらく沈黙。
あと、どなたの発言か忘れましたが、「リアル店舗では『なんか中国人が多い』とすぐ分かるが、Webではログを監視していないと分からない」という話があって印象に残っています。
セキュリティ対策、どこまでやれば適切なのか?
- 高木
外注と自社でだいぶ事情が違う。外注のケース、特に自治体発注で、ロクに見ずに検収してその後脆弱性発覚ということがある。
安全な作り方のスタンダードを作れば良い。
専門技術者が評価される仕組みが必要。試験ではなく、本当のプロフェッショナルをうまく評価する仕組みが必要。
- 中島
戦争なんだ、道路で人が倒れている。理屈抜きで助けてほしい。免許とかどうでも良い
セキュリティ対策コストは誰が負担するべきか?
- 中島
行政にがんばってほしい。くだらん道路を造るくらいなら援助してほしい。
- 中川
セキュリティ価格は消費者に転嫁されるが、消費者には区別がつかない。
NGNだと匿名性が少なくなるのではないか。
- 高木
(ぼそっと)NGNはダメだと思いますが
- 門林
Webは利用者に労働させることで安くしている。企業側が負っていたリスクも消費者に押しつけられている。
カード会社も16桁のカード番号と数桁のパスワードという脆弱な仕組みを使い続けたいために情報を隠蔽する。今のカードシステムは考え直した方が良いのかもしれない。もう Felica に変えてしまったら?
アメリカ主導の「カード」というシステムにこだわる必要はないのではないか。そうすることでリスク負担の構造も変えられるのではないか。
- 高木
一般市民も勉強してほしいという話があったが、話を聞くと、どうもサウンドハウスではDBにパスワードを生で格納していたということのようだ。そのような実装は非常識。
技術的な常識を全て把握していれば何も起きないはず。そういう常識を共有できる方法はないのか。
対策はしつくした、CIO、CTOができることは?
- 高木
セキュリティを分かっている人材を評価する仕組みをつくる。
- 門林
良き翻訳者になれ。経営サイドの言葉と技術サイドの言葉を両方理解すること。
- 中川
PDCAサイクルが重要。常にチェック、見つけたらアクションという流れを会社のプロセスに流し込む。
- 中島
一寸先は闇のジャングルの中にいるという認識を持つ。光がほしい。光、ガイダンスがほしい。
- 山崎
対策をしつくした状態が仮にあったとしても、環境が変化したら漏れが出る。
監視、モニターが必要。中川さんのPDCAの話に同意。
私の感想
中島社長に言いたかったことを高木さんが言ってくれたので、すっきりしました。:-)
中島社長はひたすら「行政が頑張れ」という主張を展開していましたが、高木さんは「既にやっている」と反論。「サウンドハウスには、SQLインジェクションを知っている技術者がいたのか」という質問はまさに核心ですが、これに「いた」と答える社長が凄い。「じゃあ、どうしてSQLインジェクションでやられたのですか?」……という質問は出ませんでしたが、その質問をしても建設的な感じの議論にはならなそうですね。
やはり認識が大きく違うのではないか、ということを再認識させられました。
……2日目に続きます。
関連する話題: セキュリティ / サウンドハウス / WASForum Conference
WASForum Conference 2008: ライフネット生命保険「インターネットとセキュリティに関する企業の責任」
サウンドハウス中島社長のお話に続いて、今年5月に開業したネット生保、ライフネット生命保険 (www.lifenet-seimei.co.jp)の中川さんのお話。
やられた人の経験談ではなく、ネット生保を新しく起業した立場から、セキュリティと企業の責任、CSRなどについてお話されました。あまり論評することもないので、ひたすら箇条書きでメモしておきます。
ネットライフ生命と既存の生保について
- 生保の約款は字が小さく、インクが薄く、紙が薄い
- ライフネットではダウンロードできるようにしている
- 普通の生命保険は、なんと契約しないと約款が見られない!
- 日本の保険は人件費が多い。保険の申込書をかわりに書いてくれたりもするような? (本当はやってはいけない)
企業の責任(CSR)
企業には4つの責任があるというお話。
- 経済的責任(義務) : 利益を上げる……配当金・給料・納税
- 法的責任(義務)
- 倫理的責任 : 社会から期待されていること。たとえば「機微情報は適切に扱ってくれるよね」という期待
- 社会公権的責任 : 社会からの要望
- ステークホルダーに対する説明責任がある。説明ができなければ社会に認めてもらえない、信頼を得られない企業は持続できない
- 生命保険は持続がとても大事 (10年、30年の商品であるため)。そのため、厳しい審査がある。ライフネットは戦後初の独立生保
- 情報セキュリティマネジメントは CSR への取り組みの一環として必要
- 競争の激化: カカクコムで価格比較できる。こんな事は昔はなかった。
- ビジネススピードが劇的に速くなり、チェックの時間も与えられなくなってきている
- 付加価値が競争の源泉となる時代が来ている
- 情報の価値が相対的に高まっている……ヒト・モノ・カネにプラスして情報、「情報」が第4の経営資源となる
- 企業は社会のネットワークの一部であり、社会全体の利益に貢献している
- 信用力が重要。その信用力はセキュリティ管理能力によって左右される
- 脆弱性 = 情報管理メカニズムの欠如。たとえば、トップが「売上げが低いから」とセキュリティ予算を削るのは、企業経営体質の脆弱性
対応
- 責任体制の明確化
- セキュリティガバナンスの確立
責任の明確化
- 情報セキュリティ課題に対応する責任……経営者
- 情報資産別に管理する責任……部門ごと
- 各組織別に業務上果たすべきセキュリティ上の責任……個々の従業員
- 人事規則に罰則までないと責任が明確化されたとは言えない
問題を起こさない対策
- 守るためのプロセスを作る
- プロセスが守られているか監査する
- 監査の結果を説明できるアカウンタビリティ
リスク分析手法の確立
- セキュリティ投資と事業の採算性
- セキュリティ投資は競争優位を勝ち取るため。セキュリティ投資は戦略投資
- セキュリティの対策は、リスクを顕在化させないための対策。しかし、リスクが顕在化しないと投資効果が分からない
- 受容可能なリスクから対策を検討
- リスクの分析、リスクを特定・評価、受容可能リスクの線引き
セキュリティ投資に意味はあるのか?
- 東京大学田中氏による統計的関連
- 目に見えない資産として評価される可能性がある
まとめ?
情報管理の仕組みの整備
- 能力と意思を分けて考える必要がある
- 能力 : 悪意による破壊が可能、ミスによる破壊が起こりえる
- 意図 : 社員はまじめだからやらないはずだ
- 意図は些細なことで変わる。解雇、不本意な転勤など。意図が変わった瞬間にその能力は脅威に変わる
情報管理の仕組みの整備
- 管理責任の所在を明確に
- オーナーを明確にする
- システム部門はオーナーの要件を満たすようにする
- オーナーとプロバイダを一にせず、分離する
- 経営者は責任分担に漏れがないことを確認する
- セキュリティを通じて企業の理念を実現する
- セキュリティレベル向上による企業価値の向上
……最後に、ライフネット生命の宣伝など。この会場に来ているようなネットリテラシの高い人は、クルマで言えば給油口を自分で開けて給油できる人。そういう人向けに
感想
私の感想ですが。
印象に残ったのは、「人事規則に罰則までないと責任が明確化されたとは言えない」というお話。それから、リスク分析と線引きの話でしょうか。
あとは、後のパネルディスカッションで投資額のお話が出たりしています。
このあと、パネルディスカッションに続きます。
関連する話題: セキュリティ / WASForum Conference / CSR
WASForum Conference 2008: サウンドハウス「Web攻撃の脅威に立ち向かうには」
1日目、カカクコムのお話の次に来たのがサウンドハウス (www.soundhouse.co.jp)のお話。
今年の4月にクレジットカード情報の流出が発覚し、大胆なプレスリリースが話題になったサウンドハウスですが、中島社長自らがお話しされるということで、かなり期待していました。実際にお話を聞いてみると、これがもうメチャクチャ面白かったです。ただ、あの話し方、身振り、スライド、どれ一つが欠けてもこの面白さは出ないと思いますので、生で見ていない人に面白さを伝えるのは難しいと思います。
※ちなみにスライドの一部は使い回しのようです。「「被害を隠すな」サウンドハウス社長が不正アクセス体験語る (internet.watch.impress.co.jp)」に掲載されているものはおおむね使い回されていました。
ともあれ、話された内容をメモしておきます。ほぼ手元のメモのままなので、長いですが……。
導入部
最初の一言が「サイバー戦争」。「戦争」というキーワードは何度も何度も出てきます。
- サウンドハウスができてから15年、突然、攻撃を受けた
- 奇襲攻撃。あっと気がついたらやられている。実体が見えてこない
- SQLインジェクションのミサイルが飛んできている。特に中国から多数のミサイルが来ている。しかも、ミサイルは目に見えない
この「ミサイル」のくだりのスライドがまた秀逸で、会場は爆笑していました。
事件までの経緯
サウンドハウスの紹介と、事件までの経緯。
- やることはやってきたつもり。最善の対策を取れと言ってきた。
- サウンドハウスは業界では大手。30万の顧客データベースをもち、毎年1～2割の増益を継続している会社
- 2005年1月、ハッカーセーフ導入
そして話は「ハッカーセーフ」の内容に。
ハッカーセーフについて
- システム脆弱性を検知する
- 詳細レポートが送られてくる。それぞれの脆弱性は5段階評価で通知され、レベル3より高い脆弱性が検知された場合、72時間以内に対応しないとシールが剥奪される。ただし、そういう高レベルな報告が来ることはほとんど無い
なぜハッカーセーフが効かなかったのかという理由について。
- Webアプリケーションは自社開発だが、消し忘れた不要ページがあったのかもしれない (.aspが2500ほどあり、管理しきれていなかった)
- ハッカーセーフが脆弱性のあるページを見逃した可能性も考えられる。たとえば、リンク切れのページは検証できない
さらに、ハッカーセーフについての反省点の話。
- ハッカーセーフの指示で対策を講じていれば良いと思っていた (が、十分ではないと分かった)。
- 例の中国のブログ (参考:「「サウンドハウス」名指しの攻撃マニュアルが中国で公開されていた (internet.watch.impress.co.jp)」) が書かれた日のハッカーセーフレポートを見ると、レベル1の危険度のみが報告されていた
- 対策も表示されるのだが、「対策は特に必要ありません」と言われたので安心してしまった
このときハッカーセーフのレポート画面が映されましたが、そのレポートは「IISがBasic認証またはNTLM認証を許容」というものでした。これはもちろん脆弱性ではなく、「念のためお知らせ」レベルのものでしょう。要するに、何も検知されていなかったということだと思います。
情報漏洩について
情報漏洩の規模とその公表についての話。このへんからちょっと微妙な空気が流れてきます。
- 1回のアクセスで20件引き出し、それが4875回のアクセスで、掛け算して97500件の漏洩と発表
- 2007年～2008年の、新規登録者の顧客データのみが対象
- カードデータの登録は27743件
- うち、2008年の登録は4811件
- さらに、被害のほとんどはカードとサウンドハウスのパスワードが同一の場合
……何が言いたいのかイマイチ分からないまま聞いていると……。
- 実際の被害規模は、4811×8割(カードのパスワードがサウンドハウスのパスワードと同一の人の割合)×5割(攻撃成功の割合) で 1000～2000件くらいだと思う
- しかし、LACの人に「漏洩の可能性があるMAXの件数で発表するべし」という旨のことを言われたので、97,500件の漏洩と発表した
LACならずとも「漏らした側の人が言ってはダメだろう」と思いますが、後の話と総合すると、「真の被害規模が見えない」ということを仰りたかったのだと思います。話は続きます。
悩み
サウンドハウスの悩み、困ったことなど。
悩み1. 被害の実態が見えない
- カード会社からの情報提供がないため、被害が何件なのか、いくらの被害が出たのか、誰が被害にあったのか分からない
- お客様からの直接の連絡は数十件あった
悩み2. 流出の原因が確定できない
- バックドアがあったのではないかと言われるが、あくまで想像でしかない
- サウンドハウス本体では古いログは残っていなかった (2007年以降のもののみ存在)
- 家具を扱う子会社がたまたま2006年のログを持っていた。それをLACが一緒くたにして検証した結果、その2006年のログからバックドア混入の形跡を発見。そこで、本体サイトも同様だったのではないかと推測された
悩み3. 迅速な情報公開が不可能
- 自社の判断で動けなかった。問い合わせの受け皿となるカード会社の準備が整っていないので、報告は出すなと言われた
- ニコスはJCBより4日準備が早かった。:-)
- 実際には、カード会社は個々のお客様にはカード停止/番号の変更を告知している
- お客様からは「なんで情報公開しないのか」というクレームも寄せられ、つらかった
このあたりは、プレスリリースでも赤裸々に語られていましたね。
悩み4. 顧客対応が困難
- お客様からの質問はだんだんエスカレートし、「カード会社とのやりとりの内容を教えろ」などいろいろ言われた
- メールでの問い合わせは4000件
- 電話は数千件
- 社長も数百件のメールを書いた
悩み5. カード会社との関係
- 問題発生時点で、サウンドハウスでのカード利用はストップ
- 再開できないとお客様が困るので、再開したいとカード会社に働きかけているが……
- JCBからは、「9月30日をもって契約を解除する」という内容証明が送られてきた。プレスリリースの内容が気に入らなかったからか (会場爆笑)
- ニコスからは、2日前 (7月2日?) に、「あと1～2週間で連絡する」という旨の連絡があったので、楽しみにしている
悩み6. 企業業績の悪化
- サウンドハウスの38%の売上げがカードによるもの
- カードが使えなくなって売上げが落ち込み、前年比 -11% となる
- ただし、今月は前年比 +1% で推移しており順調
- カードが使えなくなっても良いかもしれないとも思っている。サウンドハウスのファンのお客様は利用し続けてくれるだろう
悩み7. 周囲からのサポートが無い
- 救助どころかたたかれる
- 唯一あったのは、IPA から。「相談乗るよ」という主旨のことを言われた
- 経産省は1回呼ばれただけで音沙汰なし
- 唯一頼れるのはLAC。言えば飛んできてくれる。LACこそが日本のセキュリティ対策の鍵
講演全体を通して、「LAC最高」「LACは神」という主旨の発言が連発されていました。
悩み8. プレスリリース
- 本音がうまく伝わらない
- カード会社が悪いと言ったつもりはないのだが……
悩みの話は以上ですが、情報が少なくて実際のところ何が起きているのか分からない、という話が悩みのメインであるように思います。他に類を見ないプレスリリースが出ましたが、情報がなさ過ぎて本当に困っていたからこそ、自らはとにかく積極的に情報公開するという姿勢になったのかもしれません。それがやり過ぎかどうかは、まあ、議論の分かれるところでしょう。
教訓
今回の事件で得られた教訓。
……この辺、話の進行が早かったので手元のメモが漏れがちになっています。だいぶ抜けがあるかも。
新セキュリティ対策の徹底
新しいセキュリティ対策を徹底したという話。スライドの図は、おそらく「「被害を隠すな」サウンドハウス社長が不正アクセス体験語る (internet.watch.impress.co.jp)」に掲載されている「情報漏洩事件前後のセキュリティ対策」という画像と同じものなので、そちらを見ていただければと。
- 新しいサーバルームを作った。一部屋丸ごとサーバルームにして入退室を管理
- 一番大事なのは24時間の監視体制。LACのJSOC (www.lac.co.jp)を利用
- どんな防弾チョッキを着ても、マシンガンで撃たれっぱなしならば穴が開く。弾が当たったら徹底して検証する必要がある
外部企業とのタイアップ
- LACに全てを賭けている
- LACとは一心同体。彼らがこけたら私もこける
カード会社と連携プレーを強化
- 今はありません (会場爆笑)
- 実際、連携が何もなかった。情報が入ってこなければ対策が打てない
周辺企業を取り込んだ情報交換
- 某社が同等の被害を受けた
- お宅はどうしてるのとか、そういう情報交換が必要
セキュリティ対策の高いハードル
「日本困難で委員会」の話。スライドは「「被害を隠すな」サウンドハウス社長が不正アクセス体験語る (internet.watch.impress.co.jp)」に掲載されている画像と同じものです。
そのまんまなのですが、セキュリティ会社への提言だけメモ。
- 社会のためにデータを公表してほしい
- 他者の被害事例については、「いっぱいやられている」という話は聞くものの、公表できないと言われる
- 被害を受けた会社をなんとか説得して、被害事例を公表してほしい
今後の提言
空襲警報
- 攻撃が起きれば即、アラートを出す仕組みを構築
これは出ていると思いますが、伝わっていないということかと……。のちに、高木さんが別のセッションでツッコミを入れられています。
自己防衛
- 消費者に対して自己防衛手段を啓蒙する
- たとえば、今回の事件ではサウンドハウスのログインパスワードとカードのパスワードが同一の人が被害にあったと考えられる。パスワードを使い回さないように、という啓蒙が必要なのではないか
これも、高木さんがのちにツッコミ。
不正排除
- 不正プログラム、不正操作、不正人材を見極める必要がある
- 業界にはスパイがいるのではないか。ハードウェアの入れ替えの話を進めていたら、そのタイミングでやられた。他社でも同じタイミングでやられたことがあると聞いている
……後者の話はどこまで本気なのか分かりませんでしたが、あらためて「「被害を隠すな」サウンドハウス社長が不正アクセス体験語る (internet.watch.impress.co.jp)」を見ると同じことを言われているようなので、わりと本気なのかもしれません。以下、記事の該当部分の引用です。
攻撃者は2006年6月以降、確実に換金できる手段として、事件にならない程度に細々とカードを不正使用していたのかもしれない。弊社では、情報漏洩が発覚する数カ月前からセキュリティ対策を一新する予定を立てていた。あくまで推測だが、この情報が何らかの経路で攻撃者に伝わり、攻撃者が『時間切れ』ということで一斉攻撃を行なった可能性がある。
この情報の経路としてハード屋さんを疑っている、ということのようですね。
実践装備
- 実装レベルでのセキュリティ対策を安価に普及
対策本部
- セキュリティ情報収集して即断できるメカニズムの構築
人材確保
- ハッキングに優れた人材、セキュリティのプロを仲間にする
- 中国やアメリカではできると思うが、日本では難しいのではないか
日本には「情報セキュリティ早期警戒パートナーシップ」というものがあるために、「ハッカー」は情報開示せずにひっそり届け出ることを求められており、世間に情報が行き渡らない……などという話は全然出ていないです。念のため。
基準設定
- セキュリティ対策基準を明確にして、普及に努める
提言はこんなところ。関連するのでここにメモしておきますが、社長は後に別のセッションで、「行政にがんばってほしい。くだらん道路を造るくらいなら援助してほしい」という発言もされていました。
結び
最後に、この言葉で締めくくられました。
- 「絶対に負けられない戦いののろしが上がった! いざ、出陣!!」
残念ながら質問タイムは無し。質問というか、言いたいことはとてもたくさんありましたが……幸い、後のセッションで高木さんがほとんど言ってくださいました。それについては別途書こうと思います。
感想
私の感想を。
まず、なんと言っても中島社長のキャラクターに圧倒されました。話がとても面白いので、また機会があれば是非、生で聞きたいと思います。メモにはあまり書いていませんが、全体を通して「お客様が困る」「お客様に迷惑がかかる」「お客様のために」と、お客様を第一に考える旨の発言をされていました。非常にまっすぐで、好感の持てる人だという印象を受けました。
ただ、話の内容に賛同できるかどうかと言われると、これはまた別の話になります。
まず、脆弱性についての認識。中島社長の認識は、「戦争」というキーワードで象徴されます。気がついたら弾の飛び交う戦場のただなかにいた……というような表現もされていましたが、「普通の人はSQLインジェクションの弾が当たっても怪我一つしない」などという認識はないでしょう。「普通にちゃんと作れば攻撃されても平気」という認識ではなく、「普通にちゃんと作っても攻撃されてしまうので、厳重な対策が必要」という認識で議論を始められているように思います。この点、多くの技術者の方とは認識が異なるのではないでしょうか。「技術が重要」と言われるカカクコムの安田さんとも対照的だと思います。
関連しますが、提言がどこか他力本願なのも気になりました。「LACだけが頼り」とか「お役所から言ってもらわないと」といった発言がありましたが、「誰かが何かをしてくれるだろう」という受け身の体勢に見えます。意地悪な見方をすれば、「単にハッカーセーフがLACに変わっただけで、本質は変わっていない」とも言えそうです。ただ、前述したように、基本的な認識の部分が違っているために「誰かに何とかしてもらわないと、自分ではどうにもならない」と感じられているのではないかとも思えますが……。
積極的な情報公開をしたい、してほしい、という姿勢には共感できる点もあり、頑張ってほしいところです。
※余談ですが、2日目の最後のセッションはほぼツッコミ大会でした。この話を聞いていなかった人にはわからなそうなネタが大量に……。
続きます : ライフネット生命保険「インターネットとセキュリティに関する企業の責任」。
関連する話題: セキュリティ / サウンドハウス / 価格.com / ハッカーセーフ / WASForum Conference / シール
WASForum Conference 2008: カカクコム「不正アクセス事件から学んだ事」
WASForum Conference 2008 (wasforum.jp)に行ってきました。印象に残った話を中心に、とりとめなくメモしておきます。
まずは1日目、「不正アクセス事件から学んだ事」について。2005年に不正アクセスでサイト閉鎖となったカカクコム (kakaku.com)の、安田さんのお話です。
事件の経緯
まず事件の経緯の話などが出ますが、まあそれはさんざん出ているので割愛します。細かい部分で興味深い話が2点ほど。
- 改竄を把握したのは水曜。改竄部分を戻したら問題なかったようなので運営を継続したが、その後も断続的に改竄と修正を繰り返した。土曜の夕方に一旦サーバを停止。その後再開するも、土曜の夜になって改竄の頻度が非常に高くなり、改修での対応は無理だと判断して閉鎖に至った。
- 「どのくらいで復旧できるのか?」と社長に詰め寄られ、「一週間くらい」と返答 (実際には10日間の閉鎖)。
サイト閉鎖後のシステム対応
サイト閉鎖後のシステム系の対応について。
- OS、ソフトウェアの全再インストール。LACの人から、「ひそかにバックドアが残されているかもしれないので必須」というようなことを言われて実施。100～150台ほどあるサーバすべてについて、地道にCDからインストールを実施。2交代制 (朝10時と夜10時に人員入れ替え) でひたすら作業。しかし、これが完了してもすぐには動作してくれず、色々調整が必要だった。
- お店の人に値段を入れてもらう必要があるため、先にショップ側管理画面を再開。このとき負荷が高くなったりして色々あった模様。
- プログラムの見直し・強化を実施。OS、ネットワークレベルでのスキャンなどを実施。全体で約9000ものプログラムが存在しており、10日間で全体をチェックすることができなかったため、まずは価格比較部分のみ復旧。他は随時、3ヶ月ほどかけて復旧。
- ログを再確認したところ、3ヶ月～半年ほど前から予兆的なアクセスの痕跡があったことが判明。ちゃんと監視していればもっと早くに気づいていただろうということで、監視を強化。
- メールアドレスが個人情報なのかどうかは色々面倒な議論があるが、ともあれメールアドレス以上のクラスの情報は暗号化してから保存、というルールをつくって徹底。
社内の対応
社内の仕組みとして、以下のようなことを実施。
- 社長直属の情報セキュリティ室を設置
- セキュリティ委員会による外部の有識者との会議
- 社員への教育 (ガイアの夜明けDVDを社員教育に使用)
- 連絡網の整備、随時アップデートが必要。何かあったとき、判断を誰が下すのかを決めておかなければならない
ここで一番印象深かったのは、「セキュリティを第一とした企業文化の構築」という言葉。企業文化の改革が必要だったと。
対外的な対応
その他、対外的な対応。
- 当然ながら、ユーザへの対応が発生。コンテンツチームを中心に、電話・メールへ返答。
- 警察への報告は苦労したとのこと。所轄と警視庁のサイバーチーム両方の協力を得たりしながら進めるが、事件性があるかどうかは被害者側が実証しなければならないと言われた。アクセス制御機能があったことを証明しなければ不正アクセス事件として立件できない。警察にはWebサーバとDBサーバを引き渡したり、ネットワーク図なども渡したり。
- 経済産業省にも報告。「何で対策していなかったのだ」という主旨のことを厳しく言われ、もっとも厳しかった。:-)
- 株式市場への対応も行う必要があった。カカクコムはWebサイトが事業の全てなので、サイト閉鎖はすなわち商売をしていないということで、事業継続性が疑われることになる。再開が延びれば延びるほど厳しくなる。
- ショップへの対応。カカクコムに完全依存したショップが多く、「いつになったらオープンするのか」という問い合わせが多数あった。秋葉原のショップをまわりながら説明したり、暫定的に店へのリンク集をつくって対応したり。
※実際には「アクセス制御機能」ではなく「アクセス権限」と仰っていましたが、文脈からして、不正アクセス禁止法第2条3項で定義されている「アクセス制御機能」の事と思われます。
総論
- 「セキュリティ事故は、企業にとって致命的である」ということ。メールアドレス流出による被害問い合わせは事件から1年半ほど続き、謝り続けた。そのメールアドレスが本当にカカクコムから盗まれたのかどうかは分かりませんが、そうでないという証明もできないので、謝るしかない。
- 「セキュリティを守るのは技術と文化」。まず技術、たゆまぬ技術力の向上が必要、技術的な部分が大きい、技術負けしないように。ただし、技術があっても運用されなければ腐ってしまうので、マネージメント、会社としての取り組みも必要。優先度で言うと、1に技術、2に文化で、技術のほうが重要。
質問
質問の時間。情報公開しなかったことについてどう思っているのか訊きたかったのですが、武田さん (motivate.jp)がズバリの質問をしてくださいました。
で、回答ですが、「当時はそれで良かったと思っている」とのこと。ちなみに、例の「NDAを結んで情報開示」という話は20社くらい来て契約を結んだそうです。さらに、「今度あったらどうか」という質問をされましたが、それについては「インパクトや責任によって変わっていく」という、当たり障りのないご回答でした。
それから、セキュリティ投資はどのくらいしているのか、という質問が出ましたが、「カカクコムの場合は売上げの数%だが、必要なものを積み上げて行くだけ」というお話でした。
感想
最後に私の感想を。
後半で「技術」を強調されたのが印象的でした。元々Webで営業している企業だからだということもあるのでしょうが、後に話されたサウンドハウスの中島社長とは対照的です。カカクコムの人たちは「SQLインジェクション」というものが何なのか理解していて、何が必要なのかも分かっているという印象でした。
情報公開に関しては、会社の公式見解としては「正しかった」と言うしかないと思うのですが、中の人の心境としては複雑なのかもしれないなぁ、と深読みしております。
カカクコムのお話は以上。次は最高に面白かったサウンドハウスの中島社長のお話ですが、ここに続けると長くなりすぎてしまうので、別途書こうと思います。というわけで続きます……WASForum Conference 2008: サウンドハウス「Web攻撃の脅威に立ち向かうには」。
関連する話題: セキュリティ / サウンドハウス / 価格.com / WASForum Conference
2008年7月2日(水曜日)
海原雄山はツンデレ
購入。
- 美味しんぼ102 (www.amazon.co.jp)
そういえば少し前に「山岡と海原雄山がついに和解!」などというニュースが出ていましたが、その話が収録されています。……まあ、和解じみたエピソードは何度かあったような気もしますが…… (結婚式の時とか、「おやじ……」発言とか)。
※しかし、山岡が海原雄山を乗り越えるという話ですが、1巻から読んでいた読者からすると、海原雄山の成長ぶりのほうがめざましいと思えるわけで。最近の海原雄山は、杖で人を突いたりとか、料亭で料理をひっくり返したりとか、人に器を投げつけたりとか、人を罵倒したりとか、そういうことを一切しなくなりましたし。
2008年7月1日(火曜日)
Firefox3のオレオレ警告も……
「高木浩光＠自宅の日記 - 主婦の友社が早速やらかしてくれました (takagi-hiromitsu.jp)」。Firefox3のオレオレ警告の話ですが……うーむ。
もちろん、http://www.aka-hoshi.net/goriyou/index02.html は HTTPS ではないわけですから、この記述自体も攻撃者の用意した罠である可能性があります。Firefox3 の「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」という警告は、「サイトにこの操作をしろと書いてあっても、それはおそらく攻撃者の罠なので信用してはならない」という意味でもあるはずです。
が、そこまでユーザに伝わっているのかどうか……。
- 前(古い): 2008年6月のえび日記
- 次(新しい): 2008年8月のえび日記
