NRAが今年のセキュリティ10大ニュースを発表 52
ストーリー by Oliver
ほとんど人が穴 部門より
ほとんど人が穴 部門より
Anonymous Coward曰く、"大学教授、県知事、国会議員、弁護士、セキュリティ関連企業幹部らが組織するNPO ネットワークリスクマネジメント協会が、24日のメールマガジンで、今年のセキュリティ10大ニュースを発表した。堂々の1位は住基ネットの不安な滑り出し、2位はみずほ銀行の決済不能と異常決済、3位は富士通の自衛隊システム設計情報管理不行き届きと続く。みずほの件からは「隠蔽」「聖域」「マネジメント不在」という企業不祥事の三拍子を学べるとバッサリ。「経営者の中には『情報システムは技術の問題だ。技術のことは自分では分からないので、専 門家に聞いてみよう。』という誤った認識をした経営者が少なくないようだ」など、けっこう詳しい見解が書かれており、読み応えがある。ファイル丸見えが原因の個人情報流出事件も9位に取り上げられている。スラドの読者諸賢のセキュリティニュース大賞は何だろうか。"
うーん (スコア:5, すばらしい洞察)
関連リンクを読むとこの引用にはまだ続きがあったのね。でも続きを読んでも何か物足りない。
「情報システムにはセキュリティの問題が必ずつきまとう。建物をつくるときの防火設備と同じで、金をかけても直接利益にはならないが、おろそかにしていると大損害になる」と書いていただいたほうが、ピンとくるのだが。
セキュリティというものは (スコア:3, すばらしい洞察)
セキュリティ関連の物事は、自組織が安全なときにはあまり注目されません。
いくら担当者が警告をしても、自分が安全なときには上司も一般ユーザもセキュリティには関心を寄せません。
「難しくてわからない」「担当者がやるものだろ」などといいわけをしてその話題にふれようとしません。
しかし、いったんその安全神話が崩れたときには、担当者を槍玉に挙げてすべての責任を押しつけてしまう傾向があります。
このことは、ネットワークのみならず、様々な物事に通じるのではないかと…
＃結局、最終的に自分を守るのは自分なのでしょうか？
Re:うーん (スコア:1, おもしろおかしい)
おいおい（涙）....。
Re:うーん (スコア:1)
Re:うーん (スコア:1, 興味深い)
そのスローガンは一般的で当たり前のことなんで、説得力がないの
ですよ。一般論としてそれは誰もがわかっていて、その上で大丈夫
と思い込んでいるわけでしょ。構造的な問題をスローガンにしない
と効果が無いのだと。
指摘すべきはやはり、経営者と技術者のディスコミュニケーション
の問題ではないでしょうか。技術者が軽視されているというか、技
術者に説明能力が欠けているというか。
リスクの定量評価 (スコア:3, 興味深い)
指摘すべきはやはり、経営者と技術者のディスコミュニケーション
の問題ではないでしょうか。技術者が軽視されているというか、技
術者に説明能力が欠けているというか。
技術的な視点以前に企業におけるリスク管理, 特に定量的なリスク評価を行い, それに見合ったセキュリティ投資を行うという経営技術がごっそりと抜け落ちているところが問題だと思います.
極端な話, ごめんですむことに対して過大なセキュリティ投資を行うのは無駄ですし, 一発で会社の信用が吹き飛ぶような情報については相応のセキュリティが必要でしょう. こうした情報の価値判断は技術側からではなく, 経営側からなされるべきものです. ですが, ほとんどの経営フィールドにおいて, 社外秘とは「絶対」に漏れてはいけないという2値的な観念しかなく, これが思考停止を招いています.
ですからまずはセキュリティ障害は起こることだという前提に立って, その場合の損害を取りまとめ, ここでようやく情報システムのセキュリティの評価に入るべきです. ただ, このような議論は情報システムに限らず, 本当に何年も(下手すりゃ何十年も)前から経営におけるリスクマネジメントの重要性として言われてきていることですから, 今更言ったところで変わるものとも思えないところはあります.
Re:リスクの定量評価 (スコア:2, 参考になる)
なにもセキュリティでなくても「定量的なリスク評価」なぞしていないし、
もちろんそのリスクに見合った「リスクヘッジ」を行なっていない、
という傾向が日本の企業には強いですよね。
＃それができてたらバブルは起きてないし、今現在している金融
＃政策もかなり背中に冷や汗が…。
結局は「みんなと一緒」ならなんとなく安心できる、そして、
その「安心感」が経営者にとって一番重要なコトなのでしょう。
定量的なリスク評価に「安心感を与えられるだけの説得力」
がある評価ができているのか？という（自戒をこめた）問題
もありそうです。
みんつ
Re:うーん (スコア:0)
dis- は「無」・「不」などを意味する接頭辞。
結論として、「コミュニケーションの欠如」という言葉になるかと。
Re:うーん (スコア:1, 興味深い)
> dis- は「無」・「不」などを意味する接頭辞。
dyscommunication では？
dys- は「不全」「異常」「悪化」「不良」「困難」「欠如」を意味する接頭辞。
dyscommunicationで検索 [google.co.jp]
Re:うーん (スコア:1)
# ちなみに、dyscommunication は英辞郎にも
# Exceed にも(まだ?)ありましぇん。
Re:うーん (スコア:0)
ぐぐってみてもほぼ日本人しか使っていないので、
何らかのテクニカルタームなのかと思っているのですが、どうなんでしょう？
Re:うーん (スコア:0)
そのキャッチーさにより一般に使われるようになり、
作品名などにもなった(みたいですね)ことで
Google の上位に来ているのではないかと思います。
たぶん、外国では一般的には使われない単語なんでしょう。
# 原文で思想系の論文を読めるような人間ではなく
# あくまで推測なので AC。
Re:うーん (スコア:2, 参考になる)
山際淳司（『江夏の21球』の著者）が二十数年前に
エッセイの中で「ディスコミュニケーション」って
使っていたですよ。
曰く、ロバート・ホワイティング（『菊とバット』の著者）と
呑んでいるときに、
"One more pitcher, please"
（ビールを入れたピッチャーのこと）
と注文するのを聞いて、
「投手をもう一人って、どういう意味？」
と聞きかえしちゃったとか。
んで、外国人相手ではお互いに誤解をさけることは難しい、
「ディスコミュニケーションはいくらでもある」だって。
...なんだか非常に和風な感じがしますな
「ディスコミュニケーション」って。
Re:うーん (スコア:0)
はい、解消されませんでした。
/.j的セキュリティニュース (スコア:2, おもしろおかしい)
足 [srad.jp] 元 [srad.jp]。
足元といえば (スコア:2, 参考になる)
Re:足元といえば (スコア:2, 興味深い)
Re:足元といえば (スコア:0)
> パスワードはブラウザに保存機能があるんだし。
> どうしてこうクッキーを使いたがるのかなあと。
んーと、BASIC認証を使いたがらない状況があるから、かな？
BASIC認証で良いよって言って貰うと楽なんだけどね。
Re:足元といえば (スコア:1)
a) セッション管理ができる
b) BASIC認証ダイアログの*見ため*を心配する人がいる
を思いつくんですが他になにかあったっけ。
BASIC認証って簡単 & 便利だと思うんだけど...。
a はともかく、 b は勘弁してほしい。
# そういえばユーザの認証に証明書を使ってるサイトってまだ見たことない気が。
Re:足元といえば (スコア:2, 参考になる)
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証が必要だけど、cookieならルートディレクトリでcookie吐いておけば一回で済む
e)BASIC認証だと、毎回生パスワードをBASE64したものが流れるので生理的に受け付けられない:-)
というのもあるかと。
HTTP/1.1でもパスワード流れるんだ・・ (スコア:3, 参考になる)
HTTP/1.0 だと生で, HTTP/1.1 だとチャレンジ+パスワードのダイジェストかと勘違いしてました。
調べてみたら確かにパスワードの Base64 ですね。他人の情報を鵜呑みにした自分が馬鹿だった。反省。
# 鵜呑みにするなよ＞自分
Re:足元といえば (スコア:1)
www1.example.com と www2.example.com のようにサーバ名が違う状況でなら、たぶんおっしゃるような違いがあるのだろうと思います。
鵜呑みにしてみる？
Re:足元といえば (スコア:1)
試したら確かに 領域名(realm の値というのか..?)が同一であれば
一度の入力で、それ以後は入力の必要はありませんでした。
サーバが違うとどうなるかっていうのはやってません。めんどくさくて。^^;
..とか、書こうとしたがやっぱ実験しました。
192.168.1.x と www14.cds.ne.jp でやってみたら同じ領域名でも2回入力が
必要ですね。
w3m on Linux, mozilla 1.1b on win2k, IE5.5 on win2k で実験しました。
もちろん、調べたクライアントのすべてがそのような挙動を示しただけで、
これが正しい挙動かどうかは判断しかねます。
# 仕様書見れや＞自分
# # 見たんだがわからなかったのは秘密
Re:足元といえば (スコア:1)
ブラウザがどういう場合にユーザにユーザ名とパスワードの入力を求めるかについて、 RFC2617 [zvon.org] では、ページ A とページ B の「protection domain」が異なるならば、ページ A のユーザ名とパスワードをページ B にアクセスするときに自動的に使ってはいけない、とだけ規定しています（1.2 節 [zvon.org]）。
基本認証の場合、サーバ名が同じで領域名も同じ場合だけ、同じ protection domain に属すると見なされます（正確には、「サーバ名が同じ」ではなく「root URL が同じ」と定められています。言い換えれば、プロトコルやポート番号も同じでないといけません）。
よって、プロバイダの Web サーバなどで http://www.example.com/~user1234/ のような URL になっているページで基本認証を使うと、他のユーザがユーザ名とパスワードを盗めることになると思います。この点は cookie だと有効範囲を domain と path で指定できるので安全でしょう。基本認証と cookie で cookie のほうがよい点の一つということになります。
（と書いておきながら、ぼくはそんなこと今まで知らなかったので、まったく自信がありません。知っている人は知っていることなのでしょうか。それとも、ぼくは何か間違えている？？）
ダイジェスト認証はブラウザの対応状況が問題ですが、 cookie のように protection domain をより細かく指定できるようです。基本認証とダイジェスト認証の違いはパスワードを平文で送るかどうかだけだと思っていたので、そうではないと知って少し驚きました。
鵜呑みにしてみる？
Re:足元といえば (スコア:1)
- ユーザにアクセスログの閲覧が認められている場合
- ユーザに任意のCGIプログラムの設置が認められている場合（リクエストヘッダを環境変数などから得られる）
である（JavaScript等の静的コンテンツからはAuthenticate情報を参照できない）ため、CGI設置とアクセスログの閲覧が許されていないサーバでは、Basic認証が有効ではないかと考えられます。Re:足元といえば (スコア:1)
普通のCGIでは、CGIプログラム側に渡されるのはユーザ名だけなので、パスワードが盗まれることはありませんね。同様にアクセスログについてもそうです。
Re:足元といえば (スコア:1)
せっかく cookie には有効範囲を設定できるようになっているのに、 Javascript のほうは「身内ページ」の判定をサーバ名（だかサーバ名＋スキーム名＋ポート名）で行っているので、危険だという理解で合っているでしょうか。
そう考えると、今のところ「管理者が違うところは（name-based virtual host を使うなどして）違うサーバ名にする」という方針にしたほうが安全なのでしょうか。CGI プログラムを他のユーザが設置できなければ安全というのはそうだと思います。
調べている時間がないのですが、 CGI プログラムを置いたら、パスワードまで取れると思いますよ。 CGI プログラムで基本認証の delegation をしている例は実際に世の中にありますし。
「基本認証の delegation」という言葉は合ってないかもしれないのですが、適切な表現が見つからない上、説明している時間がありません。ごめんなさい。 W3C HTML Validator [w3.org] で validate しようとしたページが基本認証でアクセス制限をしていても、ユーザ名とパスワードを Validator に対して入力すればちゃんと validate できるというのが、ぼくが「基本認証の delegation」という言葉で表現したい動作ですが、これでご理解いただけますか？（しかも validator.w3.org は今落ちているみたいだ……。）
鵜呑みにしてみる？
Re:足元といえば (スコア:1)
Re:足元といえば (スコア:1)
以下では Apache に限定します。調べてみたら、 Apache では普通 Authorization ヘッダの内容を CGI プログラムに渡さないようになっているそうです。なので、ぼくが危惧していたような問題は起きないみたいです。
ぼくが見たケースでは、このあたり（つながらないので Google のキャッシュ） [google.com]に書かれている工夫が使われていたようです。もし mod_rewrite が有効なら、これを使うと盗めるのではないかと思いますが、たしかデフォルトでは無効だったような気がします。
鵜呑みにしてみる？
Re:足元といえば (スコア:0)
Re:足元といえば (スコア:1)
f) アプリケーションサーバ導入したら、「cookie認証 & 使えなかったら URL 埋め込み」な設定になってる(場合によっては基本認証だと機能制限される)製品だったから。
ネット管理者やハッカーが多そうな/.Jとしては (スコア:2, 参考になる)
これを機に署名チェックをしっかりと行うようになった方も多いのでは?
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:ネット管理者やハッカーが多そうな/.Jとしては (スコア:3, 参考になる)
Theoの陰謀ではないかと勘繰ってみたり...
OpenSSHに未公開・未修整の脆弱性 [srad.jp]の時にすったもんだがあったし
日本語が.... (スコア:2, おもしろおかしい)
> 世の中に密かに、だか確実に広がりつつある脅威を認識・知覚し、それらに十分対抗しうるセキュリティの構築が急務である。
「セキュリティ」って「構築」できるものだったのか！という驚きが、クリスマス商戦でみごとな敗北を喫した秋葉原を木枯らしとともに駆け抜けています(笑)。
また、「脅威を認識・知覚」する、という、その、なんというか「知覚」なんてあなた、昆虫の触角ではあるまいに、「認識」だけでよかったんじゃないの？無理に普段使い慣れない言葉を使うと、こんなことになるわさ、というような、ムズがゆさを我々に運んでくれます。
みなさま、よいお年を。
Re:日本語が.... (スコア:1)
来るべきNew Yearにはセキュリティの驚異を知覚できる人類の革新が必要とされているのです。
Re:日本語が.... (スコア:1)
安心とか安全性とか、こういうのは一つ一つ積み上げていくのが正しそう。
・・・なんてのを考えると、「構築」も可能だと思ったりして。
kaokun
ついでに (スコア:0)
> 来年末には、これらの新たな取り組みが実を結んだ記事を十大ニュースとして報じたいものである。
本当にそうなっちゃうと、このNPOの存在意義もなくなっちゃうから、NPOも存在しなくなり、十
Re:ついでに (スコア:0)
このNPOの存在意義?
来年末以前に、今年の年末がなくなるかもしれません。
→#225000 [srad.jp]
第4位の事例が今日もまた (スコア:2, 参考になる)
第6位の事例も。 (スコア:1)
Re:第4位の事例が今日もまた (スコア:0)
> 経済産業省では、情報システム厚生課の無線ＬＡＮの電波が、外部から受信できる状況だった。
> パソコンに、「ハリー・ポッター」などの映画やドラマ、アイドルのビデオなど
> 多くの不正コピーソフトが蓄積されていた。
個人的には (スコア:1)
個人的に一番影響あったので･･･
Re:個人的には (スコア:2, 参考になる)
私の責任で管理してるマシンじゃないので責任問題にはならなかったのですが、油断大敵だなぁ、と改めて気を引き締めています。
ちなみに手口ですが、OpenSSL のセキュリティホールを利用して、mod_ssl から apache を乗っ取り、ファイルでエージェントプログラムを送り込んで起動していたようでした。(つまり、踏台にされていた)
侵入の手口が杜撰で足跡消しをしてないため発覚したのですが、原理的には巧妙なヤツだと侵入が発覚し難いと思います。最新に更新済みか改めて確認するのが吉ですね。
の
UNIX 方面だと (スコア:1)
ＴＢＣ (スコア:1)
--
Regards, Regards （Slashdot.jp 無粋部）
すいません（was:ＴＢＣ） (スコア:1)
と書いてありました。
新たにスレッドをたてるまでも無うございました。失礼いたしました。
（※これらの事件の持つ意味までも否定するものではございません）。
# なお、勝手ながら反省文 [srad.jp]は省略させてください。
--
Regards, Regards （Slashdot.jp 無粋部）
Re:ＴＢＣ (スコア:0)
自分の予想では (スコア:1)
ちとジャンルが違ったかも。