園田 道夫 様

独立行政法人 情報処理推進機構
セキュリティセンター
情報セキュリティ技術ラボラトリー
研究員

リック サモナ

マイクロソフト コーポレーション
アプリケーション プラットフォーム開発チーム
プロダクトマネージャ

数年前までは、セキュリティは IT 管理者の問題として捉えられていました。でも現在の傾向としては、アプリケーション開発分野における問題と考えられるようになっています。

ガートナー社の調査によれば、セキュリティ上の脆弱性の 70% 以上は、ネットワーク レイヤではなく、アプリケーション レイヤに影響を及ぼすものです。

組織にとって、適切なネットワークとファイアウォールを設置するのはとても重要なことですが、セキュリティを念頭においてアプリケーションを設計しなければ、セキュリティ対策は成功しないでしょう。

世界的な犯罪組織がお金のために個人情報を狙ってきている傾向が顕著になっています。日本でも SQL インジェクションのようなデータベースへの攻撃がかなり増えてきています。

その結果、世界の大部分の開発者が、安全なアプリケーションを開発する能力に自信を持っていないことがわかりました。特に日本では、大いに自信を持っている開発者の割合は、わずか 1 桁、5% 程度に留まりました。

つまり問題なのは、組織が開発者に対して安全なアプリケーションを作るようにと指示しても、開発者自身がどうしたらいいのかわかっていない、という点です。この点ではトレーニングが重要になります。

それに加えて、組織が開発者にセキュリティに関する責任を与えていない、という問題もあります。
どういう点が査定に影響するのか、開発者に聞いてみてください。毎年の査定の中で、組織側がどういう点を評価しているのかというと、開発者が書いたコードの量、アプリケーションの納品の早さ、そしてアプリケーションの性能です。

部屋に入って電気をつければ明かりが灯りますが、だれも電気技師を誉めたりはしないでしょう。でも、蛇口をひねったり、電気のスイッチをつけたりしたときに、それがうまく機能しないと、技師が文句を言われます。

また、もう 1 つの視点としては、システムの発注側が、セキュリティの確保を要求したり、そのための投資を考慮したりしていないこともあげられると思います。

「あなた方のうち、家族や友人のテクニカル サポート係になっている割合は?」

つまり、開発者が休暇で帰省したり、友人を訪ねたりしたときに、家族や友人はこう言ってくる。「コンピュータの調子が悪い。ポップアップが出てくる。」と。ありませんか?

エンドユーザーの大部分にとって、それはちょっと厄介なもの、コンピュータの動きを鈍らせるものにすぎないのです。それによって実際に引き起こされるかもしれない甚大な被害については、認識していないのです。

日本は特殊かもしれませんが、一般ユーザーがアクセスするサイトの脆弱性をチェックしようとすると法律に違反する場合があります。それは法律的な問題なので仕方がないのですが、そういうこともあって、一般ユーザーが自分でチェックするノウハウは日本ではほとんど知られていないのが現状です。

1 つ目は、管理者としてログインしないことです。主要スパイウェア 20 種について言えば、そのどれもが、ユーザーが管理者としてログインしなければ、深刻なダメージを及ぼすことはありません。
2 つ目は、インターネットブラウザ内で状況に応じて許可レベルを設定し、悪意あるコードがコンピュータに攻撃を仕掛けるのを防ぐこと。
そして 3 つ目は、最新のアンチスパイウェアやアンチウイルスのソフトウェアを確実にインストールすることです。

ただ、事件が多く発生し、社会的にはプレッシャーは増えてきていますが、今までセキュリティを開発プロセスに組み込んできたことがないので、どこから手をつけることができればいいのかわからないのです。

人、プロセス、そしてツール。開発者をトレーニングし、プロセスを配置し、ツールと技術でそれを補強する必要があるのです。現状では、アプリケーションをスキャンするツールさえ使っていれば完全に安全だと、多くの組織が考える傾向にあります。でも、そうではありません。ツールでプロセスを補強することはできますが、それだけでは、コードを安全にすることはできません。

とはいえ、多くの開発者がセキュリティにしかるべき注意を払っていないという点には同意します。開発者にセキュリティに関する資料を渡すだけで、彼らが時間を割いて読むでしょうか? 脅威モデルの作成に時間を費やすでしょうか?

