特許 7597443 セキュリティ管理システム、セキュリティ管理方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-12-02

(45)【発行日】2024-12-10

(54)【発明の名称】セキュリティ管理システム、セキュリティ管理方法、及びプログラム

(51)【国際特許分類】

   G06F 21/57 20130101AFI20241203BHJP

【ＦＩ】

G06F21/57 370

【請求項の数】 8

(21)【出願番号】P 2023142902

(22)【出願日】2023-09-04

【審査請求日】2023-09-04

(73)【特許権者】

【識別番号】399035766

【氏名又は名称】エヌ・ティ・ティ・コミュニケーションズ株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】西野 卓也

(72)【発明者】

【氏名】志村 正樹

【審査官】上島 拓也

(56)【参考文献】

【文献】特開２０１５－１３８５０９（ＪＰ，Ａ）

【文献】特開２０１５－１９１３９０（ＪＰ，Ａ）

【文献】国際公開第２０１９／１８１９７９（ＷＯ，Ａ１）

【文献】中国特許出願公開第１１６６８１１３１（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／５７

(57)【特許請求の範囲】

【請求項1】

サービスを構成する部品であるアーティファクトと、前記アーティファクトのマネージャとを識別するタグを管理するアーティファクト管理装置と、
特定のアーティファクトについての前記タグと、前記特定のアーティファクトについてのセキュリティ情報とを特定の装置へ通知するセキュリティ情報通知装置と、を備え、
前記アーティファクトがソフトウェア部品である場合において、前記タグは、前記アーティファクトの名前、前記アーティファクトの格納場所、及び、パッケージマネージャを連結した情報であり、
前記アーティファクトがハードウェア部品である場合において、前記タグは、前記アーティファクトの名前、前記アーティファクトを提供する会社の名前、及び、リソースマネージャを連結した情報である
セキュリティ管理システム。

【請求項2】

前記セキュリティ管理システムは、セキュリティ情報管理装置を更に備え、
前記セキュリティ情報通知装置は、前記アーティファクト管理装置から監視対象として通知された前記特定のアーティファクトについての前記タグと、前記セキュリティ情報管理装置から通知された１以上のセキュリティ情報とのマッチング処理を行うことにより、前記特定のアーティファクトについての前記セキュリティ情報を抽出する
請求項１に記載のセキュリティ管理システム。

【請求項3】

前記セキュリティ情報通知装置は、前記セキュリティ情報管理装置から通知された、マネージャが指定されないセキュリティ情報に対し、マネージャが指定されたタグを１又は複数個マッチングさせる
請求項２に記載のセキュリティ管理システム。

【請求項4】

前記セキュリティ情報通知装置は、前記セキュリティ情報管理装置から通知された、マネージャが指定されたセキュリティ情報に対し、当該マネージャが指定されたタグをマッチングさせる
請求項２に記載のセキュリティ管理システム。

【請求項5】

前記特定の装置は、チケット管理装置であり、当該チケット管理装置は、前記セキュリティ情報通知装置から受信するタグとセキュリティ情報に基づいてセキュリティチケットを生成し、当該セキュリティチケットをサービス開発チームへ通知する
請求項１ないし４のうちいずれか１項に記載のセキュリティ管理システム。

【請求項6】

前記アーティファクト管理装置は、管理する複数のタグに基づいて、マネージャの統計情報を算出する
請求項１ないし４のうちいずれか１項に記載のセキュリティ管理システム。

【請求項7】

アーティファクト管理装置とセキュリティ情報通知装置とを備えるセキュリティ管理システムにおいて実行されるセキュリティ管理方法であって、
前記アーティファクト管理装置は、サービスを構成する部品であるアーティファクトと、前記アーティファクトのマネージャとを識別するタグを管理し、
前記アーティファクト管理装置が、特定のアーティファクトについての前記タグを前記セキュリティ情報通知装置に通知し、
前記セキュリティ情報通知装置が、前記特定のアーティファクトについての前記タグと、前記特定のアーティファクトについてのセキュリティ情報とを特定の装置へ通知するセキュリティ管理方法であり、
前記アーティファクトがソフトウェア部品である場合において、前記タグは、前記アーティファクトの名前、前記アーティファクトの格納場所、及び、パッケージマネージャを連結した情報であり、
前記アーティファクトがハードウェア部品である場合において、前記タグは、前記アーティファクトの名前、前記アーティファクトを提供する会社の名前、及び、リソースマネージャを連結した情報である
セキュリティ管理方法。

【請求項8】

コンピュータを、請求項１ないし４のうちいずれか１項に記載のセキュリティ情報通知装置として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、セキュリティに関する情報を管理するための技術に関連するものである。

【背景技術】

【0002】

サイバーセキュリティ対策のために、セキュリティに関する情報（脆弱性情報、サイバーリスク情報、サイバー脅威インテリジェンスなど）を利用することがある。例えば、脆弱性情報を利用したパッチマネジメントがサイバーセキュリティ対策の一例として存在する。

【0003】

サービス開発チームとセキュリティ対策チームが分かれている場合、サイバーセキュリティ対策のために「セキュリティに関する情報の通知」、「通知に基づくセキュリティ対策の実施」、「セキュリティ対策の実施状況の把握」のプロセスが必要になる。

【0004】

それらのプロセスをうまく動作させるための手法の１つとして、ソフトウェア部品表（SBOM：Software Bill Of Materials）を用いたサイバーセキュリティ対策が考案されている。例えば脆弱性管理の場合、SBOMを利用することで、サービス開発チームが開発するソフトウェアに関係のある脆弱性情報だけの通知を行うことができる。

