Information distribution method, information distribution system, and VC holder device

Abstract

An objective of the present invention is to share security information between organizations. To this end, an information distribution system according to the disclosed technology comprises a first wallet device, a second wallet device, and a VDR that holds information related to a first VC and a second VC. When a first VC holder requests a second VC holder to provide security information, the second wallet device receives an information provision request. The second wallet device requests, from the first wallet device, an attribute information VP associated with the information provision request. The first wallet device creates the attribute information VP from the first VC and transmits the attribute information VP to the second wallet device. The second wallet device communicates with the VDR to verify the attribute information VP. The second wallet device creates a response VP from the second VC on the basis of the attribute information VP and transmits the response VP to the first wallet device. The first wallet device communicates with the VDR to verify the response VP.

Description

Information distribution method, information distribution system, and VC holder device

[0001] The disclosed technology relates to a method / system for sharing security information between organizations using verifiable credentials (VC) and verifiable presentations (VP).

[0002] Various systems have been developed that collect information such as logs and events from network devices and security devices, display it as a series of attack flows (correlation analysis), visualize the progression of threats, and support everything from detecting dangerous access to analysis by security administrators. These are called SIEM (Security Information and Event Management). An example of a commercial SIEM is Microsoft Sentinel (Non-Patent Document 1).

[0003] Microsoft, "What is Microsoft Sentinel?" [Searched July 22, 2024], Internet<https: / / learn.microsoft.com / ja-jp / azure / sentinel / overview?tabs=azure-portal> .

[0004] In order to protect their own company's IT assets, security managers sometimes inquire about the presence or absence of attacks at other companies for reference. Ideally, they would be able to rely solely on their own company's information, but there are many cases where management is also concerned about the trends of other companies in the same industry. In fact, in communities where multiple companies participate (such as industry associations and OSS communities), the presence or absence of attacks against other companies is useful for determining the importance of an attack, such as whether the incident occurred only at their own company.

[0005] However, organizations requesting information have no way of knowing whether the responses of other companies (including when there is no response) are correct, so they do not know to what extent they can rely on the judgments of other companies. It would be possible to make a judgment if they could see the information in the SIEM used by other companies, but in many cases this information is kept confidential and not released to the public, making it difficult for a third party to confirm and verify such information at any time. To begin with, responding organizations have no incentive to respond because they are not evaluated even if they respond (even if they fulfill their responsibilities within the community).

[0006] To solve the above problems, an information distribution system according to the disclosed technology uses verifiable credentials (VC) and verifiable presentation information (VP). The information distribution system according to the disclosed technology includes a first wallet device that holds a VC (first VC) of a security log related to a first VC holder, a second wallet device that holds a VC (second VC) of a security log related to a second VC holder, and a verifiable information register (VDR) that holds information related to the first VC and the second VC. When the first VC holder requests the second VC holder to provide security information, the second wallet device receives the information provision request. The second wallet device requests attribute information VP related to the information provision request from the first wallet device. The first wallet device creates the attribute information VP from the first VC and sends it to the second wallet device. The second wallet device communicates with the VDR to verify the attribute information VP. The second wallet device creates a response VP from the second VC based on the attribute information VP and sends it to the first wallet device. The first wallet device communicates with the VDR to verify the response VP. When the second VC holder requests the first VC holder to provide security information, the first wallet device receives the information provision request and creates a reply VP.

[0007] Disclosure technology allows organizations requesting information to learn the fact-based decisions of other companies regarding security incidents, while allowing responding organizations to avoid disclosing more information than necessary and allowing a third party to verify whether they have fulfilled their responsibilities within the community.

[0008] A diagram for explaining Verifiable Credentials Data Model v1.1. A functional block diagram showing an example configuration of a security information distribution system according to a first embodiment. A flowchart for explaining schema registration processing. A flowchart for explaining data registration processing. A flowchart for explaining information request / response processing according to the first embodiment. A flowchart for explaining information request / response processing according to a second embodiment. A flowchart for explaining reputation acquisition processing. A diagram showing an example functional configuration of a computer.

