フィッシングリスク軽減のためのヒント

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

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

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

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

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

ネガティブポリシーからポジティブポリシーへの転換

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

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

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

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

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

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

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

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

ユーザを守る責任とスピード感

CNet Japanに、「カカクコム事件に見るセキュリティの本質とは」 という記事を寄稿しました。クラックされた他社の被害の手口に関する詳細情報は、セキュリティ維持の観点で不可欠だとはいえない。2ページ目では、EBサイトの攻撃から被害の拡散に至る情勢からすると、被害を想定した対応方針が必要で、そのポイントは「スピード感」 であることを示しました。最後に、WEBサイトの運営者の企業のCSR（社会的責任）に言及しました。

ご覧いただければ幸いです。

OSSプロジェクトの共感と意欲

「コードも書かない人に言われたくはない」 正直で、エモーショナルな言葉。それゆえに、共感、反発、共に大きな反響を呼んでいます。でもこの議論、「言われたくはない」、何を言われたくないのか、なぜ言われたくないのか、もっとそこを議論したいと思いました。

発言者の三浦さんの原文では、

「だからこそ、CodeFestを日本で開く応援をしたい、推進派になった。人材育成とか、日本発のＯＳＳとか、コードも書かない人に言われたくはない。一緒に取り組んでいる仲間を増やすこと、同じ空間と時間を共有して、フリーソフトウエアの世界を確かに広げた実感を共有すること、それこそが醍醐味ではないか。 」

人材育成と日本発のOSSが例に挙げられています。これはよく考え抜かれた指摘ですね、要するに誰と一緒に仕事をするか、そこで何を成果として作るか、これをコードも書かない人に言われたくない、と。 仲間と共感でき、そこで意欲的に成果がでることがサイコウにうれしい、と。ここは事実提示です。

すると、コードを書かない人に「言われたくない」ことがあるとすればそれは、開発組織における「共感」や、成果物への「意欲」が度外視されるケースだということでしょうか。(小飼さんの「コードだけでOSSの世界が回ると思ってんのか」は、そりゃそうなんですが突っ込みポイントはそこじゃない、という感想です。) 昨今の三浦さんのご活躍の現場で、何度となく彼自身が板ばさみに会い、まさに苦悩ゆえの発言だと連想されます。

さて、その「仲間との共感」と「成果物への意欲」は、ものづくりの立場にとっての軸と、要件を出す立場にとっての軸とは表現も価値観も異なります。けれど、そこの問題を提起するのであれば、「その溝はもう埋めたくありません」と言ってしまうと、そこの問題解決による発展の可能性を低めるというリスクがありますね。 共感や意欲を共有できるかどうかは主に、外的要因よりも内的要因のほうが大きいからです。内的要因でシャットアウトされると手の出しようがなくなります。

ですから、OSS開発では、開発者もユーザも一体になってはじめて意欲的な成果物に成長する、というシナリオを目指します。そして、成功しているプロジェクトに「コードを書かないプロデューサ」がいることは珍しくありません。OSSにおいては、なおのこと、「共感」と「意欲」がシンクロしている、あるいはシンクロさせる努力が必要だというわけです。

名前を挙げれば続々と、まさにそういうことをしてきた人たちが存在します。開発者、プロデューサ両方の側面ができる人もいます。マーケティングからやってきて、一生懸命理解しようとしてきた人たちもいます。そういう人たちは、自分ではなく、開発者を中心としたマンダラート、ユーザを中心としたマンダラートの両方を持っているゆえに、各ステイクホルダーとの調整ができるし、期待されているわけです。


OSS開発のステージの大きな変化

ところで、その対立構造とは異なるところで、不思議と同じ論点があり、そこでは相互に議論がものすごく盛り上がっているという動きがあります。 それは「コードを書く人」の中での話です。

いくつもの大きなベンダーやSIerがメインフレームの人間、ミッションクリティカル系技術者を駆り出してまでオープンソース開発セントラル組織を作り、実際にOSS開発を前提に基礎開発をばりばりやっています。この動きにより、OSSとは全く別のところにいた、よく訓練された技術者に新たなステージを与え、しかもこれが少なからぬ意欲を与えることに成功しつつあります。 これらが表面化するのは時間の問題でしょう。

最近、そういう方々を公の場でインタビューする機会がありました。（吉岡さんのレポート参照のこと）「メインフレーム屋」でありながら「OSS開発プロジェクト」をどうしていこうか真剣に考えている人たちです。 彼らの主な特徴としては、OSSの「自由な開発」「自由な意思決定」という部分はよく解らない。しかし、品質や時間の観念、障害解析に関するリテラシーはものすごく高い。これまで閉塞的なところから突然やって来たという意味で仙人のような人たちです。