【先行技術文献】

【特許文献】

【0005】

【文献】特開2016-218964号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかし、SBOMを用いたサイバーセキュリティ対策では、ソフトウェア部品だけに注目し、そのソフトウェア部品の使われ方に関する背景情報には注目していない。そのため、問題のある箇所が明らかになっても、サービス開発チームがサービス上の対処優先度やオペレーションコストを判断できないという課題がある。セキュリティに関する情報の通知を適切に行うことができない場合、セキュリティ対策の実施、及び、対策実施状況の把握のいずれも適切に行うことができないため、サービス開発チーム固有のコンテキストを各チーム自身で調査して補完する追加作業が必要になる。

【0007】

本発明は上記の点に鑑みてなされたものであり、セキュリティ対策において、セキュリティに関する情報の通知を適切に行うことを可能とする技術を提供することを目的とする。

【課題を解決するための手段】

【0008】

開示の技術によれば、サービスを構成する部品であるアーティファクトと、前記アーティファクトのマネージャとを識別するタグを管理するアーティファクト管理装置と、
特定のアーティファクトについての前記タグと、前記特定のアーティファクトについてのセキュリティ情報とを特定の装置へ通知するセキュリティ情報通知装置と、を備え、
前記アーティファクトがソフトウェア部品である場合において、前記タグは、前記アーティファクトの名前、前記アーティファクトの格納場所、及び、パッケージマネージャを連結した情報であり、
前記アーティファクトがハードウェア部品である場合において、前記タグは、前記アーティファクトの名前、前記アーティファクトを提供する会社の名前、及び、リソースマネージャを連結した情報である
セキュリティ管理システムが提供される。

【発明の効果】

【0009】

開示の技術によれば、セキュリティ対策において、セキュリティに関する情報の通知を適切に行うことを可能とする技術が提供される。

【図面の簡単な説明】

【0010】

【図1】本発明の実施の形態におけるセキュリティ管理システムの全体構成例を示す図である。

【図2】アーティファクトタグの例を示す図である。

【図3】セキュリティ管理システムの動作概要を説明するための図である。

【図4】セキュリティ管理システムの動作概要を説明するための図である。

【図5】セキュリティ管理システムの処理シーケンスを示す図である。

【図6】マッチングの例を説明するための図である。

【図7】マッチングの例を説明するための図である。

【図8】マッチングの例を説明するための図である。

【図9】マッチングの例を説明するための図である。

【図10】セキュリティ管理システムの処理シーケンスを示す図である。

【図11】セキュリティ管理システムの処理シーケンスを示す図である。

【図12】アーティファクト管理装置１００の機能構成例を示す図である。

【図13】セキュリティトピック管理装置２００の機能構成例を示す図である。

【図14】セキュリティアラート通知装置３００の機能構成例を示す図である。

【図15】チケット管理装置４００の機能構成例を示す図である。

【図16】装置のハードウェア構成例を示す図である。

【発明を実施するための形態】

【0011】

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

【0012】

以下では、本実施の形態の技術に関わる課題を詳細に説明し、その後に、本実施の形態に係る技術を説明する。

【0013】

（課題について）
SBOMを用いたサイバーセキュリティ対策では、大きく分けて次の２つの課題が存在する。

【0014】

（１）ソフトウェア部品だけに注目することで、部品管理のコンテキストが消失してしまう。

【0015】

（２）サービスを構成する部品として、ソフトウェア部品以外のものが存在する場合があるが、SBOMではソフトウェア部品以外のものを管理できない。

【0016】

上記の２つの課題に関連して、「セキュリティに関する情報の通知」、「通知に基づくセキュリティ対策の実施」、「セキュリティ対策の実施状況の把握」という３つのプロセスに関しての、それぞれの課題について説明する。

【0017】

まず、（１）についての課題を説明する。

【0018】

前述したように、SBOMではソフトウェア部品だけに注目しているので、ソフトウェア部品管理（パッケージマネージャ）のコンテキストが消失する。具体的には下記のとおりである。

【0019】

ソフトウェア部品の実体はソフトウェアパッケージやライブラリである。ソフトウェアパッケージやライブラリ自体も、他のソフトウェア部品に依存して配布されることがあり、ソフトウェア部品のインストールやアンインストールには、その依存関係を解決する方法が必要になる。

【0020】

依存関係を自動で解決するために、ソフトウェア部品管理には「パッケージマネージャ」を利用することがサービス開発では一般的である。しかし、SBOMを用いたサイバーセキュリティ対策では、ソフトウェア部品だけに注目し、マネージャの情報を通知には利用しない。これにより、以下のような課題が生じる。

【0021】

・セキュリティに関する情報の通知について：
依存関係の解決はマネージャ固有の事象であり、マネージャを特定できない場合、ソフトウェア部品の状態が一意に定まらない場合がある。これは、インストールされる依存ライブラリのバージョンや種類、利用されるオプション自体がマネージャによって異なる場合が存在するためである。

【0022】

・通知に基づくセキュリティ対策の実施について：
マネージャ情報が欠落することによって、セキュリティ対策において操作対象となるマネージャの情報が欠落することになる。サービス開発者が複数のマネージャを利用している場合、ソフトウェア部品がどのマネージャによって管理されているのかを特定してから、そのマネージャ経由での操作（バージョン更新など）が必要になるため、手間が増える。

【0023】