[0009] Hereinafter, embodiments of the disclosed technology will be described in detail. Note that components having the same functions are assigned the same numbers, and duplicated descriptions will be omitted.

[0010] [Verifiable Credentials] With the aim of enabling proactive management of personal information, the W3C has proposed the Verifiable Credentials Data Model v1.1 (Reference 1) and Decentralized Identifiers (Reference 2). Hereinafter, Verifiable Credentials will be abbreviated as VC and Decentralized Identifiers as DID. Figure 1 shows the roles and information flow in the Verifiable Credentials Data Model v1.1. VC is a verifiable credential issued using a public key infrastructure or similar. VC is assigned a unique ID (DID) generated using blockchain technology or similar. VC issued by an issuer is held by the holder and presented to a verifier. The verifier can verify that the VC was issued by a legitimate issuer by verifying the signature. This is called a Verifiable Presentation (VP). When presenting the VC to the verifier, the holder may present only the necessary items rather than disclosing the entire VC. The disclosure technology guarantees the contents of the security log using VC and selectively discloses (presents) the contents of the VC upon request of others.

[0011] Reference 1: W3C, Verifiable Credentials Data Model v1.1,<https: / / www.w3.org / TR / vc-data-model / > Reference 2: W3C, Decentralized Identifiers (DIDs),<https: / / www.w3.org / TR / did-core / >

[0012] [First Embodiment] Fig. 2 is a functional block diagram showing an example of the configuration of a security information distribution system according to the first embodiment. In the security information distribution system 2, a VC issuer device 208, multiple wallet devices 203, and a verifiable information registration unit (VDR) 209 are communicatively connected via, for example, a communication network 210. A VC holder is a member of a community, and a wallet device is a device operated by a VC holder to share security information within the community. It is assumed that, at the same site as each wallet device 203, there is a VC holder terminal 207 that serves as a user interface for the VC holder, and a security sensor 202. The security sensor is, for example, a SIEM.

[0013] Each wallet device 203 includes a storage unit 206. The storage unit 206 electronically stores the VC. In the first embodiment, the VC holder receives a request for security information and responds with a VP. Therefore, the requester of security information corresponds to the VP verifier in FIG. 1.

[0014] [Schema Registration] A schema is a data structure of a VC. Schemas are prepared for, for example, security sensor types, security logs, security events, etc. FIG. 3 is a flowchart explaining the schema registration process. This will be explained using FIGS. 2 and 3. The VC issuer device requests schema registration from the VDR (step S301). The VDR verifies the issuer's DID, schema definition, and VC issuer's public key information (step S302). If the verification is successful, the VDR registers the schema and notifies the VC issuer device that the schema registration is complete (step S303). If the verification fails, the VDR notifies the VC issuer device that the schema registration failed.

[0015] [Data Registration] A VC is registered in the storage unit of the wallet device. FIG. 4 is a flowchart explaining the data registration process. The explanation will be made using FIG. 2 and FIG. 4. The VC holder terminal 207 transmits registration information (information that should be verifiable) to the VC issuer device 208 and requests the issuance of a VC (step S401). The registration information includes a log output by the security sensor 202 within a certain time window. The time window may be, for example, every 30 minutes or every hour. A specific example of registration information is shown below.

[0016] <Example of registered information> (Header section) ID, type, issuer, issue date, expiration date (Content section) ID, security log content, schema, information source, event type (if no event has occurred, enter "none")

[0017] The VC issuer device verifies the license status of the VC holder and the normality of the service (step S402). If the verification is successful, the VC issuer device registers registration information in the VDR (step S403) and issues a VC to the wallet device 203 (step S404), and the wallet device 203 notifies the VC holder terminal 207 of the VC issuance (step S405). If the verification fails, the VC issuer device 208 notifies the wallet device 203 of a failure to issue the VC, and the wallet device 203 notifies the VC holder terminal 207 of the failure to issue the VC. A specific example of a VC is shown below. A VC is "registration information" to which a "certification part" has been added.

