対策実践情報対策実践情報 (ソフトウェア開発プロセスにおけるセキュリティ  ソフトウェア開発者向けのページ)

本文を印刷する

対策実践情報 (ソフトウェア開発プロセスにおけるセキュリティ  ソフトウェア開発者向けのページ)

最終更新日:2004年6月15日

I. 背景

ソフトウェアに関して、俗に「セキュリティホール」と呼ばれる欠陥の問題があり、この中には、以下の事項があります。
  1. プログラム中にセキュリティ脆弱性があり、それを攻略できてしまうもの
  2. そもそもセキュリティ設計が考慮されていない仕様(機能)
  3. 弱いユーザ認証パスワード
  4. セキュリティの弱い設定
この中で 3.と4.は、ソフトウェアプログラムの問題ではありませんが、ユーザだけの論点ともなりません。開発者による出荷時のデフォルトパスワードや、デフォルト設定は極めて重要です。

II. 論旨

IPA は、「ソフトウェア開発のプロセスにおいて、情報セキュリティ問題を低減・解消し、セキュリティ品質の高いソフトウェア開発を促進していきたい」と考えています。下記のように、各工程においてセキュリティが考慮される必要があります。

セキュリティ設計→セキュアプログラム→セキュリティテスト→セキュアなデフォルト設定と一方へ流れている。

このようにセキュリティを考慮した開発プロジェクト・マネジメントが成熟されていく方策を検討しております。セキュリティを意識した開発のためには、追加的コストが発生することも織り込むことになります。

III. 各論

1. システムのセキュリティ機能設計

例えば、秘匿すべき情報があるとき、それが秘匿されるようにする設計が重要である。ユーザ認証情報(パスワード)の保存方法などはセキュリティ設計がなされなければならないし、推測困難性が求められる処理データもある。

開発対象システムのセキュリティポリシー(セキュリティポリシーモデルおよびセキュリティターゲット)を策定し、その所有者もしくは利用者の了承を得る過程は、「要件エンジニアリング」と呼ばれる。「要件エンジニアリング」については、「システムエンジニアリングの他の分野における方法論に比べて遅れている」と言われている。

また、システムの複雑性は、「セキュリティの敵」であり、脆弱性を生む温床となると言われている。シンプルな設計を良しとする開発設計文化の定着が期待されるとともに、「複雑性のマネジメント」が課題となる。

複雑性に対処するためには、方法論が必要である。すなわち、大きな問題を対処可能な小問題に分割することと、それらの小問題の相互間における関連性が及ぶ範囲を限定することに関する方法論が必要とされる。これらの方法論は、開発モデルと密接な関係をもつ。

*トップダウン型の設計: ウォーターフローモデル

*反復型の設計: スパイラルモデル、エクストリームプログラミング

参考文献
R Baskerville, "Information Systems Security Design Methods: Implications for Information System Development" in ACM Computing Surveys, v26(1994), pp375-414.

2. セキュリティ脆弱性を生まないセキュアプログラミング

各ベンダーやオープンソースコミュニティが開発する、汎用アプリケーションやオペレーティングシステムの開発におけるプログラミング時に注意すべき点が、プラットフォームごと、開発言語ごとにある。

*インターネットサーバーアプリケーションについて、最も多く報告されているセキュリティ脆弱性は、バッファオーバーフローを引き起こすプログラミングのミスに起因するものである。

*また、電子商取引や、政府部門における電子申請が普及するにしたがって、各 webサイトにおいて、双方向性をもつアプリケーションが開発されるようになっている。これらのシステムのプログラミングにおいても、セキュリティの観点から注意すべき点がある。例えば、CGI プログラムにおいては、入力値の中に、コマンドの実行を許容してしまうようなメタキャラクタが含まれて処理されないように、浄化するチェックが必要である。

コスト効率を高めるために、経験・知識が不足するプログラマ ーが OJT (On the Job Training) を兼ねて開発にあたっている状況が多いのが実情であろう。上記のような注意点をプログラマに教育する必要がある。

3. セキュリティテスト

セキュリティテストは、セキュリティを侵害する問題を意図的に探し出すテストであり、通常の機能テストとは別のテストである。通常の機能テストでは、まずセキュリティ脆弱性を発見することは不可能であり、テストを行う者にも通常のテスターよりも高いスキルを要求することになろう。 現状において入手可能なセキュリティテストツールは、単一の観点からのツールが多く、使い勝手もあまり良くないものが多い。

エクストリームプログラミングにおいては、セキュリティテストは 1回だけではなく、ソフトウェアが進化する過程で「回帰テスト(regression testing)」が行われる必要がある。

通常、セキュリティテストは、段階的に行われる。まず、設計文書を読み、ソースコードを見直し、いくつかのテストを実施する。このようなテストを「ホワイトボックステスト(White box testing)」と呼ぶ。対称的に、文書やソースコードを読まずにシステムのみを対象とするテストは、「ブラックボックステスト(Black box testing)」と呼ばれる。

4. 出荷時のセキュアなデフォルト設定

システムのセキュリティの基本であるユーザ認証のためのパスワードや、各種設定ファイルは、文字通りユーザが設定できるファイルとして提供される。

しかし、ユーザビリティを重視する傾向とあいまって、ベンダーが提供するソフトウェアのデフォルト設定はセキュアでない場合が多いのが実情である。例えば、セキュリティ機能をもつソフトウェアにおいても、その機能をオフ設定にして出荷されているものがある。

重要な原則として、「最小権限の原則(principle of least privilege)」がある。

また、バージョンアップ時にデフォルト設定を変更すると、既存ユーザが見過ごす可能性が高いので、特に注意をすべきであろう。

例: Smurf 攻撃対策
サービス妨害攻撃(DoS 攻撃)のひとつである Smurf 攻撃対策 として、ルーターのファームウェアのデフォルト設定で対策されていること重要である。

CERT Advisory: CA-1998-01 Smurf IP Denial-of- Service Attacks
IETF RFC 2644
ルーターにおいて指図されるブロードキャストのデフォルトを変更する

( Changing the Default for Directed Broadcasts in Routers )