・セキュリティ対策の実施状況の把握について：
ソフトウェア部品が存在することはSBOMだけで把握できるが、マネージャ情報がない場合、ソフトウェア部品の管理プロセスが不明確になる。例えばインストールプロセスにおいて、マネージャが原因で脆弱なソフトウェア部品がインストールされていた場合、その原因特定が困難になる場合がある。マネージャの情報を収集することで、ソフトウェア部品の管理プロセスを考慮したセキュリティリスク分析が実施できるようになる。

【0024】

次に、（２）についての課題を説明する。

【0025】

前述したように、サービスを構成する部品として、ソフトウェア部品以外のものが存在する場合がある。例えばNWサービスの場合、トラフィック制御にNWアプライアンスを配置し、それをソフトウェア制御するサービス構成が存在するが、SBOMを用いたサイバーセキュリティ対策ではこのサービスを完全にカバーすることができない。特に脆弱性情報は、ソフトウェア部品単位ではなく販売されている製品単位で情報が公開されることも多く、ソフトウェア部品だけでなく専用アプライアンスなども網羅的にカバーできるシステムが必要である。

【0026】

また、ソフトウェア部品以外のものを管理する場合においても、部品管理のコンテキストが消失してしまうという課題は同様に発生する。

【0027】

（実施の形態の概要）
本実施の形態に係る技術の主要な部分として下記の（１）～（４）を説明する。

【0028】

（１）本実施の形態では、サービスを構成する部品は「アーティファクト」という単位で管理される。従来であればソフトウェア部品しか対応できなかったが、これによってハードウェア製品などもソフトウェア部品と同様に管理できるようになる。

【0029】

（２）マネージャ情報を含むアーティファクトの管理が行われる。従来であれば、ソフトウェア部品のマネージャ情報は消失していたが、本実施の形態では、マネージャ情報は消失しない。また、マネージャ情報を利用してソフトウェア部品の管理プロセスに対するリスク分析を行うことも可能である。

【0030】

（３）本実施の形態では、マネージャ情報を含むアーティファクトを利用したセキュリティ情報管理が行われるとともに、セキュリティアラートの通知が行われる。従来であればソフトウェア部品へのアラート通知しかできなかったが、本実施の形態では、ハードウェア製品なども含めたセキュリティアラートを通知できるようになる。また、アーティファクトだけでなく、アーティファクトとマネージャの組み合わせで生じる問題も通知できるようになる。

【0031】

（４）本実施の形態では、マネージャ情報を含むアーティファクトを利用したチケット管理を行うことができる。従来であれば、セキュリティ対策の実施プロセスで、操作対象のマネージャを再度調べる必要があったが、本実施の形態では、その確認作業の手間を減らすことができる。

【0032】

（セキュリティ管理システムの全体構成例）
図１に、本実施の形態におけるセキュリティ管理システムの全体構成例を示す。図１に示すように、本実施の形態におけるセキュリティ管理システムは、アーティファクト管理装置１００、セキュリティトピック管理装置２００、セキュリティアラート通知装置３００、及びチケット管理装置４００を有し、これらがネットワーク５００に接続されている。セキュリティトピック及びセキュリティアラートはいずれもセキュリティ情報の例であるので、セキュリティトピック管理装置２００、セキュリティアラート通知装置３００をそれぞれセキュリティ情報管理装置２００、セキュリティ情報通知装置３００と呼んでもよい。

【0033】

ネットワーク５００には、複数の端末１０が接続されており、各端末１０から、ネットワーク５００を介して、アーティファクト管理装置１００、セキュリティトピック管理装置２００、セキュリティアラート通知装置３００、及びチケット管理装置４００のいずれにもアクセス可能である。各端末１０は、サービス開発チームの端末、セキュリティ対策チーム（例えばセキュリティ担当者）の端末などである。

【0034】

（アーティファクト、マネージャについて）
本実施の形態におけるアーティファクト、及びマネージャについて説明する。本実施の形態では、サービスを構成する部品をアーティファクトと呼ぶ。アーティファクトはソフトウェア部品であってもよいし、ハードウェア部品であってもよい。

【0035】

アーティファクトを識別する情報をアーティファクトタグと呼ぶ。アーティファクトタグの例を図２に示す。

【0036】

図２に示すように、本実施の形態におけるアーティファクトタグは、アーティファクトの名前（Artifact Name）、アーティファクトの格納場所（Artifact Registry）、及び、アーティファクトマネージャ（Artifact Manager）を連結した情報である。なお、これらの情報の実態は、例えばKey:Value構成をとる情報である。

【0037】

なお、アーティファクトマネージャ（Artifact Manager）がなく、アーティファクトの名前（Artifact Name）とアーティファクトの格納場所（Artifact Registry）からなる情報もアーティファクトタグと呼ぶ。アーティファクトタグを単にタグあるいは関連タグと呼ぶ場合もある。以下では、アーティファクトマネージャをマネージャと呼ぶ。

【0038】

図２に示す例では、アーティファクトはyaml（ソフトウェア部品の例）であり、格納場所はnpm（パッケージレジストリの例）であり、マネージャはnpm（パッケージマネージャの例）である。

【0039】

本実施の形態におけるマネージャには、大きくわけて、パッケージマネージャとリソースマネージャの二種類が存在する。

【0040】

パッケージマネージャは、ソフトウェア部品を管理するマネージャである。ソフトウェア部品としては、OSライブラリ、言語ライブラリなどがある。パッケージマネージャは、アーティファクトのバージョン管理、及びアーティファクトの依存関係解決などを行う。

【0041】

