アーカイブ

Security

7/4、POPFile v0.22.5がリリースされたとの知らせを受け取りました。

この新しいバージョンの解説には、DBエンジンとしてSQLite2を使うようになったこと、日本語処理に関するあらゆる改善、そしてユーザインターフェース”Nihongo”の環境の改善も挙げられています。

私の環境では、これ以前のバージョンで判定率99.8%なので何の問題も感じていないのですが、さらに改善したというのであればそれは歓迎です。

POPFile v0.22.5の入手はこちらから。
http://popfile.sourceforge.net/wiki/download

今回のアナウンスには、SourceForge.netの’Community Choice Awards’ for 2007について触れていました。以下のリンクを訪れますと ‘Best Project for Communications’カテゴリーにノミネートされているのを見ることができます。

よろしければどうぞ。

http://sourceforge.net/awards/cca/vote.php

広告

本年も夏の風物詩、若者をセキュリティを題材にトレーニングする「セキュリティキャンプ2007」の開催が発表されました。カリキュラムの検討会では講師陣が口々に「それ、おれが聞きたいよ」という声が頻発するイキオイの、魅力的な内容となりつつあります。

ネットワーク、運用、WEBアプリケーション、その他さまざまな観点のセキュリティを他流試合で学べるのはとっても楽しいですよ。技術的にすでにスキルが高いことよりも大切なことは、取り組む意欲だと思います。セキュリティキャンプは環境としてのセキュリティの重要性を、いろんな観点で学ぶところだからです。

なぜ、セキュリティを学びたいか。 これです。

ケーススタディ、ハンズオン、ワークショップなど学び方も盛りだくさん。何かを一緒に経験したいという方なら、とても盛り上がります。修了後の人的ネットワークも貴重なプレゼントです。

なんと、修了生の一人、迎くんは今弊社でがんばってくれています。彼は、各社ケイタイの互換性に関するスペシャリストです。(DODAのサイトに登場しています)

応募資格は22歳以下のITに関心の高い皆さん。ぜひチャレンジしてみてください。もしかすると、このブログは親御さんや先生たちが見られることのほうが多いかな?だとすればご子息の参加を促してみてください。

応募締め切りは7月2日となっています。

開催日時:平成19年8月13日(月)から8月17日(金)
場所:幕張/海外職業訓練協会(OVTA)

詳しくはJIPDECの「セキュリティキャンプ2007」サイトへ。

どんな皆さんにお目にかかれるのか、今からとっても楽しみにしています。

cf. 6/1 経済産業省発表 「セキュリティキャンプ2007」の開催について

1位:「ちゃんと セキュリティ」158万件。
2位:「しっかり セキュリティ」150万件。
3位:「きちんと セキュリティ」140万件。

これらはこの記事を書く時点でGoogleでヒットした件数です。これを仮に、「セキュリティ解説の御三家」と名づけることにしましょう。まずは、検索結果をしげしげと眺めてみてください。何かもやもやとしませんか。釈然としないというか。

「セキュリティ」のように、高度な(?)概念を人に説明するのは難しい。日本語にはそういうときに便利な言葉がたくさんあります。これが、「御三家」であり、上記のとおり、解説にはひっぱりだこで用いられています。

言葉の意味するところを突っ込んで調べていくと、姿勢、頻度、正確性、網羅性、緻密性、計画性などという要素に分解して説明したほうが意図がびしっと伝わって良さそうなものですが、比較的具体的な言葉、たとえば「綿密(59600件)」「緻密(18万件)」「徹底的(72万件)」「早急(79万件)」などはそれほど使われていません。

そう、セキュリティは、「御三家」により「適切に」やれ、と。ははぁ。

これこそ、封建社会日本の奥ゆかしい文化であり、日本語の奥ゆかしさなのかもしれません。なんとなく上のほうを向かせて、無限遠を目指させておき、何かあっても「対策に漏れがありました」と言わざるを得ない状況に落とし込みます。

