アプリケーションビジネスの現場に浸透するOWASPのプロジェクト

――OWASPには多くのプロジェクトがあるようですが、その概要について教えてください。

岡田 : OWASPには、グローバル混成で非常に多くのプロジェクトが存在します。しかし、それらはおよそ3つのジャンルに分類できます。その3つとは「Protect(防御)」「Detect(検知)」「Lifecycle(Webサイトのライフサイクル)」です。Lifecycleというのは開発から運用全般をカバーするジャンルなので、「Detect」や「Protect」の要素も部分的に含まれています。そのため、OWASPのプロジェクトの成果物は、運営の立場でも、企画構築の立場でも導入しやすくなっているのです。

ところで、SCSKさんも、OWASPのさまざまなプロジェクトやガイドラインを実際の業務の中で参照されているということですが、主にそれはどの部分になるのでしょう?

境 : 脆弱性情報である「OWASP Top 10」と、アプリケーションセキュリティの診断手法である「ASVS(Application Security Verification Standard)」が多いですね。

岡田 : いずれも日本語化が進んでいる分野ですね。

境 : やはり、お客様に情報をお出しする場合には日本語でということになりますね。われわれセキュリティベンダーが独自に翻訳して提示するよりも、OWASPのような非営利団体がオープンにしている翻訳であるというところで、お客様が信頼してくださるケースも多いです。

岡田 : オープンの価値も変わってきていますよね。以前のような、技術者に余暇を使って協力してもらうというレベルではなく、あらゆる組織のプロフェッショナルのコラボレーションによって進展していくという傾向にありますし、さらにそれらがパブリックになっています。公共性という部分に価値を見いだしてもらえるという流れはたしかに広がっていると思います。

「品質の高いソフトウェア」の開発ノウハウを日本から世界に還元したい

――OWASPの中で日本を中心としたプロジェクトは進んでいるのでしょうか?

岡田 : 日本では「受発注」ベースでWebアプリケーションを作るケースが多いという特殊性があります。グローバルでは、自社で作るのが一般的です。Webサイトはセキュリティ面、技術面での変化が日々起こっていく「生き物」として認識されているので、丸投げ的に「発注」して調達するという考えにならないんですね。

そこで日本発で「セキュリティ要件定義書」のひな形を作ろうというプロジェクトが進んでいます。現在もメンバーを募集しており、最初のドラフトもまもなくリリースされる予定です。この作業はOWASP Japanでワーキンググループとして進めていますが、近い将来にOWASPにコントリビュートし、英語への翻訳も進められることになると思います。

このセキュリティ要件定義書が示そうとしているのは、Webアプリケーションを構築する際に「何をもってセキュリティが確保されているとするか」という点なのですが、現状、一般的にはどのように考えられていると、SCSKさんでは感じていますか?

境 : 多いのは、「一般に公開されている特定のガイドラインに沿っている」、もしくは「OWASP Top10のようなリストに記載されている脆弱性がないこと」といったものですね。とはいえ、レベルはまちまちで、一番詳しいところでは発注者側に「セキュリティ要件定義」の部隊を設け、彼らがRFPとして機能毎に細かく定義をしてくるケースもあります。一方で、一番低いレベルでは「脆弱性がないこと」とだけ書かれていたりもしますね(笑)。

岡田 : 「脆弱性がないこと」の一文で済むのであれば、それは楽ですね(笑)。

亀田 : 私は以前、アプリケーション開発側の立場で仕事をしていたこともあるのですが、実感として、開発の現場に「セキュリティの要件定義をできるスキルがないという」ケースも多くあるように見受けられました。そうなると、それぞれの要件を定義するというより、「特に実害がなければいい」という感じになり、セキュリティを担保するレベルが非常にあいまいになってしまいます。

岡田 : 今でもよくあるケースは「ペネトレーションテストに合格すること」という要件ですね。そうすると「少なくともテストに合格するまでは修正しろ」ということになるのですが、実際にはこれは「臭いものにはフタ」のやり方になりかねません。つまり、ソフトウェア内部の品質よりも、外部的に問題が生じないようにする対応だけに注力して進みます。

