Don'tStopMusic

たまには長文。詳しいわけでもないので、変なところはツッコミしてください。

セキュリティの問題について注目されているのは良いことだと思います。ただ、「脆弱性」という言葉が示す範囲が広がっているため、深刻かつ緊急な問題もあまりそうでない問題も一括りに同じ「脆弱性」とされているのが課題点でしょう。

何故一括りだと問題なのか。それは、不十分な情報ではユーザが正しく対処しにくいという点ではないでしょうか。(まったく深刻でない「脆弱性」に対応しなくちゃならないベンダーが大変なので、ということもあったりしますが :-p )

便利に使っているアプリが、ある日「脆弱性がある」と言われたときに、ユーザはどういう行動をとるでしょうか。「データが削除された人がいる」「個人情報がネットにばらまかれた人がいる」というならば、即刻使用を止めると思います。「盗聴により第三者の不正アクセスが可能」というのではどうでしょうか。

ユーザには許容できるリスクなのかそうでないのかを判断するだけの材料が必要です。それには、ベンダー、報道、セキュリティに関する第三者機関(IPA などのような)が、正確で、コンピュータに関する知識がなくとも理解し判断できる情報を提供しなくてはいけません。

いくつかの尺度を用いて脆弱性情報を提供するというのも一つの手だと思います。例えば、

• 実現性: どれだけ容易に危険を実現化できるのか
• 深刻度: 危険が実現したときにユーザはどれだけの被害を被るのか
• 所在: 脆弱性がどこに由来するものなのか

大雑把に具体例を挙げてみます。

「掲示板にコピペされた URL を踏めば、そのサービスのユーザはみんな被害を受ける」、という場合は実現性は極めて高いと言えます。あるいは、「通信路を盗聴するとパスワードが盗める」や「10万台の PC でクラスタを組んで解析すれば、半年くらいでパスワードが分る」という場合は実現性はやや低いと言えるでしょう。

「勝手に商品を購入できてしまう」「個人情報が取得できる」なら深刻度は相当高いでしょうし、「任意のプログラムを実行」「データが削除される」ならやや高い、「プライベートにしていた登録 URL が見える」くらいなら低でしょうか。

所在は、アプリケーションプログラム、システムの構築方法、インターネットの仕組、人間などなど。

実現性と深刻度を掛け合わせてみて、「起きる可能性がまずないなら気にしなくていいか」とか「可能性は低くても一度起きてしまったら取り返しがつかないな」とか「あんまり被害はないけど、こう簡単にできるなら鬱陶しいな」とか、判断してどう対処するかを決めるわけです。まあ、単純に高・中・低で分類してしまうのも、それでしか判断しなくなってしまうので弊害もあります。

ともかく、脆弱性というと技術寄りな説明になりがちなので、それがわからない人でも判断できるような説明の仕方が一般的になるといいなあということです。

……あーこの内容でこの文体だと大上段に構えた感じになるので気に入らないけど直すのも面倒だー。

_ [仕事] 出張行ってきます

来週は海外出張でアメリカ西海岸に行ってきます。旅行や海外出張はどんな本を持っていくかが重要なわけですが、今回は悩まず古川日出男の新刊にしました。

_ [ソフトウェア] 僕やはてながPerlを選ぶ理由 / ソフトウェア工学の役割 を読んで

ソフトウェア開発者の責任は、ほかのあらゆる製造業となんら変わりません。
目的である求められたシステムを、できるだけ最終目標に近い形で、効率的に、高品質で作ることです。

まったく正しいのですが、予算と締め切りが存在する以上、機能セットや品質もトレードオフの対象にせざるを得ません。そうなれば、何を至上命題とするかが焦点となります。

orionae さんが例として挙げているような、人命というクリティカルな要素が関わるソフトウェアであれば、品質が最も重要でしょう。

一方、はてなにとって重要なのは何か。ユーザへタイムリーにサービスを提供することだと思います。多少のバグがあっても、すぐ直せば取り返しが効くことです。ユーザに新たな体験を次々と提供できなければ第一線の企業でいることはできません。

もちろん、このトレードオフの範囲内で効率や品質を最大限高めることがソフトウェア工学に課せられた使命であり、数十年来の経験と知恵と実績がそこにはあります。ただ、あらゆる質と規模のソフトウェア開発に対して、ソフトウェア工学が最適な解ではないはずです。ソフトウェア開発に工学的アプローチが試みられた背景には、ソフトウェアの大規模化がありました。様々なスキルレベルの開発者、一人の頭では把握できないほどのたくさんのモジュール、限られた予算とスケジュール、これらをいかに適切に管理して、効率よく高い品質のソフトウェアを開発できるかが目的とされます。誰が作っても均質で計画通りに生産される工業製品、これがソフトウェア工学の目指すソフトウェアでした。

一方、ハードウェアの高速化と IDE の発展により開発環境は整備され、ライブラリやフレームワークという形で開発者間の知識・成果物が共有され、現場レベルでも経験と知恵と実績が蓄積されました。その結果、ある程度の規模と目的のソフトウェア(主にウェブアプリケーション)であれば、少数精鋭で十分な速度と品質を保って開発できると言われるようになったわけです。

はてなのスタンスは明らかに後者でしょう。その評価はユーザにしてもらえばいいのではないでしょうか。

naoya さんは、自社のサービスには「ソフトウェア工学と Java」を用いるよりも、「試行錯誤と Perl」を用いる方が良いとしています。そこには、ソフトウェアを作るのを楽しむということが創造性に繋がるという思いが込められているように思えます。そして、はてなにとってそれが正しいという自信がそこにはあります。