プロダクト脆弱性対策・対応成熟度シート
Version 1.1

この成熟度シートは、「PSIRT Services Framework Version 1.0 日本語版」をもとに、PSIRT Services Framework の各フレームワークの目的達成過程の状態を成熟度レベル毎に示したものです。

1

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
はじめにプログラム開発事業やソフトウエア販売等に関わる企業において、製品の脆弱性管理は重要な課題となってきました。この成熟度シートは⾃社開発製品または⾃社販売製品に関する脆弱性管理を課題として扱い始めた組織、または製品セキュリティ・インシデント対応チーム（PSIRT）の設⽴を進めている組織、もしくは PSIRT 業務の品質の向上を目的に、現状評価や課題の洗い出し、施策の⽅向性を検討する材料として利⽤して頂きたいものです。
2018 年にリリースされた、PSIRT Services Framework Version 1.0 日本語版では、PSIRT のあるべき姿をサービスエリア毎に詳細に記述してありますが、組織の規模や製品販売対象範規模の違いなどで、要件としてそのまま⾃組織に当てはめるには難しい面も散⾒されます。この成熟度シートは PSIRT Services Framework の理解を助けると同時に、目標とする成熟度レベルを⾃ら設定し、中小規模のビジネスにおいても参考となるよう配慮しました。
利⽤の仕⽅