言語ライブラリの管理を行う言語パッケージマネージャの例としては、JavaScript（登録商標）のパッケージマネージャ（例：npm, yarn）、及び、Python（登録商標）のパッケージマネージャ（例：pipenv, poetry）などがある。

【0042】

OSライブラリの管理を行うOSパッケージマネージャの例としては、Ubuntu（登録商標）のパッケージマネージャ（例：apt）、及びFedora（登録商標）のパッケージマネージャ（例：dnf）などがある。なお、アーティファクトがＯＳである場合には、アーティファクトタグにおいてマネージャを省略してもよい。

【0043】

リソースマネージャは、ソフトウェア部品以外の部品であるハードウェア部品（ＮＷアプライアンスなど）を管理するマネージャである。リソースマネージャは、アーティファクトのバージョン管理、及びメトリクスの取得などを行う。リソースマネージャとして例えばモニタリングツールが使用される。リソースマネージャの例として、NetBox、Zabbix（登録商標）などがある。

【0044】

アーティファクトがハードウェア部品である場合も、ソフトウェア部品の場合と同様に、アーティファクトタグは、「uuu:vvv:www」の形をとる。uuuは、Artifact Nameであり、vvvはArtifact Registryであり、wwwはArtifact Managerである。ただし、アーティファクトがハードウェア部品である場合、vvvは、例えば、当該アーティファクトを提供する会社の名前とする。例えば、uuuは、NW機器の製品名、vvvは、当該NW機器のベンダ名、wwwは、NW機器の監視を行うモニタリングツールの名前である。

【0045】

また、アーティファクトがハードウェア部品である場合、タグをCPE (共通プラットフォーム一覧)と組み合わせることで、アプライアンスの脆弱性を早期に識別可能である。また、例えば、NVDが公開する脆弱性情報に含まれるCPE情報から、タグを生成してもよい。例えば、NVDが公開する脆弱性情報に含まれるCPE情報に、ベンダ名としてvvvが含まれ、製品名としてuuuが含まれる場合において、マネージャがwwwであるとすると、当該CPE情報から「uuu:vvv:www」を生成することが可能である。この生成処理は、例えばアーティファクト管理装置１００が行う。

【0046】

（セキュリティ管理システムの動作概要）
図３、図４を参照して、セキュリティ管理システムの動作概要を説明する。図３，図４には、説明の便宜上、装置のブロックの中に、当該装置が管理する情報（あるいは当該装置が端末に通知する情報）が示されている。

【0047】

本実施の形態のセキュリティ管理システムは、ソフトウェア部品とハードウェア部品のいずれも管理可能であるが、説明を分かり易くするために、図３では、ソフトウェア部品の管理に着目して説明を行い、図４では、ハードウェア部品（NWアプライアンスなど）に着目して説明を行う。

【0048】

まず、図３を参照して、ソフトウェア部品に関しての動作概要を説明する。図３に示すように、アーティファクト管理装置１００は、提供するサービスに含まれるあらゆるソフトウェア部品についてのアーティファクトタグを保存する。ここでは、アーティファクトタグとして「xxx:yyy:zzz」に着目する。

【0049】

セキュリティトピック管理装置２００は、会社横断的に提供される「脆弱性情報、リスク情報、サイバー攻撃情報など」のデータを保存する。「脆弱性情報、リスク情報、サイバー攻撃情報など」をセキュリティ情報と呼んでもよい。図３の例では、セキュリティトピック管理装置２００は、特定のソフトウェア部品である「xxx:yyy:」についての脆弱性情報と、特定マネージャ（zzz）で管理されるソフトウェア部品である「xxx:yyy:zzz」についてのリスク情報を保持している。「TO:」は、それが指すアーティファクトの開発チーム宛であることを表す。

【0050】

図３のＳ１０１において、アーティファクト管理装置１００は、サービス開発チームが所有するアーティファクト（ここではソフトウェア部品）をマネージャと共にセキュリティアラート通知装置３００に対して監視登録のために通知する。ここでは、「xxx:yyy:zzz」が通知されたものとする。

【0051】

また、Ｓ１０２において、セキュリティトピック管理装置２００は、セキュリティアラート通知装置３００に対して、セキュリティリスクのあるソフトウェア部品の情報（セキュリティトピックあるいはセキュリティアクション）を通知する。当該情報に対し、マネージャの条件付けが可能である。ここでは、「xxx:yyy:」と、その脆弱性情報、及び、「xxx:yyy:zzz」と、そのリスク情報が通知されたものとする。「xxx:yyy:zzz」は、zzzという特定のマネージャで管理されるxxx:yyyについてリスクがあることを示している。

【0052】

Ｓ１０３において、セキュリティアラート通知装置３００は、マッチング処理されたセキュリティアラートをチケット管理装置４００に通知する。

【0053】

具体的には、セキュリティアラート通知装置３００は、アーティファクト管理装置１００から通知された「xxx:yyy:zzz」と、脆弱性情報の「xxx:yyy:」とのマッチング、及び、アーティファクト管理装置１００から通知された「xxx:yyy:zzz」と、リスク情報の「xxx:yyy:zzz」とのマッチングを行うことで、当該脆弱情報と当該リスク情報が、監視対象のソフトウェア部品についてのセキュリティ情報（アラート発出対象となる情報）であることを特定する。

【0054】

そして、セキュリティアラート管理装置３００は、「xxx:yyy:zzz」についてのセキュリティアラートとして、「xxx:yyy:」と、その脆弱性情報、及び、「xxx:yyy:zzz」と、そのリスク情報をチケット管理装置４００に通知する。

【0055】

