|
マイクロソフトディベロップメント株式会社
文＝吉田 航太郎オフィスサービス開発統括部 インプットメソッドテクノロジー 日本においてIMEの開発を担当し，実際にマイクロソフトのセキュリティ開発ライフサイクルを導入し，セキュアなアプリケーションの構築を実践している。 |
これまで3回に渡って，セキュアなアプリケーション・ソフトウエアを開発するにあたって開発者が考慮すべき基本的な考え方を紹介し，Webアプリケーションの例を取ってそれを掘り下げた。最終回となる今回は，より具体的な例として，セキュアなソフトウエアの開発のためにマイクロソフトの開発部門で実践され，効果をあげている開発モデルを紹介する。 |
マイクロソフトでは，セキュリティに対する社会的関心の高まりに応え，2002年に当時開発中だった「Windows Server2003」に対して「セキュリティプッシュ」と呼ばれるセキュリティに特化した開発フェーズを実行しました。この開発フェーズは，
- 開発者全員のセキュリティ技術教育
- 新たな知識に基づく設計の再検証
- 開発中のソースコードに対する自動／手動両方のコードレビュー
- 新たに導入したツールによる潜在的なセキュリティバグの検出と修正
などからなり，セキュリティに関連しない作業を一旦完全に停止した上で，Windows Server 2003に関わる開発者全員が数カ月という期間をこれだけに集中するという大がかりなものでした。
このイベントに先立ち設立されたのがSWI（Secure Windows Initiative）チームで，セキュリティプッシュでは開発者に対する技術サポートなどで中心的な役割を果たしました。マイクロソフトの製品開発現場におけるセキュリティに対する取り組みはその後も継続的に行われ，開発現場からのフィードバックを反映しながら，セキュアなアプリケーション開発のためのベストプラクティスはやがてSDL（Security Development Lifecycle）と呼ばれる開発プロセスを形作っています。
今ではSWIチームはWindows開発チームから離れ，マイクロソフト内のどの開発チームからも独立したセキュリティ専門チームとして，多くのマイクロソフト製品のセキュリティ向上に重要な役割を果たしています。SDLの開発・メンテナンス・拡張はSWIチームの責任の1つであり，マイクロソフトの開発現場では，多くの製品開発チームがSDL を採用し，SWIチームと協力しながらセキュアなソフトウエアの開発を行っています。
マイクロソフトでは，セキュアなソフトウエアを構築するための4大原則を，以下のようにSD³+Cとして定めています。
- Secure by Design――設計の時点からセキュリティを考慮する
- Secure by Default――既定の設定をより安全側に倒す
- Secure in Deployment――ソフトウエアの導入・設定が安全に行え，更新の適用が容易に行えるようにする
- Communications――出荷後の製品に脆弱性が発見された場合に，エンドユーザーや管理者が防御手段を取れるように率直に責任を持って伝える
通常，ソフトウエア開発プロセスは，「要件（要求分析）」，「設計」，「実装」，「検証」，「リリース」，「サポートおよびサービス」の6 つの工程に分けて考えます。SDLとは「これら6つの工程の各ステップに対してSD³+Cを実現するために必要な作業項目を追加したもの」と言うことができます。以下ではその内容を解説し，併せてマイクロソフト社内で実際に行われているSDLの運用事例をご紹介しましょう。
0. 教育
開発工程を進める前に，前提条件として開発者に対しセキュアなソフトウエア開発技術に関する教育を行うことが重要です。また，攻撃方法やその対抗技術は年々進化を続けていますから，最新の情報に基づいた再教育を繰り返し行うことが必要です。マイクロソフトでは，SWI チームが教育サービスを提供し，一方，製品開発チームには開発者全員が最新の教材で毎年再教育を受けることが義務付けられています。
1. 要件（要求分析）フェーズ
要件フェーズでは，セキュリティ上の観点から，「製品にどういう機能が必要か」，あるいは逆に「どういう機能は提供すべきでないか」を分析します。
2. 設計フェーズ
このフェーズに加えられる重要な作業項目としては，Attack surface（攻撃対象領域）の文書化とThreat modeling（脅威モデリング）があります。基本的に，ソフトウエアが外界と接している部分はすべてAttack surface になり得ます。Attack surfaceをゼロにすることは現実的には不可能ですが，無意味にそれを広げ，リスクを増やさないようにすることは重要です。
同時に，そのソフトウエアに対してどういう攻撃が考えられ，その発生確率・影響はどの程度かを細かく検討する作業，すなわちThreat modelingを行います。その結果，機能とセキュリティリスクを秤にかけ，必要な機能を絞ったり，特に注意深く開発する必要のあるコンポーネントを特定したりすることができます。
マイクロソフトでは，仕様書のテンプレート（雛形）にthreat（脅威）の分析やその対策を記入する項目を用意することで，すべての機能に対して設計の段階からセキュリティ上の考察が行われることを保証しています。
また，影響の種類，範囲，発生確率，攻撃の難易度などのパラメータを入力することでthreatの度合いを数値化するWebベースの社内ツールを用意し，設計者全員が一貫した評価基準でthreatに優先順位を付けられるように支援しています。
3. 実装フェーズ
実装フェーズでは製品のコードを書き，そのテストを行います。SDLではこの工程に以下のような要素を追加します。
- コーディングおよびテストの標準化
- セキュリティテストツールの適用
- 静的分析コードスキャンツールの適用
- コードレビューの実行
マイクロソフトで行われている実際の例としては，1番目に関しては，使用するライブラリのバージョンやコンパイラオプションをセキュリティを考慮した設定で統一することが挙げられます。また，2 番目の例としては「File Fuzzing」「RPC Fuzzing」，3 番目の例としては「PREfix」「PREfast」に代表されるツールの利用があります。最後に，すべてのソースコードはチェックイン前に別の開発者のコードレビューを受けることが義務付けられています。
4. 検証フェーズ
検証フェーズでは一般に完成したコードに対してより広範囲のテストを行いますが，SDLではこの工程にセキュリティプッシュと呼ばれるセキュリティに特化したテスト・修正作業を追加します。
5. リリースフェーズ
SDLでは，リリースにゴーサインを出せるかの判断基準にFSR（ FinalSecurity Review）と呼ばれる外部のセキュリティ専門家による検証作業を追加します。
マイクロソフトではSWIチームがこれを担当し，その内容には開発者に対するインタビュー，ソースコードのレビュー，製品に対する擬似的な攻撃などが含まれます。
6. サポートおよびサービスフェーズ
出荷後の製品に問題が見つかる可能性は常に存在します。SDLでは，脆弱性のレポートを評価し，セキュリティ勧告をリリースして適切な時期に更新すること，レポートされた脆弱性を検証し，製品の修正やコードスキャンツールの拡張などの必要な対応を取ることを求めています。
ソフトウエアのセキュリティを向上させることは社会の要請でもあり，それを実現するには業界全体でセキュリティ技術を向上させていくことが必要です。この考えに基づき，マイクロソフトの経験を業界全体で共有しようという活動の中で，SDLは広く公開されています。
SDLに関してより詳しい情報はhttp://www.microsoft.com/japan/msdn/security/general/sdl.aspをご参照下さい。この文書では，SDLの導入前後でマイクロソフト製品のセキュリティバグの数がどう変化したか，つまりSDL導入の効果に関しても実際の数字を挙げて解説されています。
以上，セキュアなソフトウエア開発のためにマイクロソフトが採用している開発プロセスについて，マイクロソフト社内での運用例と併せて簡単に紹介してきました。SDLおよびその運用例が，セキュアなソフトウエア開発に取り組まれている開発者の皆様の一助となれば幸いです。
マイクロソフト株式会社
開発者向けセキュリティ情報提供サイト
セキュリティデベロッパーセンターURL.http://www.microsoft.com/japan/msdn/security/
一般のお問い合わせ窓口
カスタマーインフォメーションセンターTEL.0120-41-6755（9:30-12:00，13:00-19:00 土日祝日，弊社指定休業日を除きます）
Windows Update，セキュリティ問題に関する情報提供及びお問い合わせ窓口
マイクロソフトセキュリティ情報センターTEL.0120-69-0196（9:30-12:00，13:00-19:00 土日祝日，弊社指定休業日を除きます）