答えは、こうです。組織がその点についてインセンティブを与えない限り、開発者のほとんどはそんなことはしないでしょう。

ですからマイクロソフトでは、二元的なアプローチをとっています。当社では安全なアプリケーションを作るための基礎的なガイダンスを開発者に提供していますが、その一方で、上級レベルの経営者とも話をして、なぜセキュリティに対する意識を高める必要があるのかを伝えています。

上級経営者の賛同がなければ、望ましい成功は得られないでしょう。問題の多くは、開発者と上級経営者との間で意思の疎通ができていないことから生じています。CIO や CSO に「あなたにとって、セキュリティはどれくらい重要ですか?」と聞けば、大抵は「極めて重要だ」と即答します。

ですから Visual Studio 2005 では、マイクロソフト社内で使っていたツールを数多く採り入れ、ツールセットとして統合された形で提供することにしました。

例えば、コード アクセス セキュリティは、管理者権限を必要としないアプリケーションの開発を可能にします。アプリケーションの最小パーミッションを計算する「Permission Calculator」というボタンも導入しました。

C# や Visual Basic でプログラミングするマネージ コード開発者には、FxCop という静的解析ツールを提供しています。これは 220 のルールを監視しますが、そのうちの 20 は、SQL インジェクションなど、セキュリティに関するものです。C++ 開発者には、バッファオーバーラン、メモリリーク、非初期化変数などを監視する PREfast を提供しています。

そして、特に興味深いのは、こうしたものをセキュリティ開発ライフサイクルに結び付ける Visual Studio Team System です。これにより、コードチェック時の静的解析ツール使用を開発者に義務付けるプロジェクトポリシーを策定することが可能になります。

このツールには、主に 2 つの利点があります。1 つ目は、脆弱性を見つけられること。2 つ目は、Visual Studio Team Systemの一環として、こうしたツールによりコードが監視されることを開発者が意識するので、初めからもっと良いコードを書くようになる、という点です。

視点を変えると、顧客がこのようなツールでチェックしてくれという開発要件を発注の時点で入れるべきである、という指針があるとなおいいですね。
要件があれば受注する側がセキュリティ対応の費用を積んで要求することもできますし、そこでよいサイクルが生まれるのでないでしょうか?

インドなどの国へソフトウェア開発を外注することに関する表現なのですが、「インドへの外注の良い点は、支払っただけのものを得られるところ。悪い点は、支払っただけのものしか得られないところ」というものです。

マイクロソフトはその点について、リーダーシップを執ろうと務めています。開発ツールを持っているというだけでなく、開発者が創設した会社だということも、その理由ですね。

私がよく引き合いに出す例に、自動車とブレーキにまつわるものがあります。私は開発者にこう聞きます。「なぜ車にはブレーキがあるのか?」すると、彼らはこう答える。「スピードを落とすため」。十分にスピードを落とせば、足を車の外に出して止められます。時速 5 キロで走っていればね。

つまり、車にブレーキをつけるのは、スピードを出せるようにするためです。同じことが、セキュリティにも言えます。セキュリティを適切に導入すれば、将来的なコストや労力を削減することができます。安全なコードをきちんと書くだけでも、ユーザー インタフェイスに関する問題や、全般的な品質や信頼性に関する問題を、ライフサイクルの早い段階で排除することができるのです。

これは、コードを書く前に、アプリケーションに影響を与え得る潜在的な脅威を割り出すというものです。そうすれば、セキュリティ上の欠陥があるコードを書いてしまう可能性を、初めの段階から減らすことができます。

組織は自分の身を守ろうとします。組織の目標は、生き残ることです。

例えば、3 つの銀行があるとして、そのうちの 1 つの Web サイトがハッキングを受けたら、消費者は他の銀行に鞍替えします。
つまり、Web サイト開発者の肩には、きわめて重い責任がかかっているのです。

一般ユーザーもそれぞれの役割を果たすべきですが、一般ユーザーが情報を入力する Web サイトの安全性については、彼らに責任を負わせるべきではありません。多くのユーザーは、そうした知識を持っていません。