チケット管理装置４００は、セキュリティアラート通知装置３００からセキュリティアラートを受け取って、ソフトウェア部品ごとに問題をチケットで管理する。また、チケット管理装置４００は、セキュリティアラートの対象であるアーティファクトの情報（マネージャの情報を含む）とタグを含むセキュリティチケットを生成し、セキュリティチケットをアーティファクトのサービス開発チームへ通知する。この通知により、サービス開発チームの端末にセキュリティチケットの表示がなされる。

【0056】

チケット管理装置４００は、ソフトウェア部品の管理ラベルのフォーマットとして、マネージャの情報が付帯したフォーマットを使用可能である。

【0057】

図３に示す具体例では、チケット管理装置４００は、セキュリティアラート通知装置３００から受信したセキュリティアラートに基づいて、「xxx:yyy:zzz」に関するセキュリティチケットとして、図３に示すように、脆弱性に対する対策、及びセキュリティリスクに対する対策を記載したセキュリティチケットを生成し、当該セキュリティチケットの通知及び管理を行う。

【0058】

次に、図４を参照して、ハードウェア部品に関しての動作概要を説明する。図４に示すように、アーティファクト管理装置１００は、提供するサービスに含まれるあらゆる部品（ソフトウェア部品、専用ハードウェア部品を含む）についてのアーティファクトタグを保存している。ここでは、アーティファクトタグとして「uuu:vvv:www」に着目する。「uuu:vvv:www」はハードウェア部品（例：NWアプライアンス）についてのアーティファクトタグである。

【0059】

セキュリティトピック管理装置２００は、会社横断的に提供される「脆弱性情報、リスク情報、サイバー攻撃情報など」のデータを保存する。「脆弱性情報、リスク情報、サイバー攻撃情報など」をセキュリティ情報と呼んでもよい。図４の例では、セキュリティトピック管理装置２００は、特定のNWアプライアンスである「uuu:vvv:」についての脆弱性情報と、特定リソースマネージャ（www）で管理される当該NWアプライアンスを示す「uuu:vvv:www」についてのリスク情報を保持している。

【0060】

図４のＳ１０１において、アーティファクト管理装置１００は、サービス開発チームが所有するアーティファクト（ここではハードウェア部品に着目）をマネージャと共にセキュリティアラート通知装置３００に対して監視登録のために通知する。ここでは、「uuu:vvv:www」が通知されたものとする。

【0061】

また、Ｓ１０２において、セキュリティトピック管理装置２００は、セキュリティアラート通知装置３００に対して、セキュリティリスクのあるアーティファクト（ここではハードウェア部品）の情報（セキュリティトピックあるいはセキュリティアクション）を通知する。当該情報に対し、マネージャの条件付けが可能である。ここでは、「uuu:vvv:」と、その脆弱性情報、及び、「uuu:vvv:www」と、そのリスク情報が通知されたものとする。「uuu:vvv:www」は、wwwという特定のマネージャで管理されるuuu:vvvについてリスクがあることを示している。

【0062】

Ｓ１０３において、セキュリティアラート通知装置３００は、マッチング処理されたセキュリティアラートをチケット管理装置４００に通知する。

【0063】

具体的には、セキュリティアラート通知装置３００は、アーティファクト管理装置１００から通知された「uuu:vvv:www」と、脆弱性情報の「uuu:vvv:」とのマッチング、及び、アーティファクト管理装置１００から通知された「uuu:vvv:www」と、リスク情報の「uuu:vvv:www」とのマッチングを行うことで、当該脆弱情報と当該リスク情報が、監視対象のハードウェア部品についてのセキュリティ情報（アラート発出対象となる情報）であることを特定する。

【0064】

そして、セキュリティアラート管理装置３００は、「uuu:vvv:www」についてのセキュリティアラートとして、「uuu:vvv:」と、その脆弱性情報、及び、「uuu:vvv:www」と、そのリスク情報をチケット管理装置４００に通知する。

【0065】

チケット管理装置４００は、セキュリティアラート通知装置３００からセキュリティアラートを受け取って、部品（ここではハードウェア部品とする）ごとに問題をチケットで管理する。また、チケット管理装置４００は、セキュリティアラートの対象であるアーティファクトの情報（マネージャの情報を含む）をセキュリティチケットとして、当該アーティファクトに関わるサービス開発チームへ通知する。この通知により、サービス開発チームの端末にセキュリティチケットの表示がなされる。チケット管理装置４００は、ハードウェア部品の管理ラベルのフォーマットとして、マネージャの情報が付帯したフォーマットを使用可能である。

【0066】

図４に示す具体例では、チケット管理装置４００は、セキュリティアラート通知装置３００から受信したセキュリティアラートに基づいて、「uuu:vvv:www」に関するセキュリティチケットとして、図４に示すように、脆弱性に対する対策、及びセキュリティリスクに対する対策を記載したセキュリティチケットを生成し、当該セキュリティチケットの通知及び管理を行う。

【0067】

（処理シーケンス）
以下、本実施の形態におけるセキュリティ管理システムの処理シーケンスを説明する。

【0068】

＜セキュリティアラートの通知制御＞
まず、図５を参照してセキュリティアラートの通知制御についてのシーケンスを説明する。Ｓ１において、サービス開発チームのユーザが端末に登録情報を入力することで、端末からアーティファクト管理装置１００に対して、サービス開発チームによるアーティファクトの登録が行われる。具体的には、マネージャの情報を含むアーティファクトタグがアーティファクト管理装置１００に登録される。

【0069】

