脆弱性の取り扱いに関するまとめ†
- ページ: BugTrack2
- 投稿者: henoheno
- 優先順位: 普通
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2005-06-02 (木) 23:54:48
- バージョン:
メッセージ†
開発プロジェクトはどのように脆弱性を取り扱うべきで、それはなぜなのかをまとめましょう。
参考文献†
- JVN: JPCERT/CC Vendor Status Notes DB 構築に関する検討 (CSS2002)
- 平成16年 経済産業省告示 第235号「ソフトウエア等脆弱性関連情報取扱基準」 (用語など)
- IPA セキュリティセンター: 脆弱性関連情報の取扱い
- スラッシュドット ジャパン | ウェブアプリの脆弱性にどう対応してますか?
脆弱性の取り扱いに関するまとめ†
脆弱性や欠陥について対応を行う場合、
- (1) 「本当に問題となっているのは何であるか」を事象を分解することで明確にし、
- (2) 「本当に安全な状態ないし組み合わせとは何か」を明らかにし、
- (3) その脆弱性や欠陥を悪用する側に与える情報を減らしつつ、
- (4) 利用者に「本当に安全な」状態への(必要最低限の)道筋を示し、
- (5) 広報が正しく浸透するかを観察し
- (6) 浸透の度合い(※時間)に応じて公開情報の内容を整理する
工夫が必要になります。
さもなくば、その内容や度合いに応じて、既存のユーザーが危険にさらされる可能性が生じるか増大します。
- (1) 不完全な対応による抜け穴を悪用されるか、
- (2) 安全でない状態や組み合わせを悪用されるか、
- (3) その脆弱性や欠陥の存在を知った者に悪用されるか、
- (4) その脆弱性や欠陥の存在を知った者に詳細を分析され悪用されるか、
- (5) 広報が届かなかいユーザー層を推測され悪用されるか、
- (6) 浸透しきらないうちに素早く該当ユーザーを検索され悪用されるか
共通する脆弱性を持つプロダクトが複数ある場合、それぞれの開発プロジェクトが問題に関するより正確な情報をとりまとめ、共有し、上記に挙げた基本的な原則について足並みを揃えるチャンスがあります。
- (1) 「本当に問題となっているのは何であるか」を相互に検証し共有する
- (2) 「本当に安全な状態ないし組み合わせとは何か」を相互に検証し共有する
- (3) どの時点ではどこまでどの様に情報を出すべきか／出さないべきかを相互に確認する
- (4) 利用者に始めはどこまで情報を出すべきか／出さないべきかを確認する
- (5) 広報のタイミングを調整し、各自の利用者向けのドキュメント等を用意し、公開する
- (6) 浸透の度合い(※時間)に応じて公開情報の内容を整理する (調整する)
複数の製品に共通する問題について、調整に失敗した場合、単独プロジェクトの単独の問題以上に状況が悪化する可能性があります。
- (1) 「本当に問題となっているのは何であるか」の認識がプロダクトごとに異なったままとなり、特定の脆弱性を「指し示す」はずの情報が収束しない
- (2) 「本当に安全な状態ないし組み合わせとは何か」が不明確となり、利用者から見て対策が不十分であるかのように見えるものが生まれる
- (3) 情報がプロダクトごとに異なり、結果としてそれらを総合すると必要最小限の情報量を越えたものとなる
- (4) 情報がプロダクトごとに異なり、結果として脆弱性に対する対策情報が混沌とする
- (5) 広報の内容や度合いがプロダクトごとに異なり、結果として問題の重要性に関する焦点が定まらず、また十分でない対応が過剰に広報される(例えば他のWebシステムが将来それを参考にする)
- (6) 情報のコントロールの度合いがプロダクトごとに異なり、そのために脆弱性情報の公開やリークに関する競争が起こる
コメント†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