そこで言うのです、「けしからん、ちゃんとやってないからだっ!」、と。殺生な話ですが、「セキュリティ解説の御三家」は殿様クラス。逆らう余地を残しません。

なので、実際にセキュリティをなんとかしなきゃいけない現場や、教育の過程などでこの言葉を言っちゃうとダメ。場がとろけちゃうんです。実際にやらなきゃいけないこと、起きている問題の本質からの距離が遠すぎて、顧客は、いや、”セキュリティ専門家”でさえも、何を、どの程度、どうしたらいいのか、根拠を提出しにくくなり、思考の軸を失います。

例)企業として全社的なセキュリティ対策がしっかりと徹底されているか、今一度確認しましょう。
例)情報の収集をきちんと行っているか
例)不要なサービスを立ち上げない
例)DNSサーバを適切に設定する

この「適切に」「確実に」「必要最低限の」などという言葉は御三家よりはちょっとましに見えますが、、、もし、妥当性の目安や、必要・不要の判断のポイントを示すことが必要ですね。さもなくば、そのメッセージは、不安感を煽る以外にどんな効果があるんでしょうか。

# あ、不安を煽るところにビジネスモデルがあるんでしたっけね? ;-p

ところで、最近発表された、注目すべきドキュメントが二つあります。

IPA「安全なウェブサイトの作り方 改訂第2版」
http://www.ipa.go.jp/security/vuln/websecurity.html

産総研「安全なWebサイト利用の鉄則」
http://www.rcis.aist.go.jp/special/websafety2007/

すばらしい。原則的であり、網羅性があります。「御三家問題」も見当たりません。読者がかなりの程度自分で判断できますし、専門家を交えて、より有意義な議論のための基礎資料にすることができます。

まずは、こういうドキュメントをちゃんと読んで・・・。はっ!(汗

すみません。これからは、「セキュリティ解説の御三家」「ちゃんと」「きちんと」「しっかり」)は、なるだけ使わないよう努力します。これからは、セキュリティ解説にこれが含まれている間は右から左へうけながすことにしましょう。

昨日のこと、Thunderbirdでメールを取得しようとすると、8000件とか表示された。唖然。私の場合、メールを取得中にメーラーが異常終了した とか、VPNあるいはSSLトンネルの通信が不意に途切れたというようなケースで、メーラーとサーバのメールボックスの同期関係が失われちゃう。ああ、 すっかり全部読み込み直しなんだな…。サーバでの保存期間をもっと短くしておけばよかったか…。

いや、問題はメールの保存期間ではない。 そのメールのほとんどがSPAMだもの。8000件中、少なくとも7000件はSPAM。それを再fetchしてごみ掃除をするなんて鬱陶しい・・・。

普段、私 のSPAM対策環境は三段構え。サーバでKaspersky Antispam(95%以上判断)、取得経路にPOPFile(私にとってのSPAMを判断)、最後にメーラーのSPAMフィルタ(前者を信じてゴミ箱 に投げ込む)。

サーバにメールが配送された時点で95%は完了している。ただ、サーバ管理者のポリシーから、それらのメールは削除されず、「これは SPAMですよ」というマーキングがしてあるだけ。だから8000通もサーバに残っているわけで、同様の理由でメール通知関連の機能は一切使っていない。

GMailのSPAMハンドリングは便利だが、私にとってGMailは「別系統」であるところに価値を感じているので、メーラからGMailにアクセスするという使い方はしていない。

で、 本題に戻って、8000通も再取得せずになんとかしたい。事前に消えていればかなり便利じゃない?もちろんtelnetで手動でPOPプロトコルをたたく のは十分可能なんだが、8000通もやるのは現実的ではない。そう、欲しいのは、「マジックハンド」のような、POPのDELEコマンドを器用に使えるツールだ。

フリーのツールを探してみたら、Spam Mail Killerというのが見つかった。

