Difference between revisions of "OWASP Secure Software Contract Annex/ja"

Revision as of 00:39, 5 July 2011

セキュア・ソフトウェア開発契約付属書

 警告：この文書は、単にガイダンスと考えられなければなりません。
 OWASPは、ソフトウェア契約を交渉するのを手助けするために、
 あなたが資格のある弁護士に相談するよう強く勧めます。

序文

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
      -- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

プロジェクトについて

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して Aspect Security から特別な貢献を感謝して認めます。

異論

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

しかし、すべての条項が私たちにとって適切であるというわけではありません…

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

しかし厳密さのレベルは間違っている….

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

しかし、私たちはそれほど多くのリスクをとることができない…

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

私たちはどのように第三者のコードを保証するでしょうか

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。 私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して Secure software contracting hypothetical case study を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

しかし、このドキュメントですべてを作ることは難しい

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

契約付属書

1. 序文

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

2. 原理

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

(a) セキュリティ決定は、リスクに基づきます 

セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

(b) セキュリティ活動はバランスが保たれます 

セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

(c) セキュリティ活動は統合されます 

ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

(d) 脆弱性は予想されます 

すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

(e) セキュリティ情報は、完全に明らかにされます 

すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

(f) 役に立つセキュリティ文書だけが必要とされます 

セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

3.ライフサイクル活動

(a) リスク識別 

開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

(b) 要求 

リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

(c) 設計 

開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

(d) 実装 

開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば OWASP Enterprise Security API（ESAPI） ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

(e) セキュリティ分析とテスト 

開発者は、（ OWASP Application Security Verification Standard (ASVS) のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

(f) セキュリティ配備 

開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

4.セキュリティ要求エリア

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

(a) 入力検証とエンコーディング 

要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

(b) 認証とセッション管理 

要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

(c) アクセス制御 

要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

(d) エラー処理 

要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

(e) ロギング 

要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

(f) 外部システムへの接続 

要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

(g) 暗号 

要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

(h) 可用性 

要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

(i) セキュアな設定 

要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

(j) 特定の脆弱性 

要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

5. 要員および組織

(a) セキュリティ・アーキテクト 

開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

(b) セキュリティ・トレーニング 

開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

(c) 信用できる開発者 

開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

6.開発環境

(a) セキュア・コーディング 

開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

(b) 構成管理 

開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

(c) 配布 

開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

7. ライブラリ、フレームワーク、および生産物

(a) 開示 

開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

(b) 評価 

開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

8. セキュリティ・レビュー

(a) レビューする権利 

依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

(b) レビュー・カバレッジ 

セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

(c) レビューの範囲 

最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

(d) 見つけられた問題 

発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

9. セキュリティ問題マネジメント

(a) 識別 

要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

(b) 保護 

開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

(c) 改善 

納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

10. 保証

(a) 保証 

開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

(b) 自己証明 

セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

(c) 悪意のあるコードのなし 

開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

11. セキュリティ承認と保守

(a) 受け入れ 

証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

(b) セキュリティ問題の調査 

受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

(c) 新しいセキュリティ問題 

開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

(d) 他のセキュリティ問題 

開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません