Information processing method, information processing device, and program

Abstract

This information processing method supports security monitoring of a monitoring target organization having a plurality of monitoring environments subject to security monitoring, and involves: acquiring security resources required for security monitoring of each of the plurality of monitoring environments (S92a, S92b, S92c); and redistributing monitoring resources allocated to each of the plurality of monitoring environments among the plurality of monitoring environments on the basis of the security resources of each of the plurality of monitoring environments (S97).

Description

Information Processing Method, Information Processing Apparatus, and Program

[0001] The present disclosure relates to an information processing method, an information processing apparatus, and a program.

[0002] Patent Document 1 discloses a resource management support apparatus for making the resource management of a system efficient and accurate.

[0003] Japanese Patent No. 7041607

[0004] By the way, since the possibility of security incidents occurring can change moment by moment due to various factors, it is desirable that security services can be flexibly customized on the user side, the SOC (Security Operation Center) side, etc.

[0005] Therefore, the present disclosure provides an information processing method, an information processing apparatus, and a program that can more flexibly customize security services.

[0006] An information processing method according to one aspect of the present disclosure is an information processing method for supporting security monitoring of a monitoring target organization, where the monitoring target organization has a plurality of monitoring environments to be the target of the security monitoring, obtains security resources required for the security monitoring of each of the plurality of monitoring environments, and redistributes the monitoring resources allocated to each of the plurality of monitoring environments among the plurality of monitoring environments based on the security resources of each of the plurality of monitoring environments.

[0007] An information processing apparatus according to one aspect of the present disclosure is an information processing apparatus for supporting security monitoring of a monitoring target organization, where the monitoring target organization has a plurality of monitoring environments to be the target of the security monitoring, and includes an acquisition unit that acquires security resources required for the security monitoring of each of the plurality of monitoring environments, and an adjustment unit that redistributes the monitoring resources allocated to each of the plurality of monitoring environments among the plurality of monitoring environments based on the security resources of each of the plurality of monitoring environments.

[0008] A program relating to one aspect of this disclosure is a program that causes a computer to execute the above-described information processing method.

[0009] According to one aspect of this disclosure, it is possible to realize an information processing method, etc., that allows for more flexible customization of security services.

[0010] Figure 1 is a block diagram showing the functional configuration of a security resource optimization system according to an embodiment. Figure 2A is a diagram showing an example of resource distribution before adjustment in the security resource optimization system according to an embodiment. Figure 2B is a diagram showing an example of resource distribution after adjustment in the security resource optimization system according to an embodiment. Figure 3 is a flowchart showing the operation of the security resource optimization system according to an embodiment. Figure 4 is a flowchart showing the detailed operation of step S90 shown in Figure 3. Figure 5A is the first diagram illustrating an example of step S92a shown in Figure 4. Figure 5B is the second diagram illustrating an example of step S92a shown in Figure 4. Figure 5C is the third diagram illustrating an example of step S92a shown in Figure 4. Figure 6A is the first diagram illustrating an example of step S92b shown in Figure 4. Figure 6B is the second diagram illustrating an example of step S92b shown in Figure 4. Figure 6C is the third diagram illustrating an example of step S92b shown in Figure 4. Figure 7 is a diagram illustrating an example of step S92c shown in Figure 4. Figure 8 is a diagram showing an example of the amount of resources required to monitor each environment with the current personnel during a specified period, according to an embodiment. Figure 9 is a diagram illustrating an example of the total amount of resources that can be handled by the current personnel according to the embodiment. Figure 10 is a diagram illustrating an example of the amount of resources required to newly respond to plan changes, etc., with the current personnel according to the embodiment. Figure 11 is the first diagram illustrating an example of step S95 shown in Figure 4. Figure 12 is the second diagram illustrating an example of step S95 shown in Figure 4. Figure 13 is the first diagram illustrating the calculation of user check content scores shown in Figure 11. Figure 14 is the second diagram illustrating the calculation of user check content scores shown in Figure 11. Figure 15A is the first diagram illustrating another example of step S95 shown in Figure 4. Figure 15B is the second diagram illustrating another example of step S95 shown in Figure 4. Figure 15C is the third diagram illustrating another example of step S95 shown in Figure 4. Figure 16 is a diagram illustrating an example of step S96 shown in Figure 4. Figure 17 is a diagram illustrating an example of the adjustment proposal generated in step S97 shown in Figure 4.Figure 18 is a diagram showing an example of impact information generated in step S98 shown in Figure 4. Figure 19A is a diagram showing an example of a ticket management table before reflecting the contents of the adjustment items. Figure 19B is a diagram showing an example of a ticket management table after reflecting the contents of the adjustment items. Figure 20 is a flowchart showing the operation during operation with the adjustment plan. Figure 21 is a diagram for explaining the adjustment of ticket expiration dates. Figure 22A is a diagram showing an example of a ticket management table when belonging to the expiration extension ticket pool. Figure 22B is a diagram showing an example of a ticket management table when moving from the expiration extension ticket pool to the highest priority response ticket pool. Figure 22C is a diagram showing an example of a ticket management table when moving from the expiration extension ticket pool to the monthly reporting ticket pool. Figure 23A is a diagram showing an example of the number of tickets at the prediction time. Figure 23B is a diagram showing an example of a ticket management table at the prediction time. Figure 24A is a diagram showing an example of the number of tickets at the observation time. Figure 24B is a diagram showing an example of a ticket management table at the observation time. Figure 25 is a block diagram showing the functional configuration of the security resource optimization system according to modified embodiment 1. Figure 26 is a block diagram showing the functional configuration of a security resource optimization system according to a modified example 2 of the embodiment. Figure 27A is a diagram showing an example of inputting the resource adjustment details for next month in the first use case. Figure 27B is a diagram showing an example of presenting the resource adjustment details in the first use case. Figure 27C is a diagram showing an example of a ticket management table in a conventional example. Figure 27D is a diagram showing an example of a ticket management table reflecting the resource adjustment details in the first use case. Figure 27E is a diagram showing an example of the priority order before and after resource adjustment in the first use case. Figure 28 is a diagram showing a prediction of the change in the average number of corresponding tickets due to the impact of the change in the first use case. Figure 29 is a diagram showing the predicted number of tickets generated and the actual number in the first use case. Figure 30 is a diagram showing an example of a ticket management table in the first use case where the extension deadline has been corrected based on the difference between the predicted number of tickets and the number of tickets generated. Figure 31A is a diagram showing an example of inputting the resource adjustment details for next month in the second use case.Figure 31B shows an example of how the impact of resource adjustments is presented in the second use case. Figure 31C shows an example of a ticket management table reflecting the resource adjustments in the second use case. Figure 32A shows an example of inputting resource adjustments for next month in the third use case. Figure 32B shows an example of how the impact of resource adjustments is presented in the third use case. Figure 32C shows an example of a ticket management table reflecting the resource adjustments in the third use case. Figure 33A shows an example of how to present the resource forecast and proposed plan for next month in the fourth use case. Figure 33B shows an example of how the impact of resource adjustments is presented in the fourth use case. Figure 33C shows an example of a ticket management table reflecting the resource adjustments in the fourth use case.

[0011] An information processing method according to a first aspect of this disclosure is an information processing method that supports security monitoring of a monitored organization, wherein the monitored organization has a plurality of monitoring environments that are subject to security monitoring, acquires security resources required for security monitoring of each of the plurality of monitoring environments, and redistributes the monitoring resources allocated to each of the plurality of monitoring environments based on the security resources of each of the plurality of monitoring environments.

[0012] This allows for the redistribution of security resources across multiple monitoring environments based on the security resources required for security monitoring. For example, to improve the security monitoring level of a particular monitoring environment (increase security resources), it is possible to improve the security monitoring level of that environment without increasing the absolute amount of monitoring resources by reducing the monitoring resources allocated to other monitoring environments. In other words, by changing the distribution of monitoring resources within the multiple monitoring environments owned by the monitored organization, it is possible to improve the security monitoring level of a particular monitoring environment. Therefore, security services can be customized more flexibly.

[0013] Furthermore, for example, the information processing method according to the second embodiment is the information processing method according to the first embodiment, wherein change information is acquired regarding a change in at least one of the content of the security monitoring and the cost of the security monitoring, and the security resources are acquired based on the change information.

[0014] This makes it possible, for example, to flexibly respond to changes in security services based on change information.

[0015] Furthermore, for example, the information processing method according to the third embodiment is an information processing method according to the second embodiment, which acquires a first security resource resulting from the change in the change information, a second security resource that can be handled in the present, and a third security resource that will be required in the future, calculates the insufficient resources based on the first security resource, the second security resource, and the third security resource, and redistributes the monitoring resources based on the insufficient resources.

[0016] This allows monitoring resources to be redistributed based on resource shortages, enabling a more appropriate reallocation of monitoring resources.

[0017] Furthermore, for example, the information processing method according to the fourth embodiment is the information processing method according to the third embodiment, wherein in the security monitoring, a plurality of rules for detecting anomalies are used, and the first security resource, the second security resource, and the third security resource may be calculated for one or more groups that classify the plurality of rules.

[0018] This makes it easier to manage resources.

[0019] Furthermore, for example, the information processing method relating to the fifth embodiment is an information processing method relating to any one of the second to fourth embodiments, and the change information may be obtained from a user of the monitored organization.

[0020] This allows for more flexible customization of security services to meet user needs.

[0021] Furthermore, for example, the information processing method relating to the sixth embodiment is an information processing method relating to any one of the second to fourth embodiments, and the change information may be obtained from the monitoring system that performs the security monitoring.

[0022] This allows for more flexible customization of security services to meet the specific requirements of the monitoring system.

[0023] Furthermore, for example, the information processing method according to the seventh embodiment is an information processing method according to any one of the second to fourth embodiments, and the change information may be obtained from a device that manages risk based on information regarding the risk of each of the multiple monitoring environments obtained from each of the monitoring environments.

[0024] This allows for more flexible and automated customization of security services to suit multiple monitoring environments (i.e., the actual security situation on site).

[0025] Furthermore, for example, the information processing method relating to the eighth aspect is an information processing method relating to the third or fourth aspect, and the change information may be acquired when the difference between the fourth security resources required to perform the security monitoring of the multiple monitoring environments using the redistributed monitoring resources and the third security resources is greater than or equal to a predetermined amount.

[0026] This allows for more flexible customization of security services based on discrepancies between the predicted number of alerts and the actual number of alerts.

[0027] Furthermore, for example, the information processing method relating to the ninth aspect is an information processing method relating to any one aspect of the first to eighth aspects, wherein the alert information acquired and managed from the multiple monitoring environments may include information indicating the risk of detected anomalies and additional information that is updated when redistributed.

[0028] This makes it easy to adjust the resources required for alerts by changing additional information.

[0029] Furthermore, for example, the information processing method according to the tenth embodiment is the information processing method according to the ninth embodiment, wherein the additional information includes priority information indicating the priority of the response to be temporarily adopted and extension information regarding a temporary extension of the response deadline for the alert, and alerts issued during the execution of the security monitoring for the multiple monitoring environments by the redistributed monitoring resources may be processed based on the priority information and the extension information.

[0030] This allows alerts to be processed based on priority and extension information, making it possible to adjust the resources required for each alert.

[0031] Furthermore, for example, the information processing method according to the 11th embodiment is an information processing method according to the 4th embodiment, wherein the change information includes a change that increases security resources for some of the monitoring environments among the plurality of monitoring environments, or for some of the rules among the plurality of rules, and in the redistribution of monitoring resources, security resources may be reduced for one or more monitoring environments excluding the aforementioned some of the monitoring environments, or for one or more rules excluding the aforementioned some of the rules.

[0032] This allows for offsetting increases in security resources for certain monitoring environments or rules by decreasing security resources for other monitoring environments or rules. Therefore, security services can be more flexibly customized by adjusting security resources.

[0033] Furthermore, for example, the information processing method according to the 12th embodiment is an information processing method according to the 11th embodiment, and reducing the security resources may include at least one of extending the deadline for responding to alerts relating to the one or more monitoring environments or the one or more rules, and raising the threshold at which such alerts are detected.

[0034] This allows for an effective reduction in security resources.

[0035] Furthermore, for example, the information processing method according to the 13th embodiment is an information processing method according to the 11th embodiment, wherein the adjustment priority to be adjusted in the redistribution of monitoring resources is determined for each of the multiple monitoring environments, and in the redistribution of monitoring resources, the response deadlines of the multiple rules of the monitoring environment with the higher adjustment priority among the one or more monitoring environments may be given priority and extended.