一方、これまでの「みんなでふもとからコツコツ上がってきた人たち」は、そうした情勢の中で組織的に参入してくる「山から下りてくる仙人」とどのように共感し、分かち合っていくのかが大きなポイントとなります。Linux Kernel MLでのLinusのカーネルダンプ問題しかり、そこには大きなエネルギーがいります。 その議論をデフォルメして言えば、企業のミッションクリティカル要件にとって必要だから、壊れたときのための機能を作らなければならない、という集団と、壊れない良いものを作りたい、そういう作りたいものを作っていこうよ、という集団の議論です。 そこは、理屈よりも「共感」が必要な世界だし、目指す成果への「意欲」の問題でもあります。

それで、両者にある見解の違いを中心に、どうするのか議論が盛り上がっていることは、OSSの発展の歴史において、これまでにないすばらしいことです。この動きはソフトウエア開発モデルの歴史に残ることだと思います。 OSSプロジェクトにおいて新規に関係者が増えていく際に、とにかく議論のテーブルがあることは必須です。

まつもとゆきひろさんがおっしゃるスローガン、「コード書きの気持ちがわからないとオープンソース・エコシステムで成功できない」というメッセージは、孤立ではなく他者との関係で自分の目的を達成したい当事者においては、全員にひとしくあてはまると思います。俯瞰的に自分のポジショニングを確認するんなら、各立場からの観点で出されるメッセージを中心にマンダラートツールで思考をはじめていくと面白いですよ。開発者、ユーザ、支援者のどこをスタートとして書いていくにしても、最終的に大きな一枚の絵に描くにはなにが必要なのか思考する助けになるように思います。

いくつかの立場を理解できる人、客観的な目撃者として指摘できる立場にいる人間は、必然的に注目を免れない傾向があります。開発者自身、あるいはプロデューサ自身、ユーザ自身の意見よりも重く見られるために奥歯にものがはさまってしまう。そういう意味では、今回の件にまつわっては、皆さんストレートで、熱いメッセージが飛び交っています。吉岡さんしかり、きんねこさんしかり・・・、反応リンク集まで。発展を目指して語る以上、議論を恐れてはいけないですよね。これからも、臆せずにメッセージを出していって欲しいですね。

街中からスキムミルクが消えた！？

「スキムミルク」。どうも森永製のものが主に流通しているようだ。

3月17日放送にて最終回を迎えたTBS番組「スパスパ人間学」で、＜より効果を期待する方に「乳脂肪を最小限に抑えたスーパーやせるヨーグルト」の作り方＞が紹介されたためと思われる。

http://www.tbs.co.jp/spaspa/2005/03/0317/0317.html

ヨーグルトはともかく、材料にとりあげられているスキムミルク。最近では、栄養補給に少々、あとはパンを作る人がちょっと使う程度の需要。当然ながらそれにあわせた供給だ。放送当日の夜あたりから品切れが出始め、翌日には陳列棚から一通り消え、やがてスーパー、コンビニ、量販店、いずれも、奥から出してきた在庫でさえ、この連休中にすっかりなくなった模様。 尋ねるも、「次回の入荷は未定」という状態。

もともとそのような細い需要のものを、毎日大量に、2週間にわたって消費するアイデアだよ。それをインパクトたっぷりで情報提供すると、いろんなところが火の車だ。 需要の細い商品に人々が殺到してこういう状態になると、その情報で助かる人は少なくなる。連休中はもろもろ止まるのは必定としよう。しかし、連休明けはどうだろう。「街中から消えた」まんまだと、なんら売上がるどころか、クレームの嵐。（他の乳業系が補完できるのならそれはそれで良いのだろうね）

あわてて起こした増産ラインで需要をまかなえると思った頃にはもしかすると忘れられている。フォローできるはずの番組は最終回で終了しているし！おそろしや、需給悪化懸念は両刃の剣だね。吉と出るか凶と出るか。

スパスパも最終回にかこつけて、キラーネタに需給悪化起こしそうな商品の火種を撒き散らして終わりか？それはちょっといただけないよ。いや、もしや、こういう番組って、生産系との同意はとってあったりするのかな。 どうも健康系のノウハウを提供するテレビ番組って、生臭い。「煽り」だよね、「啓蒙」というよりは。観る側がわかってればいいんだが･･･。終わって正解ってことかな。

（連休明けの乳業系の株価でも眺めるかな。）