2005年12月アーカイブ
|
情報セキュリティに関するJIS規格と国際規格の対応表,第三弾.(第ニ弾からの続き) 今回は JIS X(情報セキュリティ)のうち,JIS X 5053 から JIS X 5063 の 10 規格です. 未制定や廃止の情報なども含みますので,表が少し大きめ(33項目)です.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
いかちょー (2005-12-13 11:00) | コメント(0)| トラックバック(0)
モデレータの西本さん(JNSA理事・幹事/株式会社ラック)は冒頭で9つのポイントを指摘していた.
そして,NTTデータの西尾さんは
「(脆弱性に対して)自分達が発見者となる場合もある.現場では,わかっていて製品をそのまま出してしまうケース:最近の建設業者の偽装問題のようなケース」も隠れているのではないかと指摘する.
あながち,無いとはいいきれないと思う経験がある.私は昔,ISO9001 の取得後,見つけたバグを即座に直せないという状況に直面したことがあるのだ.ある保守項目にしたがってプログラムを修正するのだが,修正範囲ではない周辺に見つけたバグを目の前にして,一緒に直すことが出来ないということが起きた.これはつまり,修正履歴をきちんと管理するための正しい姿勢なのだが,見つけたバグを直すためには,発見した箇所の報告書を作成し,優先付けを行い,レビューを含む作業履歴を残して修正を行わなければならなかった.等号を不等号にするといったような,たった一文字の修正だったと記憶している.この手続きを進めるのが嫌で,見てみぬふりをしようかと思ったくらいだ.
プログラムの作成現場では,こんなことが起きていないだろうか.バグに限らず,セキュア・プログラミングから外れたコードを見つけても,見てみぬふりをしているかもしれない.あるいは,デバッグコードに脆弱性が含まれていることはチェックしていないかもしれない.トラブル解析のためにデバッグ・フラッグを ON にして運用したとたんに,脆弱性が現れたりするかもしれない.
建築業界では,検査する手続きが決まっているし,少なくとも使用されている技術は,国土交通省で認められたものを使用している.柱や壁の強度は材料とともに基準があるわけだ.受け取る側もそれらの基準に照らし合わせて検証すればよい.しかし,ソフトウェアにはそれがない.情報セキュリティの分野でも何かしらの基準を作ることも可能だが,逆にその基準を満たしてさえいれば,責任から逃れられるという利用方法に流れる可能性があり,政府も慎重な態度をとっているようである.
IT業界にいる我々が姉歯建築士を笑えるだろうか.「すぐ作れ!安く作れ!」というのは,IT業界でも同じだ.Webアプリケーションの構築はビジネスのスピードについていけているのか.本当に品質を確保し,情報セキュリティを考慮して構築されているのか.建築業界で起きた事件は,明日のIT業界の話なのだ.
いかちょー (2005-12-12 17:00) | コメント(0)| トラックバック(16)
先日,忘年会で私の誕生日だ!と宣言したら,ケーキでお祝いしていただきまして...急な宣言にもかかわらず,さすが幹事!と思っていたわけですが...
なんと,バームクーヘン二段だったというオチが(笑)
一部からはガムテープでもよかったんじゃないか,とか.
でも,うれしかったです.涙がちょちょぎれました(ToT) (爆)
さて,前置きはこのくらいにして本題.
情報セキュリティガバナンスシンポジウムでの主題は,やはり「情報セキュリティの実施を企業価値に変えよう!」ということ.これは「戦略セキュリティ」(11月20日のブログ参照)という私の持論でもあるわけですが,2006年はこれが顕著に出てくる年になると思っています.
NISC(内閣官房情報セキュリティセンター)の山口 情報セキュリティ補佐官も紹介していましたが,現在パブリックコメントに付されている「IT新改革戦略(案)」の中でも,「情報セキュリティ対策レベルの評価を入札条件等の一つとする」としています.同じパラグラフでは,情報セキュリティガバナンスに言及しています.
弊社でも「 企業における情報セキュリティガバナンスのあり方に関する研究会報告書」に則って,いろいろ進めているようですが,なかなか見えてきません.中にいて見えないのだから,外からはまったく見えないだろうと想像できます.
今までは,情報セキュリティの施策は外に出すものではないという風潮がありましたが,今後はどんなことをやっているのかを外部に見せていくことがあたりまえになっていくはずです.今取り組んでいることを見せて,いろいろな意見をもらうことも大切なことだと思っています.
どんなことをどんな風にやっているのか.少しずつこのブログで公開できればよいなぁと考えています.
いかちょー (2005-12-12 12:00) | コメント(0)| トラックバック(0)
今回は JIS X(情報セキュリティ)のうち,JIS X 0008 から JIS X 5006 の 5 規格です.
|
JIS規格番号 |
JIS規格標題 |
国際規格番号 |
国際規格標題 |
説明(日本規格協会ホームページより転載) |
|
JIS X (情報処理) | ||||
|
X 0008:2001 |
情報処理用語 ― セキュリティ |
ISO/IEC 2382-8:1998 (MOD) |
Information technology - Vocabulary - Part 8: Security |
情報処理におけるセキュリティ用語,定義及び対応英語について規定。 |
|
X 0160:1996 |
ソフトウェアライフサイクルプロセス |
ISO/IEC 12207:1995 (IDT) |
Information technology - Software life cycle processes |
明確に定義された用語を使い,ソフトウェアライフサイクルプロセスの共通枠組を規定しており,ソフトウェア産業界で引用することができる。プロセス,アクティビティ及びタスクで構成され,ソフトウェアを含むシステム,単体ソフトウェア製品及びソフトウェアサービスを取得するとき,並びにソフトウェア製品の供給,開発,運用及び保守をするときに適用。ソフトウェアは,ファームウェア中のソフトウェア部分を含む。 |
|
X 5003:1987 |
開放型システム間相互接続の基本参照モデル |
ISO 7498:1984 (MOD) |
Open Systems Interconnection - Basic reference model |
開放型システム間相互接続の基本参照モデルについて規定。 |
|
未制定 |
(標題仮訳:「情報技術-開放型システム間相互接続-基本基準モデル-基本モデル」) |
ISO/IEC 7498-1:1994 |
Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model |
|
|
X 5004:1991 |
開放型システム間相互接続の基本参照モデル ― 安全保護体系 |
ISO 7498-2:1989 (IDT) |
Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture |
基本参照モデルで規定している安全保護サービス及びその関連機構について全般的な事項。参照モデル内で安全保護サービス及びその関連機構の位置付けの定義 |
|
未制定 |
(標題仮訳:「情報技術-開放型システム間相互接続-基本基準モデル-命名及びアドレス指定」) |
ISO/IEC 7498-3:1997 |
Information technology - Open Systems Interconnection - Basic Reference Model: Naming and addressing |
|
|
X 5006:1991 |
開放型システム間相互接続の基本参照モデル ― 管理の枠組み |
ISO/IEC 7498-4:1989 (IDT) |
|
OSI管理に関する現在及び将来の規格の開発を協調のとれたものにするための枠組みを確立し,これらの規格の共通基準 (a)OSI管理に関する用語を定義し,OSI管理の概念を規定。 (b)OSI管理対象の概略,OSI管理が提供するファシリティ,OSI管理の構造を規定。 (c)OSI管理の動作を規定。 を規定。OSI管理に関するサービス又はプロトコルについては規定しない。システムの実装仕様書及び実装の適合性を検証するための基準となるものではない。 |
JIS X 0008 は,一度は目を通しておくと良いと思います.GMITS などと微妙に定義が異なったりするところもありますが,基本的な用語は抑えておくべきでしょう.
いかちょー (2005-12-07 11:10) | コメント(0)| トラックバック(1)
この掲示板の犯罪予告の話を聞いて思い出したのは,自殺サイトと呼ばれる掲示板の話です.人間社会学を研究されている先生から自殺サイトの問題点と重要性について,お話を伺ったことがあります.
自殺サイトでの書き込みの大半は実行には移されないらしいですが,ふっと実行に至る境界点があるのだそうです.また,「ニセモノ」も当然混じっていて,良いニセモノと悪いニセモノがいるそうです.良いニセモノは自殺に至らないように誘導する人.悪いニセモノは自殺に至るように背中を押す人.心理学の専門家で,良いニセモノをやっている先生も中にはいるそうです.
問題なのは,これらの書き込みが本当かウソかなかなか判断がつかないことと,この掲示板の存在自体が自殺行為に至る雰囲気を増長させている可能性があるということです.一方で,このような掲示板を閉鎖してしまうと,アングラ(アンダーグラウンド)に潜ってしまい,結局,対策も何も出来なくなってしまうため,掲示板の存在が重要になっているということです.
犯罪予告にしても同様で,掲示板があるからこそ自己顕示欲を増長させる一方で,アングラに潜んだり予兆が見えなくなると事前防止策が打てなくなります.
そうした中で,警察の事前対応には現在の制度の中では限界があると聞きます.事件が起こってから対応する従来のからの仕組みの中では,予兆があっても掲示板のログを証拠として強制的には取得できないと言います.この点をめぐって刑法の改正が検討されているようです.
私は法律の専門家ではないので詳しいことはわかりませんが,同じく検討されている「共謀罪」というのも,テロなどの犯罪を事前に防ぐためのものだそうです.ただ,共謀罪捜査に歯止めがないと,いたずら密告という別な弊害も生む可能性もあります.
話が少しそれてしまいました.
ログが強制的に取得できることが周知された場合,結局,匿名の投稿はなくなってしまうかもしれません.そうすると,掲示板を廃止したり,記事を削除したりするのと同じように,アングラの世界に隠れてしまうことが考えられます.ここが難しい問題です.
コンピュータ・フォレンジクスは,すでに犯罪捜査の手法として確立しつつあります.防止という面から,さらに情報技術が関与できるところはないのか.情報セキュリティの一環として,引き続き検討していかなければならないと思っています.
電子掲示板とアングラの続きを読む
いかちょー (2005-12-06 11:05) | コメント(0)| トラックバック(1)
手始めに,JIS Q から,"Q 2001", "Q 15001", "Q 19011"の三つ.
|
JIS規格番号 |
JIS規格標題 |
国際規格番号 |
国際規格標題 |
説明(日本規格協会ホームページより転載) |
|
JIS | ||||
|
JIS Q (管理システム) | ||||
|
Q 2001:2001 |
リスクマネジメントシステム構築のための指針 |
対応なし |
|
リスクマネジメントシステム構築のための一般的な原則及び要素を提供。原則及び要素は,どのような組織にも適用でき,かつ,どのようなリスクにも適用。リスクマネジメントシステムの認証規格としての使用を意図していない。 |
|
Q 15001:1999 |
個人情報保護に関するコンプライアンス・プログラムの要求 事項 |
対応なし |
|
個人情報の全部若しくは一部を電子計算機などの自動処理システムによって処理している,又は自動処理システムによる処理を行うことを目的として書面などによって処理している,あらゆる種類,規模の事業者に適用。 |
|
Q 19011:2003 |
品質及び/又は環境マネジメントシステム監査のための指針 |
ISO 19011:2002 (IDT) |
Guidelines for quality and/or environmental management systems auditing |
監査の原則,監査プログラムの管理,品質マネジメントシステム監査及び環境マネジメントシステム監査の実施,並びに品質及び環境マネジメントシステム監査員の力量に関する手引を提供。 |
JIS Q 15001 はいわゆる「Pマーク制度」の基本となっている要求事項です.
いかちょー (2005-12-05 17:30) | コメント(0)| トラックバック(52)
ちょっと気になったので,RBAC について.
kawabe さんのブログ「カルテ管理システム(11/21) -- RBAC」や「RBAC(Role-based Access Control)を超えて...」を読んで,改めて RBAC について簡単に書いてみることにしました..
RBAC とは "Role Based Access Control" の略で,アクセスの主体(Subject)の"Role" に応じて,客体(Object)へのアクセス権限を決めようというものです.
「アクセス制御」の(歴史的に)最も有名なモデルは,Bell と LaPadula によって定義された「Bell-LaPadulaモデル(BLPモデル)」だと思いますが,このモデルは,米国国防総省によって軍事機密を守るために開発されたもので,秘匿性モデルに分類されます.
機密レベルが上位の者が下位の者に機密を漏らすことを阻止するために考えられたモデルで,下位の者が上位に報告(write)することは出来るけれども,上位の者が下位に漏洩(write)できないように考えられています.「権限」という考え方で考えると上位になるほど権限が大きくなるように思われるかもしれませんが,BLPモデルではそれよりも機密の漏洩に主眼を置き,そのため「秘匿性モデル」と呼ばれています.
現在は廃止されていますがTCSEC ("Trusted Computer System Evaluation Criteria",通称オレンジブック)という評価基準の最高位基準では,この Bell-LaPadulla の実装が義務付けられています.(TCSEC に代わり現在は JIS X 5070 (ISO/IEC 15408)が使用されています)
「上位の権限」という考えに基づいたモデルは「完全性モデル」と呼ばれ,不正な更新の阻止に主眼が置かれています.このモデルには,Bibaモデルなどがあります.
近年では,現実の世界において,より複合的な組織やグループの形成,個人の役割の多重化などが進む中で,コンピュータシステムの世界もこれに合わせて役割によって権限の範囲を設定するモデルが主流になってきています.役割を元に権限を設定することから,Role Based Access Control と呼ばれ,RBAC(アールバック)と略記します.さまざまなRBACモデルが提案されていますが,現在はNIST(National Institute of Standards and Technology)によって提案されたRBACモデルがANSIで承認され,標準となっています.
RBACでは,一般ユーザの役割と権限の制御だけでなく,管理者の権限も分割することが出来ます.たとえば,Webサービスのプロセスや資源を管理する者と,ログを管理するもの,ユーザの管理をする者などに分けて必要な権限を与えるということが可能です.このような考え方を最少特権と呼びます.すなわち役割(ロール)に応じた必要な権限を最小限に与えるという考え方です.
このような役割と権限の割り当て方針をアクセス制御ポリシーと呼び,アクセス制御ポリシーに従ってアクセス制御の管理を行う者を,一般のシステム管理者と区別して情報セキュリティ管理者と呼ぶ場合があります.
RBAC と似たようなモデルに,TE(Type Enforcement)というものがあります.
TEとは,アクセス制御のための行列を定義して,対象物に操作を行おうとする主体のアクセスを制御するモデルです.厳密にはRBACとは異なりますが,同一視する場合もあります.TEでは,操作する側の主体の属する「ドメイン」と,操作される側の対象の属する「タイプ」を定義し,それらを行列で表して,許可される操作を記述します.
セキュアOSとして注目されているSE-Linuxは,RBACとTEを実装しています.
IPA(独立行政法人 情報処理推進機構)から「アクセス制御に関するセキュリティポリシーモデルの調査(2005/04/08)」が報告されていますので,興味のある方は一読されると良いと思います.
いかちょー (2005-12-02 14:05) | コメント(0)| トラックバック(9)
月別アーカイブ
Copyright (C) 2004-2010 Nihon Unisys, Ltd. All Rights Reserved.
Powered by Movable Type Open Source