[0036] This ensures that adjustments are made to monitoring environments with the highest adjustment priority, allowing for effective resource allocation.

[0037] Furthermore, for example, the information processing method according to the 14th embodiment is the information processing method according to the 11th embodiment, and in the redistribution of monitoring resources, the extension of the response deadline for the multiple rules may be distributed and executed to each of the one or more monitoring environments.

[0038] This makes it possible to bring the adjusted security monitoring levels of one or more monitoring environments to a similar level.

[0039] Furthermore, for example, the information processing method according to the 15th embodiment is an information processing method according to the 11th embodiment, wherein the alert information obtained from the plurality of monitoring environments includes information indicating the risk of detected anomalies and additional information which is updated when redistributed, the additional information includes priority information indicating the priority of the response to be temporarily adopted and extension information regarding the temporary extension of the response deadline for the alert, the adjustment priority to be adjusted in the redistribution of monitoring resources is determined for each of the plurality of rules, and at least one of the priority information and the extension information of the rule with the higher adjustment priority among the plurality of rules may be changed with priority.

[0040] This ensures that adjustments are made in order of priority, starting with alerts with the highest adjustment priority, allowing for effective resource allocation.

[0041] Also, for example, the information processing method according to the 16th aspect is the information processing method according to any one of the 11th to 15th aspects, and the change for increasing the security resource may be realized by at least one of improving the severity of the alert in the partial monitoring environment, adding a rule for detecting an alert, lowering the threshold for detecting the alert in the rule, and allocating an analyst with a relatively high unit price.

[0042] Thereby, the security monitoring level can be effectively improved.

[0043] Also, for example, the information processing method according to the 17th aspect is the information processing method according to any one of the 1st to 16th aspects, and may generate influence information including the influence on the security monitoring due to redistributing the monitoring resources, and output the generated influence information.

[0044] Thereby, it becomes possible to determine whether to execute the redistribution after confirming the influence information.

[0045] Also, for example, the information processing method according to the 18th aspect is the information processing method according to any one of the 1st to 17th aspects, and outputs the content of the redistribution of the monitoring resources, and when obtaining information permitting a change to the content of the redistribution, may execute a process of redistributing the monitoring resources among the plurality of monitoring environments.

[0046] Thereby, it is possible to suppress the execution of a redistribution that does not conform to the intention of the user or analyst.

[0047] Also, the information processing apparatus according to the 19th aspect of the present disclosure is an information processing apparatus that supports security monitoring for a monitoring target organization, the monitoring target organization has a plurality of monitoring environments that are targets of the security monitoring, and includes an acquisition unit that acquires the security resources required for the security monitoring of each of the plurality of monitoring environments, and an adjustment unit that redistributes the monitoring resources allocated to each of the plurality of monitoring environments among the plurality of monitoring environments based on the security resources of each of the plurality of monitoring environments.

[0048] As a result, the same effects as those of the above-described information processing method are achieved.

[0049] Further, the program according to the 20th aspect of the present disclosure is a program for causing a computer to execute the information processing method according to any one of the 1st to 18th aspects.

[0050] As a result, the same effects as those of the above-described information processing method are achieved.

[0051] Note that these general or specific aspects may be realized by a system, a method, an integrated circuit, a computer program, or a non-temporary recording medium such as a computer-readable CD-ROM, or may be realized by an arbitrary combination of a system, a method, an integrated circuit, a computer program, or a recording medium. The program may be stored in the recording medium in advance, or may be supplied to the recording medium via a wide-area communication network including the Internet or the like.

[0052] Hereinafter, embodiments will be specifically described with reference to the drawings.

[0053] Note that all of the embodiments described below show general or specific examples. Numerical values, shapes, components, arrangement positions and connection forms of components, steps, order of steps, etc. shown in the following embodiments are merely examples and are not intended to limit the present disclosure. In addition, among the components in the following embodiments, components not described in the independent claims are described as arbitrary components.

[0054] Also, in each figure, substantially the same configurations are denoted by the same reference numerals, and overlapping descriptions are omitted or simplified.

[0055] Further, in this specification, terms indicating relationships between elements such as the same and matching, as well as numerical values and numerical ranges, are not expressions representing only strict meanings, but are expressions meaning that they include substantially equivalent ranges, for example, a difference of about several percent (or about 10%).

[0056] Furthermore, in this specification, ordinal numbers such as "first," "second," etc., do not indicate the number or order of components unless otherwise specified, but are used to avoid confusion and distinguish similar components. Ordinal numbers ("first," "second," etc.) may be replaced as appropriate.

[0057] (Embodiment) The security resource optimization system according to this embodiment will be described below with reference to Figures 1 to 24B.

[0058] [1. Configuration of the Security Resource Optimization System] First, the configuration of the security resource optimization system according to this embodiment will be described with reference to Figure 1. Figure 1 is a block diagram showing the functional configuration of the security resource optimization system 1 according to this embodiment. Note that Figure 1 shows an exemplary functional configuration of the security resource optimization system 1, and the functional configuration of the security resource optimization system 1 is not limited to Figure 1.

[0059] As shown in Figure 1, the security resource optimization system 1 comprises a change adjustment request device 10, a resource adjustment device 20, a storage device 30, and a system control device 40. The security resource optimization system 1 is an information processing system that supports security monitoring for an organization that possesses multiple monitoring environments. Specifically, the security resource optimization system 1 performs a process to redistribute SOC-side resources (monitoring resources) allocated to security monitoring of each of the multiple monitoring environments, based on the security resources required for security monitoring of each of the multiple monitoring environments. Examples of organizations that are subject to monitoring include businesses, organizations, and local governments (e.g., local governments) that possess multiple monitoring environments, but it may also be any other organization that has multiple monitoring environments. Note that optimization is not limited to distributing security resources in the most appropriate way, but also includes adjusting the distribution as appropriate according to the situation.

[0060] First, the resource redistribution performed by the security resource optimization system 1 will be explained with reference to Figures 2A and 2B. Figure 2A is a diagram showing an example of resource distribution before adjustment in the security resource optimization system 1 according to this embodiment. Figure 2B is a diagram showing an example of resource distribution after adjustment in the security resource optimization system 1 according to this embodiment. Figures 2A and 2B describe the case where the SOC's monitoring target is environments 1 to 3, which are facilities owned by Company A. In this specification, "resource" means security resource. The environment here refers to facilities owned by Company A, such as buildings, factories, and apartment buildings, but is not limited to these. Also, each owned facility may be located spaced apart from each other. Furthermore, the environment may be a unit from which the content of the SOC's security monitoring can be changed. For example, if the security monitoring level is changed in a certain environment, the security monitoring level of the entire environment is changed uniformly.

[0061] As shown in Figure 2A, for example, when the same or similar monitoring systems are installed in each facility, the monitoring resources may be distributed equally (i.e., 1 / 3 each) to each environment 1 to 3. This allows each environment 1 to 3 to be monitored at a similar level of security. For convenience, the monitoring resources owned by the SOC are assumed to be 1.

[0062] Here, given that the likelihood of a security incident occurring changes moment by moment due to various factors, and that security requirements may differ in each environment (1-3), it is desirable to customize security services, such as raising the security monitoring level at any given time. This allows for more flexible customization of services by both the user and the SOC, enabling a more cost-effective and appropriate security response. Furthermore, the SOC can encourage users to try out various services and emphasize the importance of security.

[0063] However, the resources that the SOC (State of Control) can allocate to security are limited. For example, it may be difficult for the SOC to increase the security monitoring level by adding personnel or finely adjusting internal resources.

[0064] Therefore, the security resource optimization system 1 disclosed herein calculates the amount of security resources required for each environment according to the request and reallocates the current total resources (monitoring resources) of the SOC to match the amount of security resources required for each environment. This makes it possible to respond to requests even if, for example, there are no additional personnel available on the SOC side (no additional monitoring resources available).

[0065] As shown in Figure 2B, the security resource optimization system 1 redistributes monitoring resources, which were previously equally allocated to each environment, based on the amount of security resources required for each environment. For example, the security resource optimization system 1 increases the amount of monitoring resources allocated to environment 3, where an increase in the security monitoring level is desired, and decreases the amount of monitoring resources allocated to environments 1 and 2, where a decrease in the security monitoring level is possible. This suppresses an increase in the amount of monitoring resources required for security monitoring in environments 1 to 3, while improving the security monitoring level of the desired environment, thus enabling more flexible customization of security services.

[0066] The security resource optimization system 1 acquires the security resources required for security monitoring in each of the multiple monitoring environments (environments 1 to 3) in order to realize such customization of security services, and redistributes the monitoring resources allocated to security monitoring in each of the multiple monitoring environments based on the security resources of each of the multiple monitoring environments.

[0067] Furthermore, raising the security monitoring level may incur costs for the user (in this case, Company A). The security resource optimization system 1 may also use these costs to redistribute monitoring resources.

[0068] Referring again to Figure 1, when the change adjustment request device 10 acquires service / resource request change information, it requests the resource adjustment device 20 to redistribute resources. For example, if the change adjustment request device 10 acquires service / resource request change information that includes a change in service content, it outputs the information to the resource adjustment device 20 and requests adjustment of monitored resources (i.e., redistribution of resources).

[0069] Furthermore, if the change adjustment request device 10 does not need to adjust the distribution of existing monitoring resources even after acquiring service / resource request change information, it does not need to request adjustment from the resource adjustment device 20. For example, the change adjustment request device 10 may determine whether it is necessary to adjust monitoring resources based on additional costs and service plans, and only if it determines that it is necessary to adjust monitoring resources may it request the resource adjustment device 20 to redistribute the monitoring resources.

[0070] Service resource request change information may include requests to change the content of security monitoring (e.g., security monitoring level), the cost of security monitoring, etc. For example, service resource request change information may include change requests entered by users, change requests entered by the SOC (monitoring system), etc. (e.g., automatically entered), additions or reductions in service or plan content, additions or reductions in costs, etc. Also, for example, service resource request change information may include at least one of the following: a change to increase monitoring resources for some of the monitoring environments among multiple monitoring environments, or for some of the rules among multiple rules for security monitoring, and a change to decrease said monitoring resources.

[0071] Examples of automated input from the system include, but are not limited to, automated input triggered by a prediction of a significant decrease in the amount of resources required next month. Furthermore, service / resource request change information may be generated based on at least one of the following: information on the occurrence of alerts (security alerts) in other similar environments (security news), and an increased likelihood of incidents occurring due to changes in the company's environment (major system changes, large-scale restructuring, etc.).

[0072] The service / resource request change information is an example of change information. The fee is the payment the user makes to the SOC for security monitoring.

[0073] The resource adjustment device 20 performs processing to redistribute monitored resources based on acquired service / resource request change information. The resource adjustment device 20 comprises a change resource calculation unit 21, a current resource management unit 22, a future resource prediction unit 23, a first storage unit 24, a resource difference confirmation unit 25, an adjustment method determination unit 26, a resource difference adjustment unit 27, an adjustment impact information generation unit 28, and a second storage unit 29. The resource adjustment device 20 also includes a processor and memory. The memory is ROM (Read Only Memory) and RAM (Random Access Memory), and can store programs executed by the processor. Each function of the resource adjustment device 20 is realized by the processor that executes the programs stored in memory. The resource adjustment device 20 may be realized by a stationary PC (Personal Computer), a mobile terminal such as a smartphone or tablet, or a server device. The resource adjustment device 20 is an example of an information processing device.

[0074] The resource change calculation unit 21 calculates the resources that will be added or reduced as a result of the changes to the service plan, cost details, etc., according to the changed service plan, cost details, etc. The resource change calculation unit 21 calculates the amount of resources that will change as a result of the changes to the service plan, cost details, etc., based on the service / resource request change information. The resource change calculation unit 21 is an example of an acquisition unit.

[0075] The current resource management unit 22 calculates the total amount of resources currently provided by the monitoring team to the target customer (i.e., the total amount of monitoring resources). The current resource management unit 22 is an example of an acquisition unit.

[0076] The future resource forecasting unit 23 predicts the amount of resources for a specified period based on the current amount of resources. If there are seasonal fluctuation factors, these fluctuation factors may be used in predicting the amount of resources. For example, if the target service plan is to be added next month, the future resource forecasting unit 23 predicts how much resources will be needed if the same plan is continued during that period (in this case, next month). The future resource forecasting unit 23 is an example of an acquisition unit.

