第1章 総論
既存ソフトウェアの脆弱性分析
脆弱性は盲点から生まれる
ソフトウェアの開発・改修の際、既存のソフトウェアにどのような脆弱性が生じたかを把握しておくことは、新しいソフトウェアのセキュリティレベル向上に役立つ。
セキュリティ脆弱性はソフトウェア開発者が見落としがちな盲点を突かれ攻撃を許してしまうという問題である。そのため、脆弱性を想定するということは盲点を見つけるということであり、必ずしも容易ではない。
しかしながら、これまで他の開発者がどのような脆弱性を生んできたかを知れば、それと同種の問題の発生に対し事前に備えをもつことができる。
他者ソフトウェアの脆弱性を知る
インターネット上には、製品ソフトウェアの脆弱性を日々収録しているWebサイトがある。悪用を防ぐために、詳細な実装ミスの内容や攻撃手口は明かされない場合が多い。しかし、多くの対策のヒントを得ることができる。それらの例を掲げる。
- 脆弱性関連情報に関する届出状況（IPA）
- http://www.ipa.go.jp/security/vuln/report/press.html
- IPAに届け出られた脆弱性の概要と統計情報。経済産業省告示「ソフトウェア等脆弱性関連情報取扱基準」にもとづいて運営されている届出制度への届出状況。
- JVN（Japan Vulnerability Notes）
- http://jvn.jp/
- JPCERT/CC が取り扱った脆弱性情報を公開しているサイト。枠組みに参加している日本国内の製品開発者の対応状況も含まれている。対応状況には、脆弱性に該当する製品の有無、回避策や対策情報（パッチ等）も含まれる。このサイトには米国US-CERT Technical Alertと、英国NISCC Vulnerability Adviceからの情報も掲載されている。JVNも経済産業省告示「ソフトウェア等脆弱性関連情報取扱基準」にもとづいて運営されている。
- CVE（Common Vulnerabilities and Exposures）
- http://cve.mitre.org/
- 複数の組織から発表される脆弱性情報に共通の識別番号（CVE番号）を与えるプロジェクト。
- CWE（Common Weakness Enumeration）
- http://cwe.mitre.org/
- 製品の個々の脆弱性ではなく、ソフトウェアの弱点（脆弱性や不具合）のパターンに共通の呼び名を与えるプロジェクト。
- SecurityFocus
- http://www.securityfocus.com/
- ソフトウェア製品に検出された脆弱性、攻撃手口と防御手法、セキュリティ・ツール等を収集、掲載しているサイト。
旧バージョンの脆弱性を知る
新しいソフトウェアを開発する際、自社（あるいは自組織）で過去に開発したソフトウェアを機能強化したり、使っていたライブラリを再利用する場合がある。
その際、以前のバージョンのソフトウェアがどのようなセキュリティ脆弱性を含んでいるかが明らかになっているのであれば、その情報を無視すべきでない。脆弱性が後日「再発見」されたときには、対策の難易度とコストが増大しているおそれがあるからである。
脆弱性の存在が分かっている場合、それらへの対処として次のような選択肢があり得る。
- 設計・実装に修正を施して、それらの脆弱性を解消する
- 脆弱性を生じている機能やモジュールを構成から外す
- 脆弱性の存在を承知の上で使い続ける
脆弱性の分析
脆弱性を予防あるいは事後に対処するためには、脆弱性の病理メカニズムを詳細に把握する必要がある。それは、好ましくない現象がどのようにおこるのかを、机上およびコンピュータ上で調べ、それが成立する要因を分析する作業である。これらの作業は難易度が高く、時間もかかる。
したがって、可能な限り他者から得られる情報、自社（自組織）の過去製品から得られる情報を最大限に活用することが重要である。
しかし、もちろんすべての問題の解決法が得られることは期待できない。一部の問題については自社（自組織）で脆弱性の病理メカニズムを分析し、対処法を編み出す必要に迫られる。
脆弱性の記録を残す
その脆弱性にどう対処するか─解消するか放置するか─にかかわらず、脆弱性を検出した場合、それを記録に残し、後続の開発プロジェクトに役立てることが望ましい。そのことが別の開発チーム、および近い将来の自分のチームを助けることになる。
