i*を使って、情報セキュリティ国際評価基準(CC)のセキュリティ目標（ST)を作る方法

■まず、CCについて概略

評価対象：TOE
TOEが満たすべきセキュリティ目標（ST)＝部分的なセキュリティ要求仕様
→STの作成をどうするか？
　　　→STに書くべき内容と目次（パート１概説と一般モデルにある）
　　　→プロテクションプロファイル→ST作成時の参考、STのサブセット
　↓
　パート２：セキュリティ機能コンポーネント
　　　→セキュリティ機能カタログ集
　　　　　　→ST,PPはここから選択　　　
　↓
　パート３：セキュリティ保証コンポーネント
　　　→セキュリティ保証要件集：セキュリティの検査項目カタログ集
　　　　　　＋
　　　　評価保証レベル（EAL)

---

■STとセキュリティ要求仕様の対応

１．ST概要
　　　→システムの機能要求とハードウエア環境の概要

２．適合性主張

３．セキュリティ課題定義
　　　脅威→攻撃者アクター、攻撃タスク、ミスユースケース
　　　セキュリティ方針→ゴール・タスク
　　　前提条件→ゴール・タスク
　　　　　

４．セキュリティ対策方針→ゴールやタスク
　　　　TOEのセキュリティ対策方針
　　　　運用環境のセキュリティ対策方針
　　　　セキュリティ対策方針根拠
　　　　　→表で記述

５．拡張コンポーネント定義
　　　CCパート２、３以外
　　　　→ゴールやタスクで、CCパート２にないもの

６．セキュリティ要件
　　　セキュリティ機能要件
　　　　　CCパート２を使ったゴールやタスク
　　　セキュリティ保証要件
　　　　　範囲外
　　　セキュリティ要件根拠
　　　　　６．１と４．１を対応