[0077] The first storage unit 24 stores the prediction results calculated by the algorithm of the future resource prediction unit 23. The prediction results include the amount of resources required for a specified period. The first storage unit 24 is implemented by a non-volatile storage device (SSD (Solid State Drive) or HDD (Hard Disk Drive)), etc.

[0078] The resource difference confirmation unit 25 checks the difference in resources required for the change based on the predicted amount of resources, the amount of resources that need to be changed (such as additional resources), and the current total amount of resources. For example, the resource difference confirmation unit 25 calculates the difference between the amount of resources required for security monitoring next month, taking into account changes such as the plan, and the amount of monitoring resources that the SOC can provide next month.

[0079] The adjustment method determination unit 26 determines the range of adjustable resources, the adjustment method, and the priority of the adjustment targets based on the difference that occurs when a change is made (the difference calculated by the resource difference confirmation unit 25) and parameters such as the risk status and monitoring plan status of each environment.

[0080] The resource difference adjustment unit 27 creates an adjustment plan to adjust the resource difference using the specified adjustment method. The resource difference adjustment unit 27 is an example of an adjustment unit.

[0081] The adjustment impact information generation unit 28 generates impact information indicating the effects resulting from the adjustments, based on the created adjustment details and their respective supplementary information. The adjustment impact information generation unit 28 may also generate the impact information in natural language using a language model such as LLM (Large Language Models).

[0082] The second storage unit 29 stores the adjustment plan creation result (i.e., the adjustment plan). The adjustment plan creation result includes the results of considering how to adjust the monitoring of the current environment according to the changes in the service plan. The adjustment plan creation result may also include information indicating what kind of impact (e.g., risks) there will be as a result of the adjustment. The adjustment plan creation result may also include the results of resource redistribution. The impact can be obtained from the impact information and may include, for example, that it becomes more difficult to detect a particular cyberattack. The second storage unit 29 is implemented by a non-volatile storage device (SSD or HDD), etc.

[0083] The storage device 30 stores various information necessary for the resource adjustment device 20 to redistribute resources. The storage device 30 is configured to include a non-volatile storage device (SSD or HDD), etc.

[0084] The storage device 30 stores risk calculation information 31, resource adjustment method information 32, resource prediction parameters 33, SOC system information 34, monitoring plan / service information 35, and past ticket information 36.

[0085] The risk calculation information 31 is information used to calculate the likelihood of future incidents occurring in that environment, and includes, for example, at least one of the following: information from a checklist entered by a user (see, for example, Figure 13 described later), collected incident information, security news, and statistical information regarding the occurrence of alerts in the environment.

[0086] The resource adjustment method information 32 is information for determining the adjustment method, and includes, for example, at least one of the types of resource adjustment methods and information indicating the effects and impacts of each type.

[0087] The resource forecast parameters 33 are various parameters that prevent the prediction that the number of tickets will be the same this month and in the future (for example, next month), and include at least one of the following: seasonal fluctuations, pre-entered event information, personnel changes, and reductions in man-hours due to a better understanding of the environment. The resource forecast parameters 33 are used when forecasting future resources.

[0088] A ticket is a unit for managing an alert that has occurred. A ticket is also referred to as an alert ticket. Furthermore, in this specification, a ticket may be treated as synonymous with an alert (alert information).

[0089] SOC System Information 34 is information used to calculate the current total resources, and includes information such as the skills of each SOC analyst (hereinafter also referred to as analyst) and the number of analysts who possess those skills.

[0090] Monitoring plan / service information 35 includes information indicating what kind of environment is currently being provided to each customer under what plan or service.

[0091] Past ticket information 36 is information about tickets that have occurred in the past, and includes, for example, how many tickets were generated in which environments in the past, and how long it took to process each ticket.

[0092] The system control device 40 controls the SOC-side system, that is, it redistributes resources in each environment based on the adjustment plan. The system control device 40 includes a system reflection determination unit 41, a system reflection unit 42, a display information generation unit 43, a third storage unit 44, a fourth storage unit 45, and a fifth storage unit 46. The system control device 40 also includes a processor and memory. The memory is ROM and RAM, and can store programs executed by the processor. Each function of the system control device 40 is realized by the processor and other components that execute the programs stored in memory. The system control device 40 may be realized by a stationary PC, a mobile terminal such as a smartphone or tablet, a server device, etc.

[0093] The system reflection determination unit 41 determines whether or not to automatically reflect the adjustment proposal based on the reflection determination parameters, which are parameters used for the determination. The system reflection determination unit 41 may use at least one of the adjustment content and the impact content in its determination.

[0094] The system reflection unit 42 reflects the changes in the ticket management system (not shown) etc. if the system reflection determination unit 41 determines that there are no problems with the reflection. The system reflection unit 42 controls the SOC-side system to perform security monitoring with the redistributed monitoring resources, for example. The system reflection unit 42 updates the ticket management table, for example.

[0095] The display information generation unit 43 generates display information for visualizing the reflection results, etc., and displaying it to at least one of the SOC and the user, and transmits it to the SOC or the user's information terminal.

[0096] The third storage unit 44 stores reflection determination parameters, which include various parameters for determining whether or not to reflect the adjustments. The reflection determination parameters include, for example, a threshold (e.g., a certain number) for determining whether to automatically handle changes to ticket expiration dates or to request a decision from the SOC or the customer.

[0097] The fourth memory unit 45 stores the ticket management table (management information) that SOC analysts normally use in their monitoring work. The management information includes, but is not limited to, the type of ticket and the number of corresponding tickets.

[0098] The fifth storage unit 46 stores the final adjustment execution and reflection results. The fifth storage unit 46 also stores the display information generated by the display information generation unit 43.

[0099] The third to fifth storage units 44 to 46 are implemented using non-volatile storage devices (SSD or HDD), etc.

[0100] [2. Operation of the Security Resource Optimization System] Next, the operation of the security resource optimization system 1 configured as described above will be explained with reference to Figures 3 to 24B. Figure 3 is a flowchart showing the operation (information processing method) of the security resource optimization system 1 according to this embodiment.

[0101] As shown in Figure 3, the resource adjustment device 20 first performs initial settings for each monitoring environment (S10). The resource adjustment device 20 sets initial settings such as the scope of alert response and the priority of alert response. These initial settings may be pre-configured for each monitoring environment.

[0102] Next, the resource adjustment device 20 checks for the need for periodic reassessment and improvement of security monitoring levels for each environment (S20). Based on the alert occurrence history, the resource adjustment device 20 determines whether the initial settings are sufficient and whether there is a need to improve the security monitoring level (e.g., the degree of necessity). If the number of alerts is increasing or exceeds a predetermined number, the resource adjustment device 20 may determine that there is a high need to improve the security monitoring level (e.g., the degree of necessity is above a predetermined level).

[0103] Next, the resource adjustment device 20 determines, based on the check result in step S20, whether or not an improvement in the security monitoring level or security measures are necessary (S30). If the resource adjustment device 20 determines that an improvement in the security monitoring level or security measures are necessary (Yes in S30), it proceeds to step S40. If it determines that an improvement in the security monitoring level or security measures are unnecessary (No in S30), it terminates the process. Improving the security monitoring level corresponds to making changes that increase the security resources required for security monitoring.

[0104] Next, the resource adjustment device 20 creates services to improve the security monitoring level or implement security measures, such as adding rules or an IDS (Intrusion Detection System) (S40). The resource adjustment device 20 creates services, for example, based on predetermined procedures. The rules indicate the conditions for issuing a ticket (conditions for detecting an anomaly), and are not limited to, for example, a device that does not communicate with the outside world communicating using HTTP (Hypertext Transfer Protocol), authentication failing a predetermined number of times, or the amount or number of communications exceeding a predetermined value. The rules can be, for example, rules that can detect cyberattacks.

[0105] It should be noted that improving security monitoring levels is not limited to adding rules or IDS. Improving security monitoring levels may also involve, for example, changing the severity of alerts in the target monitoring environment (e.g., increasing the severity of alerts you want to focus on), changing the thresholds of the rules used, or assigning analysts with higher unit costs (skills). Changing the thresholds of the rules used doesn't change what the rule should monitor, but for example, lowering the threshold allows you to increase the amount of communication that needs to be checked (in other words, increase the number of tickets). Assigning analysts with relatively higher unit costs (skills) allows senior analysts to concentrate their efforts on high-priority issues. It should be noted that improving security monitoring levels is also possible through adding rules and changing the rule sets themselves.

[0106] Next, the resource adjustment device 20 determines whether additional resources are needed to execute the service (S50). The resource adjustment device 20 may determine whether additional resources are needed based on the service, the resources required to execute the service, and the current resource allocation status to each environment. If the resource adjustment device 20 determines that additional resources are needed (Yes in S50), it proceeds to step S60. If it determines that additional resources are not needed (No in S50), it terminates its monitoring operation.

[0107] Next, the resource adjustment device 20 generates user selection items for the user to select countermeasures for the additional resources required, and notifies the user (S60).

[0108] Next, the resource adjustment device 20 obtains the additional service and the costs that the user can add (additional costs) (S70), and determines whether the additional service can be covered by the additional costs (S80). If the cost required for the additional service is greater than the additional costs, the resource adjustment device 20 determines that it can be covered by the additional costs (No in S80) and proceeds to step S90. If the cost required for the additional service is less than or equal to the additional costs (Yes in S80), the process ends.

[0109] Next, the resource adjustment device 20 performs resource redistribution (S90).

[0110] Now, step S90 will be explained with reference to Figure 4. Figure 4 is a flowchart showing the detailed operation (information processing method) of step S90 shown in Figure 3.

[0111] As shown in Figure 4, first, the resource adjustment device 20 acquires the desired change (S91). For example, the resource adjustment device 20 acquires the desired change based on the service resource change request information from the change adjustment request device 10.

[0112] Next, the resource change calculation unit 21 predicts the resources that need to be added or modified in response to the added content (S92a). In step S92a, for example, the unit predicts the number of alerts that will increase due to raising the security monitoring level, that is, the amount of resources that will increase due to the increase in alerts (the number of alerts that will increase). The resources predicted in step S92a are an example of the first security resources that will be generated by the service resource change request information.

[0113] The resource change calculation unit 21 predicts the resources that need to be added or modified based on at least one of the results of applying the additional plan to the historical data of the environment in question, and information regarding alerts that occurred when the plan was operated in another environment. The historical data includes the number of alerts or the increase in alerts when the additional plan was previously executed in the environment in question. The alert information includes at least one of the following: the number of alerts, the actual number of responses, and the response time.

[0114] Figures 5A to 5C are diagrams illustrating an example of step S92a shown in Figure 4. Rules A and B are rules added in the additional plan. When a condition matching these rules (i.e., an alert) is detected, a ticket is issued.

[0115] Figure 5A shows the simulation results for additional plans, specifically the number of tickets when rules A and B are added in environment X. Figure 5A shows that in environment X, adding rule A increases the number of tickets by 3, and adding rule B increases the number of tickets by 2. The changes in the number of tickets (in this case, an increase of 3 and an increase of 2) are examples of the first security alert.

[0116] Figure 5B shows the analyst level and average ticket response time for additional plans. Figure 5B shows that when adding Rule A, it takes an average of 10 minutes for an analyst at level 1 and an average of 20 minutes for an analyst at level 2 to respond to tickets.

[0117] Figure 5C shows the amount of resources needed to respond to new plan changes, etc., with the current personnel (i.e., without increasing personnel in the SOC). Specifically, it shows that the expected number of tickets to be handled for ticket type A is 20 on day 1 and 5 on day 2. A ticket type is a group of tickets classified according to specific rules to facilitate resource management, and it includes at least one ticket. A ticket type may also be a group of rules. To monitor resource amounts at substantially the same granularity, rules that can monitor resource amounts at substantially the same granularity are classified into the same group. For example, rules with the same or similar effort may be classified into the same group. Similar effort means that the difference in effort between two rules is less than or equal to a predetermined number. Alternatively, for example, multiple rules may be classified by the time required for processing. The date is indicated as day 1, etc., but the display format is not particularly limited and may be indicated as, for example, 1 / 1, etc.

[0118] Furthermore, if the service resource change request information includes information that reduces security resources, such as a reduction in services, the change resource calculation unit 21 predicts the reduced security resources as the first security resources in step S92a.

[0119] Referring again to Figure 4, the current resource management unit 22 calculates the current resource status (S92b). The current resource status calculates the amount of resources that can be handled with the current personnel, etc. The current resource management unit 22 calculates the current resources from the number of alerts generated in the target customer's entire environment and the response time, or from the level of analysts who responded and the number of people for each. For example, the current resource management unit 22 calculates how many alerts can be processed in a day. The resources calculated in step S92b are an example of the second security resources that can be handled in the current situation.