Ｓ２において、アーティファクト管理装置１００は、セキュリティアラート通知装置３００に対して、アーティファクトの監視登録を行う。より具体的には、アーティファクト管理装置１００は、セキュリティアラート通知装置３００に対して、監視を求めるアーティファクトのアーティファクトタグを通知する。セキュリティアラート通知装置３００は、当該アーティファクトタグを、監視対象のアーティファクトのタグとして、登録（保存）する。

【0070】

Ｓ３において、セキュリティ担当者が端末に登録情報を入力することで、端末からセキュリティトピック管理装置２００に対して、セキュリティ担当者によるセキュリティトピックの登録を行う。セキュリティトピックにおいて、通知対象のアーティファクトが指定される。また、通知対象のアーティファクトの指定において、マネージャの条件付けも可能である。

【0071】

Ｓ４において、セキュリティトピック管理装置２００は、セキュリティアラート通知装置３００に対して、セキュリティトピックの登録を行う。より具体的には、セキュリティトピック管理装置２００は、セキュリティアラート通知装置３００に対して、セキュリティ担当者により登録されたセキュリティトピック（セキュリティリスクに関する情報とアーティファクトを指定するアーティファクトタグを含む）を通知し、セキュリティアラート通知装置３００は、当該セキュリティトピックを登録（保存）する。

【0072】

Ｓ５において、セキュリティアラート通知装置３００は、監視のための登録がされているアーティファクトのアーティファクトタグと、セキュリティトピックのアーティファクトタグとのマッチングを行うことにより、監視対象のアーティファクトについてのセキュリティトピックを抽出する。

【0073】

本実施の形態では、アーティファクトのマネージャをマッチング条件に加味できるので、マネージャとアーティファクトの組み合わせに関するバグやリスクを考慮したセキュリティトピックの抽出を行うことができる。これにより、セキュリティアラートの通知の最適化を実現できる。

【0074】

すなわち、セキュリティアラートのより柔軟な条件付けを行うことができるので、不要なセキュリティ通知を削減することができる。

【0075】

Ｓ６において、セキュリティアラート通知装置３００は、チケット管理装置４００に対してマッチング処理により得られたセキュリティアラート（セキュリティトピックを含む）を、チケット管理装置４００に通知する。その後、チケット管理装置４００から該当のサービス開発チームの端末へセキュリティチケットが通知される。

【0076】

ここで、上述したマッチングについての例を説明する。図６は、「yaml:npm:」についてのセキュリティトピックＸと、監視登録された「yaml:npm:npm」とのマッチングがなされたことを示している。このマッチングにより、「yaml:npm:」についてのセキュリティトピックＸに対して、マネージャの情報が付加されたアーティファクトの情報である「yaml:npm:npm」を、セキュリティトピックＸの情報（脆弱性情報など）とともに、例えば該当のサービス開発チームに通知することが可能となる。「yaml:npm:npm」を受信した担当者は、例えば、npmを操作することでyamlの問題に対処できることを把握する。

【0077】

図７は、「yaml:npm:」についてのセキュリティトピックＸと、監視登録された「yaml:npm:npm」及び「yaml:npm:yarn」とのマッチングがなされたことを示している。このマッチングにより、「yaml:npm:」についてのセキュリティトピックＸに対して、マネージャの情報が付加されたアーティファクトの情報である「yaml:npm:npm」及び「yaml:npm:yarn」を、セキュリティトピックＸの情報とともに、例えばサービス開発チームに通知することが可能となる。この場合、例えば、当該サービス開発チームがマネージャとしてyarnを使用している場合、当該サービス開発チームは社内でnpmも使用されていることを把握できる。

【0078】

図８は、「yaml:npm:yarn」についてのセキュリティトピックＹと、監視登録された「yaml:npm:npm」及び「yaml:npm:yarn」のうちの「yaml:npm:yarn」とのマッチングがなされたことを示している。このマッチングにより、「yaml:npm:yarn」についてのセキュリティトピックＹに対して、「yaml:npm:yarn」のみを、セキュリティトピックＹの情報とともに、例えば該当のサービス開発チームに通知することが可能となる。これにより、サービス開発チームは、yamlに対してyarnをマネージャとして使用する場合にセキュリティリスクがあることを把握できる。

【0079】

図９は、これまでに示した例をまとめて示した図である。ただし、図９には、セキュリティアクションＸも示されている。図９のＡで示すマッチングにより、特定のパッケージマネージャを使用する場合にだけ実行してほしいセキュリティ的な対処をサービス開発チームに通知することができる。図９のＢ、Ｃで示すマッチングにより、yamlに対して社内で使用されている全てのマネージャをサービス開発チームに通知することができる。図９のＤで示すマッチングにより、例えば、特定のパッケージマネージャが原因で発生するバグをサービス開発チームに通知することができる。

【0080】

＜操作対象のマネージャの明確化＞
次に、操作対象のマネージャの明確化についてのシーケンスを、図１０を参照して説明する。

【0081】

図１０のシーケンスは、図５でのＳ６に相当するＳ１１から開始する。Ｓ１１において、セキュリティアラート管理装置３００は、マッチング処理されたセキュリティアラートを、チケット管理装置４００に通知する。

【0082】

Ｓ１２において、チケット管理装置４００は、マネージャを含めたアーティファクトの情報であるアーティファクトタグを含むセキュリティチケットの情報を、該当のサービス開発チームの端末へ通知する。

【0083】

Ｓ１３において、サービス開発チームにより、セキュリティチケットの内容に従って、アーティファクトの更新などのセキュリティ対処が実施される。

