V.S.A. III

• 脆弱性が見つかった時にその情報のハンドリング体制に運用者がどのように関わるのか，あるいは関わらないのか．保守なども同時に行っているような場合には関わらざるを得ないが，その場合には運用者への情報公開の範囲をどのように絞るのか．
  
• 触れるデータは極力少なくする．触れるデータを最少にすることで，事故の発生が抑えられるとともに，運用者が疑われることが少なくなる．
  
• OS のログインと運用アプリケーションのログインを明確にする．ユーザアカウントの共有使用は極力避け，誰がどのようなオペレーションを行ったのかをあとでわかるようにする．
  
• 作業の記録を残す．誤った操作を後に追及するためではなく，正しい操作を行ったことを後に証明する記録となる．
  
• バックアップメディアなどの可搬媒体には封緘をする．
  
• 二名以上で作業を行う．操作内容の確認とともに，不正行為を抑止する効果がある．また，常に同じチームで作業を行わず，定期的に配置転換やチーム換えを行うようにする．
  
• そのほかの点についても，運用者自身をセキュリティ事故の追求から守るという視点で考えると良い．

以上のようなことを書いてきました．情報セキュリティ事故が発生した場合，運用者はシステムに物理的に一番近いため，最も疑われやすい立場になります．このことを十分に意識して，運用者自身を守る対策を行うと良いでしょう．そのことがすなわち，セキュリティを強固にすることにつながります．

運用者として ISMS を取得するのもひとつの手ですが，ISMS は決めたことを決めたとおりに運用していることを確認するフレームワークを提供し評価する制度に過ぎません．ISMS の取得によって過信することなく，運用者としてのセキュリティを考えてみてください．

こんにちは，五十嵐です．運用セキュリティに限りませんが，扱うシステムを定期的に変える - 人の配置を定期的に変えることはセキュリティ面から考慮すべき事柄です．

長い間同じシステムの操作運用を行っていると，操作に慣れてしまい，ミスをしたり，本来行うべき確認などを省略してしまうことがあります．また，データなどに触る期間が長くなると，持ち出せる可能性も大きくなります．

このようなことを防止するために定期的に配置転換を行います．触れるシステムを変えるということがひとつ．もうひとつはチーム編成を変えるということです．

操作を担当するシステムを定期的に変えるためには，運用手順書が整備され，わかりやすく記述されていなければなりません．勘に頼ったり，記述されていないことを口頭での確認で補完していたりすると運用者を変えることが困難になります．記述間違いや記述漏れなどは，速やかに訂正し，運用者との間の承認プロセスを経て，常に正確なものを使用します．配置転換が行われてもすぐに遅滞無く作業が行われるようにしておくことが大切です．

また，チーム編成を変えることは，お互いが作業内容を常に正しく確認しあうという点から必要です．同じチームで作業をしていると，なんとなくお互いに信頼できるような気になり，確認作業がおろそかになりがちです．信頼しあうことは大切ですが，慣れによる穴が出来てはいけません．また，悪い意味では，データの持ち出しなどの共謀が行われることも可能性としては忘れてはいけません．見てみぬふりをするということもないわけではありません．このような点からもチーム編成を定期的に見直す必要があります．

何度も繰り返し書きますが，運用者自身が疑われないように，また疑われても疑義を晴らすことができるような仕組みづくりが重要です．

こんにちは，五十嵐です．運用セキュリティ・シリーズ4回目です．最初にお断りしておきますが，運用者＝｛オペレータ，ファシリティ提供者｝という意味で使用しています．運用フェーズの保守などは含んでいません．狭義の「運用」です．

さて，日々の作業を行う運用者は脆弱性情報のハンドリングなどからは切り離された立場にあります．にもかかわらず，情報漏えいなどが起きた場合には，もっとも疑われやすい立場にもあります．この点から，運用のセキュリティは，自分たちを守るという視点で考えなければなりません．

前回は触れるデータを極力減らすということを書きましたが，これは通常，コンソールなどからログインし，アプリケーションなどの作業を行うことを想定しています．OS へのログインと，アプリケーションのログインと，両方で権限を最小にするようにしなければなりません．

このとき，最低でも二人以上で作業を行います．操作を間違えないように確認する意味もありますが，不正な操作が行われないように一人以上が監視するという意味もあります．行った操作はすべて記録します．ソフトウェア側で自動的に記録されるようになっていればなお確実です．この記録は不正が行われていないことを運営者が監査するために使用しますが，逆に，事故に対して運用者が疑われないためにも必要です．また，指定されていないオペレーションを行った場合にアラートが通知されるような仕組みを組み込んでおくことも大切です．

リアルタイムに間違い操作に気づくためにはアラートの仕組みを使用し，事後に確認するために操作ログ＝監査ログを使用します．この点もシステムの仕様設計の段階から要求しておくべき事項です．ログを詳細にとると，システムのパフォーマンスが低下することから，嫌われる場合もありますが，昨今の法制度や社会的な要請から，ログを採ることが当然という風潮にありますので，この機会にログのあり方などを運営者と運用者の間で，しっかりと検討しておくべきだと思います．

運用者が疑われないためにすべきことはまだまだありますが，それは次回以降に．

こんにちは，五十嵐です．運用セキュリティの三回目です．世の中で「運用セキュリティ」というと，一般には「運用フェーズ」の「セキュリティ」を指すようです．しかし，私がここで議論したいのは，運用を預かった者が考えるべきセキュリティです．今までの二回では，運用フェーズでの脆弱性情報の取扱いに関する考え方を示しました．今回は「運用者を守る」という点からセキュリティを考えて見たいと思います．

日々の運用の中には，稼動しているシステムのデータにアクセスしなければならないようなケースがあると思います．バックアップもその一つでしょう．この時，触れることのできるデータを極力減らすようにします．UNIX の root や MS Windows の Administrator などのような絶対的な権限を持つユーザでの操作は行わないようにするのです．そのためには，データへの操作権限が限定されたユーザで操作を行うようにします．逆に言えば，ユーザの権限が特権とは分離された権限で操作を行えるようにソフトウェア開発者に依頼する必要があります．

しかし，現実には，運用者が要求仕様の段階から関われるケースは少なく，出来上がってしまったシステムを仕方なく受け取るというケースがほとんどだと思います．この点は今後改善していく必要があるとは思いますが，まずは自己防衛しなければなりません．

すなわち，何か事故が起きたときに，運用者自身が被害にあわないようにすることです．スクリーンショットを取ったり，デジカメの写真で残すなど，操作の記録をすることです．一番よいのは，OS やアプリケーション側で操作の記録(ログ)が自動的に採られていることですが，オペレーションログをすべて採るような仕組みを入れているソフトウェアはまだまだ少ないようです．このログによって，運用者は悪意ある行為を行っていないことを証明できます．もちろん，電子データは簡単に改ざんできるので，証拠としては不十分ですが，なにも無いよりは自分達を守る材料にはなるはずです．

また，操作するためのユーザ(アカウント)は，できるだけ共有しないようにします．これも個々人を守るために必要です．しかし，多くの異なるシステムの運用を請け負う場合，すべてのシステムで異なるパスワードで管理することは非常に難しい場合もあります．パスワードの管理自体が煩雑になる可能性があるからです．一人のユーザについてすべてのシステムで異なるパスワードをつけて運用するのが理想ですが，すべてのパスワードが覚えきれないほどの数になることは間違いありません．紙に表などにして参照することが必要になると思いますが，その場合にはその紙をどのように管理するかを考えなければなりません．

ユーザを共有して誰が実際に操作を行った(あるいは操作を行わなかった)かが不明瞭になるリスクと，ユーザを分離してパスワードなどが漏れるリスクのどちらをとるか，運営者とよく討議する必要があります．私は面倒でもユーザを個々人で分けることをお勧めします．

• ハードでＰＣウイルスを高速チェック　産総研が技術開発 (2006/11/22 asahi.com)
• 産総研がウイルス対策をFPGAで実現，回路の組み換えで新種に対応 (2006/11/22 IT Pro)

• [PDF] 「ソフトウエア等脆弱性関連情報取扱基準」（平成16年経済産業省告示 第235号）
• 情報セキュリティ早期警戒パートナーシップガイドライン（2006年9月改訂） (IPA, JPCERT/CC)
• [PDF] SI 事業者における脆弱性関連情報取扱に関する体制と手順整備のためのガイダンス (JISA/JEITA)

• 【IT Service Forum速報】「万一に備えて，企業にもセキュリティ対応チームを」---JPCERT/CCが提言 (2006/11/21 ITPro Security)

伊藤友里恵さん，しっかり顔写真でてるし．．．

• サイト運営者
  Web サイトのオーナー．Web サイトを利用する方へサービスを提供します．
  
• 利用者
  Web サイトを利用する方．ブログのようなサービスの場合，ブログの作者と閲覧者がいますが，簡単化のために運営者と直接の利害関係にある利用者を顧客とします．
  