[0120] Figures 6A to 6C are diagrams illustrating an example of step S92b shown in Figure 4. Rules 1 and 2 are the rules included in the current plan.

[0121] Figure 6A shows the average response time for tickets by rule and analyst level. Specifically, for Rule 1, it takes an average of 30 minutes for analyst level 1 and an average of 10 minutes for analyst level 2. For Rule 2, it takes an average of 20 minutes for analyst level 1 and an average of 5 minutes for analyst level 2.

[0122] Figure 6B shows the analyst levels and current structure, specifically indicating that there are 10 analysts at Analyst Level 1 and 5 analysts at Analyst Level 2. In other words, currently, there are 10 analysts at Analyst Level 1 and 5 analysts at Analyst Level 2 who are available to handle a ticket if one is issued.

[0123] Figure 6C shows the total resources that can be handled by the current staff. The estimated number of tickets that can be handled for ticket type A is 100 on day 1 and 150 on day 2. The number of analysts at each level may change from day to day due to shifts and other factors, so the estimated number of tickets that can be handled may change each day.

[0124] Referring again to Figure 4, the future resource prediction unit 23 predicts the future resource status based on the number of tickets handled in the past (S92c). The future resource prediction unit 23 sets a prediction unit such as daily and predicts how many alerts are likely to occur in the future based on various fluctuation parameters, thereby predicting the future resource status. The future resource status includes the number of tickets that are predicted to require attention in a certain period in the future (for example, next month). In step S92a, for example, the number of alerts that are likely to occur next month is predicted, and the necessary resources are predicted based on the prediction. The number of tickets predicted here is the number of tickets that are predicted to occur if the current plan is continued. The resources predicted in step S92c are an example of the third security resources that will be required in the future.

[0125] Figure 7 is a diagram illustrating an example of step S92c shown in Figure 4.

[0126] As shown in Figure 7, the historical ticket handling count includes actual values ​​for the number of tickets handled per day, per rule, and per environment.

[0127] The future resource forecasting unit 23 may use a machine learning model to perform a time-series forecast of the number of tickets generated. This machine learning model is pre-trained by machine learning to take the number of tickets handled in the past as input and output time-series data of the number of tickets generated in a predetermined future period. In addition to the number of tickets handled in the past, this machine learning model may also be pre-trained by machine learning to take at least one other factor, such as planned personnel changes and seasonal fluctuations, as input and output time-series data of the number of tickets generated in a predetermined future period. The future resource forecasting unit 23 uses the machine learning model to predict the amount of resources that will be required to handle each monitoring environment with the current personnel during a specified period (for example, each day within a predetermined future period). Each monitoring environment is the environment of a facility owned by the same monitored organization.

[0128] Furthermore, the following example parameters may be used in resource forecasting. For example, the level of understanding of the environment and response time may be used as parameters. Depending on parameters such as the level of understanding of the target monitoring environment and the period of operation since the start of monitoring, even if the alert ticket is the same as in other environments, the response speed of the analyst may change (for example, the amount of work required decreases as the level of understanding of the environment increases), or some processes may be automated, so the amount of resources may be calculated taking these factors into account. The future resource forecasting unit 23 may, for example, use the trend of response time reduction relative to past monitoring operation time to calculate how much the response time can be reduced on average next month, and then forecast the amount of resources taking these factors into account.

[0129] Furthermore, information such as seasonal fluctuations may be used as special parameters. This information allows for adjustment of the amount of resources required. For example, it is possible to predict that alerts will increase because traffic volume increases seasonally. For instance, it is conceivable to improve the accuracy of the prediction algorithm by fine-tuning it by incorporating seasonal information such as the fact that in month X each year, the number of alerts generated by company A is considerably higher than average due to congestion, or by incorporating information such as the expectation that there will be many alerts next month due to an event.

[0130] Furthermore, planned personnel changes may be used as special parameters. Since the total amount of resources will change due to changes in skill sets, personnel changes, etc., rather than the same personnel structure as before, the future resource forecasting unit 23 may take these parameters into account when making its forecast.

[0131] Steps S92a to S92c above describe an example of managing resources by sharing them across applicable ticket types, but this is not the only example. For instance, one senior analyst could be used as the baseline to manage resources for tickets and analysts of other ranks. Similarly, while resource management is shown using ticket categories as an example, other methods are also acceptable.

[0132] There are several ways to think about resources in steps S92a to S92c. For example, they may be calculated based on the number of tickets as described above, or, as another example, based on people, skill sets, and man-hours.

[0133] Steps S92a to S92c are an example of acquiring security resources required for security monitoring of multiple monitoring environments. These security resources may be acquired from external devices.

[0134] Referring again to Figure 4, the resource difference confirmation unit 25 calculates future resource shortages based on the resources predicted or calculated in steps S92a to S92c (S93). The resource difference confirmation unit 25 calculates the difference between the amount of resources currently available and the amount of resources (future prediction + additional man-hours), etc., based on the resources predicted or calculated in steps S92a to S92c. The resource difference confirmation unit 25 calculates the difference in resource amounts for a specified period (for example, each day within a predetermined future period). A shortage of resources is an example of security resources.

[0135] Figure 8 is a diagram illustrating an example of the amount of resources required to monitor each environment with the current personnel during a specified period, according to this embodiment. Figure 9 is a diagram illustrating an example of the total amount of resources that can be handled by the current personnel, according to this embodiment. Figure 10 is a diagram illustrating an example of the amount of resources required to newly respond to plan changes, etc., with the current personnel, according to this embodiment.

[0136] Figure 8 shows the amount of resources available for each ticket type on each day in each environment (here, the number of tickets that the SOC can handle with its current personnel). This amount of resources can be calculated, for example, based on the information shown in Figures 6A to 7. In Figure 8, the number of tickets that can be handled for ticket type A in environment 1 is 20 on day 1 and 10 on day 2.

[0137] Here, if the total number of tickets shown in Figure 8 and Figure 10 is less than or equal to the number of tickets shown in Figure 9, then the current staff can handle the workload, and no adjustment is deemed necessary. Conversely, if the total number of tickets is greater than the number of tickets shown in Figure 9, then resources are insufficient, and adjustment is deemed necessary. Note that the determination of whether or not adjustment is necessary is made for each ticket type and each date, but is not limited to these criteria.

[0138] Referring again to Figure 4, the resource difference confirmation unit 25 then determines the adjustable range (S94). The resource difference confirmation unit 25 determines the adjustable range using a simple rule, such as not adjusting tickets with a severity level of high or higher, so that the target (multiple monitoring environments) does not fall below a certain security monitoring level. If the rule is not to adjust tickets with a severity level of high or higher, the adjustable range will be for severity levels of medium and low. Severity represents the original priority level for responding to an alert and is determined based on the assumed attack on the target. As an example, severity may also be classified according to the risk value, which will be described later. The adjustable range may also be information indicating, for example, which tickets in which environments should be postponed. The rules for determining the adjustable range may be pre-set and stored in the storage device 30.

[0139] Next, the resource difference confirmation unit 25 determines the priority adjustment target (S95). If the user specifies (for example, an instruction indicating that this environment may be adjusted temporarily), the resource difference confirmation unit 25 determines the specified environment as the priority adjustment target. If there is no specification, or if the adjustment is insufficient based on the specification alone, it may sequentially select other environments. The priority adjustment target is determined, for example, based on whether the likelihood of an incident occurring in that environment is high. Alternatively, the priority adjustment target may be determined based on the weighting results at multiple levels of granularity (ticket unit, monitoring environment unit, etc.), each weighted by parameters. The priority adjustment target is information indicating which rule or environment to adjust first.

[0140] First, we will explain the case where the priority adjustment target is determined on a per-monitoring environment basis (the priority of adjustments is determined on a per-monitoring environment basis), referring to Figures 11 to 14. Figures 11 and 12 are diagrams illustrating an example of step S95 shown in Figure 4.

[0141] Figure 11 shows a table for calculating which of environments 1 and 2 should take priority, and Figure 12 shows the priority adjustment target determined from the calculation results.

[0142] As shown in Figure 11, a score for each environment is obtained for each parameter. The parameters include similarity to the changed environment, ticket growth rate per month, number of tickets generated per month, and user check content score.

[0143] The similarity score to the changed environment is a value based on the degree of similarity to the environment that needs enhanced security, and is calculated based on various parameters such as industry, communication content, and equipment information. If the degree of similarity is high (for example, relatively high, or above a predetermined value), it is considered that the current resources should be maintained without making adjustments as much as possible. Therefore, the higher the similarity, the higher the degree of similarity score, while the score for similarity to the changed environment will be calculated to be lower.

[0144] The ticket growth rate per month indicates the rate at which tickets increase on a monthly basis. A high ticket growth rate suggests an increased likelihood of incidents occurring in the target field environment, and this parameter is included to determine priorities based on this perspective.

[0145] The "Number of Tickets Issued per Month" indicates the average number of tickets issued per month over the past few months.

[0146] The user check score is a numerical representation of the likelihood of an attack incident occurring using a checklist. The calculation of the user check score will be described later, referring to Figures 13 and 14.

[0147] The resource difference confirmation unit 25 determines the adjustment priority from the total score of "value of each parameter × weight for each parameter," but other methods may also be used. Furthermore, if the score result is above a certain value, the resource difference confirmation unit 25 may designate the environment as requiring monitoring and exclude it from adjustment. Figure 12 shows that environments 1 and 2 have higher environment adjustment priority (adjustment priority) in that order.

[0148] Figures 13 and 14 are diagrams illustrating the calculation of the user check score shown in Figure 11.

[0149] Figure 13 shows an example of a user-filled questionnaire (checklist). This questionnaire outlines the user's checklist for determining the priority of adjustments on a per-monitoring environment basis, and is created for each environment. Scores may be 0 or 1, or a numerical value representing three or more levels, such as a 10-point scale. Input can be performed, for example, by an analyst or the user.

[0150] Furthermore, the input of scores could be automated by limiting the processing to the range of information that can be automatically acquired.

[0151] Figure 14 shows the results of calculating scores for each environment ID based on the input results of the questionnaire shown in Figure 13. The scores shown in Figure 14 are the sum of the scores for each check ID in the questionnaire shown in Figure 13. These scores are used as the user check content scores shown in Figure 11. The scores indicate the degree of likelihood of a security incident occurring in the monitoring environment, with higher values ​​indicating a higher risk.

[0152] Next, we will explain the case where priority adjustment targets are determined on a rule-by-rule basis (where the priority of adjustments is determined on a rule-by-rule basis), referring to Figures 15A to 15C. Figures 15A to 15C are diagrams illustrating another example of step S95 shown in Figure 4. When it is on a rule-by-rule basis, whether or not to adjust a rule (for example, the priority of adjustments) is determined based on the importance of that rule in that environment. The importance is calculated based on the risk and past occurrences (positive detection / false detection), and rules with lower importance are given a higher priority for adjustment. Note that in Figures 15A and 15B, this importance is referred to as the "environmental rule importance." In addition, the "environmental rule importance" may also be simply referred to as "rule importance" or "importance."

[0153] Figures 15A and 15B show tables containing the risk for each rule, cumulative number of triggers (cumulative number of alerts), cumulative number of positive / false detections, expected trigger value / day, rule importance under different environments (for example, Figure 15A shows the case for Environment 1, and Figure 15B shows the case for Environment 2), as well as the increase or decrease in alerts due to adjustments.

[0154] Risk is a value determined by an analyst, indicating the degree of danger if an anomaly in the rule is detected. Risk is determined on a one-to-one basis for each rule.

[0155] The cumulative number of triggers indicates the cumulative number of alerts generated related to that rule.

[0156] The cumulative number of correct / false detections indicates the number of alerts that were correctly detected and the number of alerts that were falsely detected.

[0157] The "Expected Trigger Value / Day" indicates the predicted number of alerts that will occur in a day.

[0158] The environmental rule importance is the degree to which security monitoring of a rule is necessary in that environment, and is calculated based on at least the risk. In this embodiment, it is calculated based on the risk and the cumulative number of correct / false detections. The environmental rule importance is, for example, a numerical value between 0 and 1. The resource difference confirmation unit 25 calculates a base value for the environmental rule importance of the rule based on the risk of the rule, and further calculates the environmental rule importance by taking into account the ratio of false detections to correct detections. The resource difference confirmation unit 25 may, for example, convert the risk to a base value using a pre-set conversion table, and calculate the environmental rule importance by lowering the base value when false detections are relatively high, or raising the base value when correct detections are relatively high.