[0018] <Example of VC> (Registration information section) - Same as the registration information above (Certification section) - Type, issuer information, attributes, signature, proof that the signature is correct

[0019] [Information Request / Response] The flow from an information request to a response will be described. FIG. 5 is a flowchart illustrating the information request / response process. In addition to the function of responding to an information request, the wallet device 203 also has a function of supporting the information request on the information requester's side. In FIG. 5, to avoid confusion, the VC holder terminal that makes the information request is referred to as the "requester terminal." Additionally, the wallet device of the information requester is referred to as the "requester wallet device," and the wallet device of the VC holder that responds to the information request is referred to as the "holder wallet device." The following description will be made using FIG. 2 and FIG. 5.

[0020] The requester terminal (actually the VC holder terminal 207) requests the holder wallet device (actually the wallet device 203) to provide security information (step S501). The request includes the request ID, inquiry content, the URL of the wallet device of the information requester, and the response expiration date and time.

[0021] The holder wallet device requests the requester wallet device to present attribute information related to the inquiry (step S503). The requester wallet device creates attribute information to present (step S504). That is, a VP is created from the VC held by the information requester. This will be called attribute information VP. The attribute information VP is a security log at the requesting organization related to the security incident that caused the inquiry. This security log was also registered in VDR 209 in step S403. The requester wallet device transmits the created attribute information VP to the holder wallet device (step S505).

