皆さんこんにちは。今回は、ユースケース図を応用したセキュリティ分析手法であるミスユースケースをご紹介します。ミスユースケースはユースケースの拡張ですが、特別な記号などを使うわけではなく、表記法の枠組み自体は通常のユースケースの範囲内に収まっているので、astah*で十分書けるものです。前半では、astah*でミスユースケースを記述するときに便利な機能やオリジナルの論文での記述例、後半では、セキュリティに限らず一般的なリスクやハザード分析へ応用した例をご紹介します。

ミスユースケースのためのほんの少しの準備

はじめに、astah*で効果的にミスユースケースが書けるために少し準備しておきましょう。

まず、メニューの[Tools]から[Project]に入り、[Set Project Property]を選択します。

つぎに、[Default Stereotype Color]を選び、新たなStereotypeとして、「misuse case」を追加し、既定の色として赤色を選んでおきます。

次に、スクリプトエディタをひらき、ここ

var COLOR_PROPERTY_KEY = "fill.color";

var keyword = 'mis-actor';
var newColor = '#ff8484';

run();

function run() {
var targets = searchMisActors(keyword);

if (targets.length === 0) {
print('No actor having stereotype ' + keyword +'found.');
return;
}

with(new JavaImporter(
com.change_vision.jude.api.inf.editor)) {
TransactionManager.beginTransaction();
targets.forEach(function(t) { coloring(t); });
TransactionManager.endTransaction();
}

print('The color of the mis-actors was changed.');
}

function searchMisActors(keyword) {
with(new JavaImporter(
com.change_vision.jude.api.inf.model)) {
var targets = [];
Java.from(astah.findElements(IClass.class)).filter(function(a) {
return a.hasStereotype("actor") && a.hasStereotype(keyword);
}).forEach(function(a) {
targets.push(a);
print('HIT: ' + a);
});
return targets;
}
}

function coloring(target) {
with(new JavaImporter(
com.change_vision.jude.api.inf.presentation,
java.awt.geom)) {
var classDiagramEditor = astah.getDiagramEditorFactory().getClassDiagramEditor();
Java.from(target.getPresentations()).filter(function(p) {
return p instanceof INodePresentation;
}).forEach(function(actorPs) {
classDiagramEditor.setDiagram(actorPs.getDiagram());
actorPs.setProperty(COLOR_PROPERTY_KEY, newColor);
});
}
}

のスクリプトをダウンロードしておきます。

これで準備は完了です。

ミスユースケースの例

それでは、まずはミスユースケースが提案された G. Sindre および A. L. Opdahl によるオリジナルの論文[1]に現れる例を日本語に直して見ていきましょう。

ユースケースに<<misuse case>>というステレオタイプを付加することにより、色が赤くなったでしょうか。このようなユースケースは、通常のユースケースと異なり、望ましくないシナリオやシーンを表すもので、セキュリティ上の攻撃や、オペレータのミス、システムの故障などを表すものです。ここでは、何らかのオンライン販売システムに対し、カード情報の不正入手などがそのようなミスユースケースとして挙げられています。ちなみに、「misuse」という言葉自体は、「悪用」よりも「誤用」という意味が強いのではないかと思われますが、セキュリティの場合は、誤用については基本的には取り扱わないことが多いようです。

また、ミスユースケースを引き起こすアクターとして、ミスアクターというアクターに対するステレオタイプが導入されており、図上では見えませんが、犯罪者というアクターには、<<mis-actor>>というステレオタイプが付加されています。ここで、先ほどの準備のところで導入したスクリプトを実行してみましょう。<<mis-actor>>というステレオタイプを持つモデルの図要素の色が赤くなったと思います。ちなみに「mis-actor」は、「mal-actor」や「mid-user」などと呼ぶことも多いそうです。

一つ注意点としては、最近はアクターとユースケースとは、矢印のない線で結ぶことが多いですが、この例では矢印があるものもあります。原論文によると、対応づけられたユースケースに能動的に係わる場合は「矢印あり」に、受動的のみに係わる場合は「矢印なし」と使い分けているとのことです。