[0159] The "Alert Increase / Decrease Due to Adjustment" indicates the predicted increase or decrease in the number of alerts generated due to resource adjustments.

[0160] Figure 15C shows the priority order of adjustments at the rule level, determined based on the tables shown in Figures 15A and 15B. Items excluded in Figure 15C are not subject to adjustment; that is, they are items that will maintain their current resource status.

[0161] In Figure 15C, in Environment 1, rules 1 to 3 are excluded, and the priority order for adjustment is rules 6, 4, and 5. In Environment 2, rule 2 is excluded, and the priority order for adjustment is rules 6, 4, 3, 1, and 5. For example, in this environment, at least one of the priority information and extension information of a rule with a higher adjustment priority (the priority shown in Figure 15C) among multiple rules is changed with priority over rules with a relatively lower adjustment priority.

[0162] The resource difference confirmation unit 25 may, for example, exclude rules whose risk or importance is above a predetermined value from the adjustment range. The resource difference confirmation unit 25 may, for example, exclude rules with a risk of 8 or higher, or an importance of 0.9 or higher, from adjustment. The resource difference confirmation unit 25 may also determine the priority order from the rules with the lowest importance among the rules that were not determined to be outside the adjustment range. Furthermore, if there are two or more rules with the same importance, the resource difference confirmation unit 25 may determine the priority order by prioritizing the rule with the higher risk, or it may assign the same priority to each of those two or more rules.

[0163] While the above example describes determining priority for each rule individually, priority is not limited to this. For example, priority may be determined by category (group of rules) such as rules that meet certain conditions (e.g., rules with an importance of 0.5 or less). In this case, one priority is assigned to each rule with an importance of 0.5 or less.

[0164] Referring again to Figure 4, the adjustment method determination unit 26 determines the resource adjustment method by sequentially selecting from the multiple options that have the least impact on the field, since there are multiple options for resource adjustment methods (S96). Examples of resource adjustment methods include, but are not limited to, alert suppression by threshold adjustment, extension of response deadlines for some alerts, and changes to monthly reports. Threshold adjustment means, for example, raising the threshold of some rules, and is an adjustment method that secures resources by adjusting the threshold of rules to reduce the number of alerts generated, regardless of whether it is the same environment or not. Extending the response deadline for some alerts means changing from real-time processing to extending the deadline, and is an adjustment method that lowers the priority of response by prioritizing high-priority alerts, eliminating deadlines for low-severity alerts, and handling them during idle time, regardless of whether it is the same environment or not. Changing to monthly reports means changing from real-time processing to processing all at once when creating monthly reports, and is an adjustment method that lowers the priority of response by prioritizing high-priority alerts, eliminating deadlines for low-severity alerts, and processing them when creating monthly reports.

[0165] The adjustment methods are not limited to those described above and may include incorporating some rules, changing the logs and IDS used, switching to automated solutions, assigning lower-priced analysts, or simply increasing or decreasing the number of personnel. Note that the unit price is linked to the analyst's skills, and a lower unit price means the analyst has lower skills.

[0166] Inclusion of some rules means that when there are rules that may occur simultaneously, such as a rule that examines details and a rule with a higher granularity, the rules that are in an inclusion relationship are used preferentially, and the details rule is excluded (i.e., detection is not performed by the details rule). Changing the logs / IDS used means reducing the number of log types, such as IDS, that are checked for changes, or reducing the frequency of acquisition. Switching to automated responses means that although the accuracy will be lower than manual responses, the system will automatically perform reputation checks and minimum responses using pre-defined rules (e.g., playbooks only). Assigning analysts with lower rates or skills means assigning analysts with lower rates to some alerts and moving senior analysts to critical environments. Increasing or decreasing personnel means increasing or decreasing the number of personnel responsible for monitoring the environment in question. The adjustment method determination unit 26 may, for example, if there is sufficient resources (and budget for additional costs), simply suggest to the user or analyst that resources be reduced from the current level to lower costs because the number of alerts generated is lower than expected, or it may automatically adjust within the set budget.

[0167] The adjustment method determination unit 26 selects one or more adjustment methods from the above-mentioned multiple adjustment methods such that the security monitoring level does not decrease.

[0168] Figure 16 is a diagram illustrating an example of step S96 shown in Figure 4. Figure 16 is a table containing information on multiple adjustment methods.

[0169] As shown in Figure 16, the table includes adjustment items, impact summaries, applicable targets, and priorities.

[0170] The adjustment items describe the various methods for adjusting resources. These adjustment items include, for example, extending ticket expiration dates, generating monthly reports, and suppressing resources through threshold adjustments.

[0171] The impact summary shows the effects (e.g., concerns) of implementing adjustments based on the adjustment items.

[0172] The scope of what can be used includes information that restricts the rules on which adjustments can be made using the adjustment item, such as restrictions on severity and rule importance.

[0173] Priorities are set in advance based on factors such as the degree of impact on the site, with items that have a smaller impact on the site receiving higher priority.

[0174] Referring again to Figure 4, the resource difference adjustment unit 27 generates a resource adjustment plan (S97). The resource difference adjustment unit 27 generates a plan for, for example, determining whether to respond immediately or postpone at the severity level, or suppressing alert generation based on thresholds. The resource difference adjustment unit 27 performs adjustments to the adjustment priority determined by the environment or rules, etc., so that it fits within the allowable number of tickets that can be handled by the current resources.

[0175] Figure 17 shows an example of a proposed adjustment generated in step S97 shown in Figure 4. Figure 17 shows a proposed adjustment for reducing resource utilization by 20%.

[0176] As shown in Figure 17, the adjustment plan includes the priority order of adjustment methods, the target, the response method, the reduction rate, and the cumulative reduction rate. Alternatively, the adjustment plan may be generated by implementing adjustments to the highest priority items within the adjustable range of each environment, and then using other methods to make any remaining adjustments.

[0177] The adjustment method priority indicates the order in which adjustment methods should be performed. For example, the adjustment method priority may be determined based on the priority shown in Figure 16.

[0178] The target refers to the environment and rules that will be adjusted.

[0179] The corresponding adjustments correspond to the adjustment items shown in Figure 16, and illustrate the adjustment methods for reducing resources. In the example in Figure 17, one of the following has been decided: monthly reporting, deadline extension, or threshold change.

[0180] The reduction rate indicates the percentage reduction in resources when the countermeasure is implemented for the target.

[0181] The cumulative reduction rate represents the cumulative value of the reduction rates when each adjustment method is implemented. For example, when the adjustment method with an adjustment reward priority of 3 is implemented, the cumulative reduction rate is -9%, which is the sum of the reduction rates of adjustment reward priority 1 and 2 (-3% and -4%) and the reduction rate of adjustment reward priority 3 (-2%).

[0182] The resource difference adjustment unit 27 determines the response methods in order of priority as shown in Figure 16, and determines an adjustment plan so that the cumulative reduction rate becomes -20%. In the example in Figure 17, the resource difference adjustment unit 27 generates an adjustment plan that includes performing X adjustments so that the cumulative reduction rate reaches the target of -20%. The reduction rate may be calculated using a table that shows the relationship between the target, the response method, and the reduction rate. In this way, the resource difference adjustment unit 27 performs a process to reduce security resources for one or more monitoring environments among multiple monitoring environments, excluding the monitoring environment whose security monitoring level is to be improved, or for one or more rules among multiple rules, excluding the rule whose security monitoring level is to be improved. Reducing security resources may include, for example, extending the response deadline for alerts related to the one or more monitoring environments or the one or more rules, and raising the threshold at which such alerts are detected. The resource difference adjustment unit 27 may, for example, prioritize extending the response deadlines for multiple rules in the monitoring environment with a high adjustment method priority (adjustment priority) among the one or more monitoring environments compared to other monitoring environments.

[0183] Furthermore, the resource difference adjustment unit 27 may be configured to avoid bias towards adjusting the same environment or type. The resource difference adjustment unit 27 may select items to be adjusted preferentially from a security perspective, rather than simply managing and optimizing resources. For example, if only environment 1 is adjusted, the security monitoring levels in each environment may differ significantly. Therefore, the resource difference adjustment unit 27 may generate adjustment proposals so that the security monitoring levels in all environments are at a similar level (for example, constant). For example, the resource difference adjustment unit 27 may generate adjustment proposals so that the number of monitoring environments included in the target of the adjustment proposal is the same or close to that value. Alternatively, for example, the adjustment proposal may alternate between two monitoring environments, meaning that if the adjustment method priority is odd, it includes a method for addressing environment 1, and if it is even, it includes a method for addressing environment 2. For example, the resource difference adjustment unit 27 may distribute the extension of the response deadline for multiple rules to one or more monitoring environments. One or more monitoring environments include monitoring environments other than those whose security monitoring levels are improved.

[0184] Furthermore, the resource difference adjustment unit 27 may generate adjustment proposals so that the monitoring environments in which the reduction processing is performed are distributed, for example, by performing a reduction processing on an item with a severity of 0.5 in environment 1 → performing a reduction processing on the same severity in environment 2, and so on. This unit of implementation may be, for example, a rule category unit, or a category unit classified by location on the intrusion path. For example, security risks may be distributed by prioritizing the adjustment of early-stage categories such as initial intrusion for each monitoring environment. The resource difference adjustment unit 27 may generate adjustment proposals that include prioritizing the adjustment of early-stage categories such as initial intrusion, which have less risk among the intrusion paths from initial intrusion to physical damage (attack target).

[0185] Furthermore, if the resource difference adjustment unit 27 can meet the required reduction rate in only some environments, it can avoid adjusting lower-priority monitoring environments, thereby preventing a decrease in the security monitoring level of lower-priority monitoring environments.

[0186] Referring again to Figure 4, the adjustment impact information generation unit 28 generates impact information associated with the changes included in the adjustment proposal (S98). It can also be said that the adjustment impact information generation unit 28 generates impact information for new alert response criteria (severity, threshold, etc.). The impact information is information presented to the user and includes the impact on security monitoring due to the redistribution of monitoring resources, and for example, the final impact on the adjustment proposal. For example, the impact information may include information indicating that if the adjustment proposal is implemented, the system will be more susceptible to impact if this attack occurs. The impact information may also be used when determining whether or not the content can be automatically changed (step S100 shown in Figure 3, which will be described later).

[0187] The adjustment impact information generation unit 28 may generate impact information by combining the impact summary set for the adjustment items shown in Figure 16 with the information of the items that were actually adjusted. Furthermore, the adjustment impact information generation unit 28 may determine whether the impact shown in the impact information is too large (for example, whether the impact exceeds a predetermined value). The adjustment impact information generation unit 28 may include the result of the determination of whether the impact is too large in the impact information.

[0188] Figure 18 shows an example of the impact information generated in step S98 shown in Figure 4.

[0189] The adjustment impact information generation unit 28 may generate impact information, for example, as shown in Figure 18, using a language model such as LLM. The adjustment impact information generation unit 28 may also acquire a summary sentence as impact information, obtained by inputting at least one of the impact overview, information about the target environment, and information about the target rule into a language model such as LLM. Information about the target environment may include, for example, that it is a home appliance factory environment 1, 2, or 3, and the target period XXX to YYY. Information about the target rule may include, for example, that the severity is 6 or less, and that the attack phase is reconnaissance. For example, the system may extract which rules were targeted from the target rule information and have the LLM analyze and summarize the trends.

[0190] The adjustment impact information generation unit 28 outputs the generated impact information to the analyst's information terminal, for example.

[0191] Referring again to Figure 3, the system reflection determination unit 41 of the system control device 40 uses reflection determination parameters to determine whether the changes included in the adjustment proposal can be automatically modified (S100). If the system reflection determination unit 41 determines that the changes can be automatically modified (Yes in S100), the process proceeds to step S110. If it determines that the changes cannot be automatically modified (No in S100), the process proceeds to step S130.

[0192] Next, if the display information generation unit 43 determines that the content cannot be automatically changed by the system reflection determination unit 41, it presents an adjustment proposal according to the settings (S130). The display information generation unit 43 displays the information by, for example, transmitting the adjustment proposal and impact information to the information terminal of at least one of the analyst and the user. The adjustment proposal includes the content of the redistribution of monitoring resources.

[0193] Next, the system reflection unit 42 determines whether or not it has received information indicating that it approves the adjustment proposal after the information has been transmitted by the display information generation unit 43 (S140). This information is based on input operations from at least one of the analyst and the user.