まずは、各フレームワークの目的を確認したうえで、外部環境や⾃社のビジネス状況から目標を設定してください。
（※1）その後、⾃組織の現状把握のため、ティア０（※2）の内容から順に上位のティアに向けて記述を読み、⾃組織がどのティアにも最も近いかという観点で採点してください。目的の内容が明らかに業務範囲外であればそのフレームの目標を０に設定してください。目標と採点結果のギャップを分析し、⾏動計画を策定することを推奨します。採点は定期的(半年〜1 年に 1 回)、あるいは組織改革や業務改革実施後、インパクトの大きいインシデントを対処した後などが適切です。
※1 目標の設定⽅法は、本書 P4 を参照してください。
※2 記述の中に、サービスエリアの番号を記載しました。
「PSIRT Services Framework Version 1.0 日本語版」を参考にしてください。
( https://www.first.org/standards/frameworks/psirts/FIRST_PSIRT_Services_Framework_v1.0_jp.pdf )注意事項

・文中に「PSIRT」が主語として多く記述されていますが、「PSIRT」という組織が存在しなくても、PSIRT の一部の機能や脆弱性管理責任を持つ組織や個人が存在すれば、それを当てはめて評価してください。
・記述内容や⽤語が理解できない場合は、「PSIRT Services Framework Version 1.0 日本語版」の内容や⽤語の定義を確認してください。

2

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
ティアについてこの文書中のティアの概念は、NIST が公開している Cyber Security Framework 1.1 (※1) のインプリメンテーションティアの定義を参考に作成しています。
・ティア０ 何もしていない
該当のサービスエリアについて、必要性の認識がなく、いかなる活動も実施していない状態のこと。
・ティア１ 部分的である（Partial）
プロセスが定められておらず、場当たり的に事後的に対応がされている状態のこと。
脅威情報などは、一部のメンバーが確認することがあるが、ケースバイケースで流通したりしなかったりする。
・ティア２ リスク情報を活⽤している（Risk Informed）
リスクに対して意識が⾼く、プロセスが経営層などより承認されているが、全体のポリシーまで浸透しておらず、繰り返し適⽤可能な状態には至っていない。
脅威情報などは、非公式的に一部の層に流通しており、適切に処理はされているが繰り返し適⽤ができる状態までには至っていない。
・ティア３ 繰り返し適⽤可能である（Repeatable）
プロセスがポリシーとして全体に浸透しており、繰り返し適⽤可能で、外部状況の変化に応じてポリシーが定期的に更新されている。
脅威情報は、手順が定められており、継続的に正確にモニタリングされている。
・ティア４ 適応している（Adaptive）
プロセスが現在の状況や過去の教訓から調整され、最新のサイバーセキュリティ技術と実践に進んで順応し、⾼度化する脅威にタイムリーに対応している。
脅威情報は経営層に共有され、他の経営リスクと同様にモニタリングされるなどサイバーセキュリティリスクマネジメントが組織の文化となっている。
※1 IPA が公開している NIST Cyber Security Framework 日本語翻訳 ( https://www.ipa.go.jp/files/000071204.pdf )3

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
目標の設定について
どの PSIRT Services Framework のサービスエリアに、どの程度のティアを目標として定めるかは、外部環境、組織/事業の規模、提供しているサービスの形態/利⽤者像、組織のリスクに対する許容度などによって変わってきます。この目標設定は、経営層の判断が極めて重要です。目標の設定は PSIRT 活動を実施している担当者が設定するケースが多いと思いますが、経営層のレビューや承認プロセスを経て目標の設定をすることが望ましいです。
外部環境
外部環境とは、攻撃者の攻撃の⾼度化、組織の顧客が製品セキュリティに対して求める要求が⾼まり、外部から脆弱性報告を多く受けているか、などです。業界として攻撃ターゲットとなり攻撃が⾼度化し、顧客のセキュリティ要求の⾼まりがあれば、「脆弱性の発⾒」、「脆弱性の開示」、外部から脆弱性の報告を多く受けている場合は、「脆弱性情報とトリアージと分析」に関するサービスエリアのティアをあげることを推奨します。
組織/事業規模
組織/事業規模が拡大するにつれ、ステークホルダが多くなります。規模が大きくなるにつれ、「ステークホルダマネジメント」、「脆弱性情報のトリアージと分析」
、
「脆弱性の
開示」
、
「トレーニングと教育」などのサービスエリアのティアをあげることを推奨します。
提供しているサービスの形態/利⽤者像
提供しているサービスが多くの製品に組み込まれるコンポーネントなのか、1 社のみに提供しているオンプレ製品なのか、アップデートを⾃社で完結できるクラウドサービス
なのかによって「対策」、「脆弱性の開示」などのサービスエリアの目標が変わってきます。⾃社のみで対策が完結するようなサービスや、特定の組織のみに提供しているサー
ビスであれば「脆弱性の開示」のサービスエリアは最小限のティアで問題ないでしょう。多くの組織がオンプレミスで利⽤し、アップデートの適⽤に顧客またはステークホル
ダの協⼒が必要なサービスであれば「脆弱性の開示」は⾼いティアが求められます。
リスクに対する許容度提供しているサービスが侵害された場合に、社会に与える影響が大きいが小さいか、レピュテーションリスクの想定、損害を補償するだけの財源が組織に確保されているかによって、全体のサービスエリアのティアに求められる要求が変わってきます。

4

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.1 内部のステークホルダ管理
目的︓ 社内のステークホルダに対して PSIRT の権限と専門知識を確⽴し、脆弱性の修復や製品セキュリティの円滑は調整を促進する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

脆弱性に関する管理の柱として一部の担当者は PSIRT の必要性

PSIRT と内部ステークホルダと[1.1.1]PSIRT が組織として、そPSIRT の存在が組織全体に共有

PSIRT は必要とされていない。

を感じており、業務で顕在化しのコミュニケーションの重要性の責任者や機能、役割が文書化され、製品の脆弱性に対応する

⼜は、必要と認識しながらも経た脆弱性情報に関して限られたに気がつきはじめ、インシデン

され周知されている。内部ステ

ことが組織の文化となってお営者は組織内にその機能を持つ

相手に情報共有し、業務範囲やト対応プロセスは徐々にパターークホルダとしては、経営層、り、環境の変化に応じて PSIRT

為のリソースは提供していな

既存の業務分掌を超えたなかでン化している。経営者とも意識

広報・CC、法務部門、開発部門、 のポリシーが適時⾒直されるない。

対処している。

を合わせ、製品は顧客が利⽤す

営業部門などが定義されていど環境に適応した組織となってることで初めて価値が生み出さ

る。

いる。

れると感じている。

[1.1.3]インシデント事後対応
プロセスの構築が構築されており、脆弱性の対応について振り返り、課題を設定するプロセスがある。

5

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.2 発⾒者のコミュニティとの交流
目的︓ 組織の PSIRT が研究コミュニティにも積極的に貢献し、製品セキュリティに影響を及ぼす可能性のある脅威に対する状況認識をしやすい環境を構築する。発⾒者との否定的または敵対的な関係は、脆弱性に対処する上で、不利益を被る可能性のある研究の早期通知の機会損失につながり、それによって組織に対するステークホルダの感情に影響を与える可能性がある。

ティア 0

ティア 1 (Partial)

ティア 2 (Rick Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

組織外の脆弱性の発⾒者と積極

PSIRT は[1.2.1]特定の適切な発⾒者との交流、イベントへの[1.2.1]特定の適切な発⾒者と[1.2.1]特定の適切な発⾒者と的に交流する必要性は感じてい発⾒者とプライベートな契約を参加に関しては、関連する部門

プライベートな契約を締結する

プライベートな契約を締結するない。また、交流活動が脆弱性締結することや、[1.2.4]会議やの業務として明記されてはいな

ことや、[1.2.4]会議やその他のことや、[1.2.4]会議やその他の公開のための対応を準備する助その他のイベントにおけるセキ

いが、部門内で必要とされ適宜イベントにおけるセキュリティ

イベントにおけるセキュリティ

けとなることに気づいていなュリティ発⾒者との交流や、実施されている。

発⾒者との交流や、[1.2.1]セキ

発⾒者との交流や、[1.2.1]セキい。

[1.2.1]セキュリティ上の欠陥

ュリティ上の欠陥やトピックス

ュリティ上の欠陥やトピックス

やトピックスに関する学術研究に関する学術研究を後援するこに関する学術研究を後援するこを後援することが脆弱性情報公となどが、ポリシーとして推奨となどが、公式的に実施され、開のための対応を準備する手助される、もしくは予算化される

必要あれば突発的なイベントのけになると、担当者は気づき始などで公式的に交流している。

後援などの対応も実施していく

め、一部のメンバーが非公式的ことが組織文化となっている。

にイベントなどに参加している。

6

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.3 コミュニティと組織の交流
目的︓ PSIRT は、パートナーや仲間との活発なエコシステムを構築し維持する必要がある。これらコミュニティとの関係は、欠陥を発⾒し修復するための「多くの目」のアプローチを支援するだけでなく、脆弱性修復の全体的な経験を改善するために、異なるグループ間のグッドプラクティスを共有する助けにもなる。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

第三者、サプライヤ、上流のベパートナーから調達したコード

PSIRT は[1.3.1.2]他の PSIRT、 [1.3.1.1] 調 達 先 か ら 脆 弱性の調達先との情報連携が頻繁⾏わ

ンダ、OEM などのパートナーかやコンポーネントの中に脆弱性

セキュリティベンダやバグバウ

報告を受け処理するための NDA

れ、過去の対応の教訓からプロら調達したコードやコンポーネが発⾒された際に対応が必要とンティベンダとの交流やカンフなどが締結されている。

セスが調整され、情報連携によントの中に脆弱性が発⾒された

考え、情報収集⽅法を考え、調ァレンスイベントなどの積極的[1.3.1.2] 有 ⽤ な コ ミ ュ ニティ

る対応がタイムリーに実施でき際の、組織内の連携について何達先のコミュニティやイベントな参加などによる活発な対話のチャネルでの活動に必要なリソる。

も検討されていない。

に参加するメンバーが出てきて中で、有⽤と思われるコミュニースが予算化されている。

いる。

ティやパートナーとのチャネル

どのコミュニティと交流するを⾒つけるようになってきておか、情報連携⽅法についてポリり、有⽤な情報は組織内の役割

シーが定めてあり、繰り返し実にしたがって連携するようにな

施可能な状況にある。

っている。

7

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.4 下流のステークホルダマネジメント
目的︓ PSIRT は製品のセキュリティ脆弱性に関する情報やインシデント対応の情報を伝達するために、組織のステークホルダ基盤とのチャネルを構築し、維持する必要が
ある。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

⾃社製品のバグやセキュリティ

PSIRT の一部の担当者は個人的組織の下流ステークホルダに、[1.4.1.1]明確な製品ライフサイ[1.4.1.1]脆弱性の改修やサポー脆弱性に関する情報を提供するに製品のバグやセキュリティ脆

PSIRT とのコミュニケーション

クルとサポートポリシーを確⽴

ト期間については明確なポリシために下流ステークホルダとの弱性に関して日頃から交流のあを⾏う⽅法やセキュリティ問題するために、脆弱性の改修やサポーが定義されており、かつ下流ス良好な関係の構築に関心がない。 る下流のステークホルダと情報のサポートを受ける⽅法が確⽴ート期間についてポリシーが定

テークホルダとの適切な対応にの共有や対応をしている。しかされ始めている。

義され文書化されている。

ついて常に検討されている。

し、PSIRT の担当者の対応は場脆弱性の改修やサポート期間に[1.4.1.2]下流のステークホルダ[1.4.1.2]脆弱性の関する情報や当たり的であり、重要な情報が必

ついては明確なポリシーはなく、 との交流について、良好な関係をインシデント対応の情報を伝達

ずしも提供されているとは限ら都度設けられる会議によって個構築することが有効であると認するため、組織のステークホルダない。

別に決められる。

知されている。脆弱性の関する情基盤とのチャネルを構築し維持

報やインシデント対応の情報をするための運⽤について改善が伝達するため、組織のステークホ

⾏われ、PSIRT と下流ステーク

ルダ基盤とのチャネルを構築しホルダとの間に信頼関係が生ま維持するための運⽤について文れている。

書化されている。

8

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.5 組織内でのインシデントに関するコミュニケーションの調整
目的︓ ビジネス内のすべての関係者が、セキュリティ脆弱性の対応情報に関する情報を知っていることを確認し、次のステップを妥当に判断できるようにする。コミュニケーションはさまざまな形（E メール、伝統的なメール、RSS フィード、ソーシャルメディアなど）で取ることができるが、最終的にはすべての情報が、ステークホルダが懸念する脆弱性・インシデントの情報を明確にかつタイムリーかつ正確に提供する。

ティア 0

ティア 1 (Partial)

レベル 2 (Risk Informed)

レベル 3 (Repeatable)

レベル 4 (Adaptive)

PSIRT 設置の有無に関わらず、セキュリティ・インシデント対応

インシデントオーナーは決まっ

インシデント対応時にステーク

インシデントに関するコミュニ

セキュリティ・インシデントに対状況の把握、次のステップのためた組織あるいは個人によって実ホルダと十分でリアルタイムにケーションのポリシーが存在しする旗振り役がどの組織（またはの妥当な判断材料などの提供な施され、インシデント対応時にス

コミュニケーションを得るため運⽤されており、かつそのポリシ個人）であるか明確であること

ど、PSIRT が提供するべき基本

テークホルダと十分なコミュニに必要な通信チャネル、共有のルーが有効に機能しているかを測や、対応状況の把握、次のステッ的なインシデント対応のためのケーションを得るために必要なール、機密保持対策がポリシーと定し、常に改善するサイクルが回プのための妥当な判断材料など仕組みが必要であることが、議事

通信チャネルが検討されている

して定義されている。

っている。

の提供など、ステークホルダが懸録、組織内のポータル、メーリン

が、情報の種類や整理⽅法、また・[1.5.1]コミュニケーションチ

念する脆弱性・インシデントの情

グリストやチャット等で一部の秘密裏に運⽤されるよう必要最ャネルを提供する。

報を明確かつタイムリーに提供関係者が情報を共有しているが、 小限の共有に関する仕組みまで

・[1.5.2]安全なコミュニケーシ

する必要性に誰も気づいていな

旗振り役は場当り的である。

は検討されていない。

ョンの管理⽅法を提供する。

情報の共有に関する仕組みは、一・[1.5.3]脆弱性トラッキングシ

定の⽅法で定着しつつあるが、利ステムにおけるセキュリティ脆

⽤者の選定、アクセスコントロー

弱性の収集、分類、ルーティング、ル、認証などの運⽤⽅法が適切で優先順位づけのプロセスの提供。

い。

あるかどうかは議論されていな
い。

9

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.6 表彰と謝辞による報酬を発⾒者に与える
目的︓ 脆弱性の公開にむけた調整への発⾒者の貢献に対して謝辞を示す。これらの謝辞によって発⾒者は⾃らの専門性に関するポートフォリオを作成することができ、それにより⾃身の市場評価を⾼めることができる。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

PSIRT 設置の有無に関わらず、一部の担当者は、発⾒者に対し

PSIRT の慣習として、[1.6.2]

組織のポリシーとして、発⾒者組織の機能として、[1.6.2]脆弱

謝辞を示すことにより、製品のて謝辞を示す、もしくはなんらパブリックセキュリティアドバ

への謝辞の公開や、報奨プログ性発⾒者への報奨プログラムは脆弱性の発⾒者との信頼関係をかの報酬が与えられるよう都度

イザリ、ソフトウエアリリース

ラムが開始され、予算が組まれ繰り返し⾒直しがされ、発⾒者築くことが重要であることが理配慮しているが、その⽅法は場ノート、CVE テキストで、発⾒ている。

との信頼関係の醸成に有効な施

解されていない。

当たり的であり、関係者個人に者への謝辞を含めることが当た・[1.6.1.1]リリースノートなど策となっている。

より異なる。

り前となっている。

への記載
・[1.6.2]発⾒者への報奨制度

10

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア１/ ステークホルダ エコシステム マネジメント
1.7 ステークホルダメトリクス
目的︓ PSIRT の活動指標と成果に関するデータを提供する。これは、PSIRT がどれくらい効果的にサービスを提供しているかをステークホルダが理解するのに役⽴つ。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

PSIRT は、組織内外のステーク

一部の担当者は、組織内外のステ

PSIRT は一部ステークホルダの各ステークホルダがどのような[1.7.3]メトリクスデータの分析

ホルダに活動指標や成果を報告

ークホルダに関わらず PSIRT 活

要求などにより活動指標や成果情報が必要かを[1.7.1]理解すると⾒直しにより、メトリクスデー

することの重要性に気付いてお動指標や成果を報告したりしてを報告しているが、定期的に実施ため、ミーティングやアンケート

タに適切な情報（背景、経緯、環らず、活動していない。

いるが、場当たり的に実施されてするようなポリシーまで定めらを実施し記録し、[1.7.2]メトリ境など）を添えることが必要であいるに留まる。

れていない。

クスを収集し、[1.7.4]メトリク

ることを認識し、実⾏している。

スを報告するポリシーが定めら

メトリクス情報の報告からのフれている。

ィードバックを得て、適宜改善さ
れている。

11

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア２/ 脆弱性の発⾒
２．１ 脆弱性報告の受付
目的︓ ステークホルダの製品に関する脆弱性情報の報告者にとって報告しやすいプロセスとメカニズムを確⽴し、脆弱性報告への備えを維持する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

ステークホルダ内外を問わず、脆組織内における[2.1.1.3]脆弱性[2.1.1.3]脆弱性の報告窓口は特脆弱性の報告窓口について、

外部への発⾒者へのレスポンス

弱性の報告の受け付ける必要性の報告窓口担当は、特定の個人が定の部署や担当者がアサインさ[2.1.1.1]報告の提出⽅法と様式

タイムは組織内で SLA が定義さを感じていない。

実施しており、その個人の意識やれており、窓口業務として必要なを定義しており、[2.1.1.2]コン

れており、状況をモニタリング

業務状況によって受付業務の品

組織構造の設置やコンタクトポ

タクト情報の詳細を公開し、し、SLA に反した場合には適切質が異なる。また受理した情報のイントの宣伝などが実施されてWeb サイトなどで周知されていにリソースの再配分などの対応

扱いは個人の管理能⼒にゆだねいる。受付の効率化のため、る。

がなされている。また、[2.1.2.2]

られている。

[2.1.1.1]報告の提出⽅法と様式

・[2.1.1.3]一般的なコンタクト

不正な報告を⽤いた攻撃の標的が公開されているが、受け付けた

ポイントの登録も準備され、報告にされことを想定し、業務環境は

脆弱性の取り扱い⽅法についての暗号化についても対策されて堅牢化がなされ、報告を独⽴して確⽴したポリシーは定まっていいる。

取り扱う状態にある。

ない。

・脆弱性⽅法の取扱⽅法が定められており、[2.1.2.3]タイムリー
な受理連絡や、[2.1.2.1]連絡可能な他のチャネルの監視も実施
している。

12

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア２/ 脆弱性の発⾒
２．２ 報告されない脆弱性を特定する
目的︓ 状況認識を維持し、ステークホルダの製品に影響する脅威を発⾒するための時間を減らし、フルディスクロージャの可能性を減らす。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

報道機関、技術ブログ、専門の一部の担当者が都度[2.2.1]攻製品開発者が[2.2.2]製品に関

製品開発者やその関係者が業務

製品開発者やその関係者が業務

データベース、ソーシャルメデ

撃情報データベースや[2.2.2]

連する内容のカンファレンスプ

として、[2.2.1]攻撃情報データ

として、[2.2.1]攻撃情報データ

ィア、技術刊⾏物やカンファレ

カンファレンスプログラムを確

ログラムに参加し、[2.2.1]攻撃

ベースの監視や、[2.2.2]カンフ

ベースの監視、[2.2.2]カンファ

ンスを通じて開示される脆弱性

認し、⾃組織の製品に影響があ

情報データベースの確認についァレンスプログラムの監視、レンスプログラムの監視、があることを認識しておらず、るものを情報共有しているが、てルール化し定常的に実施して[2.2.3]⾼名な報告者による発[2.2.3]⾼名な報告者による発確認していない。

実施は場当たり的である。

いる。

表の監視、[2.2.4]マスメディア

表の監視、[2.2.4]マスメディアの監視を実施しており、その業の監視を実施しており、各監視

務は全社的に周知されている。

対象の優先順位や効率化がなさ
れている。

13

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア２/ 脆弱性の発⾒２．３ 製品コンポーネントの脆弱性のモニタリング
目的︓ ステークホルダの製品のサプライチェーン内の脆弱性を特定、収集、監視し、製品チームに対し、製品に影響する脆弱性を通知する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

外部コンポーネントに含まれる製品開発者の一部が、[2.3.1]製

製品開発者の一部が、[2.3.2]サ

以下のプロセスが定義され文書

以下のプロセスが定期的に⾒直脆弱性について管理し、情報収品コンポーネントの目録を作成

ードパーティのアドバイザリの化されている。

され改善定義されている。

取する必要性を感じていない。

し管理しはじめた。

モニタリングをしはじめ、

・[2.3.1]製品コンポーネントの・[2.3.1]製品コンポーネントの[2.3.5]組織内の開発チームへ

目録

目録の通知がされはじめた。

・[2.3.2]サードパーティのアド・[2.3.2]サードパーティのアド

バイザリのモニタリング

バイザリのモニタリング

・[2.3.3]脆弱性に関するインテ・[2.3.3]脆弱性に関するインテリジェンスソースのモニタリン

リジェンスソースのモニタリンググ

・[2.3.4]ベンダ組織内のサプラ・[2.3.4]ベンダ組織内のサプライチェーンの脆弱性情報の受付

イチェーンの脆弱性情報の受付

手順

手順

・[2.3.5]組織内の開発チームへ

・[2.3.5]組織内の開発チームへ

の通知

の通知。

外部コンポーネント︓ 脆弱性は大まかに３つに分類される。①製品固有のソースコード内の脆弱性、②製品開発者の組織内リソースによってメンテナンスされるコンポーネントの脆弱性、③製品開発者の外部のリソース（サードパーティ）によってメンテナンスされるコンポーネントの脆弱性。製品の観点では②③は外部コンポーネント。

14

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア２/ 脆弱性の発⾒２．４ 新しい脆弱性を⾒つける
目的︓ 外部組織が発⾒する前に製品の脆弱性を発⾒する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

外部組織が発⾒する前に製品の一部の担当者は、製品の脆弱性[2.4.1] 脆 弱 性 ア セ ス メ ン ト[2.4.1] 脆 弱 性 ア セ ス メ ン ト[2.4.1] 脆 弱 性 ア セ ス メ ン ト

脆弱性を発⾒することが、製品について内部で発⾒し対処した(Red Team テスト、グレーボッ(Red Team テスト、グレーボッ(Red Team テスト、グレーボッのセキュリティ問題への対処に案件がトータルコスト面で有利

クス／ブラックボックスセキュ

クス／ブラックボックスセキュ

クス／ブラックボックスセキュ

おいて、工数の削減になること

であることに気づき、脆弱性発

リティアセスメント、リバース

リティアセスメント、リバース

リティアセスメント、リバースに気付いておらず、活動してい⾒のための活動を⾏っている。

エンジニアリングなどの幅広い

エンジニアリングなどの幅広い

エンジニアリングなどの幅広いツールの使⽤)を導入し始めた。

ツールの使⽤)の⽅法や、ツールの使⽤)の⽅法や、[2.4.2]セキュリティテストツ

[2.4.2]セキュリティテストツ

ールの専門知識の維持に関するールの専門知識の維持に関する管理⽅法について定義され文書管理⽅法について⾒直しが定期化されている。

的に⾏われ改善している。

ない。

レッドチームテスト︓ 実際のサイバー攻撃への対応を経験するもの。破壊的・妨害的な活動を避けながら、一般的なサイバー攻撃や⾼度な攻撃による模擬攻撃によって、資産を保護するための能⼒を診断すること
ブラックボックスセキュリティテスト︓ アプリケーションの内部動作に関する知識がほとんどないかまったくない状態で、外部の攻撃者としてアプリケーションのセキュリ
ティ制御・防御、およびデザインを外部からテストすること
グレーボックスセキュリティアセスメント︓ テスターがソースコードを除く、システム構成情報、管理者情報などを受け取り、システム内部からの⻑期間に渡る攻撃をシミ
ュレートすること

15

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア２/ 脆弱性の発⾒
２．５ 脆弱性発⾒のメトリクス
目的︓ PSIRT 測定値とパフォーマンスに関するデータを提供する。これは PSIRT が与えられた領域やサービスの提供に関してどれほど効果的であるかをステークホルダに理解させるのに役⽴つ。
ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adoptive)

PSIRT のサービスに関する KPI

一部の担当者が、PSIRT サービ

組織の管理する KPI が明確にな

以下の項目を KPI として管理さ

以下の項目を KPI として管理し、を定め、ステークホルダの理解をスの向上を目的とした KPI を検ってきており、一部の KPI が管れ、ポリシーとして定義されてい運⽤レポートとしてステークホ

得ることの重要性を理解してお討し始めたが、本務とは別に⾃発理され始め、情報共有をしている。

ルダに発⾏されており、継続的にらず、活動をしていない。

的に実施されている。

る。

・[2.5.1.1]発⾒された脆弱性と検証

⾒直し、改善が⾏われている。

された脆弱性の総数

・[2.5.1.1]発⾒された脆弱性と検証

・[2.5.1.2]サードパーティ製コンポ

された脆弱性の総数

ーネント(OSS、ミドルウエア、OS・[2.5.1.2]サードパーティ製コンポ等)に落とし込まれた検証済みの脆ーネント(OSS、ミドルウエア、OS

弱性の総数等)に落とし込まれた検証済みの脆・[2.5.1.3]CWE に落とし込まれた

弱性の総数

検証済みの脆弱性の総数

・[2.5.1.3]CWE に落とし込まれた・[2.5.1.4]脆弱性発⾒のアプローチ

検証済みの脆弱性の総数毎に細分化され発⾒された脆弱性の・[2.5.1.4]脆弱性発⾒において、細総数分化されたアプローチ毎に発⾒され・[2.5.2.3]トリアージまでの時間た脆弱性の総数。

・[2.5.2.4]フルディスクロージャ、

・[2.5.2.3]トリアージまでの時間

外部から攻撃された脆弱性、メディ・[2.5.2.4]フルディスクロージャ、

アによって特定された脆弱性の数。

外部から攻撃された脆弱性、メディ
アによって特定された脆弱性の数。

CWE: 共通脆弱性タイプ一覧 CWE（Common Weakness Enumeration） https://www.ipa.go.jp/security/vuln/CWE.html

16

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア３/ 脆弱性情報のトリアージと分析
3.1 脆弱性の認定
目的︓ 組織は、対応したい問題の種類と範囲について、適切な認定基準を定義する必要がある。認定基準は、セキュリティベースラインを設定し、脆弱性の報告を効果的にトリアージするのに役⽴つ。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)[3.1](製品の品質管理担当者)[3.1]脆弱性か、そうでないか[3.1]脆弱性の判定基準は存在[3.1]製品開発チームと品質保[3.1] 組織として脆弱性の認定は、対処すべき問題の種類や範は、担当者のスキルや意思に任するが、網羅的、体系的ではな

証部門が脆弱性の判定基準を定のためのセキュリティベースラ

囲の基準を作成する必要性を感されており、脆弱性の性質に基く、組織の一部で共有されるに義している。バグバーは悪⽤可インが定義されており、悪⽤可

じていない。また、バグと脆弱づき網羅的、体系的に分類されとどまっている。

能な脆弱性を網羅しており、緊能な脆弱性とセキュリティ問題

性の違いが定義されておらず、てはいない。

[3.1.1]判定基準の文書化のフ急とそれ以外に分類されていが区別されている。

脆弱性認定プロセスは存在して[3.1.1]脆弱性の優先順位を決ォーマットは部門ごとに異なる。品質ゲート（品質基準）はバグバー（脆弱性定義）は緊急、いない。

める取り組みが一部で実施される。また、特定の個人の知識に最低限許容可能なセキュリティ

警告、重要、注意に細分化され[3.1.1] 最低限の許容可能なセ始めている。

依存し文書化されていない場合

品質が定義されており、それにて区別され、品質ゲート（品質キュリティ品質レベル（品質ゲもある。

基づき製品はリリースされてい基準）は、最低限許容可能なセート）や脆弱性の優先順位付け[3.1.2]外部から寄せられた脆る。関係者は文書にとして共有

キュリティ品質が定義されてお基準（バグバー）は存在してい弱性情報をデータとして管理しされている。

り、それに基づき製品はリリーない。

ていない。従って、判定基準に[3.1.2]外部情報によって、定期スされている。

反映されない場合がある。

的に改訂がされる。

[3.1.2.1]脆弱性の報告は、デ[3.1.2.1] 外 部 か ら 寄 せ られたータとして管理はされて、改訂

脆弱性情報をデータは反映されのフィードバック情報とはなっるが、バグバーや品質ゲートのている。

粒度が粗いため、反映に時間がかかるなどや、反映されない場
合がある。

17

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア３/ 脆弱性情報のトリアージと分析
3.2 発⾒者との関係構築
目的︓ 研究コミュニティおよび、製品やサービスの脆弱性を最もよく報告する人を理解し、信頼性の⾼い報告者からのレポートの即時エスカレーションを検討する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)[3.2.2]特定の良質な報告者と[3.2.1]脆弱性の報告者への対応[3.2.1]脆弱性を報告した個人及[3.2.1]脆弱性を報告した個人や[3.2.1]脆弱性を報告した個人及の関係維持に関心がないため、すは担当者の意思に任されており、 び組織に関するデータベースが組織のデータベースにより、一般