http://www.forest.impress.co.jp/lib/inet/mail/antispam/spamkiller.html

ス パムなどの迷惑メールをPOPサーバーから自動で削除するメールチェッカー。タスクトレイに常駐して一定時間おきにPOPサーバーをチェックし、あらかじ め指定した削除条件にあうメールがPOPサーバーにあればサーバーから自動削除。残りを新着メールとしてサウンドやタスクトレイアイコンの点滅で通知す る。削除条件には送信者、宛先、Return-Pathなどに含まれるメールアドレス、およびメールヘッダーの任意の文字列を複数指定できる。・・・ 複数メールアカウント対応で、削除条件の設定画面では新着メールのヘッダーを参照しながら設定できるようになっている。

おお、ゴージャスな機能がついているね。しかも最近アップデートされたようだ。いわゆるBlacklist方式でSPAM対策することを目的に作りこまれて いるので、このツールだけでSPAM対策は完結しない。私の場合、サーバに配送された時点でほとんどの判断が終わっているので、メールヘッダの記載を指定 するだけでかなり十分に機能する。Spamassassinを仕込んでいる人にも有効だろう。条件に正規表現も書けるところがまたイイ。

超便利だわ、これ。
標準ツールに決定。

PCのシャットダウンボタンをデスクトップに設置すると、確かにこれは便利でした。でも、編集中のドキュメントを壊す可能性もあり、ちょっとコワい。結局、「-t 5」くらいのオプションにしています。

利用頻度からすれば、PCのロックのほうが欲しい。この機能はWindowsのビルトイン機能で言うところの「コンピューターのロック」ですね。このショートカットを同様の方法で作ろうと調べると、キーボードショートカット「Windowsキー + L」があると知りましたが、残念ながら、私の常用しているキーボードにはWindowsキーは存在しないもの。

と言っている間に簡単に作れましたので、以下に手順を示します。

1. デスクトップ上で右クリックし、「新規作成」→「ショートカット」を選択する。
「新規作成」→「ショートカット」

2. すると、そのショートカットの内容を記述するように求められるので、
rundll32 user32.dll,LockWorkStation」と記述。(copy & pasteするといいです。)
rundll32 user32.dll,LockWorkStation

3. 「このショートカットの名前」として、自動で表示される「rundll32.exe」ではわかりにくいですので、ここをたとえば「PCのロック」などに変更し、「完了」をクリック。
ショートカットの名前を変更

4. 出来上がり。デフォルトではアイコンの選択の余地がないのがさびしい気もしますが、別に目立つ必要もないし、さりげないのがかえって良いかもね。
「PCのロック」ショートカット完成

思いのほかスムーズにロックしてくれます。デスクを立つ時、ぽちっと押してください。「意図的」なセキュリティ、いいものですよ。

・ ・・・ ・

ここからはオマケ。

このボタン、あまりかっこよくないぞ?という方のために上級者用?TIPSを書いておきます。作成したショートカットを右クリックし、プロパティを開きます。

次に出たウィンドウで「アイコンの変更」をクリック。この時点ではたいした選択肢がない。そこで、

C:\Windows\system32\shell32.dll

あるいは、

%SystemRoot%\system32\shell32.dll

を選択しますと、たくさんアイコンの選択肢が増え、キーホルダーのようなアイコンを選ぶことができます。

Shell32.dllのアイコンだけちょっと拝借

私のデスクトップでは、こんな感じになっています。

PCのロックボタンらしくなりました。

ご参考まで。

「ポジティブポリシー重要!」といったそばから「べからず集」、すなわちネガティブポリシー的なのも何なのだが(苦笑)、こういう記事がでた。

日経BP ITPro 記者の眼「“フィッシング時代”のメール「べからず」集」

紋切り型のセオリー集としてではなく、リスク軽減のヒントとして捕らえていただきたい。サイトによってリスクはさまざまだし、防衛方法もさまざまなので。かといって、「他社様」の選択が正しいわけでもないのに、ダメなほうに横並びなのはあまりに嘆かわしいしね。