[0194] If the system reflection unit 42 determines that the proposed adjustment is acceptable (Yes in S140), the process proceeds to step S110. If it determines that the proposed adjustment is not acceptable (No in S140), the process ends.

[0195] Next, the system reflection unit 42 executes the process of changing various settings in the monitoring system (S110). The system reflection unit 42 reflects the results of the resource redistribution in the ticket management table on the SOC side. For example, for tickets for environment 1, the system reflection unit 42 changes the method of handling rules with a rule importance of 0.5 or less to a monthly report, changes the deadline for handling rules with a rule importance of 0.6 to an extended deadline, and changes the threshold for a rule importance of 0.5. Note that this change is temporary and may be automatically reverted to the original method after a predetermined period has elapsed. Step S110 corresponds to executing the process of redistributing the monitoring resources allocated to each of the multiple monitoring environments among the multiple monitoring environments.

[0196] Figure 19A shows an example of a ticket management table before the contents of the adjustment items are reflected. Figure 19A includes information about each ticket included in the ticket management table in a certain environment.

[0197] As shown in Figure 19A, the ticket management table includes the following columns: ticket no., detection name, severity, risk, environment ID, temporary importance, temporary severity level, and temporary triage method. The ticket management table according to this embodiment includes, in addition to the conventional ticket management table, temporary importance, temporary severity level, and temporary triage method as additional columns.

[0198] The ticket number is a number assigned sequentially to each ticket (alert information). The rule name is a name used to identify the rule. The severity and risk are as described above. The environment ID is identification information that identifies the corresponding monitoring environment. At least one of the severity and risk is an example of information indicating the risk of the detected anomaly.

[0199] Temporary importance indicates whether the item will be temporarily adjusted (down) or strengthened (up / add) during the change period. If it's added, it represents a temporarily added rule. Also, since the content of the adjustment items hasn't been reflected yet, rules 1 and 2 show a "-" indicating that severity hasn't been adjusted.

[0200] Temporary severity is a triage criterion separate from the original ticket's risk and severity, indicating the priority of the response to be temporarily adopted. Temporary severity may take precedence over risk and severity during the temporary period. During the temporary period, the response to the alert is determined according to the value of the temporary severity. Since the content of the adjustment items has not yet been reflected, in Figure 19A, for example, the same severity as severity is entered. Note that temporary severity and severity are not limited to "low," "medium," and "high," but may be four or more levels, or may be indicated by numbers, etc. Temporary severity is an example of priority information.

[0201] The temporary adjustment method indicates how resources will be temporarily adjusted. For example, if the deadline is extended, the extension deadline will be entered.

[0202] Temporary importance, temporary significance, and temporary adjustment methods are examples of additional information that is updated when redistributed.

[0203] Figure 19A shows an example where Rule A was added to increase the security monitoring level in a given environment.

[0204] Figure 19B shows an example of a ticket management table after the contents of the adjustment items have been reflected.

[0205] The system update unit 42 updates the ticket management table so that, because the addition of rule A increases the resources at edge 1 (environment 1), the resources at edges 2 and 3 (environments 2 and 3) are reduced. In other words, a redistribution of management resources is performed.

[0206] For example, the system implementation unit 42 reduces the importance of Rule 1 from a severity level of "medium" to a relative level, and as a method of adjustment, changes the processing of tickets for Rule 1 from real-time processing to deadline extension. Similarly, it reduces the importance of Rule 2 from a severity level of "medium" to "low," and as a method of adjustment, changes the processing of tickets for Rule 2 from real-time processing to monthly reporting. This reduces the processing load on the monitoring system related to security monitoring.

[0207] In this way, the system reflection unit 42 may achieve the reduction rate associated with the addition of rule A by distributing the targets for priority adjustment to edges 2 and 3. This makes it possible to suppress discrepancies in security monitoring levels at edges 2 and 3.

[0208] Referring again to Figure 3, the display information generation unit 43 then notifies the change processing result (S120). The change processing result may include that the setting changes corresponding to the adjustment proposal have been completed. This allows the analyst or user to be notified that the setting changes for the adjustment proposal have been completed. The change processing result is an example of display information.

[0209] Next, we will explain the operation of the resource changes during use, referring to Figure 20. Figure 20 is a flowchart showing the operation (information processing method) during use in the proposed adjustments.

[0210] As shown in Figure 20, the resource difference confirmation unit 25 of the resource adjustment device 20 confirms the difference with the assumed resource information (S210). The resource difference confirmation unit 25 compares, for example, the assumed resource status (e.g., assumed number of tickets) with the current resource status (current number of tickets) and calculates the difference. The resource difference confirmation unit 25 determines, for example, whether there is a difference between the assumed amount and the actual amount in a batch such as on a daily basis.

[0211] Next, the resource difference confirmation unit 25 determines whether or not it is necessary to readjust the ticket response deadline, etc., based on the confirmation results (S220). For example, if the number of tickets is greater than expected (e.g., a threshold), the resource difference confirmation unit 25 determines that readjustment is necessary because it is necessary to further reduce resources. Also, for example, if the number of tickets is less than expected (e.g., a threshold), the resource difference confirmation unit 25 determines that readjustment is necessary because there is sufficient resources and it is possible to shorten the deadline. Note that the resource difference confirmation unit 25 only needs to determine that readjustment is necessary if the number of tickets is greater than expected.

[0212] If the resource difference confirmation unit 25 determines that readjustment of ticket deadlines, etc. is necessary (Yes in S220), it proceeds to step S230. If it determines that readjustment of ticket deadlines, etc. is not necessary (No in S220), it returns to step S210 and continues processing.

[0213] Next, the resource difference confirmation unit 25 determines whether the current resources will affect monitoring if readjustment of ticket response deadlines, etc., is necessary (S230). The resource difference confirmation unit 25 determines that the current resources will affect monitoring if it is not possible to handle all adjustments even if all adjustments within the adjustment range are readjusted to monthly reports, etc. This allows the resource difference confirmation unit 25 to determine that monitoring will be affected, for example, if the number of tickets generated is irregularly too high. If the resource difference confirmation unit 25 determines that the current resources will affect monitoring (Yes in S230), it proceeds to step S240; if it determines that the current resources will not affect monitoring (No in S230), it proceeds to step S260.

[0214] Next, if the resource difference adjustment unit 27 determines that the current resources would affect monitoring, it generates additional adjustment proposals (S240). The resource difference adjustment unit 27 generates new other adjustment proposals, such as adding resources or further lowering the security monitoring level of the environment. Adding resources may incur additional costs.

[0215] Next, the display information generation unit 43 prompts the system to present additional adjustment proposals (S250). The display information generation unit 43 generates, for example, display information for displaying the additional adjustment proposals and transmits the generated display information to the analyst's or user's information terminal.

[0216] If approval for the additional adjustment proposal is obtained from the analyst or user, the processing from step S100 onwards shown in Figure 3 may be executed. Since this is an irregular change, it is preferable that the additional adjustment proposal be reflected not automatically, but, for example, after obtaining approval from the analyst or user. For example, if the resource difference adjustment unit 27 obtains information indicating approval for the additional adjustment proposal from the analyst or user, it may execute the processing from step S100 onwards shown in Figure 3.

[0217] Furthermore, if the resource difference confirmation unit 25 determines that there is no impact on monitoring in terms of resources (No in S230), the system reflection unit 42 executes setting change processing (setting change processing for each location) for each part of the monitoring system (S260). The system reflection unit 42 executes setting change processing for each location within the adjustment range of the current resources. The processing in step S260 is the same as in step S110 shown in Figure 3.

[0218] Next, the adjustment of ticket expiration dates will be explained with reference to Figures 21 to 24B. Figure 21 is a diagram illustrating the adjustment of ticket expiration dates. The ticket expiration date adjustment process shown below is performed, for example, by the resource difference adjustment unit 27.

[0219] As shown in Figure 21, tickets may be managed in three pools, with extension deadlines set to adjust resources. Note that the number of pools is not limited to three; two or more are acceptable.

[0220] The three pools include a priority response ticket pool, an extension (best effort) ticket pool, and a monthly reporting ticket pool.

[0221] The highest priority ticket pool includes alerts for environments where real-time security monitoring levels have been enhanced, such as those related to Service Level Agreements (SLAs) that do not allow extensions, and for environments that should not be subject to adjustment. For example, the same severity level as usual will be entered in the additional column of the ticket management table.

[0222] The deadline extension ticket pool is used when resource adjustments are necessary, such as in conjunction with improvements to the security monitoring level of the second-priority pool for deadline extensions. For example, a temporary triage level (severity) is set in the ticket management table, and a separate deadline is set. The deadline may change due to extensions or shortenings depending on the status of other tickets.

[0223] The monthly reporting ticket pool is a third-priority pool with a lower priority than the deadline extension ticket pool. It is used when resource adjustments are necessary, such as in response to improvements in security monitoring levels. For example, the ticket management table will have a temporary triage level set and will indicate that it will be addressed in the monthly report.

[0224] If there is a discrepancy of more than a predetermined amount between the predicted number of tickets (predicted value) and the actual number of tickets generated (actual value), tickets may be moved between different pools depending on the type of ticket. Various criteria can be considered for moving tickets between pools. For example, if the number of tickets related to a ticket increases and the overall anomaly level is judged to be high (in combination with alert aggregation technology), or if the discrepancy between the actual number of tickets generated and the predicted number of tickets generated is larger than a predetermined amount and adjustments are made, these are examples of cases where adjustments are made.

[0225] For example, if a ticket that was previously in the "lower priority" category becomes associated with another ticket belonging to a "highest priority" ticket pool, or if multiple extended tickets become associated with each other and a new ticket with a high overall abnormality is issued, it may be moved from the extended ticket pool to the "highest priority" ticket pool (category up). Conversely, moving from the "highest priority" ticket pool to the extended ticket pool (category down) may be prohibited, or permitted if certain conditions are met.

[0226] Furthermore, for example, if the actual amount of resources required is less than predicted, the tickets may be moved from the monthly reporting ticket pool to the extended deadline ticket pool (category up). Conversely, if the actual amount of resources required is more than predicted, the tickets may be moved from the extended deadline ticket pool to the monthly reporting ticket pool (category down).

[0227] Figure 22A shows an example of a ticket management table when a ticket belongs to the extension ticket pool. Figure 22B shows an example of a ticket management table when a ticket is moved from the extension ticket pool to the highest priority ticket pool (category up). Figure 22C shows an example of a ticket management table when a ticket is moved from the extension ticket pool to the monthly reporting ticket pool (category down).

[0228] Figure 22B shows the ticket management table when ticket 2 is found to be related to ticket 3, which has a higher priority. In Figure 22A, ticket 2 had an extension deadline (2024 / 3 / 15), but because ticket 2 was categorized up due to the existence of a related ticket with a higher priority, the extension deadline is removed in Figure 22B (shown as "-" in Figure 22B). Additionally, a column indicating the association with a ticket with a higher priority (shown as "related important ticket no." in Figure 22B) may be added to the ticket management table. In Figure 22B, since ticket 2 is related to ticket 3, information indicating ticket 3 is entered in the corresponding column. The column indicating the association is just one example of additional information.

[0229] For example, related important tickets can be identified based on whether or not the source IP (Internet Protocol) address is the same.

[0230] Figure 22C shows the ticket management table when ticket 2 is changed from an extension to a monthly report because the number of tickets is higher than expected.

[0231] Next, in the extension ticket pool, adjustments are made to shorten or shorten the deadline based on deviations in the time series forecast. These adjustments will be explained with reference to Figures 23A to 24B. Figure 23A shows an example of the number of tickets at the forecast time. Figure 23B shows an example of the ticket management table at the forecast time. Figure 24A shows an example of the number of tickets at the observation time. Figure 24B shows an example of the ticket management table at the observation time.

[0232] As shown in Figure 23A, the predicted number of tickets issued is 20 for day 1, 15 for day 2, and 15 for day 1. However, as shown in Figure 24A, the actual number of tickets issued on day 2 is 15 for day 1 and 5 for day 2. In other words, the actual number for both day 1 and day 2 is 5 less than the predicted number. In this case, there is a surplus of allocated resources.

[0233] Therefore, the resource difference adjustment unit 27 updates the extension deadline for ticket 2 from 2024 / 3 / 15 to 2024 / 3 / 10, as shown in Figures 23B and 24B. The update cycle may be, for example, one day, or it may be in real time. For example, if ticket 2 is linked to another important alert, the extension deadline may be updated in real time.