び組織のデータベースがあり、履べての報告は同一に扱わられる。 一部、良好な関係が構築される。 あり、履歴や成果、処理事例を知公開の前に組織としての改修結歴や成果、処理事例、やり取りの[3.2.3]特定の報告者に良好な対[3.2.3]発⾒者とは個人的な関ることができる。

果や内容が報告される。

内容を知ることができる。特定の応をする必要性を感じていない係であり、最も良好な結果が得ら[3.2.2]信頼性の⾼い報告者の存[3.2.2]一貫性のある信頼性の⾼報告者のレポートに対しては、一ため、発⾒者プロファイルは作成れるような対応が常時、⾏えると在は組織として知られているが、 いごく一部の報告者の存在は組

般公開の前に組織としての改修

されていない。

は限らない。

トリアージプロセスの効率改善

織として認知され、一般公開の前

結果や内容が報告される。

[3.2.4]報告者からの脆弱性レポ[3.2.4]脆弱性レポート迅速に評にはつながっていない。

に組織としての改修結果や内容[3.2.2]一貫性のある信頼性の⾼ートを迅速に評価する必要性を価するための定義がないため、報[3.2.4]脆弱性レポート迅速に評が報告される。

い報告者の存在は組織として認感じていないため、脆弱性レポー

告者と担当者との誤解、理解不⾜