• 運用サービス・プロバイダ (OSP: Operation Service Providor / FSP: Facility Service Providor)
  運用者．日々のオペレーションを行う方．ハウジングやホスティング，iDC などの設備において，ファシリティを提供する方も含みます．
  
• マネージド･サービス･プロバイダ (MSP: Managed Service Providor)
  監視や障害のコールセンターなどを行う方．
  
• 保守サービス･プロバイダ (mSP: Maintenance Service Providor)
  システムのメンテナンスやソフトウェアの改修などを行う方．
  
• 脆弱性発見者
  Web サイトの脆弱性を発見した方．利用者の一人と考えればよいでしょう．

こんにちは，五十嵐です．開発，導入が終わって運用フェーズに入った段階での情報セキュリティについて考えています．

運用が移管される時に，導入チームからの引継ぎを行わなければなりませんが，その時に必要とされるものは何か．顧客との間で合意を得た運用手続き文書は当然として，設計，開発，テスト，導入のうち，運用に必要となる文書を引き継がなければなりません．

このとき，運用チームへ必要以上に情報が渡らないようにしなければなりません．理由の一つは，機密性の保持．もう一つは運用者が不要な責任を負わないため．運用者自身を守るという視点にも立たなければなりません．

運用チームに何人かを配置する場合，管理者権限のようなものをどこまで与えるかということも考える必要があります．一つの管理者ユーザアカウントを共有するという方法もありますが，誰がどのようなオペレーションを行ったのかを明確にするためにも，複数のアカウントで管理ができ，それぞれのオペレーションが記録されていることが大切です．

そうなると，仕様を作る段階で，運用形態を考えた管理仕様を考えなければなりません．正直なところ，複数運用者が運用を行うことまできちんと考えられて作られたソフトウェアは多くはありません．世の中に出ているアプリケーションの中には，OS の管理権限とアプリケーションの管理権限を区別できないものすらあります．そういうソフトウェアを使ったシステムの運用をを外部に移管することは移管する側にとっても移管される側にとっても，脅威を増大させることになってしまいます．

管理者権限のユーザを勝手に増やせるかどうかというのも考慮すべき点です．管理ユーザを作るという権限と，運用を行うという部分も全く切り離して，あるいはサブセットの権限の委譲などを考慮して設計されていることが望ましいソフトウェアの姿だと思います．

そこまで考えて作られたソフトウェアというものは世の中にいくらもないのではないでしょうか．運用に当たる予定のチームが，仕様策定の段階から関わっていけるようにしていきたいですね．

• [PDF] 我が国のインターネット治安情勢について (平成 18 年 10 月期) (2006/11/10 @Police)
• インターネット治安情勢 (@Police)

毎月マメに見ているわけではないのですが，9月は TCP ポート 445 番への攻撃が急増していたのに対して，10 月は激減しているようです．MS Windows の脆弱性に対する攻撃が一段落してきたのですね．

こういうレポートを見ていて思うのですが，様々なところで定点観測などが行われ，それぞれがレポートを出していますが，総合的にまとまったレポートをだせないものでしょうか．警察もそうですが，Telecom-ISAC や JPCERT/CC などなど．．．

ちなみにこの @Police のサイト，RSS リーダに登録しておくと毎月のインターネット治安情勢のレポートが出ると知らせてくれるので便利です．
RSS⇒ http://www.cyberpolice.go.jp/index.rdf

• JPCERT/CC 訳『C/C++セキュアコーディング』刊行のお知らせ (JPCERT/CC)
• 『C/C++セキュアコーディング』 (ASCII)

• 松下電器産業、家庭向け高速PLC製品を12月9日に発売 (2006/11/13 Broad Band Watch)
• コンセントでネット接続---松下が国内初のPLCアダプター発売 (2006/11/13 日経パソコン PC Online)
• コンセントでネット接続---松下が国内初のPLCアダプター発売 (2006/11/13 IT Pro Network)
• 高速PLCついに店頭へ，松下が190Mbpsモデムを12月発売 (2006/11/13 IT Pro Network)

• 電力線通信の規制値に答申，今秋の規制緩和が見えた (2006/06/29 IT Pro Network)
• 電力線搬送通信設備の技術基準等の整備に関する無線設備規則の一部改正案に係る電波監理審議会からの答申及び関係省令案等についての意見募集の結果 (2006/09/13 総務省)
• 【速報】高速電力線通信がついに解禁，省令改正へ (2006/09/13 IT Pro Network)
• 高速電力線通信の屋内利用がついに解禁，4日付けで法改正 (2006/10/04 IT Pro Network)
• CEATEC (2006/10/06 Tyzoh ブログ)

