誰がシステムのセキュリティを“大丈夫”にするのか：Security&Trust ウォッチ（57）

[上野宣，＠IT] PC用表示

LINE

Hatena

　「セキュリティは大丈夫なようにしておいてよ」

　開発を依頼するときに、こんな言葉を交わしていませんか。開発会社は開発のプロなんだから、セキュアなシステム構築のことも熟知しているし、任せておけば大丈夫……果たして、それで本当に大丈夫なのでしょうか。

開発会社はセキュリティなんかにかまっている余裕はない？

　これまで、いくつかの開発会社やその現場を見てきましたが、その中にはセキュリティのことをあまり考えていない開発会社もありました。そういった会社は、セキュアなシステム構築への取り組みを会社として何もしていなかったり、セキュリティのことは設計者やプログラマの個人的なスキルに依存していることもしばしばです。

　中には「セキュアにシステム構築なんかしている場合じゃない」と社長自らが述べている開発会社もありました。セキュリティにはコストがかかるし、特別なスキルが必要という先入観からなのか、セキュリティのことは一切考えないという思考停止の状態に陥っているようにも見えます。

　そのような会社は、“何かが起きる”確率が小さいと考えているのかもしれません。もしセキュアな開発ができたとしても、明確に競争力があり、もうかるわけではない、というのが本音なのでしょう。

　その会社には提案力などはあったので、“何かが起きる”その日までは、コストが低い開発会社としてやっていけるのでしょう。しかし、セキュリティ対策をしないリスクを、顧客が本当に納得しているとは思えません。

セキュリティの問題は無償で修理してもらえるか

　システムにセキュリティ的な問題が起きたとき、サービスを停止したり、システムの修正が必要になります。開発の要件に、明確にセキュリティ要件が含まれていなかった場合、そのコストは誰が持つことになるのでしょうか。

　瑕疵（かし）担保期間内であれば、無償で開発会社に修正してもらえるでしょう。開発会社との力関係にもよるかもしれませんが、追加コストを支払い、修正対応する場合もあるかと思います。しかし、サービスが停止している期間の補償まで受けられることは少ないでしょう。

　運用開始後にビジネスの問題とは別の理由で売上が減ったり、追加コストが必要という不確実な要素が残っているよりは、最初からリスクを把握してコストを投じ、セキュリティ対策を行う方が事業への影響が少なくて済みます。そのためにはセキュリティ要件を明確にし、システム発注側と開発側が合意しておく必要があります。

Webアプリケーションのセキュリティ要件は明確になっている

　例えば、Webアプリケーションの対策として、脆弱性診断や、Webアプリケーションファイアウォール（WAF）などの防御システムなどもありますが、こういったシステムの開発（実装）フェイズ以後の対策は、ある程度のコストを必要とします。

　セキュリティ対策に掛けるコストを激減させるためには、「開発時に脆弱性を作り込まないようにすること」です。そして、開発時に脆弱性を作り込まないためには、セキュリティ要件を明確にし、要件を満たす実装を施していくことが必要になります。

【関連記事】

セキュリティ、そろそろ本音で語らないか（4）

“セキュアなWebアプリ”に立ちはだかる課題－＠IT

http://www.atmarkit.co.jp/fsecurity/rensai/talk04/talk01.html

　開発時に完ぺきなセキュリティ対策を施したからといって、必ずしも明日以降も安全とは限りません。しかし、Webアプリケーションに関してはここ数年、新しい攻撃手法はほとんど発見されていないのです。

　そしてここ数年間で、安全なWebアプリケーションを構築するためのセキュリティ要件は明確になっていて、それを実施することで大半の攻撃を防げるのです。

　要件定義に使えるWebシステム／Webアプリケーション向けのセキュリティ要件は、無償で公開されていますので、新規の案件ならばすぐにでも活用できます。

【参考】

Webアプリケーション開発に伴うセキュリティ要件をまとめた「発注者のためのWebシステム／Webアプリケーションセキュリティ要件書」をクリエイティブコモンズライセンスにより無償で公開

http://www.tricorder.jp/press20090330.html

IPA ISEC　セキュア・プログラミング講座

http://www.ipa.go.jp/security/awareness/vendor/programming/

　セキュリティ要件は、開発会社に渡して終わりというものではなく、発注者と開発者で要件を詰める際の材料として活用するのがよいでしょう。要件に記載してある項目を実装しないという選択をするならば、そのリスクについて把握することが必要になります。

　ここではWebアプリケーションを例に挙げましたが、ほかのシステム開発でもセキュリティ要件を明確にし、開発時に脆弱性を作り込まないようにすることで、セキュリティ対策に掛けるコストを軽減できます。

セキュリティのためには発注側が適切なコストを支払う必要がある

　セキュリティ要件が明確ならばコストが増えないのかというと、そうではありません。単に機能要件や性能要件を満たすだけのシステム開発に比べると、開発期間や費用も多くなります。また、セキュリティ要件通りに実装できているかどうかを確認するために、脆弱性診断やソースコード検査なども必要です。

　そして、開発会社側の問題ですが、セキュリティを理解していないエンジニアも大勢いますので、セキュアプログラミングができるようにするための教育も必要です。

　いまのところセキュアプログラミングは、一部の有志による取り組みといったレベルにとどまっています。会社の方針としてセキュアプログラミングに取り組んでいる会社は、それほど多くありません。

　会社がセキュアプログラミングに取り組むようになると、コストは最終的に発注者が支払うことになります。しかし、これまでコストを投じていなかった開発会社が、セキュアプログラミングに取り組み、そのコストをすぐに発注者に転嫁するのは難しいかもしれません。

　「セキュリティは大丈夫なようにしておいてよ」と言えるためには、発注側がセキュリティ対策の必要性を理解し、適切にコストを積み上げることが必要です。しかし、それが「あたりまえ」になるためには、まだ時間が掛かりそうです。

　安いけど速く走るだけで、安全でない車には現代の人はお金を出しません。しかし、衝突に強い車や、エアバッグなどのオプションにはお金を支払います。それは、人々が安全な車の必要性を理解しているからです。

　セキュリティにコストを投じないシステム発注者に必要なのは、安全なシステムの必要性を理解してもらうための啓蒙活動だと、私は思っています。

Profile

上野宣（うえのせん）

株式会社トライコーダ代表取締役

セキュリティコンサルティング、脆弱性診断、情報セキュリティ教育を主な業務としている。

近著に「今夜わかるメールプロトコル」、「今夜わかるTCP/IP」、「今夜わかるHTTP」（共に翔泳社）がある。個人ブログは「うさぎ文学日記」

「SecurityTrust ウォッチ」バックナンバー