価するための定義はあるが体系[3.2.3]報告者のプロファイルが知され、優先的にエスカレーショ

トに最低限記載されるべき情報ための連絡工数が増え、トリアー化されていないため、情報不⾜に整備され、連絡先、過去のプレゼ

ンされ、トリアージの効率が⾼のガイドラインは定義されておジが遅くなることがある。

よる連絡工数が⾼く、トリアージンの成果や、手法、得意とする製い。

に時間がかかる場合がある。

品、インセンティブなどが、含ま[3.2.3]報告者のプロファイルがれており、報告者によるインシデ整備され、連絡先、過去のプレゼ

らず、公開もされていない。

ント対応プロセスに違いがある。 ンの成果や、手法、得意とする製[3.2.4]脆弱性レポートのガイド

品、インセンティブなどが含まれラインが定義され公開されていており、報告者との対応をスムーる。

ズにさせることができる。

18

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア３／ 脆弱性情報のトリアージと分析
3.3 脆弱性の再現
目的︓ 脆弱性レポートの品質をあげるためのツールと環境を提供する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)[3.3]( 製 品 の 品 質 管 理 担 当者 )[3.3.2]脆弱性を再現させるため[3.3.2-4]脆弱性を再現させるた[3.3.1-5]脆弱性の再現に関する脆弱性の再現に関する責任者は、

