最初のステートメントは、セキュリティはプログラムの非機能的なプロパティであり、プログラムが何をするかではなく、何をしないかによって決定されるということです。
最初のステートメントと非常に密接に関連する2番目のステートメントは、「セキュリティ機能」がアンチ機能であるということです。これらは、一部のソフトウェア機能にアクセスできないユーザーから機会を奪います。
特に、これは、この同じセキュリティを実現する手段の1つであるセキュリティ機能を、「通常の」基本機能を説明するのと同じ方法では説明できないことを意味します。 この目的には他のアプローチを使用する必要があります。 現在まで、この問題を解決するためにいくつかの方法が提案されてきました。 それらの中で最も人気のあるものの1つは、虐待オプションの方法-誤用のケース-この記事に専念しています。
記載箇所
乱用オプションを使用して安全要件を記述および分析する方法は、10年以上前に最初に提案されました。 著者は、Guttorm SindreとAndreas Lothe Opdahlの2人の専門家です[1]。 その後、彼らはこの方法を大幅に開発しました[2,3,4]。 別の専門家であるIan Alexanderは著者のアプローチを補足し、その新しいアプリケーションを提案しました[5,6,7]。 興味があり、虐待オプションの使用に真剣に知りたい人は、リンクで記事を読むことをお勧めします。 この方法は引き続き調査および開発されているため、インターネット検索を使用して最新の資料を参照することもお勧めします。
残りの部分については、このアプローチを簡単に説明し、非常にシンプルでささいな例でその使用方法を示してみます。
ユースケースの拡大
この記事を読んだ誰もが、ソフトウェアの機能要件がユースケース、ユースケースを使用してしばしば説明されることを知っていると思います。 各ユースケースは一連のアクションであり、実行中、正当なユーザーはプログラムの機能を使用して、最初から最後まで、自分のタスクの1つを解決し、目標の1つを達成します。 つまり、ユースケースはプログラムが何をすべきかを説明しています。
しかし、プログラムがしてはならないことを説明したいと思います。 このために、虐待オプションも役立ちます。
虐待オプションは、ユースケースの拡張です。 このような各オプションを使用して、侵入者がシステムの所有者に損害を与えながら、目標の1つを達成できる方法が説明されています。
悪用オプションとともに、プログラムの望ましくない使用を防ぐように設計されたセキュリティ機能の効果を説明するユースケースが作成されます。
ユースケースと同様に、乱用オプションはグラフィカルまたはテスト形式で表示できます。 もちろん、クリーンなユースケースと同様に、グラフィック図とテキストの任意の組み合わせが受け入れられます。
情報をグラフィカルに表示する場合、虐待オプションはユースケースとともに描かれます。 それらを異なるものにするために、いくつかの新しい要素とそれらの間のいくつかの関係が追加され、前者を表します。
最初に、侵入者を示す要素が追加されます。 同一の人物が正当なユーザーと侵入者の両方として行動できる場合、図に2回表示されます。1回は正当なユーザーとして、2回目は侵入者として表示されます。 グラフィカルに、侵入者は正当なユーザーと同じ方法で示されますが、異なる色で強調表示されます。
次に、犯罪者のターゲットを示す要素が追加されます。 この要素-悪用のバリアント-は、正当なユーザーの目的-ユースケースと同じ方法で示されます。 ユースケースと虐待ケースを区別するために、攻撃者と同様に後者を異なる色で示します。
第三に、2つの関係が追加されます。 脅威の関係とは、このシステム機能を使用して、特定の侵入者の目標を達成できるという事実を指します。 「軽減」関係とは、このセキュリティ機能を使用して、この濫用オプションのリスクを軽減するという事実を指します。
虐待オプションのテキスト表示では、新しいグラフィック要素に対応するテンプレートと、新しい関係に対応するテンプレートの新しいフィールドが導入されています。
これらの拡張機能は、機能安全要件を説明するのに十分です。
最もシンプルなシステム
メソッドに慣れるために、非常に単純化された例を見てみましょう。
特定のドキュメントを読むことができるプログラムがあるとします。
明らかに、許可されていないユーザーを含むすべてのユーザーは、同じ機能を使用して同じドキュメントを読むことができます。 この事実の説明を図に追加します。
そのため、私たちのプログラムに存在する脆弱性、つまり、許可されていないユーザーが機密文書にアクセスする能力について説明しました。 そして、それを排除する機会を見つけたいです。
アクセス制御により、私たちにとって有害な方法で機能の使用を防止できると判断する場合があります。 アクセス制御のために、ユーザーを事前認証する必要があります。 ユーザーはユーザー名とパスワードを入力する必要があります。
結果のプロジェクトを分析した後、パスワードを選択することで認証をバイパスできることがわかります。 この事実をチャートに追加します。
発見された脆弱性を排除するために、パスワードを入力し、対応するユーザーをブロックしようとする連続した失敗した試行を数回プログラムで検出する必要があります。
受け取ったプロジェクトの分析は、侵入者は、おそらく最初のものとは異なるものであるが、許可されたユーザーの作業をブロックできたことを示しています。
この時点で、このようなロックを許可できると判断したとします。 修正する脆弱性がないため、分析は完了したと見なすことができます。
このように、プログラムの脆弱性を減らすように設計された、脆弱性とセキュリティ機能のこの機能に関連するプログラムの機能という説明を受け取りました。 この図は、プログラムの脆弱性も示しており、その存在は許容されると認識されています。
この例に欠けているもの
前のセクションの例は非常に原始的であり、完全ではありません。 メソッドの動作を説明するために、これ以上の必要はありません。 ただし、機能安全要件を適切に分析するために基本的に必要な情報が欠落していることに注意を喚起したいと思います。
十分なビジネスコンテキストがありません。
虐待オプションの助けを借りて、侵入者が行う方法を説明することを思い出しましょう。
- 彼の目標を達成します。
- システム所有者に損害を与えます。
したがって、まず、開発中のプログラムに対する攻撃に誰が興味を持ち、その目標、リソース、能力は何かを理解する必要があります。 これらのパラメーターが異なる潜在的な違反者のグループがいくつか存在する場合があります。
また、どのイベントがプログラムの所有者に害を及ぼす可能性があるかを理解し、その有害性の程度を評価する必要があります。
当然ながら、モデリングを開始する前にビジネスコンテキストを理解して説明する必要があります。
シミュレートされたアプリケーションのアーキテクチャは定義されていません。
まず、この例ではセキュリティメカニズムとしてアクセス制御を使用することにしましたが、これには認証が必要でした。 この状況では、データ暗号化を使用できると判断できました。 すべての正当なユーザーにキーを提供すると、セキュリティは例で取得したシステムと同等のシステムになります。 つまり、2つのソリューションが同等ではないことは明らかですが、現時点では、2つの可能な保護オプションから選択できる情報は提供されていません。
実際、2つのアーキテクチャオプションを見てみましょう。
最初のケースでは、図は安全な部屋にあるサーバーで実行されるシステムを説明しています。 ユーザーはリモートアクセスのみを持ち、説明した機能のみを使用します。 この場合のアクセス制御は、おそらく最良のソリューションです。
2番目のケースでは、プログラムがユーザーの個人用ラップトップで実行され、その主なタスクはメディアが盗まれたときにドキュメントを保護することだと想像してください。 おそらく、この場合、暗号化は2つのソリューションの中で最良です。
アーキテクチャの依存関係は、セキュリティの非機能的な性質の1つの現れであることに注意してください。
単純な例では、この依存関係は明白であり、簡単に気付くことができます。 より複雑な状況では、相互依存はより微妙な場合があり、それを特定することは困難な作業になります。 セキュリティは、システムの物理的特性に依存する場合があります。情報の入力場所、保存場所、処理場所、送信方法。 セキュリティは論理アーキテクチャにも依存します。システムの個々のコンポーネントの機能、相互接続に依存します。
アーキテクチャの一部はプロジェクトの最初の段階ですでに知られており、変更されていません。 アーキテクチャの別の部分は、機能要件の分析に基づいて開発されており、アーキテクチャのこの部分は、プロジェクトの実装中にわずかに変更される場合があります。 また、これらの変更により、セキュリティ機能の要件の分析に戻ることが必要になる場合があります。
長所と短所
長所
このメソッドの最も重要な利点の1つは、多くの人が機能を記述するための、時間をかけて検証された既存の理解可能なメソッドの拡張として構築されることです。 これは、乱用オプションを使用して行われた説明が開発者と顧客の両方に明確になることを意味します。
もう1つの非常に重要な利点は、この方法により、メイン機能と、悪用を防ぐためにプログラムに追加する必要があるセキュリティ機能との関係を簡単に追跡できることです。 したがって、セキュリティ機能の実装は、本当に必要になるまで延期できます。
短所
この方法の欠点は、標準の記述方法の拡張であるということです。 また、ユースケースが自動化されている場合、使用しているプログラムがこの拡張機能をサポートしていないことが判明する場合があります。 その後、少なくとも部分的に、虐待のオプションを放棄するか、自動化を放棄する必要があります。
しかし、私の意見では、この方法の主な欠点は、機能の説明に過度に焦点を合わせていることです。 保護対策に関する決定の採択が実質的に依存する大量の情報は、他の文書、他の図にあります。
この方法は、利用可能なすべての情報を考慮せずに、またはアプリケーションアーキテクチャの重要なセキュリティ決定が行われる前であっても、意思決定を引き起こすことができます。
おわりに
虐待オプションの方法は、独自の利点と欠点を持つツールです。 他のツールと同様に、特定の範囲の問題を解決したり、正しく使用したりするのに適しています。
セキュリティ要件を説明および分析する方法は他にもあります。 これらは、説明したものの代替として、およびそれと一緒に使用できます。 しかし、これは他の記事のトピックです。
文学
- G.シンドレとALオプダール、「誤用事例によるセキュリティ要件の引き出し」、Proc。 TOOLS Pacific 2000、2000年11月。
- G.シンドレとALオプダール、 「誤用ケースの説明のテンプレート」国際ワークショップ要件エンジニアリング：ソフトウェア品質の基礎（REFSQ 2001）、2001年の議事録。
- G. Sindre、AL Opdahl、およびGF Brevik、 「誤用事例の構造化メカニズムとしての一般化/専門化」 、情報セキュリティの要件エンジニアリングに関するシンポジウムの議事録、2002年。
- G. SindreおよびAL Opdahl、 「誤用事例によるセキュリティ要件の抽出」 Requirements Engineering Journal、10（1）：34–44、2005。
- I.アレクサンダー、 「使用事例と誤用事例との対立する目標の相互作用のモデリング」 、Proceedings第8回要件エンジニアリングに関する国際ワークショップ：ソフトウェア品質の基礎、2002年9月
- I.アレクサンダー、 「トレードオフ分析における誤用事例の最初の産業経験」 、IEEE共同国際要件エンジニアリング会議、2002年9月の議事録
- I.アレクサンダー、 「誤用事例：悪意のある使用事例」 IEEE Software、2003