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" のお話．
Stanislaw Jarecki さんのホームページで公開されている 2002年の資料 "Negotiated Privacy (Extended Abstract)" を読んでみました．

kawabe さんが紹介している「匿名認証」のようなものかと思ったのですが，全然違いました．ばっさり要約すると「ある条件に合致したデータの数が設定しておいた閾値を超えたときにデータを要求者に公開する仕組み」ということになります．

この論文では，例えば伝染病の早期発見のために「24時間以内に同じ大都市エリアで処置された特定の症状の組み合わせを持つ患者が5人以上いる場合には、それらの患者に関する記録から他の情報を明らかにせよ」というような状況をあげています．

5 人より少ないというような条件に合致しない場合には，個人を特定できないが，必要なときには個人を特定できるようなデータを公開するというものです．そのためには，データの提供者とデータの利用者の間で，この閾値となる条件を事前に "Negotiated" しておくわけです．

保健所や警察などの公的機関と住民の間には有効な技術だと思います．
ただ，他の民間での利用方法がいまひとつ思い浮かびません
どんなところで使えるでしょうか．．．

　台風も進路がそれたみたいで，傘が要らないのはうれしいですねぇ．早く秋晴れになってくれないでしょうか．そうこうしているうちに冬になってしまいます．今日から秋冬物のスーツにしました．

　さて，去る 10 月11日に JISA で作成した脆弱性情報の取り扱いに関するガイダンスの説明会が行われました．私もこのガイダンスの作成に携わったのですが，残念ながら別な用事で出席できませんでした．140名以上の方が出席し，盛況だったようです．

　このガイダンスの正しい名前は 「SI事業者における脆弱性関連情報取扱に関する体制と手順整備のためのガイダンス」 です．これは 9 月 8 日付けで公表されています．10月11日の説明会で使用された「概要」も先日公開されました．

　このガイダンスには

1. SI 事業者は脆弱性関連情報が公表されてから対応を行う．すなわち，公表前に脆弱性関連情報を入手できるわけではない．
2. Web サービスの運営者を通じて IPA から通知が来る．
3. 体制を整備しましょう．

ということが書かれています．

　特に Web サービスを提供しているシステムの SI 事業者は，サービス運営者からの依頼があって初めて， IPA あるいは JPCERT/CC などと連携していくことになります．そのためには，IPA から通知された脆弱性情報をどのように社内で伝達し，対応するのかを平常時に考えておくことが必要です．

　写真は，中国土産で上司がもらった神舟(ShenZhou：シェン・チョウ)と長征2F型ロケット(Chan-Zheng - 2F)の金ピカ模型．すごい，めずらしい，ほしい．でも，中国は広報にもそうとう力を入れてるようで，何人かの友人が「持ってるよ」とのこと．そんなにたくさんくばってるのか？！ 私にも一つください．

# こういうのを一般に見せて話を書くのは，ひょっとすると，
# 情報セキュリティ的にやばいのかも
# (と，無理矢理，情報セキュリティに結びつけ．．．)

　さて，本題．
　「情報セキュリティ事故の8 割が内部犯罪と言われている」というのを聞いたりしますが，本当なのでしょうか？
　インターネットを検索してみると，確かにいろいろなところでそう書いてあります．しかし，どこにも根拠が見当たりません．JNSA の「2004年度情報セキュリティインシデントに関する調査報告書」の中の，「人為的なミス」や「内部の犯罪」というデータを合わせても 6 割程度です．JNSA の分類での「内部犯罪・内部不正行為」はわずか 7.9% にすぎません．

　いったい，この「8 割が内部犯罪」というのはどこから出てきたものなのでしょうか．

 

事故の8割が内部犯罪ってほんと？の続きを読む