は、脆弱性発⾒者のレポートが確の決められた環境は無く、再現確

めの環境整備や手法は一部の担責任者が定められ、必要なリソー

必要なリソース(環境、ツール、

実に再現可能であることを保証

認は必要性を感じた担当者のス

当者に任され、そのプロセスはほス(環境、ツール、要員、保護対要員、保護対策)が適切であるか、する必要性を感じていない。

キルや意に任される。[3.3.4]そぼ一定に進められ、脆弱性レポー策)を具備するための予算計画が⼜、関連する業務の部門間連携、[3.3.1]⼜は、再現するための技のため、脆弱性レポート、PoC

ト、PoC を含む関連情報の保護承認されている。脆弱性の再現確

その際の課題の抽出、シフトレフ

術的専門知識や再現環境の不備

その他関連する情報を保護するは配慮されるが、それらのガイド

認に関連するプロセスは文書化

トへのフィードバック等の管理を理由に、再現性確認を実施して対策は十分といえない。

ラインが社内で定められ承認さ

され管理されている。

をしている。

いない。

[3.3.3]また、再現に必要なツー

れてはいない。

製品ライフサイクルに基づく市

ルは十分でなく、作業効率は意識[3.3.1]再現に不⾜している技術

場リリースの目録が管理され、脆されていない。

