2008年7月5日に開催された「WASForum Conference 2008」の2日目「事件は現場で起こっている……セキュリティライフサイクルとマルプラクティス」に参加しました。GREE の藤本真樹さんの携帯電話絡みの話と、Sony の松並さんのセキュリティライフサイクルの話が、特に興味深かったです。
以下、簡単なレポートです。
- 開催日時: 2008年7月5日 10:00～17:00
- 場所: 東京・東銀座 時事通信ホール
- テーマ: 事件は現場で起こっている……セキュリティライフサイクルとマルプラクティス
Morning Session: 今どきのWebセキュリティ
- EV SSLの意義と課題 (日本電子認証協会 秋山卓司氏)
- SQLインジェクション対策再考 (HASHコンサルティング 徳丸浩氏)
- 正しくない対策の例
- SQL文を全角化して格納
- セミコロンを拒否(複文を受け付けないようにしたい)
→ データの中にはセミコロンを含む場合もあるので駄目
← SQL Server ではセミコロンなしでも複文が書けるので、対策にはならない (他のミドルウェアでは効果があるかもしれないけど、SQL Server では無意味) - %20 を \%20 に変換して格納 → 全く意味なし(効果なし)
- 削除するキーワードのリストを作っておいて、そのリストに載っているキーワードを削除してから格納
→ 誤爆が排除できない
- 正しい対策
- バインドを使う
- バインドが使えない場合
- 文字列 → シングルクォートで囲む。シングルクォートが含まれる場合は、シングルクォート2個に変換
- 数値 → 妥当性チェックを実施
- Shift_jis は避ける
- Shift_jis では漢字の2バイト目に \ (0x5c) 相当のコードが来ることがあるので、いろいろやっかい。UTF-8 を使う
- 正しくない対策の例
- 携帯電話向けWebのセキュリティ (グリー 藤本真樹氏)
- 携帯電話では
- referer がない
- クッキーが使えない (使える端末もあるが、使えないことを前提にした方がよい)
- セッションハイジャックされやすい
- 端末固有情報を使うことで、セッションハイジャックを回避
- アクセス毎にセッションIDを変える
→ 「前のページへ戻る」操作をされてしまうと駄目(欠点)
- 日記に URL を貼り付ける人がいる。当然、セッションIDつきのまま、貼り付けられることになる
→ その URL へのアクセス時、動的にセッションID部分を各ユーザ本来のセッションIDに挿げ替えるような処理を入れることで対策している - その他、携帯特有の問題など
- 中高生とか、携帯の貸し借りが多い → お手上げ
- パスワードがいい加減な人が多い
- 携帯は買い替えが多いため、(電話番号をそのまま使った)メールアドレスの再利用が頻繁に発生する
→ 以前の携帯の持ち主へメールを送ったつもりが、新しい持ち主に届いてしまう - IPスプーフィング対策として、携帯キャリアが割り当てているIPアドレス以外からのアクセス(PCからのアクセスとか)は拒否するようにしている
→ 結構、突発的に変わるため、変わったことを知らずにいると、PC用のWebページを携帯に送ってしまうこともある (実際に、最近も mixi で発生していた)
→ 告知用のページをはてなアンテナに登録して監視している。告知されるのは実際に実施される3日前とか、かなりぎりぎりなので、見落としやすい
- 携帯電話では
- OpenID のセキュリティ (サイボウズラボ 山口徹氏)
- OpenID は(適切な対策を行なわない限り)中間者攻撃に弱い(盗聴、なりすまし)
- OpenID にはログインの概念はあるが、ログアウトの概念はない
Afternoon Session: セキュリティデベロップメント“ライフサイクル”: 裏側と表側
- セキュリティの作りこみはどのように行なわれているのか
- (1-a) マイクロソフト 加治佐俊一氏
- マイクロソフトの SDL、SD3+C の解説
- 2001年、CODE RED、Nimda 対策として、最初のセキュリティに関する取り組みを開始
- XP には間に合わず、その時点で開発途中だった Windows Server 2003 から適用対象
- 開発者全員(約8000人)がいったん開発作業を停止し、開発中の製品の総点検
- その間、開発は止まったまま。最初1ヶ月の予定が、結局3ヶ月(でも完全には終わらず。一部の人間を残し、開発作業に戻る)
- 2004年に Security Development Lifecycle (SDL) という取り組みを開始 (作業結果は ISMS の100倍くらいの量の文書になる)
- その後も SDL の改良は続けられ、現在は SD3+C (C は communication)に進化
- SD3+C: Security by Design, by Default and in deployment, and Communications
- 2001年、CODE RED、Nimda 対策として、最初のセキュリティに関する取り組みを開始
- マイクロソフトの SDL、SD3+C の解説
- (1-b) ソニー(の子会社) 松並勝氏
- 自社でのセキュリティへの取り組み方 (現在、親会社のソニーへも展開中)
- SDL はマイクロソフトだからできるのであって、普通の会社には無理
- 8000人がかりで総点検とか、ISMS の100倍くらいの量の文書とか、他の会社ではほとんど不可能
- 極力コストをかけず、簡単にできて、それでいて効果の高い方法を模索
- ライトウェイトアプローチ (LWSSA)
- 費用対効果の高いものから順に手をつける
- 全プログラマ対象にセキュアプログラミング教育(4時間)を実施
- ドキュメントのみを対象としたセキュリティレビュー専門組織を立ち上げる
- 組織所属員は4ヶ月間のセキュリティトレーニングを受ける (必須)
- ドキュメントのレビューは、隅から隅まで全部見ていたらきりがないので、「気になるキーワード、文章」を検索し、その近辺を重点的に読む
- 脅威分析表(重要キーワード一覧)にしたがってチェック
- 見る範囲を絞る
- コードレビュー
- 静的解析ツールで分析
- 結果の精査は「セキュリティレビュー専門組織」でやる
- 精査の途中で上がってきた修正すべき項目を開発者に順次伝えつつ、修正コストがどれくらいになるかをインタビューし、コストの低い修正だけを行なうようにする (修正コストを考慮した脆弱性分析)
- 結果の精査は「セキュリティレビュー専門組織」でやる
- 静的解析ツールで分析
- 「セキュリティレビュー専門組織」の負担が大きすぎることがわかってきた
- 開発者によるセキュリティの作りこみ
- コードレビューは開発者自身にやらせる
- 各プロジェクトにセキュリティのことがわかる人間を最低1人はつくる
→ 「セキュリティレビュー専門組織」向けの4ヶ月間のトレーニングを受けさせる (会社全体で、毎年10人くらいづつ教育している)- 「セキュリティレビュー専門組織」内に教育対象者を受け入れて、OJT 形式で教育を実施
- 「セキュリティレビュー専門組織」の仕事をやらせる
- 費用対効果の高いものから順に手をつける
- ライトウェイトアプローチ (LWSSA)
- SDL はマイクロソフトだからできるのであって、普通の会社には無理
- 自社でのセキュリティへの取り組み方 (現在、親会社のソニーへも展開中)
- (1-a) マイクロソフト 加治佐俊一氏
- Security Wars Episode III (高橋郁夫弁護士)
- ダースベーダーのコスプレで登場
- Star Wars 風プレゼン資料
- Eposode I 闇に落ちたハッカー
- Episode II 匿名軍団の攻撃
- Episode III 希望か絶望か
- Webセキュリティのマルプラクティス (門林雄基さん、岡田良太郎さん)
- マルプラクティスというのは、「間違ったプラクティス」というような意味
- 会場の反応を集計するための仕組みが秀逸
- 会場からは指定URLにアクセスして投票、あるいはコメント投稿
- 間違ったセキュリティ対策、間違ったIT技術の使い方を列挙
- 「発火セーフを入れるだけで安心」(そんなわけない)
- 最後は、「マル」を含むダジャレによる間違ったプラクティスの列挙
感想
- グリー(GREE)の人の携帯電話関連の話は非常に興味深く、おもしろかったです。
- ソニーの人の取り組みは、他の組織でも大いに参考になるし、取り込めるものは取り込んだ方がいいのではないかと、思います。ただし、4ヶ月間拘束して(その間、その人本来の業務は完全に止まる)のセキュリティ教育は、たいていの組織で無理なんじゃないかとも思います。