[0022] The holder wallet device requests the VDR 209 to verify the attribute information VP (step S506). The VDR 209 notifies the holder wallet device of the verification result of the attribute information VP (step S507). If the verification is successful (if a security incident at the requester's organization described in the attribute information VP is confirmed), the holder wallet device creates security information to be presented from the VC it ​​holds based on the attribute information VP (step S508). This will be called an answer VP. The answer VP changes depending on the attribute information VP. Below are examples of attribute information VP and corresponding answer VPs.

[0023] <Example of an answer VP according to attribute information VP> When answering a request to inquire "whether (specified) malware has been detected" (Example 1) Attribute information VP: Log indicating that the information requester may be the source of the attack Answer VP: Detected host, time, specimen hash, malware family, TTP (Example 2) Attribute information VP: Log indicating that the information requester has been attacked Answer VP: Specimen hash, malware family, TTP (Example 3) Attribute information VP: No log indicating the relationship between the information requester and the attack Answer VP: Whether specified malware has been detected

[0024] As mentioned above, VP does not disclose all VC but presents only some necessary items. This allows VC holders to share security logs to the extent necessary while concealing information they do not want to disclose to information requesters (e.g., security sensor device and version information, host information, user names, etc.).

[0025] The holder wallet device transmits the response VP to the requester terminal (step S509). If the verification of the attribute information VP by the VDR 209 fails, the holder wallet device notifies the requester terminal that the response is not possible.

[0026] The requester terminal requests the VDR 209 to verify the reply VP (step S511). The VDR 209 notifies the requester terminal of the result of the reply VP verification (step S512). If the verification is successful, the requester terminal adopts the reply VP as reliable.

[0027] The above is a description of the first embodiment. In the above description, [data registration] was described assuming that the wallet device and security sensor are located at the same site, but the security sensor may be located at a different site from the wallet device (for example, on the cloud). In step 401, wallet device 203 acquires a log from the security sensor at the remote site and transmits registration information to VC issuer device 208. In addition, in this specification, "successful verification" of a VC or VP means that the validity of the VC or VP has been confirmed, and "failed verification" means that the validity has not been confirmed.

[0028] [Second embodiment] We want to evaluate community members who have made significant contributions as information providers. Furthermore, we want to provide an incentive for providing information by allowing members with higher ratings to receive more detailed answers. Therefore, in the second embodiment, we accumulate transaction data for answer VPs and use it as a member's reputation.

[0029] An example of the configuration of a security information distribution system according to the second embodiment is the same as that of the first embodiment (FIG. 2). FIG. 6 is a flowchart illustrating information request / response processing according to the second embodiment. This differs from the first embodiment in that it further includes a reputation acquisition step S601 and a transaction recording step S602. FIG. 7 is a flowchart illustrating the reputation acquisition processing in detail. The following description will be made using FIGS. 2, 6, and 7.

[0030] First, step S602 will be described. The VDR 209 notifies the requester terminal of the verification result of the answer VP (step S512). If the verification is successful, the VDR 209 records the transaction of the answer VP (step S702). This transaction is used to calculate the evaluation (reputation) of the VC holder (community member). If the verification is unsuccessful, the VDR 209 does not record the transaction of the answer VP.

[0031] [Reputation Processing] Next, steps S601 and S508 will be described. Steps up to step S507 are the same as in the first embodiment. Following step S507, the owner wallet device performs reputation acquisition processing (step S601). The owner wallet device sends a transaction request related to the information requester to VDR 209 (FIG. 7, step S702).

[0032] The VDR 209 searches for transactions related to the designated VC holder (step S703). The VDR 209 sends the search results to the holder wallet device (step S704). The holder wallet device calculates the reputation using the search results (step S705).

[0033] The holder wallet device then creates a reply VP from the VC it ​​holds based on the acquired reputation and attribute information VP (FIG. 6, step S508). The subsequent processing is the same as in the first embodiment, except for the addition of step S602.

[0034] This concludes the description of the second embodiment. In the above description, reputations were acquired to create a response VP. However, any community member may acquire the reputation of another community member to evaluate the community member. In this case, any member terminal may be used to perform the reputation acquisition process of FIG. 7. The member terminal transmits a reputation request to the wallet device 203 of the VC holder whose reputation is to be calculated (FIG. 7, step S701). The wallet device 203 and VDR 209 perform steps S702 to S705, and the wallet device 203 transmits the calculated reputation to the member terminal (step S706).

[0035] [Specific examples of information requests / replies] <Example 1: AntiVirus> The information requesting organization suspects that their organization may have acted as a springboard to send emails containing malware, etc., and would like to confirm the status of the email in question at the recipient organization. (1) Inquiry content: Was the sample with hash value xxx blocked within the organization? (2) Attribute information VP: The sample was detected within the requesting organization, and the domain of the inquired organization (VC holder) was found in the email sending log. (3) Response VP: Detected and quarantined / Detected and deleted, etc.

[0036] <Example 2: Email> The information requesting organization wants to investigate whether their organization is the source of Emotet attacks. They also want to investigate whether their organization is being used as a disguised BEC (Business Email Compromise) attack. Let's say the domain name of the information requesting organization is "verifier.com." (1) Inquiry content A. Has the sender blocked emails from "verifier.com"? B. Has the sender blocked emails from "verif1er.com"? (2) Attribute information VP A. The VC holder's (information requesting organization's) domain was found in the email sending log. B. Investigating whether a similar domain to theirs is being used in attacks. (3) Response content VP A. Whether the sender is blocking emails from "verifier.com" or not, etc. B. Whether the sender is blocking emails from "verif1er.com" or not, etc.

[0037] This concludes the explanation of [specific examples of information requests and responses].

[0038] [Program, Recording Medium] The functions realized by the components described in this specification may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in a memory.

[0039] In this specification, a circuitry, unit, or means is hardware that is programmed to realize or performs the described functions, which may be any hardware disclosed herein or any hardware known to be programmed to realize or perform the described functions.

[0040] If the hardware is a processor considered to be a type of circuitry, the circuitry, means, or unit is a combination of the hardware and software used to configure the hardware and / or processor.

[0041] The various processes described above can be implemented by loading a program that executes each step of the above method into the recording unit 2020 of the computer 2000 shown in Figure 8, and operating the control unit 2010, input unit 2030, output unit 2040, display unit 2050, etc.

[0042] The program describing the processing contents can be recorded on a computer-readable recording medium, which may be, for example, a magnetic recording device, an optical disk, a magneto-optical recording medium, a semiconductor memory, or any other suitable recording medium.

[0043] The program may be distributed by, for example, selling, transferring, lending, etc. portable recording media such as DVDs and CD-ROMs on which the program is recorded. Furthermore, the program may be stored in a storage device of a server computer, and then transferred from the server computer to other computers via a network, thereby distributing the program.

[0044] A computer that executes such a program may first temporarily store the program recorded on a portable recording medium or transferred from a server computer in its own storage device. Then, when executing a process, the computer reads the program stored on its own recording medium and executes the process in accordance with the read program. Alternatively, the computer may read the program directly from a portable recording medium and execute the process in accordance with the program. Furthermore, the computer may execute the process in accordance with the received program each time a program is transferred from a server computer to the computer. Alternatively, the server computer may not transfer the program to the computer, but may instead execute the process through a so-called ASP (Application Service Provider) service, which realizes the processing function by issuing an execution instruction and obtaining the results. Furthermore, the server computer may execute the process at the terminal using a so-called SaaS (Software as a Service) service, which allows users to use part of a server computer along with the program. In this embodiment, the program includes information used for processing by an electronic computer that is equivalent to a program (such as data that is not a direct instruction to a computer but has properties that dictate computer processing).

[0045] Furthermore, in this embodiment, the device is configured by executing a predetermined program on a computer, but at least a part of the processing contents may be realized by hardware.

Claims

1. A security information distribution method using verifiable credentials (VC) and verifiable presentation information (VP), wherein a device holding a VC (first VC) of a security log related to a first VC holder is defined as a first wallet device, a device holding a VC (second VC) of a security log related to a second VC holder is defined as a second wallet device, and a device holding information related to the first VC and the second VC is defined as a verifiable information registration device (VDR), and when the first VC holder requests the second VC holder to provide security information, the second wallet device receives the information provision request, and the second wallet device requests attribute information VP related to the information provision request from the first wallet device, the first wallet device creates the attribute information VP from the first VC and sends it to the second wallet device, the second wallet device communicates with the VDR to verify the attribute information VP, the second wallet device creates a response VP from the second VC based on the attribute information VP and sends it to the first wallet device, and the first wallet device communicates with the VDR to verify the response VP.

2. A security information distribution system using verifiable credentials (VC) and verifiable presentation information (VP), comprising: a first wallet device that holds a VC (first VC) of a security log related to a first VC holder; a second wallet device that holds a VC (second VC) of a security log related to a second VC holder; and a verifiable information registration device (VDR) that holds information related to the first VC and the second VC, wherein when the first VC holder requests the second VC holder to provide security information, the second wallet device receives the information provision request, the second wallet device requests attribute information VP related to the information provision request from the first wallet device, the first wallet device creates the attribute information VP from the first VC and sends it to the second wallet device, the second wallet device communicates with the VDR to verify the attribute information VP, the second wallet device creates an answer VP from the second VC based on the attribute information VP and sends it to the first wallet device, and the first wallet device communicates with the VDR to verify the answer VP.

3. An information distribution system as described in claim 2, wherein the VDR holds a set of answer VPs (first transactions) previously created by a first wallet device, the second wallet device acquires the first transactions from the VDR, and the second wallet device creates the answer VP from the second VC based on the attribute information VP and the transaction.

4. A first or second wallet device constituting a security information distribution system using verifiable credentials (VC) and verifiable presentation information (VP), the system comprising: a first wallet device that holds a VC (first VC) of a security log related to a first VC holder; a second wallet device that holds a VC (second VC) of a security log related to a second VC holder; and a verifiable information registration device (VDR) that holds information related to the first VC and the second VC, wherein when the first VC holder requests the second VC holder to provide security information, the second wallet device receives the information provision request; the second wallet device requests attribute information VP related to the information provision request from the first wallet device; the first wallet device creates the attribute information VP from the first VC and sends it to the second wallet device; the second wallet device communicates with the VDR to verify the attribute information VP; the second wallet device creates a response VP from the second VC based on the attribute information VP and sends it to the first wallet device; and the first wallet device communicates with the VDR to verify the response VP. VC holder equipment.

Images