たりきのポジションペーパー（ベータ版）
●略歴
1997年、プログラマに転職。スタンドアローンのビジネスアプリケーションの開発からデータベース、ネットワークアプリケーションへと手を広げる。
業務として工業機械制御や顧客管理システム、WEB系データベースシステム等の開発に従事。また、サーバ管理者として外部に常駐した経験もあり。
2000年、WEB サイト「他力本願堂本舗」を開設。
2001年、A.D.200X 創設メンバーとして参加。同年、@Random 創設メンバーとして参加。
2003年、31歳で独立。主に雑誌連載を中心とした執筆活動、サーバ運用支援、コンサルティング、派遣社員もしくは業務受注により生計を立てる。
2004年、主にコスト面からのアプローチを試みた「サーバー防衛大学校」出版。
同年、他力本願堂本舗 閉鎖
●セキュリティ情報の取扱についての個人的立場
・脆弱性情報公開のあり方について
アプリケーションレベルの脆弱性では、完全公開かそれに近いものが必要と考える。
セキュリティ情報について、アプリケーションエンジニアに向けた情報としては脆弱性の情報は広く知られてしかるべきものと考える。これは同種の脆弱性が再生産されないよう、少なくとも勉強しようとしているエンジニアに対して情報の入手にかかるコストを下げることが必要であることが理由。
ただし、ウイルスや攻撃ツールそのものの公開は必要無い。しかし実証実験に必要となるコンセプトコードは必要だ。実際にどのように攻撃が為されるかの情報は、IDS のシグネチャを作成するだけでなく、実際の攻撃の脅威を疑似体験することができればエンジニアの教育にも役立つ上、無理解な周囲の説得材料にも使える。
いわゆる厨房への対策は考慮すべきだが、一部エンジニアや専門家だけの情報となることは避けたい。なぜなら、すでにアプリケーションエンジニアやネットワークエンジニア、WEB アプリケーションプログラマはごまんと存在するからだ。全てのプログラマ、及びシステム管理者にその情報が必要となる。
コンセプトコードは脆弱性の影響範囲を確認するためのツールとなりえる。
対して、WEB システムの脆弱性では、詳細情報の公開についての明確なガイドラインが必要と考える。
WEB システムの脆弱性では往々にして特定のサイトの脆弱性となる。あのサイトにはこのような脆弱性がある、という情報を公開する際に、管理者と連絡がつかない場合・管理者の対応が期待できない場合・危険性が大きく、ユーザに自衛を促す必要が迫っている場合については、公開もやむなしと考える。
ただし、可能な限りの連絡手段を用いてコンタクトを取るべきだ。また、連絡を受けた側が真摯に対応するべきだ。現在、このようなガイドラインとして有効なものは存在しない上、不正アクセス禁止法に関連して連絡を取る事が憚られる。
なお、上記のいずれについても、対策方法は完全公開が必要。
新しい脆弱性情報については可能な限り対策手法も併記されるべきだ。攻撃手法に直接転用できるだけに対策手法を同時かより早くリリースすることが望ましい。
・コミュニティとセキュリティ情報のあり方について
オープンなコミュニティ、特に誰でも参加と発言が可能な形態において、ネットワーク上のものであればプロパイダ責任法に規定された以上の責任を負わされるべきではない。また、コミュニティ内の人物の不祥事に対してコミュニティそのものが引責すべきではない。
情報の取扱については個人の責任に帰結する。情報に対して適切な取扱が行えないと考えられる場合を除いて、情報の取扱に不備があった場合は取り扱った個人に責任を帰結させるべきだ。ただし、より上層部からの指示があった場合のみ引責範囲を拡大しなくてはならないと考える。
●セキュリティ系コミュニティのあり方についての個人的立場
・コミュニティのあり方について
コミュニティ内の議論は可能な限りオープンであることが望ましいと考える。クローズであることによって第三者からの違和感や指摘を受ける機会が失われ、その結果によりコミュニティそのものの体質が歪になりかねない。
センシティブな情報を扱う以上、その運営を含めてクリアにされているべきだ。
また、脆弱性情報公開のあり方で述べたように現在数多くのエンジニアに対して脆弱性情報や対策手法は簡単に入手できるべき情報だと考える。コミュニティ参加者や研究者に限定するべきではなく、また衆人環視の下でコミュニティ自体の健全性を維持するためにも、ML や BBS などは公開されていることが望ましい。
●現時点で問題があると認識している事柄
・脆弱性情報の取扱について
アプリケーションレベルの脆弱性
コンセプトコードは詳細情報としてアリだと思う。改造して攻撃コードとして使った場合、使ったやつが悪い。野草の知識を悪用して毒草を集めるのと似ている。
ウイルス等、被害を拡大させるものについてはその限りではない。
コンセプトコードは対策と共に提供されるべき。攻撃手法のみの提供は避けなくてはならないと考える。ほとんどのユーザと多くのエンジニアはコンセプトコードや脆弱性の詳細から対策パッチを作成できないから。
ML、BBS などでコンセプトコードが公表された場合、プロパイダ責任法相当の責任を超えて運営者に責任を負わせるべきではない。
しかし、悪意を持ってツールや攻撃手法を添え、攻撃を助長するような公表を行った人物は引責しなくてはならないだろう。
実際に攻撃を行った人物は当然断罪される必要がある。
WEB サイトの脆弱性
現時点ではまともに情報をハンドリングすることすら難しいことが IPA の脆弱性情報取扱でよくわかった。
ここでは個人レベルでの情報取扱にのみ触れる。
公表の際には公表に至る経緯を添えることが望ましい。
管理者もしくは管理者が対応することが期待できるメールアドレス等に通知を行ってから二週間もしくは10営業日以内に返信が無かった場合には、対応の可能性が低いとして公表を行うことも可能とする、といった通知から対策完了等の公表までの明確なガイドラインが必要
適切な「公表の場」が必要かもしれない
脆弱性情報の公表の場にはモデレータが必要？
不正アクセス禁止法とサイバー犯罪条約の改善が必要
・コミュニティの引責
コミュニティが扱う情報が転用され攻撃に利用された場合もコミュニティに引責されかねない現在の状況は間違っている
コミュニティの参加者が攻撃を行った場合にコミュニティそのものに引責される現在の状況は間違っている
責任範囲の明確化が必要か？（本来なら責任分岐点は事例ごとに明確なはずだが・・・解らないor解ろうとしないヤツラが多すぎる）
・セキュリティ情報、脆弱性情報
これらの情報は基本的に公開情報であることが望ましい、必要とする人物には容易に入手できてしかるべき有用な情報だが、現状では情報統制に傾いている。
ただし情報の取扱に対して正しい判断を下す事が難しい幼稚な人物への対策が必要。年齢によるレーティングが必要か？どのような仕組みであれば実現できるだろうか。
情報は対象別に提供されるべきか？（一般ユーザむけに概要と対策、プログラマや管理者向けに原理と対策、一般・アマチュアを含む研究者向けに全ての詳細な情報、といった段階的な提供）
・コミュニティ
中央集中がひどい。現状でコミュニティの萎縮・クローズドコミュニティ化・情報統制が行われることは危険。
「トレセン」という表現に見られるように、最終的に中央のコミュニティに出ることが当然といった風潮が問題。東京一極集中の異常性。
一極集中の原因のひとつには、情報産業そのものの東京集中が挙げられるだろう。パワーのあるエンジニアや人脈が東京に集中している。
地方格差を埋めるには全国的規模のメタな組織が必要？（各地でのイベント・セミナー・勉強会レベルの交流から人材の交流を行い、かつそれにかかる費用等を賄えるようなもの）
コミュニティへの参加の敷居は可能な限り低いことが望ましいが、現状はそうではない方向に流れつつある。
・不正アクセス禁止法など
グレーゾーンが大きすぎるため萎縮の原因となっている。
ユーザが保護されているとは言いがたい
サイバー犯罪条約では正当な研究行為等が阻害される恐れが強い。
・その他
セキュリティ教育は交通ルール並みに噛み砕かなくてはいけない
基本的なしつけレベルの教育が為されていない
情報の取扱と取捨選択について訓練されていない
●総括
セキュリティ情報、脆弱性関連情報は可能な限りオープンであることが必要。
罪を犯したものはその正犯と幇助は罰せられるべきだが、コミュニティそのものには引責することは間違い。
不正アクセス禁止法やサイバー犯罪条約関連法には不備が多すぎるため改善の必要がある。
民間レベルの、あるいはボランティアベースのコミュニティを萎縮させるべきではない。
情報を正しく取り扱う能力に欠ける者をフィルタリングする必要がある。
情報を正しく取り扱う能力に欠ける者であってもコンピュータセキュリティの面では対策を行う自由を保障されるべき。
基本的な教育（むしろ、躾）が必要
コンピュータセキュリティを取り巻く世論の改善が必要