そういったWebサイトはスケールしません。なぜなら、機能追加のたびに同じ問題が起こるからです。実際に発注すべきは、セキュリティ面も含めて「品質の高いソフトウェア」であるはずです。これは発注側が、ソースコードを入手して自由に改変し、拡張していけるレベルの品質を持ったソフトウェアです。

「テストに合格すること」という要件定義は、たしかに簡単なのですが、結果的に「中味はスカスカ」なのに、外見だけはしっかりしている家を作れと指示しているのと何ら変わりません。こうした状況が続くと、業界として才能を持った若いエンジニア、新たな技術に対応したスキルを持った素晴らしいエンジニアをうまく使うことができないばかりか、つじつま合わせだけが得意なエンジニアばかりが増えてしまう。これはまずいわけです。

この「セキュリティ要件定義書」は、「こういうことができるソフトウェアだと、品質が高い」「こういうことが実装できるエンジニアなら、どんなアプリケーションの開発やサイトの構築にも対応できる」という、有用なベンチマークになることが期待できます。これは、例えば東日本大震災後の被災地支援や、復興の旗印のもと新たなビジネスを立ち上げるためのWebサイト構築などにも、貢献する成果物になるだろうと思っています。

OWASPのいろいろなガイドラインやドキュメンテーションと一緒に、開発者のスキルを市場で役立たせていく枠組みを作るという活動は、日本の環境に向いているような気がしています。SCSKさんのエンジニアの方にも合った活動なのではないでしょうか。ドラフトを元に、みなさんの意見を出して、しっかりしたものを作っていくというのは、OWASP Japanの2013年における極めて重要なプロジェクトのひとつになると思っています。

境 : 日本とグローバルのセキュリティ業界では、少し視点が違っているのはたしかだと感じています。日本では可用性を脇に置いて、機密性・完全性を重視する傾向があります。一方グローバルでは「情報は使える状態にあってこそ意味がある」という考え方のもとに、可用性とのバランスが重要視されます。「機密性・完全性・可用性の三点が、バランスよく質の高いアプリケーションを作ることが、ビジネス上のメリットになる」という考え方が一般的になれば、日本のソフトウェアビジネス、インターネットを活用したビジネスも、さらに盛り上がっていくのではないかと思います。その点で、このプロジェクトには賛同したいですね。

岡田 : 日本では、東日本大震災後、Webサイトセキュリティに関する情報流通が、これまでになく盛り上がってきていると感じています。それも、個別のノウハウを知っているというだけでなく、体系的にどのように適用して効果を出すのかという方向に眼を向けたエンジニアが非常に増えています。OWASP Japanは、OWASPの資料、日本独自の社会環境やノウハウを、日本全体、ひいては世界にコントリビュートすることを目指していきます。

2013年は2月に済州(チェジュ)島で、APSECという環アジア地域のOWASPのイベントがあり、私も参加します。それを受け、OWASP Japanでは、3月11日の週に2013年最初のイベントを皮切りに、6月、8月と開催する予定です。8月のイベントは「OWASP DAY」と銘打って、学生の夏休みを狙って行いたいと思っています。ぜひ多くの方に参加していただき、様々なコラボレーションを実現したいですね。

亀田 : DEFCONのCTFやWASForumの「ハードニング」(サイトの堅牢化)といった競技に参加して感じるのは、日本人技術者のセキュリティへの関心は年々高まってきているものの、まだまだ世界レベルに達している人材は少ないという点です。OWASP Japanのイベントは、セキュリティに対する関心と知識、技術を持った多くの人々と交流することができる貴重な機会です。ぜひ、こういった場で、意識を高めて向上するきっかけとしていきたいと思っています。

岡田 : SCSKさんには、今後もエンジニアリング面や組織面でのサポートを含めて、幅広くOWASP Japanの活動にご協力いただけるとお聞きしており、大変うれしく思っています。

――どうもありがとうございました。