情報セキュリティにおける脅威（2）
脆弱性の概要
脆弱性とは
組織や情報システム、物理環境など、情報の取り扱いにかかわる構成要素の中で、情報の漏えいや紛失、改ざんなどのリスクを発生しやすくしたり、拡大させたりする要因となる弱点や欠陥のこと
Vulnerability(バルネラビリティ)、Security Hole(セキュリティホール)
脆弱性の種類
ソフトウェア製品等の脆弱性を識別・評価する仕組み
JVN
国内で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供するポータルサイト
IPAとJPCERTコーディネーションセンターが共同運営
●脆弱性関連情報を収集
●対策方法・対応状況の掲載
・脆弱性に該当する製品の有無
・回避策(ワークアラウンド)
・対策情報(バッチなど)
CVE(共通脆弱性識別子)
脆弱性を識別するための識別子
個別の製品に含まれる脆弱性を対象とし、米国政府の支援を受けた非営利団体のMITRE社が採番している
CWE(共通脆弱性タイプ一覧)
脆弱性の種類を識別するための共通基準
SQLインジェクション、クロスサイトスクリプティングなど脆弱性の種類(脆弱性タイプ)の一覧を体系化して提供している
CVSS(共通脆弱性評価システム)
脆弱性の深刻さを評価する仕組み
IT製品の脆弱性に対するオープンで汎用的な評価手法
ベンダに依存しない共通の評価方法を提供している
評価する3つの基準
基本評価基準(Base Metrics)
脆弱性そのものの特性を評価する基準。
機密性、完全性、可用性に対する影響を表し、CVSS基本地(Base Score)を算出する
現状評価基準(Temporal Metrics)
脆弱性の現状の深刻度を評価する基準
攻撃コードの出現有無や対策情報が利用可能であるかといった基準で評価し、CVSS現状値(Temporal Score)を算出する
環境評価基準(Environmental)
製品利用者の利用環境も含め、最終的な脆弱性の深刻度を評価する基準
攻撃による被害の大きさや対象製品の使用状況といった基準で評価し、CVSS環境値(Environmental Score)を算出する
脆弱性検査
脆弱性検査とは
システム(OS、ミドルウェア、Webアプリケーション等)に対し、潜在的な脆弱性を検査すること。
脆弱性検査の概要
一般的に、脆弱性診断・検査には、ブラックボックス型とホワイトボックス型とがある。
| ブラックボックス型： | 動作している対象システムに対し、実際に擬似的な侵入・ |
|---|---|
| 攻撃を仕掛けることで診断を行う。 | |
| ホワイトボックス型： | システムの設計書、仕様書、設定情報、ソースコードなど | をもとに、机上で診断を行う。 |
脆弱性検査の必要性
対象となるシステムに存在するセキュリティホールを発見・検出することで対策の実施を促す。脆弱性診断・検査の結果に基づいてセキュリティホールを塞ぐことにより、侵入、改ざん、情報漏えいなどのインシデントによる被害を未然に防ぐこと可能となる。
脆弱性検査の実施
脆弱性検査の実施対象／実施方法／対処方法
実施対象として、「OS、サーバソフトウェア」「Webアプリケーション」の2つが代表的
★その他★
●データベース(DBMS)に対する脆弱性検査
●無線LANアクセスポイントに対する脆弱性検査
OS、サーバソフトウェア
主な検査項目
- バージョン、パッチ適用状況
- アカウントやパスワードの設定
- 既知の脆弱性の有無（BOF攻撃など）
- 管理者法コマンドなどの使用可否
- アクセス権設定の適切性
- DoS攻撃への耐性
実施時期・頻度
- 新たにサーバ環境などを構築した際、本番運用開始前に実施
- 運用開始後も定期的に実施する必要あり
実施方法
ブラックボックス検査
- ネットワークを介して検査対象ホストにアクセスを試みて検査を実施
- 市販ツールやフリーウェアなどを使用
- ツールの結果に基づきより詳細な検査や検証を専門技術者が実施
ホワイトボックス検査
- 検査対象ホストの構成や仕様書、各種設定ファイルなどを入手して机上で検査を実施
特徴・留意点
- 仕様がある程度統一されている市販製品への検査なので、基本的な脆弱性はツールによって検査可能
- ツールによる検査結果の検証や、ツールでは実施困難な高度な検査を要する場合は、専門技術者による実施が必要
- DoS攻撃検査などは本番運用に影響を及ぼす可能性が高いため、実施する時間帯などを検討／調整する
対処方法
- 発見された脆弱性は直ちに対処するとともに、同じ製品構成の他のホストにも同様の脆弱性が存在する可能性が高いので、それを確認する必要がある
- 市販製品の脆弱性は次々に発見されているから、構成・設定などに変更がない場合も定期的な実施が必要
Webアプリケーション
主な検査項目
- セッション管理の脆弱性（クエリストリング、クッキー、hiddenフィールドの設定・使用方法など）
- XSS脆弱性の有無
- SQLインジェクション脆弱性の有無
- OSコマンドインジェクション脆弱性の有無
- ユーザ認証、暗号化の適切性
実施時期・頻度
- 新たにWebページ(Webアプリケーション)を開設する際に、本番運用開始前に実施
- 一度検査を実施し、対策を施したページについては仕様の追加／変更がなければ再検査不要
- 新たなWebページや機能が追加される際には検査を実施する
実施方法
ブラックボックス検査
- 検査対象のWebアプリケーションにアクセスし、実際にデータを入力したアプリケーションの機能を実行して検査を実施
- 専門技術者による検査が中心
- 一部の基本的に部分については市販の検査ツールなどを用いて実施することも可能
ホワイトボックス検査
- 検査対象Webアプリケーションのシステム構成、詳細仕様、画面遷移に関する文書、ソースコードなどを入手して机上で検査を実施
特徴・留意点
- Webアプリケーションは、サイトによって独自の使用となる為、検査ツールなどでは十分な検査の
- 入力フィールドの意味や各ページの関連性などを人間が判断しながら実施する必要がある
- 検査の実施により、DBに実際にデータが登録されたり、各種の処理が実行されたりすることになるので、事前の調整、実施後の対処が必要
- 会員向けページ、管理者向けページなどの検査のためには、検査用アカウントを用意する必要がある
対処方法
- 発見された脆弱性については直ちに対処するとともに、そのページを開発したベンダによる他のアプリケーションにも同様な脆弱性が存在する可能性が高いため、それを確認する必要がある
- 再発防止のため、開発ベンダにセキュアなアプリケーション開発手順を確立／徹底させる必要がある
ツールによる検査の有効性と限界
市販のパッケージ製品やフリーウェアなどが豊富にあり、多岐にわたる検査項目を効率的に実施できる。
自動診断ツールによるチェックは、診断範囲が限定される上、誤探知の問題が存在し、システムの重要度や影響の評価はツール化できない。
管理者がツールを用いて検査を実施するだけでなく、重要度に応じて専門業者に脆弱性検査を依頼することが望ましい。
脆弱性検査の実施におけるその他の注意点
- 脆弱性検査を専門業者に依頼する場合、サービスメニュー、SLA、過去の実績、業界での評判等から技術力、信用度を評価した上で選定する。
- 脆弱性検査の実施に関するポリシや運用手順の確立が必要
- 脆弱性検査ツールを使用する場合、常に最新のバージョンにアップデートしておく必要がある
- 大規模なサイトに対する脆弱性検査は継続的な運用を前提として、検査対象の選定、検査実施スケジュールの調整、検査の実施、検査結果の管理、対策実施状況の管理などを、総合的に行う脆弱性検査システムの導入や構築を検討する
ファジング
ソフトウェアのブラックボックス検査手法の一つで、開発者が想定しにくい様々な種類のデータを入力してみて、不具合がないか調べるもの。外部からの攻撃に利用できる保安上の弱点（脆弱性）が存在しないか調べるために行われることが多い。 最も一般的な方式では、サイズや内容がランダムな大量のデータをプログラムによって自動的に作り出し、テスト対象に次々与えてみて、意図しない動作が発生しないか調べる。ソフトウェアの挙動から異常が起きそうな入力値を人が考えて列挙する手法や、値を連続的に変化させてしらみつぶしにテストする手法が用いられることもある。
