PSIRT Services Framework v1.0 日本語版

近年「PSIRT」という言葉が注目を集めています。PSIRT(Product Security Incident Response/Readiness Team)とは、製品を提供している組織において、製品にセキュリティ上の問題が発見された際に、報告の窓口を努めるとともに、組織内の対策活動を円滑にすすめるための司令塔となる機能を指します[1]。

従来、セキュリティリスク対応のための組織内機能としてはCSIRT(Computer Security Incident Response/Readiness Team)がその役割を担うものとして認識されています。製品やサービスを提供する組織においては、その提供物における脆弱性などのセキュリティ問題への対処をCSIRTが担うこともあれば、製品やサービスを所管する部門が対処することもあります。一般的に、CSIRTが主として取り扱うことが多い組織内の情報システムインフラにおけるセキュリティ問題と、組織が顧客へ提供する製品やサービスにおける脆弱性等の問題は、対処の性質が異なるものであり、一部の脆弱性情報を扱うコミュニティの中では、製品のセキュリティ問題に対処する機能としてPSIRTという概念をCSIRTと区別して使用してきました。

そのような中で、昨今IoTの拡がりとともに多くの情報機器がネットワークに接続されセキュリティ上の脅威にさらされるようになり、それらの機器によるセキュリティ問題が顕在化し始めたことで、製品のセキュリティ問題に対処する機能としてのPSIRTが注目されるようになってきました。製品やサービスを提供する日本国内の企業においても、PSIRTを持つ組織が徐々に広がってきています。しかしながら、その構築・運用についての知見が広く共有されることは多くありませんでした。

『PSIRT Services Framework』は、国際的なCSIRTのフォーラムであるFIRST(Forum of Incident Response and Security Teams)が作成した、PSIRTがその役割を担う際に必要となる機能や資産についてまとめられた文書です。このたびJPCERT/CCは、Software ISAC(一般社団法人コンピュータソフトウェア協会)に参画するサイボウズ株式会社さま、グローバルセキュリティエキスパート株式会社さまと共同で、FIRSTによる英語の原著『PSIRT Services Framework Version 1.0』を日本語に翻訳し、FIRSTのWebサイト上で公開しました。

PSIRT Services Framework v1.0 日本語版

この文書では、PSIRTが提供すべきサービスを「サービスエリア」と名付けた以下の6つの枠組みに分類しています。

  • サービスエリア 1: ステークホルダエコシステムマネジメント
  • サービスエリア 2: 脆弱性の発見
  • サービスエリア 3: 脆弱性のトリアージと分析
  • サービスエリア 4: 対策
  • サービスエリア 5: 脆弱性の開示
  • サービスエリア 6: トレーニングと教育

それぞれのサービスエリアでは、PSIRTがサービスを提供するために必要な、またはサービスの提供に役立つ機能や資産が列挙されています。
例として、サービスエリア 2 より、「サービス 2.1 脆弱性の受付」を一部抜粋してみましょう。ここではPSIRTが「脆弱性報告を受け付ける」というサービスを提供するための機能が列挙され、それらの目的と期待される成果が具体的に述べられています。

サービス 2.1 脆弱性報告の受付

PSIRT にとっての主要なシナリオは、ステークホルダの製品に影響する報告の受付である。脆弱性報告の受付において鍵となる要素は、必要な組織構造の設置と維持、コンタクトポイントの定義と宣伝、情報を受けられる体制を定義し維持することである。

    目的: ステークホルダの製品に関する脆弱性情報の報告者にとって報告しやすいプロセスとメカニズムを確立し、脆弱性報告への備えを維持する

    成果: PSIRT が脆弱性報告の受付に特化した機能を備える


  機能 2.1.1 到達性を確保する

  PSIRT はその存在についての認知を確立し、外部組織や組織内のエスカレーションパスから常に利用可能でなければならない。明確に定義されたコミュニケーションチャネルは、発見者、パートナー、ステークホルダが PSIRT に脆弱性を報告する際の助けとなる。

      目的: 脆弱性を報告しようとする者が、必要なコンタクト先と提出方法についての情報を容易に見つけることを可能にする

      成果: 多数のレポートが提出された際に、PSIRT が脆弱性情報を受理できないというクレームが起こらないようにする


    サブ機能 2.1.1.1 報告の提出様式を定義する

     様々なチャネルから品質がバラバラな脆弱性情報が来ることが予想される。報告を処理する最善の方法を定義することが有用である。これにはウェブフォームや、公開のチケットシステム、E メールアドレス、サポートホットライン、その他の提出方法が考えられる。

...(略)...

  機能 2.1.2 脆弱性報告の取り扱い

  脆弱性報告は様々なソースから様々な様式で報告される。外部とのコミュニケーションチャネルを常に監視し、報告に対しタイムリーに対応することは極めて重要である。外部の発見者へのレスポンスタイムは組織内で SLA を定義するべきである。

      目的: ベンダ企業内の他部署、ステークホルダ、サードパーティ(発見者、他組織の PSIRT や CSIRT 等)からの脆弱性報告を受け付けるプロセスとメカニズムを提供する

      成果: サードパーティからの脆弱性報告を取り扱う専門機能

...(略)...


『PSIRT Services Framework』では上記の例の他にも、発見者コミュニティとの交流(サービス1.2)、発見された脆弱性の認定基準(サービス3.1)、脆弱性情報を開示する際の関係者間調整(サービス5.1)といった、PSIRTを運用する際に直面するであろうと思われる数々の課題に対しても、必要とされるサービスや備えるべき機能が具体的に述べられています。「備えるべき」と書きましたが、この文書に列挙された機能をすべて備える必要は必ずしもありません。各機能の目的や成果を参照しながら自組織の活動にとって有益となる機能を取捨選択し、PSIRTの構築・運用に活かすことができる内容となっています。

この文書がPSIRTに携わる方々にとっての指針の一助となることを願っています。

早期警戒グループ 福本郁哉

参考情報


[1]: PSIRTは Product Security Incident Response/Readiness Team の略であり、「チーム = 部署」というイメージから「組織内機能」という説明に違和感を持たれるかもしれません。しかし、PSIRTは必ずしも部署(人)である必要はなく、あくまでも「対応を行う機能」として捉えられます。極端な話をすると、全て機械的に自動化されたシステムがPSIRTとしての役割を担っていても良いわけです。

≪ 前へ
トップに戻る
次へ ≫