[0234] (Modification 1 of the Embodiment) The security resource optimization system according to this modification will be described below with reference to Figure 25. In the following description, the differences from the embodiment will be the main focus, and the same or similar content as the embodiment will be omitted or simplified.

[0235] Figure 25 is a block diagram showing the functional configuration of the security resource optimization system according to this modified example. The security resource optimization system according to this modified example differs from the security resource optimization system 1 according to the embodiment in that it automatically calculates on-site risks and redistributes resources based on the results.

[0236] As shown in Figure 25, the security resource optimization system according to this modified example includes a change adjustment request device 10 and a resource adjustment device 20, in addition to a field risk calculation device 50. The field risk calculation device 50 may be an integrated device with the change adjustment request device 10 or the resource adjustment device 20. Furthermore, the security resource optimization system may also include a storage device 30 and a system control device 40.

[0237] The field risk calculation device 50 periodically calculates the risk of each monitored field environment, independently of requests from users or analysts. The field risk calculation device 50 acquires risk calculation information from the field (monitoring environment) and performs risk calculation based on the acquired risk calculation information. The risk calculation information may be, for example, the results of a questionnaire as shown in Figure 13, or the scores as shown in Figure 14. The risk calculation information may also include information indicating on-site risks, such as the number of alerts generated, the status of attacks against competitors, and the presence of employees or former employees who may be at risk of information leakage. The risk calculation information may also include information indicating whether the risk status, the likelihood of incident occurrence, etc., have reached a certain level or not. The field risk calculation device 50 is an example of a device that manages risk based on risk information of each of multiple monitoring environments acquired from each of those monitoring environments.

[0238] If the on-site risk calculation device 50 determines that the risk at the site is high, for example, when the score shown in Figure 14 exceeds a predetermined value, it sends service / resource change request information to the change adjustment request device 10 in order to attempt to change the service or adjust resources. This makes it possible to automatically change the service or adjust resources by determining the risk at the site.

[0239] The field risk calculation device 50 may also automatically or manually obtain matching parameters that contribute to the occurrence of an incident and determine whether or not to send service resource change request information based on the overall score.

[0240] (Modified Example 2 of the Embodiment) The security resource optimization system according to this modified example will be described below with reference to Figure 26. In the following description, the differences from the embodiment will be the main focus, and the same or similar content as in the embodiment will be omitted or simplified.

[0241] Figure 26 is a block diagram showing the functional configuration of the security resource optimization system according to this modified example. In this modified example, if there is a difference of a predetermined amount or more between the predicted amount of resources and the actual effort required to respond during resource adjustment operations, the security resource optimization system requests the resource adjustment device 20 to redistribute resources.

[0242] The security resource optimization system includes, in addition to the resource adjustment device 20, a prediction difference confirmation device 60, a sixth storage unit 71, and a seventh storage unit 72. The security resource optimization system may also further include a change adjustment request device 10, a storage device 30, and a system control device 40.

[0243] The prediction difference confirmation device 60 is activated periodically after resource adjustments and changes have been made and operations have started (for example, after step S110 shown in Figure 3) to determine whether there is a difference of a certain amount or more between the prediction and the actual number of tickets generated. If there is a difference of a certain amount or more, it sends a readjustment request to the resource adjustment device 20 as necessary. The prediction difference confirmation device 60 obtains the prediction result of the number of tickets generated (previous prediction result) from the sixth storage unit 71 and the actual measurement result of the number of tickets generated during the change period in which resource adjustments are being made (change period operation result) from the seventh storage unit 72, determines whether the difference in the number of tickets generated is greater than a predetermined amount, and if there is a difference of a certain amount or more, it may send a readjustment request to the resource adjustment device 20 as necessary. The prediction difference confirmation device 60 may also send a readjustment request to the resource adjustment device 20 via the change content adjustment request device 10. A readjustment request is an example of service / resource change request information.

[0244] Thus, the resource adjustment device 20 obtains a request for readjustment when the difference between the fourth security resource (actual result of the number of tickets generated during the change period) and the third security resource (predicted result of the number of tickets generated), which are required to perform security monitoring of multiple monitoring environments using the redistributed monitoring resources, exceeds a predetermined amount.

[0245] The operation of the security resource optimization system in this modified example may be the same as, for example, the operation shown in Figure 20.

[0246] (Examples of using the security resource optimization system) Below, examples of using the security resource optimization system according to the above embodiment and modified examples 1 and 2 of the embodiment (hereinafter also referred to as embodiments, etc.) will be described with reference to Figures 27A to 33C. First, the first example of using the system to upgrade the plan for Edge 1 (environment 1) will be described with reference to Figures 27A to 30. Figure 27A is a diagram showing an example of inputting the resource adjustment details for next month in the first example of use. Figure 27A shows the display screen of the user's information terminal. The display screen may be, for example, a custom screen when customizing a service.

[0247] As shown in Figure 27A, suppose a user sends a request to the SOC for next month's resource adjustments, asking to change the Edge 1 plan from "Plum" to "Bamboo" (upgrade) in the Pine-Bamboo-Plum price range, without increasing the cost. Figure 27A is an image showing that the user is making adjustments to strengthen support for certain environments, even though no additional costs are incurred. Users can freely customize security plans via a custom screen, and can adjust existing resources to match any additional costs.

[0248] Figure 27B shows an example of how resource adjustments are presented in the first use case. Figure 27B shows, for example, the display screen of an analyst's information terminal.

[0249] As shown in Figure 27B, the display screen shows the selected additional items, the results of the existing service investigation, the resources required, and the impact of the adjustments to the existing service. The display screen also shows icons for "Check other options" and "Confirm".

[0250] The display screen shown in Figure 27B is an example of the screen presented in step S130 shown in Figure 3.

[0251] This allows analysts to understand the user's request (additional items), what resource adjustments were made to fulfill them and their impact, and whether any additional resources are needed, before deciding whether to grant permission.

[0252] Figure 27C shows an example of a ticket management table in a conventional example. "status" indicates whether or not the ticket has been addressed (open means not addressed, close means addressed), and "create time" indicates the time the alert occurred.

[0253] Figure 27D shows an example of a ticket management table reflecting resource adjustments in the first use case. The temporary change period (tmp change period) indicates the end date and time of the temporary period. The dashed box shown in Figure 27D is an additional column specific to this disclosure. This additional column is added to the existing ticket management table for temporary adjustments due to the impact of configuration changes and is not present in the conventional ticket management table shown in Figure 27C. The temporary change period is an example of extension information included in the additional information.

[0254] Alerts issued while performing security monitoring across multiple monitoring environments using redistributed monitoring resources are processed based on priority and extension information.

[0255] Figure 27D shows an example where, in response to a request to change the plan for Edge 1 from "Plum" to "Bamboo," the importance level of Rule 1 in Edge 1, an environment where the security monitoring system needs to be strengthened, is set higher than its original severity level ("up" in tmp importance), and Rule 4 is added to Edge 1 ("add" in tmp importance). In Figure 27D, the importance level of Rule 1 in Edge 1 is set to "high," which is higher than the original severity level of "medium."

[0256] In this way, resources can be adjusted by increasing the security monitoring level of Rule 1 at Edge 1, adding Rule 4, and postponing (reducing resources for) the handling of Rules 1 and 2 at Edge 2. The time freed up by postponing the handling of Rules 1 and 2 at Edge 2 can be used for security monitoring of Edge 1. This allows the security monitoring level of Edge 1 to be increased without additional charges.

[0257] Note that the addition of Rule 4 is temporary and will only last until the temporary change period ends. Once the temporary change period has elapsed, Rule 4 may, for example, be automatically removed from the ticket management table.

[0258] Furthermore, in Figure 27D, at Edge 2, which is a different environment from Edge 1, the temporary importance is lower than the original severity. Specifically, the temporary importance of Rule 2 remains at medium, but an extension deadline (March 15, 2024) has been set, effectively making it less important than the original severity. Also, the temporary importance of Rule 4 is low, which is lower than the original severity, and it has been changed to a monthly report.

[0259] In this way, the number of tickets that analysts handle in a single day can vary from environment to environment in response to temporary changes in importance. By effectively adjusting the total number of tickets, it is possible to temporarily strengthen the security monitoring system for some monitoring environments without incurring additional costs.

[0260] Figure 27E shows an example of the priority order before and after resource adjustment in the first use case. Figure 27E shows the priority order for handling tickets.

[0261] As shown in Figure 27E, updating the ticket management table also updates the priority of adjustments. For example, the priority of tickets in Edge 1, an environment where the security monitoring system needs to be strengthened, will be increased. Note that "1" indicates the highest priority.

[0262] Furthermore, the average number of tickets handled may change before and after resource adjustments. For example, the number of tickets whose temporary importance increases may increase, while the number of tickets whose temporary importance decreases may decrease. Also, there may be a difference between the predicted number of tickets and the actual number of tickets. In such cases, it is desirable to readjust the resources. Resource readjustment will be explained with reference to Figures 28 to 30. Figure 28 is a diagram showing the predicted change in the average number of tickets handled due to the impact of the change in the first use case. Figure 29 is a diagram showing the predicted number of tickets and the actual number in the first use case.

[0263] Figure 28 shows an example where the number of alerts generated per day (i.e., the number of tickets generated) for Edge 1 and Edge 2 changes before and after resource adjustment, but the total number of alerts generated per day remains unchanged. In other words, there is no significant change in the total number of tickets handled by the analysts before and after resource adjustment. Thus, it is desirable to perform resource adjustments in such a way that the total number of tickets handled by the analysts does not differ by more than a predetermined amount.

[0264] Figure 29 shows the predicted / actual number of tickets generated for Edges 1 and 2, and for Day 1 and Day 2, respectively. On Day 1, the predicted and actual total number of tickets are the same, but on Day 2, the actual number is lower than the predicted number. Thus, adjustments such as extension deadlines may be made based on the discrepancy between the predicted number of tickets and the actual number of tickets.

[0265] Furthermore, the actual difference in the number of cases, and the predicted total number of cases for the following day, could be displayed in a calendar-like format.

[0266] Figure 30 shows an example of a ticket management table in the first use case where the extension deadline has been modified based on the difference between the predicted number of tickets and the actual number of tickets issued. In Figure 30, an example is shown where the extension deadline has been brought forward because the number of tickets is less than expected.

[0267] Figure 30 shows an example where the extension deadline for Rule 2 is moved forward from 2024 / 03 / 15 to 2024 / 03 / 13, and Rule 4 is changed from a monthly report to an extension deadline, with the deadline set to 2024 / 03 / 16. In this way, extension deadlines may be adjusted according to the actual number of tickets during the period in which resources are being adjusted and operated. If the actual number of tickets is greater than the predicted number, the extension deadline will be adjusted to be later.

[0268] Next, we will explain a second use case for making adjustments to reduce costs, referring to Figures 31A to 31C. Figure 31A is a diagram showing an example of inputting the resource adjustments for next month in the second use case.

[0269] As shown in Figure 31A, suppose a user sends a request to the SOC for a 20% reduction in costs as part of the resource adjustments for next month. Figure 31A is an image illustrating an example of adjustments when a user wants to reduce costs from next month onward. As a result, monitoring resources are adjusted to match the reduced costs.

[0270] In this case, the service resource request change information includes information based on input to the screen shown in Figure 31A. For example, the service resource request change information is obtained from the user.

[0271] Figure 31B is a diagram illustrating an example of how the effects of resource adjustments are presented in the second use case.

[0272] As shown in Figure 31B, the analyst is shown the details of the adjustments to the existing service and the impact of those adjustments. When the analyst clicks the "Decided" icon, the adjustments are implemented.

[0273] Figure 31C shows an example of a ticket management table reflecting resource adjustments in the second use case. Figure 31C shows an example where adjustments were made at edge 2, which has a high adjustment priority.

[0274] Figure 31C shows an example where the extension deadline for Rule 2 is set to 2024 / 03 / 15, and Rule 4 is changed to a monthly report, thereby reducing the amount of resources allocated to monitored organizations that own Edge 1 and 2 in proportion to the amount of cost savings. Figure 31C also shows an example where the priority of Edge 2 is lowered in order to reduce costs while maintaining the security monitoring level as much as possible.

[0275] Next, we will explain a third use case, which involves making adjustments to increase costs, with reference to Figures 32A to 32C. Figure 32A shows an example of inputting the resource adjustment details for next month in the third use case.

