製品セキュリティを守るチームをゼロから作りたいけど、何から始めればいい？成熟させるには？PSIRT Maturity Document 紹介（レベル２）
前回は、PSIRT をゼロから構築するレベル１を紹介しました。今回は、いくつか脆弱性に対応し、より高度なことが求められるようになった PSIRT レベル２について紹介します。
運用基盤
経営からの信頼を得ること、PSIRT の権利を記述した憲章を確立し、ポリシー、基準、ガイドラインを定めましょう。また、予算を確保し、スタッフを揃え、必要なツールを調達しましょう。
ステークホルダ マネジメント
製品の脆弱性を発見した場合、誰が何をすべきか、社内の関係者がプロセスと役割を理解している状態にしましょう。また、PSIRT は誰がどのように自社製品を利用しているか把握しておく必要があります。製品の脆弱性が意図せず公開されてしまった場合など、より重大な事故が発生した場合に関係者を招集し、復旧できるようにプロセスの整備をしましょう。脆弱性の対応について PSIRT が社内関係者から相談されるようになっていると理想的です。
脆弱性の発見
報告を受けるだけでなく、複数の脆弱性を発見する方法を知り、問題を解決するためのツールを利用しましょう。外部から脆弱性の報告を受けるのではなく、自社内で脆弱性を発見することで、緊急に対応が必要な事案を減らしましょう。この段階では、製品のコンポーネントのリスト（BOM）を作り、監視・修正ができているべきです。
SDLC について
PSIRT はソフトウェア開発ライフサイクルに入って、製品リリース前にフィードバックの提供と、脆弱性の修正に役立てるようにするのが理想的です。
トリアージと分析
脆弱性の評価プロセス
この段階では、いくつかの案件に対応して、脆弱性と認定すべきか否か、検討して判断する練習をしてきていると思います。有名になりたいセキュリティ研究者からの脆弱性とはいえない報告に対応しているかもしれません。PSIRT は、脆弱性を定量的に評価するプロセスを検討するとよいでしょう。
モデルの検討
PSIRT のモデルを検討しましょう。同じ会社内で複数のチームが複数の製品を開発していることと思いますが、PSIRT はどうあるべきでしょうか？１つの PSIRT が複数の製品を担当する中央集権型もあれば、製品ごとに PSIRT を設置する分散型もあるでしょうし、その中間型も考えられます。それぞれ長所・短所があるので、よく考えてチームを作りましょう。
報告者データベース
定期的に脆弱性の連絡をくれる発見者のデータベースを構築しましょう。優れた報告をくれる発見者のレポートは、優先的・簡易なプロセスで対処することで、重要な問題を迅速に対応できるようになります。
発見者にステータスを通知
発見者と友好的な関係を築くために、脆弱性報告に関するチケットを管理し、定期的にステータスを発見者に通知することも検討しましょう。脆弱性の対応に不満を持ち、意図しない脆弱性情報の公開されるリスクを減らすことができます。
再現環境と安全な取り扱い
脆弱性を再現させる環境を開発し、その環境は、通常の業務環境からは隔離しましょう。脆弱性を再現させる手順（エクスプロイト）は、取り扱い方法を文書化し、安全に管理できるようにしましょう。
スコアリングの強化
CVSS を使って、脆弱性の評価に習熟し、製品の脆弱性について説明ができるようになりましょう。CWE を導入しスコアリングを強化したり、重要度のラベルの定義をすることも検討しましょう。
脆弱性の修復
関係者と協力して、脆弱性を修復しましょう。
脆弱性の開示
修正した脆弱性をアドバイザリなどの形式で開示して、報告者への謝辞の掲載も検討しましょう。
まとめ
社内ステークホルダの信頼
脆弱性発見時のポリシー・プロセスを整備し、周知しましょう
特に社内ステークホルダの信頼が重要。脆弱性について相談を受けるようになっていれば最高
脆弱性の評価プロセスを整備
いい脆弱性を報告してくれる人とは、よい関係を築きましょう
脆弱性情報は、安全に管理できるように
脆弱性の重要度のスコアリング能力は強化しましょう
修復と開示
修復したら、利用者に開示
報告者に感謝しましょう
サイボウズのセキュリティ室は、今後も企業のセキュリティ組織に役立つガイドラインや、書籍の紹介記事を掲載していきます。
この記事がよかった、参考になったと思われた方は「好き」のクリックをお願いします。
また、セキュリティ室の取り組みや、セキュリティニュース、サイボウズに受信した怪しいメールなどの情報をツイートしています。＠CybozuSecurity のフォローもお願いいたします。
この記事が気に入ったらサポートをしてみませんか？