ここまでに現れたミスユースケースの特徴は以下の通りです。

望ましいユースケースと望ましくないシナリオやシーンを表すミスユースケースを一つの図上で表すことができる
ミスユースケースを引き起こす、又は実施する主体となるアクターも明示的に示すことができる

ミスユースケースの手法の特徴を説明するために、もう少し大きな例を見てみましょう。

ここでは新たな関係がいくつか出てきました。まず、<<includes>>関係は、UMLに標準にあるものですが、ここでは例えば、パスワードの不正入手が、通常のログオンを何回も試みることも含まれることなど、ミスユースケースも、通常の機能を利用して実現されることを表現するために利用されています。ただ、「フラッド攻撃システム」が「顧客情報の登録」ユースケースを含んでいることは、今見ると少しおかしな感じもしますが、ここでは原論文を尊重して、そのまま書いています。

<<prevents>>と<<detects>>は、ミスユースケースに対する意図する対策を表現するものです。例えば、DoS攻撃などをフラッド攻撃システムによるミスユースケースに対しては、通常の顧客情報の登録を拡張したユースケースである、重複登録の防止により、防護しようとしていることを表現するため、<<prevents>>が使われています。<<detects>>関係は、ミスユースケースを検出することを意図したユースケースを表現するために用いられています。これらの関係を用いることにより、判明された望ましくないシーンやシナリオに対して、すべて対策がとられているか、それら対策と、もともと実現しようとしていた機能と矛盾がないか、などの検討ができるようになることが分かると思います。以上をまとめると、前の例で分かったことに加えて、この例で読み取ることができるミスユースケースの特徴は以下の通りです。

もともと実現したかった機能などを表すユースケースと、望ましくないシーンやシナリオを表すミスユースケースとの関係を表現できる
望ましくないシーンやシナリオを表すミスユースケースと、その対策のために導入された機能などを表すユースケースとの関係も表現できる

次の例は、セキュリティに限定せず、要求や設計に関するトレードオフ分析にミスユースケースを応用した例[3]を見ていきます。先ほどとは少し異なったユースケース間の関係を導入しています。

ここでは、ミスユースケースからユースケースに対して、threatensという関係が見られます。これは、明示的に、ミスユースケースとそれによって実現が脅かされるユースケースの関係を表現するものです。もう一つのmitigatesは、前のユースケースで現れた<<prevents>>と基本的に同様の考えに基づくもので、あるミスユースケースと、それによるリスクを軽減する対策を表すユースケースの関係を明示的に表すものです。<<prevents>>は完全にリスクを防げるように見えてしまいますが、多くの場合そうではないため、あらたにmitigatesを導入したとのことです。
この例はセキュリティの観点でいうと、ある攻撃に対して対抗策が講じられているが、その対抗策をターゲットとした攻撃があり、さらにその攻撃を想定した対抗策があるといった状況を表現していることになります。

これらを使ったもう少し大きな例を見ていきます。

ここでは、ミスユースケースで挙げた望ましくないケースを悪化させる可能性のあるケースを示すaggravates関係や、ユースケース間でその実現にあたってはトレードオフ関係にあるものを示すconflicts with関係が導入されています。

さて、次にミスユースケースに対するツール支援の可能性について紹介します。次の例は、ミスユースケースを提案した G. Sindre および A. L. Opdahl による最初の提案から五年後の論文[3]に現れるものです。

ここではミスユースケースと通常のユースケースの間の関係として、<<threaten>>と
<<mitigate>>が使われています。これらは、[2]と同様の意味で用いられています。最近では、この二つの関係を使うことが多いようです。

さてこのミスユースケース図に現れるミスユースケースの中で、いくつかは対応策が示されており、いくつかはそうではありません。これは、<<mitigate>>関係によってつながるユースケースをもつものと持たないものとして区別できます。これは例えば、

var COLOR_PROPERTY_KEY = "fill.color";

var misusecase_name = 'misuse case';
var mitigate_name = 'mitigate'
var treatedMisuseCaseColor = '#ff8484';
var untreatedMisuseCaseColor = '#ff0000';

run();

