なぜ、いま「セキュアコーディング」なのか？：もいちど知りたい、セキュアコーディングの基本（1）（1/2 ページ）
多くのソフトウェアが脆弱性を抱えたまま出荷され、不正アクセスや攻撃の脅威にさらされているいま、セキュアな開発に関する技術や経験を有するプログラマがいっそう求められるようになりました。この連載ではC/C++言語を例に、セキュアコーディングで特に重要となるトピックスを紹介していきます。
ソフトウェアセキュリテイをめぐる状況
今月から数回に渡って「C/C++セキュアコーディング」の連載を担当させていただくことになりました、JPCERTコーディネーションセンター（JPCERT/CC）、脆弱性解析チームの久保と戸田です。よろしくお願いします。第1回目の本記事は久保が担当します。
まず始めに、連載のタイトルにもある「セキュアコーディング」とは何なのか、言葉の整理も兼ねて、あらためて考えてみたいと思います。
セキュアコーディングとは、攻撃者やマルウェアなどの攻撃に耐えられる、堅牢なプログラムを書くことです。
インターネットにつながったシステムの上で動くソフトウェアやソフトウェアを組み込んだ製品は、ネットワークを経由した攻撃の脅威に常時さらされています。ソフトウェアのある種の欠陥やバグによって作り込まれる「脆弱性」は、攻撃者が細工した不正な入力データをプログラムに送りつけることで攻撃され、プログラムのユーザーがセキュリティ被害を受けることになるわけです。
そのような攻撃の脅威をあらかじめ想定し、たとえプログラムが意図しないデータを受け取ったとしても、意図した通り正しく動作するプログラムを書くこと―――脆弱性を作り込まないこのコーディング作法が、本連載のテーマであるセキュアコーディングです。
現実にはソフトウェアの多くは、脆弱性を抱えたまま出荷され、市場に出回り、その結果、ほとんど毎日のように脆弱性が発見されています（注1）。ちなみに2011年の1年間に見つかったソフトウェアの脆弱性は約7000件（注2）です。この数字は、あくまで見つかった脆弱性の数であり、氷山の一角にすぎません。脆弱性の多くは、まだ発見されていないだけで、多くのプログラムに潜在的に存在すると考えられます。
注1：例えば筆者らが購読しているoss-securityというオープンソース・ソフトウェアに関するメーリングリスト（特にOSやそのパッケージ関連）では、ほとんど毎日、新規の脆弱性について報告があり、CVEと呼ばれる脆弱性のユニークな識別子が割り振られています。
注2：osvdb.org に2011年1月1日から2011年12月31までの期間に登録された脆弱性の件数は7316。
脆弱性のコスト
このように脆弱性が放置され続けている原因の1つに、コストの問題があります。脆弱性のないソフトウェアを開発するにはお金が掛かるのです。設計段階からセキュリティ上の脅威を想定し、脆弱性を作り込まないためにセキュアコーディングを実践し……等々、セキュアな開発にはコストがかかります。コストを負担するのはユーザーであり、つまりはソフトウェアの価格や利用料が上がるということです。
これまでユーザーがソフトウェアに求めてきたのは、より高い性能であり、より優れた機能であって、セキュア開発によって得られる「もし攻撃されても被害を受けないソフトウェアの堅牢性」というソフトウェアの品質ではありませんでした。あるいは、そもそも、セキュリティという品質のパラメータがごっそり抜け落ちており、これまで検討すらされなかった（その必要がなかった）のかもしれません。
いずれにせよ、攻撃されない限り実害に結び付くことのない脆弱性をあらかじめ取り除くというインセンティブが働きにくい要因が、ソフトウェアのマーケットをこれまで支配してきました。
しかし、この市場の力学は変わりつつあります。また変わらざるを得ないポイントに、我々は立たされています。理由は、再びコストの問題です。
脆弱性を作り込むことによって発生するさまざまなコストが、作り込まない場合のコストを上回る――そのことが、もはや無視できない問題として、我々に突きつけられているのです。
脆弱性に対する攻撃が衰えることはありません。日々発見される脆弱性。それを攻撃するexploitのツール化。攻撃の自動化と洗練。ゼロデイ脆弱性と呼ばれるパッチの存在しない脆弱性は、数万円から、場合によっては数千万円の値段で売り買いされることがあるほどの経済価値を持ち、アンダーグラウンドのマーケットでやりとりされています（注3）。
サイバー戦争に備えた兵力を有する国が増えていく中で、他国をサイバー攻撃するための「兵器」として利用可能なソフトウェアの脆弱性は、ますます価値を持つことになるのでしょうか。2007年公開の映画「ダイ・ハード4.0」で描かれた、発電所や工場のプラントを制御するソフトウェアの脆弱性を攻撃する「サイバーテロ」は、昨年2011年に登場したStuxnet（関連記事）により、現実の脅威であることが明らかになりました。ソフトウェアの脆弱性はもはや、従来のソフトウェア開発者とユーザーの市場の枠を超えて、社会インフラや国際関係をも脅かす問題にまで発展しています。
注3：フォーブス誌の取材に応じたバンコクを拠点に活動するセキュリティ研究者は、ハッカーが見つけた脆弱性を米国政府関係者に売り、15％の仲介料を得ているという。 "Shopping For Zero-Days: A Price List For Hackers' Secret Software Exploits" http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
セキュア開発の経済性
「ソフトウェアの欠陥を出荷後に見つけて修正すると、仕様策定や設計段階に見つけて修正する場合の100倍のコストがか掛かる」
"Finding and fixing a software problem after delivery is often 100 times more expensive than fiding and fixing it during the requirements and design phase."
――Barry Boehm（南カリフォルニア大学教授、ソフトウェアエンジニアリングの専門家）
脆弱性が社会に与える影響までコストに含めてしまうと話が複雑になるため、開発者とユーザー、ソフトウェアビジネスの世界に話を戻し、脆弱性について考えてみたいと思います。
前述のように、セキュアな開発を行う上で障害となるハードルの1つは、コストの問題です。通常の開発に掛かるコストが100であり、セキュアな開発に追加で掛かるコストが20であれば、セキュアな開発には120コストが掛かります。これは単純なコスト増であり、市場競争の中コスト削減が求められ、予算の限られた状況では到底受け入れられないでしょう。
しかし、このコストの考え方には見落としがあります。それは、開発後に発生するメンテナンスコストです。ソフトウェア開発全体で掛かるコストは、開発コスト＋メンテナンスコストであり、このメンテナンスコストが占める割合は、全体の6〜8割に上るともいわれています（注4）。
以下、話を単純化して考えます。仮に、メンテナンスコストが70％であるプロジェクトにおいて、より多くの開発期間とコストを開発フェーズに費やせば、その分メンテナンスコストが減少します。言い方を換えれば、セキュアな開発を行うことで、製品リリース前の開発に掛かるコストが増加したとしても、トータルでの開発コストは下がるという考え方です（TCOの削減）。例えば開発コストが30、メンテナンスコストが70（トータルで100）の開発プロジェクトにおいて、30＋20＝50のコストを掛けてセキュアなソフトウェアを開発することで、メンテナンスコストが70から30に減少し、TCOとしては50＋30＝80のコストに抑えることができるのです。
開発ライフサイクル全体のコストとして考えたとき、セキュア開発がTCOの削減につながるということは新しい話ではないでしょう。開発フェーズの初期の段階でバグをつぶすのにかかるコストと、後期のフェーズで掛かるコストでは1500倍の開きがあるという、Barry Boehm氏の研究とも一致します（注5）。脆弱性が実際に攻撃され、その被害を補償する社会コストまでを想定した場合、TCOの削減につながることは想像に難くありません。
| ステージ | 改修コスト（Baziukモデル） | 改修コスト（Boehmモデル） |
|---|---|---|
| 要件定義 | 1X | 0.2Y |
| システム設計 | - | 0.5Y |
| コーディング | - | 1.2Y |
| システムテスト | 90X | 5Y |
| 出荷前テスト | 90〜440X | 15Y |
| 検収テスト | 440X | - |
| 運用 | 470〜880X（*設計変更が必要な場合は、最大で2900倍） | - |
注4："Facts on Software Maintenance Costs" http://www.ehow.com/about_6460450_software-maintenance-costs.html
注5："The Economic Impacts of Inadequate Infrastructure for Software Testing" http://www.nist.gov/director/planning/upload/report02-3.pdf
セキュリティを作るのは「人」
セキュア開発が経済的なメリットをもたらすとすれば、誰がそれを実現するのでしょうか。プレーヤーはあくまで人、プログラマです。
いまや、セキュアコーディングなど、セキュアな開発に関する技術や経験を有するプログラマがより求められる世界にシフトしていることは、間違いありません。コードを書くのはプログラマであり、コードを正しく修正できるのもプログラマであるというソフトウェアエンジニアリングのパラダイムは、しばらくの間大きく変わることはなさそうです。コーディング段階で混入し得る脆弱性を作り込まないためのセキュアコーディングでは、プログラマ一人一人がセキュアコーディングの正しい知識を持ち、一定のルールを守ってコーディングすることが求められます。
しかし、それでもミスをするのは人の常。ヒューマンエラーが付きもののプログラミングにおいては、コード解析ツールなどを利用し、コーディングエラーを検出してそれを排除することで、コードの品質やセキュリティの向上を図ることができます。しかし、ツールは万能ではありません（注6）。最終的に判断を下し、コードを修正するのはプログラマです。
セキュアなソフトウェア開発においては、経済性に基づいた市場の力学を変えることも重要ですが、プログラマの意識改革や、セキュアな開発を行えるプログラマの育成も同じくらい重要になります。
注6：動的解析ツールValgrindの検出結果を適切に修正しなかったために、Debian Linuxで管理されていたOpenSSLのライブラリに致命的な脆弱性が作り込まれた事件はあまりにも有名（http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166）
Copyright © ITmedia, Inc. All Rights Reserved.