こういうのは、ともすれば一人歩きしてしまいがちな「セオリー集」になってしまいがちだが、適用を自分で考えることができるよう、微妙なニュアンスを表現に加味してくださった勝村氏のご苦労に感謝したい。欲をいえば、やや過剰ギミな名前の連呼はご勘弁願いたいところだが。

ま、それもリスクヘッジなら仕方がないね ;-p

6/29に第二回情報セキュリティEXPOの専門セミナーにてお話をさせていただく機会がありました。第一回のときは、OWASPの人とペアでしたので、「Webセキュリティ」の話一色でさせていただいたので、「フィッシングに利用されないようなサイト作りを」みたいなことを提言しました。今回は、アンチウィルスベンダーの方とペアで、どちらかというと企業がどのように防衛するか、という御題をいただきました。

Webにせよメールにせよ、セキュリティ防衛をする際に念頭におくべきことがあります。その一つは、「ネガティブポリシー(negative policy)」と「ポジティブポリシー(positive policy)」の違い。前者は、例えば「ブラックリスト」にのっとって受け入れられないものを排除する方式で、いうなれば悪いものをろ過する方式であり、前者と対照的に「ホワイトリスト」にのっとって受け入れられるものを厳密に定義する方式を解説しました。

ウィルス対策の場合、原理的に言ってウィルス定義ファイルはまさにブラックリストであり、それゆえにアップデートしつづけなければなりません。もちろん、ヒューリスティック検知方式などで補完することにより、ブラックリストに載っていないものも「それっぽい」ということで濾過することを可能にしています。SPAM対策でよく用いられる、ベイズ理論は、悪いものと良いものの両方の類推方法を学習していきますので、これら二つの方式の組み合わせと考えることができるでしょう。

WEBのフォームの入力データの場合、よく「サニタイズ(sanitize:「消毒」の意)」という言葉が用いられます。これは、ネガティブポリシーに基づく用語です。HTMLのタグや特殊記号などをフィルタリングするなり、クォーティングするなりという処理を行なうことを指します。しかし問題は、実際には入力データはそのアプリケーションの要件により毒にもなれば実にもなるわけですから、サニタイズという概念では完結しません。

また、危険の可能性がある文字なりパターンなりのすべてをプログラマーが知らない場合はどうでしょうか。見落としリスクがあるということです。そのアプリケーションは、そのプログラマーの腕に依存します。新たな脅威がでてきたら、そのプログラマーは直ちにサニタイズプログラムをアップデートしなければならないでしょう。それは現実的な方法ではありません。そういうわけで、WASForumのコンファレンスで高木さんが「サニタイズ排除キャンペーン」を発表されたのには全く同意です。

むしろ、正しいアプリケーション設計の観点から言うなら、本来すべきことはサニタイズではなく、入力の有効性検証(input validation)です。これはサニタイズに似ているようでも、実際には全く異なります。害のないデータでも無効なものはいくらでもあります。各々のフォームにおいて、「有効な(valid)」データを、桁数、文字種などに至るまできちんと定義し、そうでないものをすべて排除するという方式をとることです。

現場では、ポジティブリストの安全性を担保するため、あるいは、どんなリスクがすでに発生しているかを知るため、ブラックリストに該当する入力があった際にアラートを発生させるなどの方策を実装する場合などには、サニタイズプログラムは有効でしょう。しかし、根本的に、危険の可能性を知っていることだけを前提にした設計は、運用的にすぐに破綻しやすい、ということです。

今回の講演でこの話をしましたら、熱心に聴いてくださったメディアの方がサマリーを掲載してくださっていました。少しニュアンスが異なる部分もなきにしもあらずなのですが、シェイプアップしてサマライズしてくださっていますので、ぜひご覧ください。ご意見、ご感想も歓迎します。