水無月ばけらのえび日記

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. が必要

ソニーの製品セキュリティへの取り組み

• 家電製品のセキュリティ……被害は多発していない、対策の価値がエンドユーザに認知されていない
• セキュリティ対策のために製品の価格を上げることは許されない (多くのコストはかけられない)

ライトウェイトアプローチ (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の真似をするのは難しいでしょうが、軽量版でできるところまでやる、というアプローチは面白いですね。どこまでやるのかがポイントでしょうが……。