V.S.A. III

本日は，ちょっと格式高く．

「セキュリティ技術 ― 情報技術セキュリティの評価基準」というのをご存知でしょうか．JIS X 5070 の名称です．"Common Criteria" と書いたほうがわかる方が多いかもしれません．国際規格では ISO/IEC 15408 で，"Information technology - Security techniques - Evaluation criteria for IT security" というタイトルが付けられています．

これは，製品の情報セキュリティをどのように評価するかということを取り決めた規約です．内容は，IPA セキュリティセンターのページで概要などを紹介しているので，知らない方は覗いてみると良いと思います．

この評価制度は(非常に大雑把に言うと)，CC(Common Criteria) - PP(Protection Profile) - ST(Security Target) という三つの文書を用いて，対象となる製品の情報セキュリティのレベルを評価し，認証しようというものです．CC は，評価のための基準のテンプレートを用意し，PP でテンプレートを利用して情報セキュリティの要求定義をし，ST で情報セキュリティの実装を記述するようになっています．PP と ST には認証制度があり，基準レベル(EAL: Evaluation Assuarance Level)をクリアしているものを保証します．

例えば，ある政府機関が調達に際して，あるレベルのセキュリティを確保したいと考えたとします．このとき，この調達側である政府機関が PP を作成します．PP では，CC を用いて，その中の要件を抽出し，規約に従って変更を加えるなどしてセキュリティの要件を定義します．この PP がどのくらいのセキュリティレベルを正しく定義しているかどうかを保証するのが PP の認証です．調達に応じる側は，この PP に基づいて製品にセキュリティを実装します．そのときに，どのようにあるいはどの程度 PP のセキュリティ要件を実装したのかを記述するのが ST です．ST も必要があれば認証を取り，セキュリティレベルを保証してもらうことができます．

この例に挙げたプロセスが理想的なプロセスですが，現実には認証をうけずに PP と ST を作成することがあります．
また，実際には PP や ST の作成と開発が並行して行われるケースも世の中一般に少なくないようです(根拠データがあるわけではありません．私の感触です)．

私は，この PP の作成プロセスと ST プロセスを製品やソフトウェアの開発工程の中に標準的に組み込むことで，生産性と品質が向上するのではないかと考えています．

要件定義の中で，セキュリティ要件を記述するのは今や当たり前になっていますが，CC(あるいは PP) の言葉で記述されているものは多くはありません．それは CC を正しく理解している人が少ないこともありますが，PP の作成に手間と時間が掛かるからだと思っています．

ehira さんや ukon さんの blog で，生産性向上の話が書かれていますが，SLCP と JIS X 5070 を組み合わせて PP/ST をソフトウェア開発のルーチンにしてしまえないでしょうか．いわば，ソフトウェア開発の「空気」にしてしまえ，ということです．ソフトウェアが出来上がると，認証を取るかどうかは別にして，PP と ST が出来上がっている．そんな風にならないかと思っています．



本日のプライベート：
昨日は，「二日つづけてうなぎかよ」という声にもめげず，懲りずにまたしても「信長丼」を食べました．
お店の人曰く「『ひつまぶし』は名古屋でしょ．それの小さいランチセットなので『信長丼』なんです．」．．．orz
じゃぁ，「家康丼」というのもあるのか？

カテゴリ：情報セキュリティ , 雑感

<< Negotiated Privacy | Main | 規格四面のお風呂の中で～ >>