【0084】

上記のように、サービス開発チームへ通知するセキュリティチケット（セキュリティアラートと呼んでもよい）に、部品についてのマネージャの情報を含めることにより、操作対象のマネージャ（アーティファクトの更新などに利用）が明確になる。よって、サービス開発チームにおける確認作業の手間を削減できる。

【0085】

＜アーティファクトのマネージャの分析＞
次に、アーティファクトのマネージャの分析に関するシーケンスを、図１１を参照して説明する。

【0086】

Ｓ２１～Ｓ２２において、各サービス開発チーム（図７の例ではチームＡとチームＢのぞれぞれ）が、端末から、アーティファクト管理装置１００に対してアーティファクトの登録を行う。登録するアーティファクトの情報にはマネージャの情報が含まれる。

【0087】

アーティファクト管理装置１００は、登録されているアークファクトのマネージャについての統計情報を算出する。統計情報は、特定のものに限定されないが、例えば、サービス開発チームごとあるいは会社全体の「部品ごとの使用マネージャの種類数、部品ごとの使用マネージャの構成割合」などである。

【0088】

Ｓ２３において、例えばセキュリティ担当者が、端末により、アーティファクト管理装置１００から、マネージャの統計情報を取得する。Ｓ２４において、セキュリティ担当者は、セキュリティトピック管理装置２００に対して、マネージャの統計情報を加味したセキュリティトピックの登録を行う。例えば、セキュリティ担当者は、多く使用されているマネージャについてのセキュリティトピックを、あまり使用されていないマネージャについてのセキュリティトピックよりも優先的に登録することができる。

【0089】

また、Ｓ２４において、セキュリティ担当者は、端末から、チケット管理装置４００を介して、マネージャの統計情報を加味したセキュリティ対応策の支援を行うことができる。

【0090】

上記のように、マネージャの統計情報を取得することで、アーティファクトの管理プロセスを考慮したセキュリティ情報の配布、及びセキュリティ対処の支援を行うことが可能となる。また、サービス開発チームの実環境を考慮したリスク分析を行うことが可能となる。

【0091】

（装置構成例）
図１２に、アーティファクト管理装置１００の機能構成例を示す。図１２に示すように、アーティファクト管理装置１００は、情報取得部１１０、情報通知部１２０、分析部１３０、及び記憶部１４０を備える。

【0092】

情報取得部１１０は、サービス開発チームなどの端末から、アーキファクトの登録情報として、マネージャの情報を含むアーキファクトタグの情報を受信し、受信した情報を記憶部１４０に格納する。

【0093】

情報通知部１２０は、記憶部１４０から読み出したアーキファクトタグの情報をセキュリティアラート通知装置３００へ通知する。分析部１３０は、記憶部１４０に格納されている複数のタグに基づき、マネージャの統計情報を算出する。

【0094】

図１３に、セキュリティトピック管理装置２００の機能構成例を示す。図１３に示すように、セキュリティトピック管理装置２００は、情報取得部２１０、情報通知部２２０、及び記憶部２３０を備える。

【0095】

情報取得部２１０は、セキュリティ担当者などの端末から、アーキファクトのセキュリティに関する情報を受信し、受信した情報を記憶部２３０に格納する。この情報にはマネージャが指定されている場合もあるし、マネージャが指定されていない場合もある。

【0096】

情報通知部２２０は、記憶部２３０から読み出したアーキファクトのセキュリティに関する情報をセキュリティアラート通知装置３００へ通知する。

【0097】

図１４に、セキュリティアラート通知装置３００の機能構成例を示す。図１４に示すように、セキュリティアラート通知装置３００は、情報取得部３１０、マッチング処理部３２０、情報通知部３３０、及び記憶部３４０を備える。

【0098】

情報取得部３１０は、アーティファクト管理装置１００から、監視対象とするアーティファクトの情報（マネージャの情報を含む）を受信し、受信した情報を記憶部３４０に格納する。また、情報取得部３１０は、セキュリティトピック管理装置２００から、セキュリティ上の問題があるアーティファクトについてのセキュリティ情報（マネージャの情報を含む場合と含まない場合がある）を受信し、受信した情報を記憶部３４０に格納する。

【0099】

マッチング処理部３２０は、記憶部３４０に格納されているアーティファクトの情報（マネージャの情報を含む）と、セキュリティ情報との間のマッチング処理を行う。マッチング処理により得られるマッチング（タグとセキュリティ情報との組み合わせ）の例は前述したとおりである。

【0100】

情報通知部３３０は、マッチング処理により得られた情報をセキュリティアラートとしてチケット管理装置４００に通知する。

【0101】

図１５に、チケット管理装置４００の機能構成例を示す。図１５に示すように、チケット管理装置４００は、情報取得部４１０、セキュリティチケット生成部４２０、情報通知部４３０、及び記憶部４４０を備える。

【0102】

情報取得部４１０は、セキュリティアラート通知装置３００から、タグとセキュリティ情報を含むセキュリティアラートを受信し、受信した情報を記憶部４４０に格納する。

【0103】

セキュリティチケット生成部４２０は、記憶部４４０に格納されているセキュリティアラートの情報に基づいて、セキュリティチケットを生成する。情報通知部４３０は、セキュリティチケット生成部４２０により生成されたセキュリティチケットを、例えば、当該セキュリティチケットが対象としているアーティファクトを用いたサービス開発を行っているチームの端末に通知する。

【0104】