的専門知識等が顕在化し、他の部

弱性の再現確認の結果で必要な門との連携も⾏われるが、計画性処置がとられている。

は無い。
[3.3.5]脆弱性の再現確認において、他の製品への影響や脆弱性のバリエーションの存在を意識することがある。

19

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 4/ 対策
4.1 対策リリースのマネジメント計画
目的︓ サービス対象者にどのプロダクトがサポートされるのか、対策が提供されるメカニズムおよび、提供間隔を伝えること。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

ステークホルダがセキュリティ[4.1.1.1]市場にリリースされて[4.1.1]一部の製品で製品ライフ[4.1.1]製品ライフサイクルの管[4.1.1]製品ライフサイクルが確修正プログラムを適⽤するためいる全ての製品の目録を作成す

サイクルの管理が実施され、サポ理のためのプロセスが確⽴し、す⽴、過去の経験、顧客の利⽤実態に計画を⽴てることを想定し、修ることや、[4.1.1.3]製品ライフ

ート終了時期などが明確になっべての製品でサポート終了時期などから柔軟に対応ができてい正プログラムのリリース間隔を

サイクル内で製品がいつサポーている。 [4.1.2.1]RPM 等でセが明確になっている。[4.1.3.1]

る。[4.1.2]セキュリティパッチ

確⽴することが必要である認識

トされなくなったかを特定する

キュリティ修正プログラムをパ

プロダクトマネジメントチーム

リリースマネジメント計画の⽴がない。

など、修正プログラムのリリース

ッケージ化するための、様々なコやリリース管理と連携して、セキ

案、運⽤、評価についてステーク間隔を確⽴するための準備が担

ンテンツタイプを理解し、

ュリティ修正プログラムの配信

ホルダの間で継続的に調整が⾏

当者レベルで進められている。

[4.1.2.3]様々な製品間でセキュ時期を決定するプロセスや、われている。

リティプログラムの展開⽅法を[4.1.3.2]セキュリティ修正プロ

特定する仕組みを一部で提供しグラムが通常の間隔で配信され始めた。

ない場合の例外を特定し、文書化している。

RPM︓ 米 Red Hat 社が開発したパッケージ管理システム。アプリケーションのインストールやアンインストール、アップグレードなどの管理が簡単に⾏える。現在では、Vine Linux や Turbolinux などのさまざまなディストリビューションでこの RPM を利⽤してバイナリーパッケージやソースパッケージが作られている。

20

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 4/ 対策
4.2 対策目的︓ 影響を受けるプロダクト、バージョンおよび、影響を受けるステークホルダに基づいて対策を提供するためのベストプラクティスとプロセスを提供する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

発⾒者に報告された脆弱性に対一部担当者が[4.2.1.4]根本原因[4.2.1.2]影響を受ける製品、バ[4.2.1]報告された脆弱性に対し[4.2.1]報告された脆弱性に対しする対策分析と緩和、修正プログ分析するために、[4.2.1.1]品質ージョン、ステークホルダ、およて脆弱性の認定基準、影響を受けて脆弱性の認定基準、影響を受け

ラムを提供する前の回避策を検ゲートまたはバグバースに対しび同時に修正する必要のあるバ

るバージョンの調査⽅法、原因分るバージョンの調査⽅法、原因分討することに必要性を感じていて脆弱性報告やインシデントをリエーションを特定し、析や回避⽅法の検討についてプ

析や回避⽅法の検討についてプない。

検証するとともに、[4.2.1.5]脆[4.2.1.3]関連するサポート契約

ロセスが定められており、安定的ロセスが定められており、案件の弱性を拒否するなどの対応を⾏

及びモデルを確認している。

に対応できる。[4.2.2]対策の決対応ごとに振り返りが⾏われ継っている。

[4.2.1.6]対策分析として、ある定について、最終決裁者や検討プ

続的に改善されている。[4.2.2]

脆弱性が原因で発生するリスク

ロセスが定められており、安定し対策の決定について、最終決裁者を軽減または対策する⽅法を特た運⽤ができる。[4.2.3]対策のや検討プロセスが定められてお定している。また、[4.2.2.1]影

公開⽅法が定められており、安定り、プロセスが継続的に改善され響を受けた全ての製品バージョ

運⽤できる。

ている。[4.2.3]対策の公開⽅法

ンで、報告されてすべての脆弱性が定められており、継続的に改善が対策されていることを確認しされている。

ている。

21

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 4/ 対策
4.3 インシデントハンドリング
目的︓ 深刻な脆弱性を管理するための計画を策定し、それに対処するために必要なすべてのリソースを動員する能⼒を開発する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

インシデント（ゼロディ攻撃、意一部の担当者がインシデントのインシデントの発生を内部ステ[4.3.1.3]インシデント対応計画[4.3.1.4]インシデント発生時の図しない脆弱性の開示など）が発発生を想定し[4.3.2.1]インシデ

ークホルダは認識しておりが定められており、ステークホル

トレーニングや、机上訓練の結果生することを想定しておらず、発ントに関連する情報を収集して[4.3.1.2]役割分担、責任の割り

ダに周知されている。[4.3.1.4]をもとに改善が進んでいる。ま生した場合の対応計画や役割分