[0276] As shown in Figure 32A, suppose a user sends a request to the SOC to increase costs by 20% as part of next month's resource adjustments. Figure 32A is an image illustrating an example of adjustments when a user pays extra to try other plans and services from next month onward. As a result, resources are adjusted to match the additional costs.

[0277] Figure 32B is a diagram illustrating an example of how the effects of resource adjustments are presented in the third use case.

[0278] As shown in Figure 32B, the analyst is shown plan changes corresponding to additional costs as enhancements to the existing service. When the analyst clicks the "Confirm" icon, the changes are implemented.

[0279] Figure 32C shows an example of a ticket management table reflecting resource adjustments in the third use case. Figure 32C shows an example where rules 1 and 4 are added to edge 1 according to the additional cost.

[0280] Figure 32C shows an example where rules 1 and 4 were temporarily extended until April 1, 2024.

[0281] Next, a fourth use case in which the SOC proposes a plan change to the user will be explained with reference to Figures 33A to 33C. For example, the security resource optimization system 1 disclosed herein may be used when the SOC allows the user to try other plans without additional cost. For example, if it is predicted that the number of alerts will decrease next month based on seasonal factors and trends, an additional plan may be proposed to the user. Figure 33A is a diagram showing an example of a presentation in the fourth use case, which presents the resource forecast for next month and a proposed plan.

[0282] Figure 33A shows the display screen shown on the user's information terminal when an analyst proposes a plan for the following month. Figure 33A indicates that the amount of resources required next month is expected to be lower than anticipated, and that the plan can be customized with a small additional cost and / or other environmental adjustments. The security resource optimization system 1 generates and displays the display screen shown in Figure 33A based on the proposal received from the analyst.

[0283] In this case, the service resource request change information includes information based on the screen shown in Figure 33A. For example, the service resource request change information is obtained from the monitoring system (or analyst).

[0284] Figure 33B shows an example of how the effects of resource adjustments are presented in the fourth use case. Figure 33B shows the display screen shown on the user's information terminal.

[0285] As shown in Figure 33B, the user is shown the details of the adjustments to the existing service and the impact of those adjustments. When the user clicks the "Confirm" icon, the adjustments are implemented.

[0286] Figure 33C shows an example of a ticket management table reflecting the resource adjustments in the fourth use case. Figure 33C shows an example where the final adjustments are the same as those in Figure 31C.

[0287] In addition to the above, the following usage examples are also possible.

[0288] For example, the security resource optimization system 1 disclosed herein may be used to generate resource adjustment proposals due to various circumstances on the SOC side (e.g., personnel reductions). Also, for example, the security resource optimization system 1 disclosed herein may be used when, as a result of conducting a risk assessment on the SOC side, it becomes necessary to review the security monitoring level of the monitoring environment (e.g., changing the monitoring plan and installed equipment to match the risk level).

[0289] (Other Embodiments) The Security Resource Optimization System 1, etc., according to one or more embodiments has been described above based on embodiments, modified embodiments 1 and 2 (embodiments, etc.), but this disclosure is not limited to these embodiments, etc. As long as it does not depart from the spirit of this disclosure, various modifications that a person skilled in the art can conceive of may be applied to these embodiments, and forms constructed by combining components from different embodiments may also be included in this disclosure.

[0290] For example, the resource adjustment device 20 according to the above embodiment may have at least one function of the system control device 40. Furthermore, the resource adjustment device 20 and the system control device 40 may be implemented by a single device. Also, the resource adjustment device 20 may store at least one piece of information stored in the storage device 30.

[0291] Furthermore, in the above-described embodiments, requests for additional plans, plan changes, and price changes can be made from either the SOC side or the user side, and adjustments are made when a request is made. In addition, the ticket management table is updated according to the adjustment details.

[0292] Furthermore, in the above embodiments, each component may be implemented by being composed of dedicated hardware or by executing a software program suitable for each component. Each component may also be implemented by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0293] Furthermore, the order in which each step in the flowchart is performed is illustrative for the purpose of specifically illustrating this disclosure, and may be in a different order. Also, some of the above steps may be performed simultaneously (in parallel) with other steps, and some of the above steps may not be performed.

[0294] Furthermore, the division of functional blocks in the block diagram is just one example; multiple functional blocks can be implemented as a single functional block, a single functional block can be divided into multiple parts, or some functions can be moved to other functional blocks. In addition, the functions of multiple functional blocks with similar functions can be processed in parallel or time-sharing by a single piece of hardware or software.

[0295] Furthermore, the security resource optimization system 1, etc., according to the above embodiments may be implemented as a single device or as a plurality of devices. When the security resource optimization system 1, etc., is implemented as a plurality of devices, the components of the security resource optimization system 1, etc., may be distributed among the plurality of devices in any manner. When the security resource optimization system 1, etc., is implemented as a plurality of devices, the method of communication between the plurality of devices is not particularly limited and may be wireless communication or wired communication. In addition, wireless communication and wired communication may be combined between the devices.

[0296] Furthermore, each component described in the above embodiments may be implemented as software, or typically as an integrated circuit (LSI). These may be individually integrated onto a single chip, or some or all of them may be integrated onto a single chip. Here, we refer to it as an LSI, but depending on the degree of integration, it may also be called an IC, system LSI, super LSI, or ultra LSI. Moreover, the method of integrated circuit implementation is not limited to LSIs; it may also be implemented using a dedicated circuit (a general-purpose circuit that executes a dedicated program) or a general-purpose processor. After LSI manufacturing, a programmable FPGA (Field Programmable Gate Array) or a reconfigurable processor that can reconfigure the connections or settings of circuit cells inside the LSI may be used. Furthermore, if an integrated circuit implementation technology that replaces LSIs emerges due to advances in semiconductor technology or other derived technologies, it is natural that the components may be integrated using that technology.

[0297] A system LSI is a highly functional LSI manufactured by integrating multiple processing units onto a single chip. Specifically, it is a computer system composed of a microprocessor, ROM, RAM, and other components. The ROM stores the computer program. The system LSI achieves its function by having the microprocessor operate according to the computer program.

[0298] Furthermore, one aspect of this disclosure may be a computer program that causes a computer to perform each characteristic step included in the information processing method shown in any of Figures 3, 4, and 20.

[0299] Furthermore, for example, the program may be a program to be executed by a computer. Also, in one aspect of this disclosure, such a program may be recorded on a computer-readable non-temporary recording medium. For example, such a program may be recorded on a recording medium and distributed or made available. For example, by installing the distributed program on a device having another processor and having that processor execute the program, it becomes possible to have that device perform the above-mentioned processes.

[0300] This disclosure is useful for information processing devices and the like that support monitoring systems for monitoring facilities under surveillance.

[0301] 1 Security Resource Optimization System 10 Change Adjustment Request Device 20 Resource Adjustment Device 21 Change Resource Calculation Unit (Acquisition Unit) 22 Current Resource Management Unit (Acquisition Unit) 23 Future Resource Prediction Unit (Acquisition Unit) 24 First Storage Unit 25 Resource Difference Confirmation Unit 26 Adjustment Method Determination Unit 27 Resource Difference Adjustment Unit (Adjustment Unit) 28 Adjustment Impact Information Generation Unit 29 Second Storage Unit 30 Storage Device 31 Risk Calculation Information 32 Resource Adjustment Method Information 33 Resource Prediction Parameters 34 SOC System Information 35 Monitoring Plan / Service Information 36 Past Occurrence Ticket Information 40 System Control Device 41 System Reflection Judgment Unit 42 System Reflection Unit 43 Display Information Generation Unit 44 Third Storage Unit 45 Fourth Storage Unit 46 Fifth Storage Unit 50 Field Risk Calculation Device 60 Prediction Difference Confirmation Device 71 Sixth Storage Unit 72 Seventh Storage Unit

Claims

1. An information processing method for supporting security monitoring of a monitored organization, wherein the monitored organization has a plurality of monitoring environments that are subject to security monitoring, the method acquires the security resources required for security monitoring of each of the plurality of monitoring environments, and the method redistributes the monitoring resources allocated to each of the plurality of monitoring environments based on the security resources of each of the plurality of monitoring environments.

2. The information processing method according to claim 1, wherein change information is obtained regarding a change in at least one of the content of the security monitoring and the cost of the security monitoring, and the security resources are obtained based on the change information.

3. The information processing method according to claim 2, comprising: acquiring a first security resource resulting from the change in the change information, a second security resource that can be handled in the present, and a third security resource that will be required in the future; calculating the insufficient resources based on the first security resource, the second security resource, and the third security resource; and redistributing the monitoring resources based on the insufficient resources.

4. The information processing method according to claim 3, wherein, in the security monitoring, a plurality of rules for detecting anomalies are used, and the first security resource, the second security resource, and the third security resource are calculated for each of the one or more groups obtained by classifying the plurality of rules.

5. The information processing method according to any one of claims 2 to 4, wherein the change information is obtained from a user of the monitored organization.

6. The information processing method according to any one of claims 2 to 4, wherein the change information is obtained from a monitoring system that performs the security monitoring.

7. The information processing method according to any one of claims 2 to 4, wherein the change information is obtained from a device that manages risks based on information about the risks of each of the plurality of monitoring environments obtained from each of the monitoring environments.

8. The information processing method according to claim 3 or 4, wherein the change information is obtained when the difference between the fourth security resources required to perform the security monitoring of the multiple monitoring environments using the redistributed monitoring resources and the third security resources is greater than or equal to a predetermined amount.

9. The information processing method according to any one of claims 1 to 4, wherein the alert information acquired and managed from the multiple monitoring environments includes information indicating the risk of detected anomalies and additional information that is updated when redistributed.

10. The information processing method according to claim 9, wherein the additional information includes priority information indicating the priority of the response to be temporarily adopted and extension information indicating a temporary extension of the response deadline for the alert, and alerts issued while the redistributed monitoring resources are performing the security monitoring on the multiple monitoring environments are processed based on the priority information and the extension information.

11. The information processing method according to claim 4, wherein the change information includes a change that increases security resources for some of the monitoring environments among the plurality of monitoring environments, or for some of the rules among the plurality of rules, and the redistribution of monitoring resources reduces security resources for one or more monitoring environments excluding the aforementioned some of the monitoring environments, or for one or more rules excluding the aforementioned some of the rules.

12. The information processing method according to claim 11, wherein reducing the security resources includes at least one of extending the deadline for responding to alerts relating to the one or more monitoring environments or the one or more rules, and raising the threshold at which such alerts are detected.

13. The information processing method according to claim 11, wherein the adjustment priority to be adjusted in the redistribution of monitoring resources is determined for each of the multiple monitoring environments, and in the redistribution of monitoring resources, the response deadlines of the multiple rules are extended preferentially for the monitoring environment with the higher adjustment priority among the one or more monitoring environments.

14. The information processing method according to claim 11, wherein the redistribution of monitoring resources is performed by distributing the extension of the response deadline for the plurality of rules to each of the one or more monitoring environments.

15. The information processing method according to claim 11, wherein the alert information obtained from the multiple monitoring environments includes information indicating the risk of detected anomalies and additional information which is updated when redistributed, the additional information includes priority information indicating the priority of the response to be temporarily adopted and extension information regarding the temporary extension of the response deadline for the alert, the adjustment priority to be adjusted in the redistribution of monitoring resources is determined for each of the multiple rules, and at least one of the priority information and the extension information of the rule with the higher adjustment priority among the multiple rules is changed with priority.

16. The information processing method according to claim 11, wherein the change to increase the security resources is achieved by at least one of the following: improving the alert severity of the part of the monitoring environment; adding rules for detecting alerts; lowering the threshold for detecting alerts in the rules; and assigning analysts with relatively higher unit costs.

17. An information processing method according to any one of claims 1 to 4, which generates impact information including the impact on security monitoring due to the redistribution of the monitoring resources, and outputs the generated impact information.

18. The information processing method according to any one of claims 1 to 4, which outputs the details of the redistribution of the monitoring resources, and when information permitting changes to the details of the redistribution is obtained, executes a process to redistribute the monitoring resources among the multiple monitoring environments.

19. An information processing device for supporting security monitoring of a monitored organization, wherein the monitored organization has a plurality of monitoring environments that are subject to security monitoring, and the information processing device comprises: an acquisition unit that acquires security resources required for security monitoring of each of the plurality of monitoring environments, and an adjustment unit that redistributes the monitoring resources allocated to each of the plurality of monitoring environments based on the security resources of each of the plurality of monitoring environments.

20. A program for causing a computer to execute the information processing method described in any one of claims 1 to 4.

Images