７．TOE要約仕様
　　　　→SFR(セキュリティ機能要件）をあらわすゴールやタスクの詳細タスク　　　

---

■i*を使った場合

１．本来のI*モデルを作成する
　　　　　→黄色で書く

２．攻撃モデルを作成する
　　　　セキュアトロポスを使って
　　　　　→悪意を持ったアクター追加（赤で書く）

３．「３．セキュリティ課題定義」を作成
　　　脅威 : T.攻撃タスク

４．セキュリティ対策を含むドメインモデルを作成する
　　　　　→セキュリティのソフト作成
　　　　　→それに対する＋＋のゴール作成＊トップゴール
　　　　　→そのゴールに対する、CCパート２のゴールを作成
　　　　　　　　　→CCパート２のゴールになるまでゴール分解する
　　　　　→その結果、必要なものを追加

５．これらを踏まえて１章～２章
　　TOE概要
　　セキュリティ機能　４の＊トップゴール

６．４章を書く→３章は３で書いた
　４．１　セキュリティ対策方針
　　　　O.トップゴール

　４．３
　　　トップゴール　VS　攻撃タスク

７．６章を書く．セキュリティ要件
　　６．１　セキュリティ機能要件
　　　　→４で分解したCCパート２の内容を列挙
　　　　　CCの一部を書き換えて、使える
　　６．３
　　　　トップゴール　VS　６．１のCC

８．７章のTOE仕様を書く

テストと検証をまとめてみる

テストや検証について、その位置づけをまとめてみる。

---

■静的と動的

テストや検証には、

・プログラムを動かさないで解析する－１．静的チェック
・プログラム、ないしはシミュレーター等を「動かして」解析する－２．動的チェック

に主に分かれる

---

■１．静的チェック

　これは、大きくは、

・文法やお作法が合っているかどうか

　という、１－１レビュー的なものと、

・プログラムの仕様上、正しいものか

　という、１－２検証的なもの

に分かれる。

１－１は、文法規約のチェックとか、パーサー、コンパイラなど。

１－２検証的なものは、形式仕様記述を利用したものが、さまざまある。たとえば
　　Z
　　Event-B、B
　など。どちらも、証明していく形でチェックする。
　Zは、仕様の断片とか、規約レベルでもそれぞれの規約をスキーマとして定義して、検証できる。
　Event-Bのほうが、もちょっとプログラム的かな？
　ただ、どちらも、似たようなことが出来る。Bは、Event-Bより、詳細といえる。

　Zも、Event-Bも、やる気になれば、データを入れた、動的チェックに近いことも出来る。
　一方、VDMは、基本的に動的チェックだが、最近、証明させる形の静的チェックもできるようだ。
　OCLは、びみょー。クラスを陰仕様のような形で書けるが、それで、どーなのよといわれると・・

---

■２．動的チェック

　動的チェックは、

　２－１．プログラムを実際動かし、確認する

　２－２．シミュレーションを行い、総当り的にチェックする

　の２種類。



２－１．プログラムを動かすものが、普通のテストに相当する。
　また、形式仕様のVDMは、テストデータを作って、設計仕様レベルのチェックができる。
　(一般のテストは設計ではなく、実装したもののテスト）
　データのテストとしては、OCLがあり、
　Javaの実装したものを、DbCに基づき、事前事後条件を形式的に記述、確認するものとしては、JMLがある。


２－２．のシュミレーションを使った総当りチェックは、モデル検査の分野である。

　モデル検査としては、並行時の動きを、設計レベルで調べるSPIN,SMV、LTSA、
　さらに時間概念を加えたuppaalなどがある。
　Javaを利用したものとしては、JPFがある。

　また、並行時の動きの詳細化を調べるものとしては、FDRがある（CSPで記述）
　これをJavaレベルでしらべる、JCSPってのもある。

---

ざっくり言うと、こんな感じかな・・・

astah*を使って、ICONIX風一気通貫システム開発 その５：属性を埋める

「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す

前回、（３）をやったので、今回は、「（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく」について。

---

■ロバストネス分割が終わった後

　ロバストネス分析が終わると、画面とエンティティの名前はきまる。
　でも、
　　　・まず、その中の属性は、わからない

　　　・１ユースケース１画面になっているので、画面単位としては大きすぎる
　　　　　　　ユースケース：「受注を修正する」だと、「受注修正画面」になってしまうが、
　　　　　　　　　一般には、修正は、一覧を出して、そこから修正レコードをクリックしてもらい、
　　　　　　　　　その後、詳細(編集）画面を出して、そこから修正してもらう。
　　　　　　　　　つまり、「受注一覧」と「受注詳細」の２画面になる。

　　　・エンティティは正規化されているわけではないので、一貫性を持って
　　　　保存しなければならないデータが、分散されている可能性がある。

　そこで、これらの問題を解決し、画面構成とエンティティ構成（DBのテーブル構成）を決めていくのが、ここでの課題である。

---

■アプローチ方法

　画面構成とエンティティ構成（DBのテーブル構成）を決めるために、以下の作業を行う。

（あ）バウンダリの出力項目(属性）をとりあえず決める

（い）判っているところ（属性）をとりあえず埋める

（う）ユースケースシナリオあるいはアクティビティ図にしたがって、操作したとして、
　　　（あ）で決めた出力が得られるかどうか確認する
　　→得られない場合、（い）に項目追加などして、もういちど（う）、
　　　得られるまで、（い）と（う）を繰り返す

（え）指針を決めて、画面を分ける

（お）指針を決めて、エンティティ部分を決める

このとき、（え）は、全体では「（５）バウンダリの項目を元に、画面構成を考える。」にあたり、（お）は、全体では「（６）(必要があれば）エンティティを正規化して、ER図にする」にあたります。

　ということは、（４）は、（あ）、（い）、（う）をやればいいわけです。

---

■具体的方法：（あ）バウンダリの出力項目(属性）をとりあえず決める

　出力するもの＝成果物のクラス（バウンダリ）は、「（３）ロバストネス分析」で埋まっているはずです。

　埋まってなかったら、バウンダリに追加してください。
　　　それは、どこかのコントロールに所属するはずです。
　　　どこに所属するかというと、ユースケースシナリオに書いてあるはずです。
　　　　　　線で結んでください

　　　　　　書いてなかったら、ユースケースシナリオが間違っていますから、
　　　　　　　　どこで、出力すべきか考え、
　　　　　　　　ユースケースシナリオを書き直して、
　　　　　　　　「（２）ユースケースシナリオを書く」の手順に戻ってください

　いいですか、出力するもののバウンダリ、クラスはできてますよね。
　そこに、出力項目を、属性として、がんがん追加してください。
　出力すべき項目、たとえば、受注票、納品書の項目は、帳票レイアウトなり、
　実物の帳票を見れば判るはず。

　　もし、考えてなければ、今、考えてください。
　　帳票だけでなく、画面の出力項目も同様です。

　　ただし、考える際、項目だけで、レイアウトはまだいいです。

---

■具体的方法：（い）判っているところ（属性）をとりあえず埋める

　出力を受けて、入力項目を考えるのですが、
　とにかく、とりあえず、画面や帳票、エンティティで判ってるところは、
属性(項目）を、全部埋めちゃってください。

　エンティティに関しては、ドメイン分析をしていれば、その内容を埋めていけばいいし、
　その他でも、とにかくとりあえず、埋めてください。
　もちろん、このとき、完全じゃなくっていいです。適当なところで・・・

　完全性は、（う）で担保します。

---

■具体的方法（う）：出力が得られるかどうか、確認する

　そうしたら、ユースケースシナリオ等にもとづいて、入力から、出力までの操作を追っていきます
　(逆に、出力から入力を追って行っても良い）。

　出力するデータ項目を入力データ項目(画面等のバウンダリの属性＋エンティティの属性）から得られない／作れない場合は、入力項目が足りませんので、その足りない項目を追加します。
　追加する際、どこのバウンダリに項目追加すればいいかを考えて、追加します。

　追加＝（い）の行為に相当しますので、（う）をやり直します。

---

ちなみに、（う）の行為が検証ということになります。
この検証を、ソースコードレベルでやってしまうと、アジャイルになり、
形式仕様言語で記述して行うと、検証っぽくなります。
もっとも、アジャイルの場合は、（う）、（え）、（お）を一貫して行いますが・・・

ということで、（４）はおしまい。

12月2日(木)のつぶやき

18:21 from web
”ついに宇宙人発見か？　NASAが「宇宙生物学的発見」の会見へ”だそうな 　http://headlines.yahoo.co.jp/hl?a=20101202-00000016-cnn-int
by xmldtp on Twitter