Skip to content

Latest commit

 

History

History
46 lines (36 loc) · 6.78 KB

C01.セキュリティ要件の定義.md

File metadata and controls

46 lines (36 loc) · 6.78 KB

C01:セキュリティ要件の定義

説明

セキュリティ要件は、ソフトウェアのさまざまなセキュリティ特性が満たされていることを保証するために必要なセキュリティ機能のステートメント、すなわち宣言文です。セキュリティ要件は、業界標準、適用される法律、および過去の脆弱性の履歴がら導かれるものです。セキュリティ要件は、特定のセキュリティ問題の解決、または潜在的な脆弱性を排除するための、新たな機能または既存の機能への追加機能を定義します。

セキュリティ要件は、アプリケーションに対し、よく審査されたセキュリティ機能の基礎を提供します。あらゆるアプリケーションに対して個別にカスタマイズされたセキュリティを作り上げるよりも、標準となるセキュリティ要件を作ってください。そうすることで、開発者はセキュリティコントロールとベスト・プラクティスの定義を何度も利用できます。同様の審査済みのセキュリティ要件は、過去に発生したセキュリティ問題に対する解決策を提供します。セキュリティ要件は、これまでのセキュリティ問題の再発を防ぐためにあるのです。

The OWASP ASVS

OWASP Application Security Verification Standard (ASVS) はセキュリティ要件と検証基準を示すカタログです。 OWASP ASVSは、開発チームが詳細なセキュリティ要件を策定する際のソースになります。 セキュリティ要件は、共有された上位のセキュリティ機能ごとの「カゴ」に分類します。たとえばASVSには、認証、アクセス制御、エラー処理/ロギング、Webサービスなどのカテゴリが含まれています。それぞれのカテゴリには、それぞれ検証可能なステートメントのドラフトとなるベストプラクティスを示す要件集があります。

ユーザストーリーと誤用ケースによる要件の強化

ASVSの要件は、検証可能なステートメントであり、ユーザストーリーと誤用ケースに拡げられます。ユーザストーリーまたは誤用ケースの利点は、システムにユーザが何を提供しているかを説明するのではなく、ユーザまたは攻撃者がシステムに対して行うことをアプリケーションに正確に結びつけることです。 ASVS 3.0.1の要件を拡張する例を示します。 ASVS 3.0.1の「V2:認証検証要件」セクションにおいて、要件2.19ではデフォルトのパスワードに焦点を当てています。

2.19 アプリケーションフレームワークまたはアプリケーションが使用するコンポーネント(「管理者/パスワード」など)においてデフォルトのパスワードが使用されていないことを確認します。 この要件には、デフォルトパスワードが存在しないことを確認するアクションと、アプリケーション内でデフォルトパスワードを使用しないというガイダンスが含まれています。

ユーザストーリーは、システムのユーザ、管理者、または攻撃者の視点に焦点を当て、ユーザがシステムで行いたいことに基づいて機能を記述します。 ユーザストーリーは、「ユーザは、x、y、zを行うことができます」という形式で記述されます。

ユーザは、ユーザ名とパスワードを入力してアプリケーションにアクセスできます。 ユーザは、最大1023文字の長いパスワードを入力できます。 ストーリーが攻撃者とその行動に焦点を当てているときは、誤用ケースと呼ばれます。 攻撃者は、デフォルトのユーザ名とパスワードを入力してアクセスすることができます。 このストーリーには、ASVSの伝統的な要件と同じメッセージが含まれています。ユーザまたは攻撃者の詳細を追加すると要件をより明確にすることができます。

実装

セキュリティ要件をうまく活用するには、以下の4つの段階が必要です。

  • 発見/選択
  • 文書化
  • 実装
  • アプリケーション内に新しいセキュリティ機能が正確に実装されているかの確認

発見と選択

セキュリティ要件の発見と選択から始めます。 このフェーズでは、開発者はASVSなどの標準ソースからセキュリティ要件を理解し、アプリケーションのリリースに含める要件を選択します。発見と選択のポイントは、このリリースまたはスプリントで取り扱える範囲のセキュリティ要件を選択し、各スプリントで繰り返し実行、時間の経過とともにセキュリティ機能を強化していくことです。

調査と文書化

調査および文書化においては、開発者はアプリケーションが現在要件を満たしているかどうか、または何らかの開発が必要かどうかを判断するために、新しいセキュリティ要件セットに対する既存のアプリケーションの対応状況をレビューします。この調査は、レビュー結果を文書化することで終わります。

実装とテスト

開発の必要性があると判断された後、開発者はアプリケーションを何らかの方法で変更して、新しい機能を追加したり、安全性の低いオプションを削除したりする必要があります。このフェーズでは、開発者はまず要件に対処するために必要な設計を決定し、その後要件を満たすためのコードの変更を実施、完了します。 テストケースは、新しい機能の存在を確認したり、安全性の低いオプションが存在しないことを証明可能な内容にする必要があります。

脆弱性の防止

セキュリティ要件は、アプリケーションのセキュリティ機能を定義します。 アプリケーションライフサイクルの初めからより良いセキュリティを構築しておくことにより、多くの種類の脆弱性を防止することができます。

参考資料