• [PDF] NCSC-TG-001 トラステッド・システムにおける監査を理解するためのガイド (日本セキュリティ・マネジメント学会)
• (原文) A Guide to Understanding Audit in Trusted Systems (米国 NIST)

• バルカン (フリー百科事典『ウィキペディア（Wikipedia）』)
• バルカン (スタートレック) (フリー百科事典『ウィキペディア（Wikipedia）』)
• バルカン人 (フリー百科事典『ウィキペディア（Wikipedia）』)

• [PDF] Protection Profiles for Discretionary Information Flow Control (DIC)
• [PDF] Discretionary Information Flow Control (MU) ：Multi-User
• [PDF] Discretionary Information Flow Control (SU) ：Single-User

• 失敗知識データベース (JST 科学技術振興機構)

ここでは事故の原因などを分類し，傾向などがわかるようになっています．情報セキュリティの事故なども登録されています．

情報セキュリティに限らないのですが，会社の営業が公募などで取れなかった原因，失敗した原因を共有できる仕組みがあるといいのではないかと思っています．あるお客様に対しては効果がなかった提案でも，他のお客様には効果があるものもあるはずです．そういうものを全社的に洗い出す仕組みがあると，営業効率が上がるのではないかと思います．

情報セキュリティでは，どのような状況がどんな失敗を生むのかをもっと広く公開していくべきではないでしょうか．確かに社内の恥をさらすようなことになるかもしれませんが，それによって良い方向に進めれば，失敗のマイナス点をプラスに向けることが出来るのではないかと思っています．

kernel = "/boot/vmlinuz-2.6.18-1.2200.fc5xen0"
memory = 128
name = "rinza-rdf"
disk = ['file:/work/Rinza_RDF_Appliance-0.1.0/rinza-rdf-xen-image\
/rinza-rdf/rinza-rdf-system.img,sda1,w',\
'file:/work/Rinza_RDF_Appliance-0.1.0/rinza-rdf-xen-image\
/rinza-rdf/rinza-rdf-data.img,sdb1,w']
root = "/dev/sda1 ro"
vif = [ '' ]

# xm create rinza-rdf.xen
Using config file "rinza-rdf.xen".
Started domain rinza-rdf

# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0      363     1 r-----   1520.7
rinza-rdf                                  2      128     1 -b----     16.6

# xm console rinza-rdf
...
...
VFS: Cannot open root device "sda1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Xen も初めて触ったので，この環境がうまく行っているかどうかもよくわかりません．他の方は簡単に立ち上げられたのでしょうか？ Xen の設定が悪いのか，Rinza Rdf Appliance が悪いのか，他の要素なのか．．．

Anonymous で Trac に「問題」として報告すればいいのかな？
チケットというのもよくわからないのですが．．．

Rinza RDF Repository Appliance が動きませんの続きを読む

• VirtualLogix - Real-time Virtualization for Connected Devices
• [PDF] ピーター・リチャーズ 経営最高責任者からのお知らせ (2006/09/26 VirtualLogix)

旧社名 Jaluna からつい先日， 9 月 26 日に VirtualLogix という名前に変更されたようです．知りませんでした．携帯などの組み込み系で利用されているようです．

セキュリティ面など，どうなっているのか気になります．他のマイクロカーネルもどうなっているのか，調べてみようかと思います．みんな組み込み系に流れているのでしょうか．マイクロカーネルというよりも「Virtualization」の方面から注目されているようです．

こんにちは，五十嵐です．10 年ほど前，マイクロカーネルがブームとなりましたが，昨今はどうなのでしょうか．

Mach，Chorus，Sprite など，様々なマイクロカーネルが登場して，研究者の間では Mach 主流，商用的には Chorus という感じだったと思います．セキュリティを強化するには，小さいカーネルでモニタリングシステムが必須とされていますが，今こそマイクロカーネルが威力を発揮するのではないでしょうか．

マイクロカーネルに，リソースの管理とセキュリティを任せてしまい，その上に OS をかぶせる．ある意味 VM 環境ともいえますが，こうした小さいカーネルがセキュリティを強化することに役立つような気がしています．

世の中的には最近は，どういう感じなんでしょう．私的にはちょっとだけ Chorus をかじったので，セキュリティ面から今一度マイクロカーネルというものを見直してみてはどうかと思います．オープンソースのマイクロカーネルがあれば見てみたいですけれど．．．
(TRON がそうだといえば，そうなのかもしれませんね)