おり、[4.3.1.4]役割分担や責任当てが実施されている。

インシデント発生時のトレーニた、業界で発生したインシデント

担、責任の割り当てが⾏われていの割り当てを検討している。

[4.3.1.3]インシデント対応計画

ングや、机上訓練が実施されてい事例を分析し、⾃社で同様の事例は策定されているが、[4.3.1.4]

る。

が発生した場合のため、インシデない。

インシデント発生時のトレーニント対応計画やトレーニング内

ングや、机上訓練などは⾏われて容を改善している。

いない。

22

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 4/ 対策
4.4 脆弱性リリースメトリクス
目的︓ 管理レポート⽤に定期的にデータを収集する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

PSIRT の運⽤レポートやインシ

一部の担当者が PSIRT 活動に関組織として PSIRT の運⽤状況

以下の項目を例とする PSIRT 評

PSIRT の運⽤レポートやインシ

デント対応能⼒をステークホル

する運⽤状況を分析、公開するこや、インシデント対応能⼒を計測

価⽅法を定め、定期的に報告してデント対応能⼒に関するレポー

ダに開示する必要性を認識してとの必要性を感じ、情報の収集とする必要性を感じ、一部は経営層いる。

トを分析、報告しステークホルダ

おらず、公開していない。

公開を実施している。

向けに報告を⾏っている。

・[4.4.1.1]報告された脆弱性数のフィードバックを受けて、レポと確認された脆弱数（製品／事業ートの改善および PSIRT の⽅針単位別）に反映させるなどを実施してい・[4.4.1.2]確認された脆弱性のる。

サードパーティコンポーネントによる分類
・[4.4.1.3]確認された脆弱性の
CWE による分類（製品／事業単位別）
・[4.4.2.5]インシデントの数
・[4.4.2.3]対策状況の追跡

23

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 5/ 脆弱性の開示
5.1 通知目的︓ 連携活動を通じ、ベンダと発⾒者に対して透明性を確保する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

適切な通知のプロセスを決定

一部の担当者は、ステークホル

製品に関する脆弱性が発⾒され製品に関する脆弱性が発⾒され脆弱性が発⾒された場合の通知

し、対策⽅法、修正、回避策にダに対する対策⽅法などの適切た場合に、さまざまなステークた場合に、ステークホルダへのポリシーが定められ、通知され関する情報をタイムリーにステな時期に情報を開示する必要性

ホルダへの通知が重要であるこ

通知時期や、通知内容がポリシたあとの振り返りや分析が⾏わークホルダに提供することの重を感じており、情報を開示するとは、組織として認識しているーとして定められており、適切れ、通知⽅法、通知内容の改善

要性が認識されておらず、何もなどの対応を⾏っている。

が、対応は場当たり的に対応さに通知されている。

サイクルが機能している。

情報を開示していない。

れており、常に実施されるとは
限らない。

24

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 5/ 脆弱性の開示
5.2 調整目的︓ 修正によって取り除かれた脆弱性を説明する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

PSIRT は潜在的な脆弱性を報告

一部の担当者は[5.2.1.1]第三者組織として、発⾒者への情報提供[5.2.1]発⾒者とのコミュニケー[5.2.1]発⾒者とのコミュニケー

する発⾒者の目的、意図やスタンの発⾒者から脆弱性レポートを

および、情報開示時期をステーク

ションおよび[5.2.2]複数ベンダ

ションおよび[5.2.2]複数ベンダスを理解し、合意された日程にて受領したことを報告することや、 ホルダと調整することの重要性間の調整についてプロセスが定間の調整について、案件の対応ご責任ある情報開示を推進・促進す[5.2.1.2]報告された脆弱性に関を認識し、[5.2.1.3]発⾒者に修められており、継続して実施できとに振り返りが⾏われ、常に改善ることが重要であることを認識する対応状況を発⾒者に対して正を提供し、検証を可能にするこる体制になっている。

しながらスピーディに対応をすしていない。

定期的に通知することなど、双⽅とや、[5.2.1.4]脆弱性を報告し的なコミュニケーションが必要

た発⾒者の貢献を認め、謝辞を述であることを認識し、活動をしてべること[5.2.2.2]影響を受けるいる。

ベンダの特定をするなどの対応

また、脆弱性情報の開示についてを開始している。

ることが可能となっている。

ステークホルダ間の調整が必要であることを認識し、一部実施を始めている。

25

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 5/ 脆弱性の開示
5.3 情報開示
目的︓ アップデートに含まれるセキュリティ関連の修正内容を提示する。

ティア 0

ティア 1 (Repeatable)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

セキュリティアップデートをリ

一部の担当者は、セキュリティア

組織として、脆弱性情報の公開の脆弱性情報の開示プロセス・テン

脆弱性情報の開示について、案件リースする際、ステークホルダやップデートをリリースする際に、 必要性を認識し、すべてのプロダ

プレートが定められており、リリごとに振り返りが⾏われるなど

ベンダにその内容が正しく伝わステークホルダに情報を開示す

クトで、リリースノートやセキュースノート、アドバイザリ、ナレ

常に改善のためのプロセスが存るよう、適切な情報開示をするこる必要性を認識し、リリースノー

リティアドバイザリ、ナレッジベ

ッジベースが公開プロセスに従在し、事案や状況に応じて適切にとが重要であることを認識してトやセキュリティアドバイザリ、 ースで脆弱性情報に関する情報って公開されている。[5.3.1.3]

素早く対応できる体制となっておらず、実施していない。

ナレッジベースに脆弱性に関すを公開している。

脆弱性情報の公開には承認プロいる。

る情報を公開している。

ま た [5.3.2.6] 発 ⾒ 者 へ の 謝 辞セスがあり、[5.3.2.6]発⾒者へや、[5.3.2.5]CVE 番号の割り当の謝辞、[5.3.2.5]CVE 番号の取てなどが一部実施されている。

得についてもプロセス化されている。

26

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 5/ 脆弱性の開示
5.4 脆弱性情報マネジメントの評価指標
目的︓ 経営層への報告のために定期的にデータを収集する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

脆弱性情報の公開に関する指標一部の担当者は、脆弱性情報の公組織として、脆弱性情報の公開に

脆弱性情報の公開に関する指標

脆弱性情報の公開に関する指標を取り、経営層へ報告する必要性

開に関する指標を策定し、経営層関する指標の必要性が認識され、 の作成がプロセス化され、アドバの作成がプロセス化され、アドバを感じておらず、実施していなに報告する必要性を感じており、 アドバイザリの公開数、プロダク

イザリ公開数、プロダクトごとのイザリ公開数、プロダクトごとのい。

セキュリティアドバイザリの公

トごとの公開された脆弱性件数

公開件数、アドバイザリの閲覧状

公開件数、アドバイザリの閲覧状

表数などを作成し、報告したこと

や、アドバイザリの閲覧件数など

