水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > WASForum Conference 2008: セキュリティの作り込みはどのように行われているのか?

WASForum Conference 2008: セキュリティの作り込みはどのように行われているのか?

2008年7月5日(土曜日)

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

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト