始めに
この記事は "Eliciting security requirements with misuse cases1"（邦題「ミスユースケースを用いたセキュリティ要求の獲得」）およびミスユースケースの紹介です。
概要
皆さんもよくユースケース図とユースケース記述を使われると思います。
ユースケース図を使うことで、ステークホルダ内での情報の伝達が容易になります2。
またユースケース記述を使うことで、要求分析や要求の一貫性に威力を発揮します3。
ユースケース図とユースケース記述は、ほとんどの機能要求に適しています1。
しかしユースケース図とユースケース記述だけでは、非機能要求を無視してしまう可能性があります。
実際に、セキュリティニーズが高いECソフトウェアの開発プロジェクトにおいて、セキュリティ要求の無視が観察されています4。
それを防ぐ手法の1つに、ミスユースケースを用いた体系的なアプローチがあります。
ユースケース
ユースケース図
ユースケース図とは、UMLで定義されている図の1つです。
例えば次のような図1です。
PlantUML文
名前が付けられた機能の断片をユースケース（楕円で囲まれた部分）、その機能を呼び出す人またはものをアクター（人型の図形またはカスタムアイコン）と呼びます。
また、アクターとユースケースの「関連」を実線で記述し、ユースケース間の関係（後ほど登場します）を破線で記述（またその内容を'<<'と'>>'で囲んで記述）します。
ユースケース記述
ユースケース記述とは、もっとも重要なアクターやユースケースのステップなどの詳細を記述するものです。
ユースケース図だけでは、システムの関心事をどのように満たすかを理解するために必要な詳細が得られません。
ですから、どのユースケースにもユースケース記述を添付すべき5です。
UMLでは厳密な規則は定義されていませんが、テンプレートは次のようなもの6です。
| ユースケース記述の詳細 | その詳細が何を意味するか、なぜそれが役立つか |
|---|---|
| イテレーション | 要求獲得の4つのステップ (Façade, Filled, Focused, Finished)2 を記述 |
| 概要, 製作者, 日付 | |
| 目的 | システム内でのユースケースの位置付けおよびこのユースケースが重要である理由 |
| 基本アクター | ユースケースと関係する主要なアクターを記述する。ユースケースの実行を引き起こすアクター、ユースケースの実行から情報を直接受け取るアクターを含む |
| 関連アクター | ユースケースの実行には関係するが「主役」ではないアクター |
| 基本フロー | ユースケースの通常の実行における重要なステップの説明 |
| 代替フロー | 「基本フロー」に記述されたステップの代替ステップの説明 |
| 例外フロー | 「基本フロー」に記述されたステップの例外ステップの説明 |
| 拡張ポイント | このユースケースが個別のユースケースを記述した詳細なオプションパスで拡張している場合、そのパスを挿入できる基本パスまたは代替パスのアクションのリスト |
| トリガー | ユースケースの実行のきっかけとなる、アクターが引き起こすイベント |
| 仮定 | このユースケースを実行する前はどのような環境か |
| 事前条件 | このユースケースを実行する前に何が行われなければならないか |
| 正常終了条件 | ユースケースを実行した場合、システムはどのような状態になるか |
| 異常終了条件 | ユースケースを正常に実行しなかった場合、システムはどのような状態になるか |
| 関連要求 | このユースケースがどの要件を（部分的または完全に）満たすか |
例えば、先ほどのユースケース図における「顧客情報を登録する」ユースケース記述は、次のようなもの6です。
| ユースケース名 | 顧客情報を登録する |
|---|---|
| イテレーション | Filled |
| 製作者 | John Davis |
| 日付 | 2001.05.23 |
| 概要 | 顧客は名前、住所、メールアドレス、電話番号をオンラインショップに登録する |
| 基本アクター | 顧客 |
| 関連アクター | なし |
| 基本フロー | bp-1. 顧客は登録を選択する bp-2. システムは登録画面を提供する bp-3. 顧客は登録画面の入力欄を全て埋めて送信する bp-4. システムは登録を承認し、顧客に照会番号を返す |
| 代替フロー | [...] |
| 例外フロー | E1. アクションbp-3において、顧客は必須入力情報が欠落した状態で送信した場合、より情報を提供するためにアクションbp-3に戻る E2. アクションbp-3において、入力された情報が既に登録済みの別の情報と一致した場合、システムはユーザに、顧客情報が既に登録済みのため、登録が破棄されたことを通知し、ユースケースを終了する |
| 拡張ポイント | [...] |
| トリガー | [...] |
| 仮定 | [...] |
| 事前条件 | [...] |
| 正常終了条件 | 顧客情報は登録され、以降連絡先情報を新たに入力せずともオンラインショップから商品の注文が可能になる |
| 異常終了条件 | [...] |
| 関連要求 | [...] |
実際にプロジェクトに適用する場合は、必要な詳細を付け加えたり、不要な詳細を省略することが重要です。
ミスユースケース
ミスユースケース図
ミスユースケース図は、UMLのユースケース図を拡張した図です。
ユースケース図を記述する際に使うのと同じような感覚で、include、extend、汎化などの通常のユースケース間の関係や、通常の関連付けの関係を、ミスユースケース間の関係や、ミスユースケースとミスユーザとの関係で用いることができます。
先ほどのユースケース図をミスユースケース図に拡張した図を、次に示します。
PlantUML文
ミスユースケース図では、ミスユースケースとミスユーザを新しく定義しています。
- ミスユースケース
- 実行可能なシステムまたは他のエンティティの振舞い（バリアントを含む）シーケンスであり、シーケンスが完了可能であるならば、エンティティのミスユーザとの相互作用や一部のステークホルダーへの危害を記述できる。
- ミスユーザ
- ミスユースケースを開始するアクターである。このミスユースケースの開始は、意図的であるか偶発的であるかを問わない。
ミスユースケースでは色を反転させることで、（同じ楕円状であることにより）似たようなものであるということと、（反転色であることにより）否定的であることの両方を表しています。
ミスユーザに関しても、アクターと色を反転させますが、上図では色設定がうまくいかず、色はそのままです（ミスユースケースに直接関連しているアクターがミスユーザとしておいてください）。
ユースケースとミスユースケースとの具体的な関係として、次のようなものがあります。
前者を<<threaten>>関係と呼び、後者を<<mitigate>>関係と呼びます。
- ミスユースケースはユースケースを脅かす
- ミスユースケースは、ユースケースを悪用、妨害する。例えば、 DoS 攻撃を用いた「システムを溢れさせる」ミスユースケースは、正統なユーザが顧客登録を含むインターネットサービスへのアクセスを妨害することで、「顧客情報を登録する」ユースケースを脅かす。
- ユースケースはミスユースケースを緩和する
- ユースケースはミスユースケースの対応策であるため、ユースケースはミスユースケースの成功可能性を緩和できる。一例として、「情報を保護する」ユースケースは「カード情報を引き出す」ミスユースケースの対応策である。
上図では特別な扱いはしていませんが、ミスユースケースと<<mitigate>>関係を持つユースケースを、セキュリティユースケースと呼ぶこともあります。
最初のユースケース図と比べると、ミスユースケースを記述したことで、「情報を保護する」セキュリティユースケースと「入力する」セキュリティユースケースを追加しています。
ユースケースのみの場合よりセキュリティ要求に強いと言えます。
ちなみに、隠しテキストとして置いてあったPlantUML文を見比べた方なら気づいたかもしれませんが、PlantUML文の最初にミスユースケースとミスユーザの色を設定しています。
これをコピペし、ミスユースケースに<<misuse>>オプションを追記すると、色を反転してくれます。
<<misuser>>にも適用させたかったのですが、記述しても適用されてくれませんでした。
ミスユースケース記述
ミスユースケース記述もユースケース記述同様、もっとも重要なアクター（あるいはミスユーザ）やミスユースケースのステップなどの詳細を記述するものです。
ミスユースケース記述は、簡易的な記述方法と詳細な記述方法の2つがあります。
簡易的なミスユースケース記述
ユースケース記述に「脅威」という項目を追加することで、簡易的なミスユースケース記述になります。
先ほどの「顧客情報を登録する」ユースケース記述に脅威の項目を追加したものを、次に示します。
| ユースケース名 | 顧客情報を登録する |
|---|---|
| イテレーション | Filled |
| 製作者 | John Davis |
| 日付 | 2001.05.23 |
| 概要 | 顧客は名前、住所、メールアドレス、電話番号をオンラインショップに登録する |
| 基本アクター | 顧客 |
| 関連アクター | 外部攻撃者 |
| 基本フロー | bp-1. 顧客は登録を選択する bp-2. システムは登録画面を提供する bp-3. 顧客は登録画面の入力欄を全て埋めて送信する bp-4. システムは登録を承認し、顧客に照会番号を返す |
| 代替フロー | [...] |
| 例外フロー | E1. アクションbp-3において、顧客は必須入力情報が欠落した状態で送信した場合、より情報を提供するためにアクションbp-3に戻る E2. アクションbp-3において、入力された情報が既に登録済みの別の情報と一致した場合、システムはユーザに、顧客情報が既に登録済みのため、登録が破棄されたことを通知し、ユースケースを終了する |
| 拡張ポイント | [...] |
| トリガー | [...] |
| 仮定 | [...] |
| 事前条件 | [...] |
| 正常終了条件 | 顧客情報は登録され、以降連絡先情報を新たに入力せずともオンラインショップから商品の注文が可能になる |
| 異常終了条件 | [...] |
| 関連要求 | [...] |
| 脅威 |
T1: 顧客が自身の名前と住所ではなく、偽った情報を登録した場合に考えられる結果を次に示す : T1-1. 存在しない人物が顧客として登録される T1-2. 存在する人物が不本意ながら知らず知らずのうちに顧客として登録される T1-3. 指定された人物がオンラインショップの顧客であることが第三者に明らかにされる（上記の例外フローE2を参照） T2: [...] |
詳細なミスユースケース記述
セキュリティ脅威の詳細な特定と分析を支援するために、トリガ、事前条件、基本パス、代替パスなど、大部分はテキストを用いて記述されるフィールドのテンプレートに基づいて、通常のユースケースと同等の条件で詳細なミスユースケースを記述します。
ミスユースケース記述のテンプレート1を、次に示します。
| ミスユースケース名 | 通常のユースケースと同じ意味を持つ |
|---|---|
| 製作者, 日付, 概要 | |
| 基本フロー | ミスユーザやシステムが、提案するシステムに障害を発生させるアクションを記述する |
| 代替フロー | 基本フローでは説明していないが、基本フローに十分似通っている、提案するシステムに障害を発生させる方法を記述する |
| 緩和ポイント | ミスユースケースを緩和できる基本フローまたは代替フローのアクションを識別するもので、特定のアクションのミスユースケースを緩和するためのいくつかの手法を同じフィールドに記述でき、また各手法を個別のセキュリティユースケースとして更に記述できる。拡張ポイントに関して、ミスユースケースは最終的に、対応するセキュリティユースケースとの<<mitigate>>関係を持つ必要があるが、セキュリティユースケースの詳細な説明は設計寄りであることが多く、ユースケースやミスユースケースを超えた詳細なリスク分析と実装コスト分析を必要とするため、オプションとする |
| 拡張ポイント | ミスユースケースが個別の拡張ミスユースケースを記述した詳細なオプションパスで拡張される場合が存在するため、そのオプションパスを挿入できる基本フローまたは代替フローのアクションをリスト表示できる。通常のユースケースの拡張ポイントに関して、ミスユースケースはオプションパスを含むミスユースケースとの<<extend>>関係を持つ必要がある |
| トリガー | ミスユースケースを発動するシステムまたはその環境内での状態やイベントを記述する。いくつかのミスユースケースでは、トリガーは常に真の値を取り、永久に危険が存在することを示す |
| 仮定 | ミスユースケースが発動可能なシステム環境内での状態を記述する |
| 事前条件 | ミスユースケースが発動可能なシステム状態を記述する |
| 緩和保障 | ミスユースケースを緩和した結果の保証を記述する、または、もし緩和点を詳細に定義していない場合は、後々設計するセキュリティユースケースを緩和するためのセキュリティ要求のレベルを記述する、あるいは、もし緩和点をセキュリティユースケースによって記述している場合は、ミスユースケースをどのように緩和しているかに関わらず、可能な限り強力なセキュリティ保証を記述する |
| 関連要求 | 通常、業務規定はミスユースケースによって侵害されるため、それらの規定へのリンクを記述する。また、脅威を有効化する規定や、脅威の緩和方法や排除方法の制限へのリンクを含めることもある |
| ミスユーザの人物像 | ミスユーザがミスユースケースを発動するのは、意図的または不注意によってであるのか、内部者または外部者であるからなのか、どれだけ技術的に熟練している必要があるのかなど、ミスユーザについて想定できるもの全てを記述する |
| スコープ | 提案するシステムにおけるミスユースケースは、例えばビジネス全体に影響するのか、あるいはユーザとコンピュータの両方のシステムなのか、あるいはソフトウェアシステムのみであるのかなどを示す |
| イテレーション | 通常のユースケースにおいて、ミスユースケースの簡易的な記述と詳細な記述の両方が記述可能であると便利であるため、通常はプロジェクトのユースケースで用いられるイテレーションレベルのセットに基づいた、ミスユースケースのイテレーションレベルを示す |
| レベル | 通常のユースケースでは、一般または特定の抽象レベルでミスユースケースを指定できるため、"Writing effective usecases."7で示すように、例えばミスユースケースが概要なのか、ユーザ目標なのか、あるいはサブ機能なのかを記述する |
| ステークホルダとリスク | ミスユースケースに関わる各ステークホルダの主要なリスクを明記する。抽象的なレベルであれば、リスクを「システムは数時間利用できない」「競合他社は受診者の機密医療情報を取得できる」といったテキスト的に記述でき、具体的なレベルであれば、脅威が発生した際に、コストに潜在的な損失が含まれている場合、各ミスユースケースの亜種の発生の可能性やコストを見積ることができる |
| 技術やデータの種類 | ミスユーザは、PCやWAP携帯端末などの様々なプラットフォームからミスユースケースを実行するが、それらの各ケースにおいて機器固有のアクション以外は共通であるため、候補となる機材のタイプを列挙し、特定の動作がどのように異なるかを説明する |
| 技術用語とその説明 | 技術用語およびその他の問題を説明する |
具体例として、一般的な「データを改竄する」ミスユースケースを特化した「Webクエリ操作によってデータベースを改竄する」ミスユースケースの詳細な記述1を、次に示します。
| ミスユースケース名 | Webクエリ操作によってデータベースを改竄する |
|---|---|
| 概要 | 攻撃者が検索窓の入力欄にWebクエリ攻撃を行い、機密情報を不正操作（更新、削除、流出）する |
| 日付 | 2001.02.23 |
| 製作者 | David Jones |
| 基本フロー | bp-1. 攻撃者は製品検索窓に値を入力し送信する bp-2. システムがクエリに一致する製品を表示する bp-3. 攻撃者は送信された URL を変更してクエリエラーを発生させ、再送信する bp-4. クエリが失敗することでシステムはデータベースのエラーメッセージを、データベース構造の詳細を含んだ状態で攻撃者に表示する bp-5. 攻撃者はそれを元に、機密情報を表示したり変更したり削除したりするように、ネストされたクエリを追加して送信する bp-6. システムが変更されたクエリを実行し、データベースの変更や機密情報を公開する |
| 代替フロー | ap1. bp-3やbp-5において、攻撃者はアドレスウィンドウのURLを変更しない代わりに、エラーまたはネストされたクエリを入力欄に直接入力する |
| 緩和ポイント |
mp1. bp-4において、正確なデータベースエラーメッセージをクライアントに表示しない。これはミスユースケースを完全に防止するものではないが、bp-5において攻撃者がテーブルやフィールド名を推測する時間を稼ぐことができる mp2. bp-6において、システムはフォームから受信した全てのクエリが、入力欄から期待できるクエリかどうかを判定することで、変更されたクエリを実行しない。これはミスユースケースを防止する |
| 拡張ポイント | [...] |
| トリガー | tr1. 常に真である。どのような場合にも起こりうる |
| 事前条件 | pc1. この機能が公に利用可能であるか、攻撃者が顧客として登録していることで、製品検索が可能である |
| 仮定 | as1. システムにデータベースクエリ入力を与える検索窓が存在する |
| 緩和保障 | 攻撃者が、誰でも利用可能なWebフォーム（mp2を参照）を介して権限なしにデータベース・アクセスが出来ない |
| 関連要求 | オンラインショップのサービスはインターネット上で顧客に提供されているものとする |
| ミスユーザの人物像 | データベースやクエリ言語に関する知識に強い熟練者であるか、少なくともクラッカーWebサイトで公開されている悪用方法などを理解できる人物 |
| ステークホルダとリスク |
st1. オンラインショップ：削除された場合はデータの損失、顧客が製品を注文できないまたは価格が変更された場合は収益の潜在的な消失、st2のst1における悪評の発生 st2. 顧客：攻撃者が製品価格を引き上げた場合は潜在的な（少なくとも一時的な）金銭の損失、データが消失した場合は注文ができないことによる時間の浪費、ミスユーザが顧客の機密情報を流出した場合はプライバシーの喪失、ミスユーザがクレジットカード番号等を流出した場合は金銭の損失 |
| 技術用語とその説明 | [...] |
| スコープ | ビジネス全体およびビジネス環境 |
| 抽象レベル | ミスユーザのサブ目標 |
| 精度レベル | Focused |
ミスユースケースの欠点
ミスユースケースの欠点について記述します1。
- ウイルスを添付したEメールを送信するといった単一の操作で行われる場合のように、ミスユースケースは特定のアクションシーケンスであるとは限りません。このような場合は、多くのテンプレートフィールドが埋め込まれたミスユースケースとして説明できますが、パスフィールドは空欄のままであり、詳細な説明情報が少なく、自動パターン検索が難しくなります。
- ウイルスが作成者とは独立したコンピュータからまた別のコンピュータに広がり、そのプロセスをもはや支配していないという状況のように、ミスユーザは常に特定可能であるとは限りません。このような状況では、明らかに識別可能なミスユーザは存在しませんが、ウイルス自体をミスユーザとみなす解決策が存在します。この解決策は、攻撃スクリプトエンジンや自動エージェントのように、他の種類のソフトウェアにも適用できます。また別の解決策として、誤ってウイルスを実行してしまうおっちょこちょいなユーザをミスユーザとみなすこともできます。これは、一般的に意図せぬミスユースケースや安全要求へと拡張できる解決策です。
- ミスユースケースとミスユーザは特定できるが、通常のユースケースを脅かすミスユースケースを特定できない状況のように、ミスユースケースは常に特定のアクションシーケンスを実行するとは限りません。ウイルスは原則として、システムのあらゆる種類のデータ送信を媒介して侵入し、システムによって行われた全ての動作に影響を与える可能性があるため、ウイルス攻撃もまた重要なポイントです。
終わりに
ミスユースケースは、もともとセキュリティ要求のために開発されましたが、それ以外の非機能要求にも適用できます。
これを機に、非機能要求について、また品質要求について考えてみてはいかがでしょうか。
ここまで読んでくださってありがとうございました！
もしおかしい点、気づいた点がありましたら教えてください。
特に、PlantUMLの色設定については詳しくないため、設定間違いなど多々あると思います。
-
Guttorn Sindre and Andreas L. Opdahl: "Eliciting security requirements with misuse cases," Requirements Engineering, Vol 10, Issue 1, pp 34-44, 2005 ↩
-
Kulak D, Guiney E: "Use cases: requirements in context." ACM Press, New York, 2000 （日本語版「ユースケース導入ガイド」 市川和久 訳） ↩
-
Weidenhaupt K, et al: "Scenario usage in system development: a report on current practice." IEEE Software 15(2):34 ‒ 45, 1998 ↩
-
Anton AI et al (2001) Deriving goals from a use case based requirements specification. Req Eng 6(1):63 ‒ 73 ↩
-
Russ Miles, Kim Hamilton 著, 原 隆文 訳: "入門 UML 2.0." オライリージャパン, 2008 ↩
-
"Eliciting security requirements with misuse cases1" における簡易的なミスユースケース記述や"入門 UML 2.05"を参考 ↩
-
Cockburn A: "Writing effective usecases." Addison-Wesley, Boston, 2001（日本語版「ユースケース実践ガイド 効果的なユースケースの書き方」ウルシステムズ株式会社 監訳） ↩