況などが定期的に報告されてい況などが定期的に報告されて、経がある。

が報告されている。

る。

営判断に関わる指標として活⽤され、さまざまな指標を取得する
ための改善がされている。

27

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 6/ トレーニングと教育
6.1 PSIRT のトレーニング
目的︓ PSIRT スタッフはセキュリティの世界で起こっていることの最前線にいる必要がある。この幅広い知識は主要なセキュリティ認定で示されているように、一般的なセキュリティトピックを理解し、確固たる基礎を築き上げる必要がある。セキュリティに焦点を当てたカンファレンスや業界コンソーシアムへの関与、ブログ、広報、コンソーシアムの出版物、熱心な一消費者として業界全体に対する認識を持つことなど、これらによって更新をしていく必要がある。また、PSIRT のメンバーはセキュリティとプ
ライバシーに関する法律について、世界で絶え間なく変化していることも認識する必要がある。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

PSIRT が、常に変化する脅威環

一部の担当者はセキュリティト

組織として PSIRT 担当者のトレ

PSIRT のトレーニングについて

PSIRT のトレーニングポリシー境に追従していく必要性を感じ

ピックを理解し、必要なトレーニーニングの必要性を理解し、予算ポリシーがあり、トレーニングメが定められており、外部環境の変ておらず、トレーニングは⾏われングを受けているが、トレーニンが組み込まれている。が、トレーニューが決められている。トレー化（法規制や顧客の意識の変化なていない。

グ内容や受講者について計画性

ニング内容については、ポリシー

ニングの内容には、[6.1.1.]技術ど）に応じて、トレーニング内容はない。

がなく、トレーニング内容がバラ的なトレーニング（攻撃手法、ツが⾒直され、適時必要なトレーニ

バラになっている。

ール、法規制や認証、プライバシングを実施できる体制となってー法など）[6.1.2]コミュニケー

いる。

ショントレーニング、[6.1.3]プ
ロセスに関するトレーニング、[6.1.4]タスクツールに関する
トレーニングが含まれる。

28

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 6/ トレーニングと教育
6.2 開発チームのトレーニング
目的︓ セキュアなコードを記述でき、文書化されたセキュリティガイドラインを使⽤して開発を⾏い、製品のアーキテクチャと設計を作成する適切なセキュア開発ライフサ
イクル(SDL)プログラムを組織に奨励する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

開発チームは、セキュア開発が最開発の一部のメンバーは、PSIRT

組織として、開発メンバーが、開発チームに対し PSIRT プロセ

開発チームに対し PSIRT プロセ

適化すれば、⾃社製品がすでに市プロセスがなぜ存在するのか、どPSIRT プロセスがなぜ存在する

スをトレーニングすることがポスをトレーニングすることがポ場にリリースされた後のセキュのように機能するのか、そしてのか、どのように機能するのか、 リシーとして定められており、定リシーとして定められており、ト

リティ対応に比べてはるかに安PSIRT プロセスを支援するため

そして PSIRT プロセスを支援す

期的にトレーニングが実施されレーニングが実施され、開発チー

価であることを認識していない。 の製品開発としてなにをする必るための製品開発としてなにをている。

ムが PSIRT プロセスに対し協⼒要があるのかを理解している。

する必要があるのかを理解してして、PSIRT 活動をスムーズにいる必要があると認識している。

実施できる体制となっている。

29

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 6/ トレーニングと教育
6.3 診断チームのトレーニング
目的︓ 組織が、適切なセキュリティテストツールの特定を含む、適切なセキュア開発ライフサイクルプログラムを持つことを奨励する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

診断チームは、診断が最適化すれ

診断チームの一部のメンバーは、 組織として、診断チームのメンバ

診断チームに対し PSIRT プロセ

診断チームに対し PSIRT プロセ

ば、⾃社製品がすでに市場にリリ

PSIRT プロセスがなぜ存在する

ーが、PSIRT プロセスがなぜ存スをトレーニングすることがポスをトレーニングすることがポースされた後のセキュリティ対のか、どのように機能するのか、 在するのか、どのように機能する

リシーとして定められており、定リシーとして定められており、ト応に比べてはるかに安価である

そして PSIRT プロセスを支援すのか、そして PSIRT プロセスを期的にトレーニングが実施されレーニングが実施され、開発チーことを認識していない。

るための製品開発としてなにを支援するための製品開発としてている。

ムが PSIRT プロセスに対し協⼒する必要があるのかを理解してなにをする必要があるのかを理して、PSIRT 活動をスムーズにいる。

解している必要があると認識し実施できる体制となっている。

ている。

30

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 6/ トレーニングと教育
6.4 すべてのステークホルダへの継続的な教育
目的︓ すべてのステークホルダグループが、PSIRT プログラムでの役割を果たすため、必要な訓練または基本的な意識を持っていることを確認する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

PSIRT は、内部ステークホルダ

PSIRT の一部のメンバーは、内組織として PSIRT プロセスのト

内部ステークホルダへのトレー

すべてのステークホルダは、への PSIRT プロセスのトレーニ部ステークホルダへの PSIRT プ

レーニングの必要を認識し、法ニングはポリシーとして定めら

PSIRT プログラムの一定レベルングの必要性を認識しておら

ロセスのトレーニングが必要で務、リスク管理部門、マーケテ

れ、定期的にトレーニングが⾏の訓練と理解について標準が設ず、実施されていない。

あることを理解し、経営層向け

ィング部門、広報、サポート、われている。

けられ、その内容は定期的に⾒への PSIRT プロセスのトレーニ営業部門に対するトレーニング

ングを実施している。

を実施し始めている。

直されている。

31

PSIRT Services Framework Ver 1.0 に基づくプロダクト脆弱性対策・対応成熟度シート
サービスエリア 6/ トレーニングと教育
6.5 フィードバック機能の提供
目的︓ セキュリティ業界の急速な変化に対応し、維持し続けるために継続的にトレーニングを改善する。

ティア 0

ティア 1 (Partial)

ティア 2 (Risk Informed)

ティア 3 (Repeatable)

ティア 4 (Adaptive)

インシデントの根本原因の分析

インシデントの根本原因についインシデントの根本原因についインシデントの根本原因についインシデントの根本原因についで得られた情報を使って、類似のて、類似のインシデントが発生して、類似のインシデントが発生して、類似のインシデントが発生して、類似のインシデントが発生し脆弱性インシデントが発生しなないための取り組みが必要であないための取り組みの必要性をないための取り組みがポリシーないための取り組みがポリシー

いようにする取り組みの必要性

ることを一部の担当者が認識し、 組織として認識し、情報共有が⾏として定められ、情報共有の⽅として定められ、取り組みの内容を感じておらず、対応していな活動をしている。

法、ツールが統一され、継続的にが日常的に改善され、情報共有す実施されている。

ることが組織の文化となっていい。

われている。

る。

32