function run() {
var misuseCases = getAllMisuseCasesInDiagramEditor();
if (misuseCases.length === 0) {
print('No misuse case found.');
return;
}
var misuseCasesWithColors = calcMisUseCaseColors(misuseCases);
with(new JavaImporter(com.change_vision.jude.api.inf.editor)) {
TransactionManager.beginTransaction();
misuseCasesWithColors.forEach(function(m) {changeColor(m.case, m.color);});
TransactionManager.endTransaction();
}
}

function getAllMisuseCasesInDiagramEditor() {
with(new JavaImporter(com.change_vision.jude.api.inf.model)) {
var diagramViewManager = astah.getViewManager().getDiagramViewManager();
var diagram = diagramViewManager.getCurrentDiagram();
if (diagram === null || !(diagram instanceof IUseCaseDiagram)) {
print('Open UseCase diagram.');
return [];
}
return Java.from(diagram.getPresentations()).filter(function(p) {
return p.type.equals('UseCase') && p.getModel().hasStereotype(misusecase_name);
}).map(function(p) {return p.getModel();});
}
}

function calcMisUseCaseColors(misuseCases) {
with(new JavaImporter(com.change_vision.jude.api.inf.model)) {
var useCases = Java.from(astah.findElements(IUseCase.class)).filter(function(u) {
return !u.hasStereotype(misusecase_name);
});
var misuseCasesWithColors = [];
misuseCases.forEach(function(misuseCase) {
misuseCasesWithColors.push({case: misuseCase, color:
useCases.some(function(useCase) {
return Java.from(useCase.getClientDependencies()).some(function(d) {
return d.hasStereotype(mitigate_name) &&
d.getSupplier().getName().equals(misuseCase.getName());});}) ?
treatedMisuseCaseColor : untreatedMisuseCaseColor});
});
}
return misuseCasesWithColors;
}

function changeColor(misuseCase, color) {
with(new JavaImporter(com.change_vision.jude.api.inf.presentation, java.awt.geom)) {
var usecaseDiagramEditor = astah.getDiagramEditorFactory().getUseCaseDiagramEditor();
Java.from(misuseCase.getPresentations()).filter(function(p) {
return p instanceof INodePresentation;
}).forEach(function(misuseCasePs) {
usecaseDiagramEditor.setDiagram(misuseCasePs.getDiagram());
misuseCasePs.setProperty(COLOR_PROPERTY_KEY, color);
});
}
}

のようなスクリプトでチェックすることができます。以下がスクリプトを実行した結果です。

濃い赤色になっているものが、一つも対策が打たれていないもので、薄い赤色は、一つ以上の対策によりリスクの軽減がはかられているものです。

このスクリプトでは、ユースケース間の<<include>>関係などは考慮しておらず、また、あるミスユースケースに一つ<<mitigate>>があるからといって、そのミスユースケースに対する対抗策として十分であるとは限りません。ただ、目的に応じてスクリプトを拡張していくことにより、記述が巨大になったときでも、ある程度のチェックの自動化が期待できることが分かると思います。

いかがでしたでしょうか。ミスユースケースは、ユースケース図の表現の範囲で、セキュリティに関する要求などの分析が効果的にできるものです。もともと実現したい機能、それに伴う望ましくないシナリオ、さらにその対策を実現する機能、それに伴う望ましくないシナリオ、その対策・・・、という関係は、セキュリティ分野に限らず、安全性やその他のリスク、非機能要件などにもみられる関係だと思います。実際、上に紹介した設計のトレードオフ分析への応用例[2]の他にも、セキュリティ以外の品質特性への応用の試みがいくつかあります[5, 6]。それらを参考に、プロジェクト毎に適用のルールを決めておけば、皆さんのプロジェクトにも応用できるかもしれません。また、より効果的かつ厳密なセキュリティ分析を目指す方向の拡張[4]も提案されています。みなさんもぜひ活用を検討してみてください。

本稿の作成にあたっては、以下の文献や情報を参考にしました。また、記事の内容について、文献[4]の著者の一人でもある田口研治さんにレビューしていただきました。ここにお礼申し上げます。