（ハードウェア構成例）
本実施の形態で説明したいずれの装置（アーティファクト管理装置１００、セキュリティトピック管理装置２００、セキュリティアラート通知装置３００、及びチケット管理装置４００）も、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。

【0105】

すなわち、当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

【0106】

図１６は、上記コンピュータのハードウェア構成例を示す図である。図１６のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。なお、当該コンピュータは、更にＧＰＵを備えてもよい。

【0107】

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0108】

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワーク等に接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。

【0109】

（実施の形態の効果等）
以上説明したとおり、本実施の形態で説明した技術により、セキュリティ対策において、セキュリティに関する情報の通知を適切に行うことが可能となる。この「通知」は、例えば、セキュリティアラート通知装置３００からチケット管理装置４００への通知、あるいは、チケット管理装置４００からサービス開発チームへの通知である。

【0110】

より具体的な効果として下記の４つの効果がある。

【0111】

（１）ソフトウェア部品以外でもSBOM同様のセキュリティ管理を実現できる。

【0112】

（２）サービス開発チームの実環境（管理プロセスと言い換えてもよい）を考慮したセキュリティリスク分析を行うことが可能となる。

【0113】

（３）セキュリティアラートのより柔軟な条件付けが可能となり、その結果、不要なセキュリティ通知の削減が可能となる。

【0114】

（４）セキュリティ対策の実施プロセスにおいて確認作業の手間を削減することが可能となる。

【0115】

すなわち、本実施の形態に係る技術により、SBOMを利用したセキュリティ対策の対象領域を広げ、より効率的で正確なサイバーセキュリティ対策を実現することが可能になる。

【0116】

以上の実施形態に関し、更に以下の付記を開示する。

【0117】

＜付記＞
（付記項１）
サービスを構成する部品であるアーティファクトと、前記アーティファクトのマネージャとを識別するタグを管理するアーティファクト管理装置と、
特定のアーティファクトについての前記タグと、前記特定のアーティファクトについてのセキュリティ情報とを特定の装置へ通知するセキュリティ情報通知装置と
を備えるセキュリティ管理システム。
（付記項２）
前記セキュリティ管理システムは、セキュリティ情報管理装置を更に備え、
前記セキュリティ情報通知装置は、前記アーティファクト管理装置から監視対象として通知された前記特定のアーティファクトについての前記タグと、前記セキュリティ情報管理装置から通知された１以上のセキュリティ情報とのマッチング処理を行うことにより、前記特定のアーティファクトについての前記セキュリティ情報を抽出する
付記項１に記載のセキュリティ管理システム。
（付記項３）
前記セキュリティ情報通知装置は、前記セキュリティ情報管理装置から通知された、マネージャが指定されないセキュリティ情報に対し、マネージャが指定されたタグを１又は複数個マッチングさせる
付記項２に記載のセキュリティ管理システム。
（付記項４）
前記セキュリティ情報通知装置は、前記セキュリティ情報管理装置から通知された、マネージャが指定されたセキュリティ情報に対し、当該マネージャが指定されたタグをマッチングさせる
付記項２に記載のセキュリティ管理システム。
（付記項５）
前記特定の装置は、チケット管理装置であり、当該チケット管理装置は、前記セキュリティ情報通知装置から受信するタグとセキュリティ情報に基づいてセキュリティチケットを生成し、当該セキュリティチケットをサービス開発チームへ通知する
付記項１ないし４のうちいずれか１項に記載のセキュリティ管理システム。
（付記項６）
前記アーティファクト管理装置は、管理する複数のタグに基づいて、マネージャの統計情報を算出する
付記項１ないし５のうちいずれか１項に記載のセキュリティ管理システム。
（付記項７）
アーティファクト管理装置とセキュリティ情報通知装置とを備えるセキュリティ管理システムにおいて実行されるセキュリティ管理方法であって、
前記アーティファクト管理装置は、サービスを構成する部品であるアーティファクトと、前記アーティファクトのマネージャとを識別するタグを管理し、
前記アーティファクト管理装置が、特定のアーティファクトについての前記タグを前記セキュリティ情報通知装置に通知し、
前記セキュリティ情報通知装置が、前記特定のアーティファクトについての前記タグと、前記特定のアーティファクトについてのセキュリティ情報とを特定の装置へ通知する
セキュリティ管理方法。
（付記項８）
コンピュータを、付記項１ないし５のうちいずれか１項に記載のセキュリティ情報通知装置として機能させるためのプログラムを記憶した非一時的記憶媒体。

【0118】

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0119】

１０ 端末
１００ アーティファクト管理装置
１１０ 情報取得部
１２０ 情報通知部
１３０ 分析部
１４０ 記憶部
２００ セキュリティトピック管理装置
２１０ 情報取得部
２２０ 情報通知部
２３０ 記憶部
３００ セキュリティアラート通知装置
３１０ 情報取得部
３２０ マッチング処理部
３３０ 情報通知部
３４０ 記憶部
４００ チケット管理装置
４１０ 情報取得部
４２０ セキュリティチケット生成部
４３０ 情報通知部
４４０ 記憶部
５００ ネットワーク
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置
１００８ 出力装置

【要約】

【課題】セキュリティ対策において、セキュリティに関する情報の通知を適切に行う。
【解決手段】セキュリティ管理システムにおいて、サービスを構成する部品であるアーティファクトと、前記アーティファクトのマネージャとを識別するタグを管理するアーティファクト管理装置と、特定のアーティファクトについての前記タグと、前記特定のアーティファクトについてのセキュリティ情報とを特定の装置へ通知するセキュリティ情報通知装置とを備える。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】