JP2017215799A - Information processing method device, method for controlling information processing device, and computer program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce a workload in updating a security policy while maintaining security strength in an information processing method device having a function of forced access control.SOLUTION: An information processing device having a function of forced access control includes holding means for holding a security policy for managing access by the forced access control, acquisition means for acquiring information on the vulnerability of an application and update information of the application, and update means for updating the security policy with a function of kernel thread on the basis of the information acquired by the acquisition means.SELECTED DRAWING: Figure 11

Description

  The present invention relates to an information processing apparatus having a function of forced access control, a method for controlling an information processing apparatus, and a computer program.

  In a general computer system, a system administrator's authority is usually required to access important information in the system. This is a mechanism for preventing a malicious person from falsifying a computer system by allowing only a system administrator to access important information in the system.

However, on the other hand, if the authority of the system administrator is taken by a malicious person,
There is also a risk that the computer system is easily altered. In view of this, several mechanisms have been proposed for restricting access to computer resources such as specific execution processes, files, and devices of the system even if the system administrator has authority.

  One of the proposed mechanisms is mandatory access control (referred to as Mandatory Access Control, MAC). This controls access to an execution process and a file based on a security policy (hereinafter referred to as policy) created in advance. Patent Document 1 discloses a technique related to MAC.

JP 2012-18102 A

  As described above, in order to apply the MAC to the information processing apparatus, it is necessary to create a policy. Normally, the policy is created in advance by a computer system builder or the like.

  However, in general, there are many unknown vulnerabilities in operating systems and application programs. If an unknown vulnerability is discovered, unauthorized access using the vulnerability may occur. The occurrence of such unauthorized access is not assumed in the policy created in advance, and if the policy created in advance is used continuously, unauthorized access may be permitted. Therefore, although it is necessary to update the policy, updating the policy sequentially based on the discovery of unknown vulnerabilities and other information is a heavy workload for the administrator of the computer system. On the other hand, if the policy is automatically updated by a specific application having a user interface, unauthorized access may be allowed if the specific application is hijacked by a malicious person.

  The present invention has been made in view of the above-described problems, and an object of the present invention is to reduce a workload in updating a security policy while maintaining security strength in an information processing apparatus having a forced access control function. .

  In view of the above problems, the present invention provides an information processing apparatus having a forced access control function, a holding unit that holds a security policy for managing access by the forced access control, and information related to application vulnerabilities; An acquisition unit that acquires update information of an application, and an update unit that updates the security policy with a function of a kernel thread based on the information acquired by the acquisition unit.

  According to the present invention, in an information processing apparatus having a forced access control function, it is possible to reduce a work load in updating a security policy while maintaining security strength.

(A) It is a schematic diagram which shows the whole structure of information processing apparatus. (B) It is a schematic diagram which shows the program structure of information processing apparatus. (A) It is the schematic which shows the structure of OS110 in 1st Embodiment. (B) It is a figure which shows the example of the process information 117. FIG. It is a flowchart of the policy update process in 1st Embodiment. It is a flowchart of the forced access control process in 1st Embodiment. It is a flowchart of the policy update process in 3rd Embodiment. It is a figure which shows the example of a (a)-(d) policy. (A), (b) It is a figure which shows the example of an access log. (A) It is a figure which shows the example of known vulnerability information. (B) It is a figure which shows the example of an application table. It is a flowchart of the access log analysis process in 1st Embodiment. It is the schematic which shows the structure of OS110 in 3rd Embodiment. It is the schematic which shows the structure of OS110 in 2nd Embodiment. It is a flowchart of the policy update process in 2nd Embodiment. It is the schematic which shows the structure of OS110 in 4th Embodiment. It is a flowchart of the policy update process in 4th Embodiment. It is a figure which shows the example of the update information of (a), (b) application. It is a figure which shows the example of the user interface which makes a user select the update of a policy. It is a figure which shows the example of the update log | history of (a), (b) application.

  Hereinafter, a first embodiment which is an embodiment of the present invention will be described with reference to the drawings.

(First embodiment)
The present embodiment relates to an information processing apparatus having a forced access control function for forcibly managing application access. In this embodiment, the access log is analyzed using the function of the kernel thread, and the policy (security policy) of the corresponding application is updated or newly created. Since kernel threads generally do not have a user interface, there is a low possibility that they will be manipulated by a malicious person. Therefore, it is possible to maintain the security strength in updating the policy.

(Overall configuration of information processing device)
FIG. 1A shows the overall configuration of the information processing apparatus 100 in the present embodiment.

  The information processing apparatus 100 includes a CPU 101, ROM 102, RAM 103, I / F 104, HDD 105, operation unit 106, display unit 107, and engine 108. Each component is connected by a bus 109.

  The CPU 101 controls the operation of each unit in the information processing apparatus 100 according to a computer program stored in the ROM 102. In addition, a computer program (OS (Operating System) or application) loaded in the RAM 103 is executed. The ROM 102 is a read-only memory, and stores a boot program and firmware, various computer programs for realizing processing to be described later, and various data. A RAM 103 is a work memory that temporarily stores programs and data for processing by the CPU 101, and various computer programs and data are loaded by the CPU 101.

  The I / F 104 is an interface for communicating with an external device such as a network device or a USB device. Data communication through the network and data transmission / reception with external devices. The HDD 105 is a non-volatile storage device that holds an OS, various computer programs, or various data.

  Next, FIG. 1B shows the configuration of the computer program of the information processing apparatus 100 in this embodiment. The information processing apparatus 100 according to the present embodiment operates the OS 110 and a plurality of applications 111. The plurality of applications 111 are computer programs that run on the OS 110.

  The application 111 may be any application that performs information processing. For example, there are a document editing application, an image editing application, a Web connection application, and the like. There are also a print processing application, a scan processing application, a copy processing application, and the like. When the application 111 writes data to the HDD 105, write processing is performed via the OS 110. The reading process is the same. At the time of reading / writing, the OS 110 designates a logical address of the HDD 105 and performs reading / writing on the HDD 105.

(Logical configuration of OS 110)
FIG. 2A is a schematic diagram showing a functional configuration of the OS 110 in FIG. Note that at least a part of the following functions of the OS 110 are executed by a kernel thread.
FIG. 2B is a diagram illustrating an example of process information 117 of a process operating on the OS 110. Note that each function of the OS 110 is realized by the CPU 101 executing the program code of the OS.

  The vulnerability information analysis unit 118 is a resident process that is activated when the OS 110 is activated.

  After startup, the system access log acquired from the log DB 112 is analyzed periodically (for example, every hour or every day), and the analysis result is passed to the policy processing unit 114.

  When the policy processing unit 114 receives the analysis result of the access log or the system call and process information 117 of the control target application 111 from the vulnerability information analysis unit 118, the policy processing unit 114 performs the following processing. When the access log analysis result is received, the policy processing unit 114 updates or newly creates a policy based on the analysis result, and passes it to the policy DB 113. On the other hand, when the system call and process information 117 is received, the policy processing unit 114 passes the policy corresponding to the system call to the access control unit 115. Here, the process information 117 is shown in FIG. 2B, for example. “Status” on the first line indicates process information, for example, “sleeping” indicating sleep or “running” indicating execution. “Pid” on the second line indicates the identifier of each process, and “Cmdline” on the third line indicates the path of the execution file.

  If the policy processing unit 114 has an interface or a network such as a keyboard and a mouse, there is a possibility that a malicious person will be hijacked. Therefore, in this embodiment, the policy processing unit 114 functions as a kernel thread of the OS 110 that does not have a user interface. Targets whose access and processing can be controlled by forced access control are programs existing in the user space such as applications and commands of the OS 110. A kernel thread is a function that is processed in a kernel space that is different from the user space. Therefore, unless a user interface for explicitly accessing from the user space is implemented, access from the user is difficult. Therefore, it is possible to prevent takeover by a malicious person.

  The access control unit 115 rejects the request acquired from the system call based on the policy corresponding to the application 111 to be controlled. If not rejected, a request is input to the system call processing unit 116. The system call processing unit 116 performs system call processing corresponding to the request. The above is the functional configuration of the OS 110 in the present embodiment.

  Next, the <forced access control process> and <policy update process> of the OS 110 will be described.

(Forced access control processing)
FIG. 4 is a flowchart showing a forced access control process executed by the OS 110 stored in the ROM. In the following, description will be made in association with each component in FIG.

  First, in step S401 of FIG. 4, the policy processing unit 114 of FIG. 2A acquires a system call (request to the OS) issued from the application 111.

  In step S402, the policy processing unit 114 in FIG. 2A determines whether to perform forced access control. If forced access control is to be performed (YES), the process proceeds to step S403. In step S403, the policy processing unit 114 in FIG. 2A inputs the policy of each application from the policy DB 113 and passes it to the access control unit 115.

  On the other hand, when the forced access control is not performed in step S402 (NO), the process proceeds to step S405. In step S405, the system call processing unit 116 in FIG. 2A performs system call processing for processing a request from the application, and the processing of the OS 110 is terminated.

  In step S404, the access control unit 115 in FIG. 2A determines whether to permit an access request for a computer resource accessed by the application 111 based on the input policy. If the access request is permitted (YES), the process proceeds to step S405. In step S405, the system call processing unit 116 in FIG. 2A performs system call processing for processing a request from the application, and the OS 110 processing ends.

  As an example, a case where a request for reading the file “/usr/local/user_data/text.txt” is input to the application “App1” will be described. When there is such an input, the policy at 601 in FIG. 6A is input. In 601a 601a, the path of an application execution file is described in order to indicate which application has a policy. In 601b, specific rules are described, one line for each file. The first half of each line indicates the path name of the file, and the control information to be permitted is written in the second half. If “read” is described, reading is permitted, and if “write” is described, writing is permitted. For example, the line 601c permits reading of the file “/ usr / bin / App1”. Note that the rules for a plurality of files may be described together on a single line using special symbols. For example, “/ usr / local / user_data / * read” of 602d permits reading of all files under the “/ usr / local / user_data” folder.

  In this case, since reading of “text.txt” under the “/ usr / local / user_data” folder is permitted, this request is permitted and the process is executed. On the other hand, if the access request is not permitted in step S404 (NO), the request is rejected and the processing of the OS 110 is terminated.

(Policy update process)
FIG. 3 is a flowchart showing details of the policy update process executed by the OS 110. In the following, description will be made in association with each component in FIG. This process is periodically performed at predetermined time intervals. For example, it is performed every hour or every day.

  First, in step S301 of FIG. 3, the vulnerability information analysis unit 118 of FIG. 2A acquires an access log from the log DB 112. For example, access logs such as 701 shown in FIG. 7A and 702 shown in FIG. 7B are acquired.

  Next, in step S302, the vulnerability information analysis unit 118 in FIG. 2A analyzes the access log acquired in step S301. Analysis is performed in view of the presence or absence of abnormal access. The specific process of step S302 is, for example, the process shown in FIG. 9A or 9B. As specific processing in step S302, processing shown in FIGS. 9A and 9B will be described.

  In the process of FIG. 9A, abnormal access is determined based on whether or not there are abnormally many accesses to the same file.

  First, in step S302a, it is determined whether the number of accesses to the same file is greater than or equal to a predetermined threshold (threshold value: TH_A). The threshold value TH_A may be set to 100, for example. If it is equal to or greater than the threshold TH_A (YES), the process proceeds to step S302b, and the abnormality detection flag is turned ON in step S302b. Note that the initial value of the abnormality detection flag is OFF before the start of <policy update processing>. If it is less than the threshold TH_A (NO), the process is terminated.

  For example, in the case of 701 in FIG. 7A, when the file access of each row of 701a is counted, since the same file “text.txt” is accessed 140 times, the threshold value TH_A is exceeded. In step S302c, the path of the target file that is equal to or greater than the threshold TH_A is recorded. The above is the process of FIG.

  On the other hand, in the process of FIG. 9B, abnormal access is determined based on whether there are abnormally many accesses from unknown IP addresses.

  First, in step S302d, it is determined whether or not an access from a terminal having an unknown IP address is greater than or equal to a threshold value TH_B. The threshold value TH_B is set to 10, for example. If it is equal to or higher than the threshold TH_B (YES), the process proceeds to step S302b, and the abnormality detection flag is turned ON in step S302b. If it is less than the threshold TH_B (NO), the process is terminated. For example, in the case of 702 in FIG. 7B, when the unknown IP address of 702a is counted, since there are 30 accesses from the same unknown IP address “XXX.XXX.XXX.YYY”, the threshold value TH_B is exceeded. . In step S302e, the target IP address equal to or higher than the threshold value TH_B is recorded. The above is the process of FIG.

  In step S302, the access to the same file and the access from the same IP address may be counted by using a shell script or Perl.

  In step S303, the vulnerability information analysis unit 118 in FIG. 2A detects an abnormality detection flag and determines whether an abnormality has been detected. If the abnormality detection flag is ON and an abnormality is detected (YES), the process proceeds to step S304. Then, the policy processing unit 114 in FIG. 2A inputs the policy of each application from the policy DB 113. If the abnormality detection flag is OFF and no abnormality is found (NO), the process ends.

  In step S305, the policy processing unit 114 in FIG. 2A determines whether there is a policy for an application in which an abnormality has been found. If there is a policy (YES), the process proceeds to step S306, where the policy processing unit 114 in FIG. 2A updates the policy and ends the process. There are two update methods. One is a method of adding only a rule for denying access to a file having an abnormal access or access from an IP address having an abnormal access. For example, if the original policy is 601 in FIG. 6A, a rule is added as in 602b and 602c in FIG. 6B. It becomes a rule to reject by describing "deny" at the head of the rule. Note that 602c rejects all “ALL” access from the IP address “XXX.XXX.XXX.YYY”. The other is to add a range to be rejected. If there is an IP address that refuses access to the folder to which the file that has been accessed abnormally or has an abnormal access, only a rule that rejects all external IP addresses is added. For example, if the original policy is 601 in FIG. 6A, a rule is added as in 603b and 603c in FIG. 6C. Note that 603c denies access to all “ALL” from all external IP addresses “OUTSIDE_IP_ALL”. Further, if there is another update method, the method may be applied.

  On the other hand, if there is no policy (NO), the process proceeds to step S307, where the policy processing unit 114 in FIG. 2A creates a new policy and ends the process. To create a new policy, for example, as a starting point, first create a policy with only an application execution file path as indicated by 601a in FIG. 6A and a rule permitting reading of the executable file as indicated by 601b. . Next, add a rule that denies the reading of files with abnormal access.

(Second Embodiment)
In the first embodiment, when an abnormal access is found, an application policy is updated or newly created using a kernel thread. However, if the abnormal access disappears or an application patch corresponding to the abnormal access is applied, the policy may be relaxed or restored to the original policy in consideration of the load of the application. In this embodiment, policy update or new creation is performed in consideration of abnormal access changes and application patch adaptation. As a result, it is possible to cope with a change in abnormal access without manually updating or creating a new policy.

  This embodiment and the first embodiment are the same except for only a part of (logical configuration of OS 110) and (policy update processing), and the rest. Therefore, only the difference from the first embodiment of (OS 110 logical configuration) and (policy update processing) will be described below.

(Logical configuration of OS 110)
FIG. 11 is a schematic diagram showing a functional configuration of the OS 110 in the present embodiment. Note that each function of the OS 110 is realized by the CPU 101 executing the program code of the OS.

  Further, the log DB 112, the policy DB 113, the access control unit 115, the system call processing unit 116, and the process information 117 are the same as the units having the same names in FIG.

  The vulnerability information analysis unit 118 is a resident process that is activated when the OS 110 is activated.

  After startup, the system access log acquired from the log DB 112 is analyzed periodically (for example, every hour or every day), and the analysis result is passed to the policy processing unit 114.

The policy determination unit 121 acquires the current version and the last update date from the application 111. On the other hand, application update information is acquired from the policy DB 113 based on the name of the application 111. For example, the information shown in FIG.
“Version” indicates the version of the application. “Last update date” indicates the last update date of the application. “Vulnerability” indicates whether there is a vulnerability that cannot be addressed unless stated in the policy. In the case of “Yes”, information of items of “vulnerability-related access log name”, “vulnerability range”, and “response status” to be described below is described. In the case of “None”, no information is described in the above item. “Vulnerability-related access log name” describes the name of the access log in which the vulnerability was discovered. “Vulnerability range” indicates a range where there is vulnerability, for example, a function name such as “funcM” is described. Lastly, “response status” indicates the response status to the vulnerability. “Provisional support by policy” is in the process of analyzing the access log or watching the situation, and indicates that the policy may change in the future. In addition, “in response by policy” indicates that there is no possibility of policy change in the future for the version of the application that is determined to be addressed by the policy. Descriptions such as “described in the 15th line” and “described in the 16th line name” indicate where the rule for the vulnerability is described in the policy.

  Then, based on the access log analysis result, the application version and the last update date, and the application update information, it is determined whether to modify or create a new policy.

  Then, based on the access log analysis result, the application version and the last update date, and the application update information, it is determined whether to modify or create a new policy.

  When the policy processing unit 114 receives the determination result of the policy determination unit 121 or the system call and process information 117 of the application 111 to be controlled, the policy processing unit 114 performs the following processing. When the policy is corrected and newly created, the policy processing unit 114 updates or newly creates the policy based on the application update information and the analysis result, and passes the policy to the policy DB 113. On the other hand, when the system call and process information 117 is received, the policy processing unit 114 passes the policy corresponding to the system call to the access control unit 115.

  Here, as in the first embodiment, the policy processing unit 114 is a kernel thread having no user interface. This makes it possible to prevent takeover by a malicious person.

(Policy update process)
FIG. 12 is a flowchart showing details of policy update processing in the OS 110. A description will be given in association with each component of FIG. This process is performed periodically. It may be performed at the timing when the application or access log is updated. Moreover, you may implement at the timing when the policy with respect to the vulnerability of the organization which uses this embodiment was decided.

  Steps S301 and S302 are the same as the steps having the same names in FIG.

  In step S308, the policy determining unit 121 in FIG. 11 acquires application update information from the policy DB 113 based on the name of the application 111.

  In step S309, the policy determination unit 121 in FIG. 11 determines whether there is an application that needs to be updated or newly created. The determination is made based on the access log analysis result, the application version and the last update date, and the application update information. If there is an application that requires updating or creating a new policy (YES), the process proceeds to step S304. On the other hand, if there is no application that needs to be updated or newly created (NO), the process ends.

  Specifically, first, it is confirmed whether or not the application version and the last update date are newer than the update information. If it is new, it is confirmed whether or not the vulnerability range described in the update information is supported from the description of the update history of the application as shown in FIG. 17A (“corresponding to unauthorized access to funcM”).

  If it corresponds, it is determined that the policy needs to be updated. Next, when the abnormality detection flag in the access log analysis result is OFF and the presence / absence of vulnerability in the update information is “Yes”, it is considered that the vulnerability described in the policy is gone, and the policy needs to be updated. . On the other hand, if the abnormality detection flag in the access log analysis result is ON and the vulnerability of the update information is “None”, it is considered that there is a vulnerability described in the policy and it is necessary to update or create a new policy judge.

  When the update information is changed, the “version” and the “last update date” are changed after the above determination process.

  Moreover, what was mentioned above was determined automatically. However, the final determination may be performed by the user. Therefore, for example, a user interface as shown in FIG. 16 may be displayed to allow the user to make a final determination. This can be realized by connecting a mouse, keyboard or monitor to the I / F 104 of FIG. The squares to the right of “Yes” and “No” in FIG. 16 are check boxes, and a final determination is made by checking with a mouse or a keyboard.

  Steps S304 and S305 are the same as the steps having the same names in FIG.

  Step S306 is basically performed using the step with the same name in FIG. 3 and the update information of the application. For example, if a vulnerability related to the vulnerability-related access log name “LOG-2016-049” in FIG. 15A is not found from the access log analysis result, the rule on the 16th line of the policy from “response status” Is deleted. Then, the vulnerability information related to “LOG-2016-049” is deleted from the update information.

  Step S307 is basically the same as the step with the same name in FIG. 3, but is performed using the update information of the application. Since the policy is newly created, for example, in FIG. 15A, first, the “vulnerability presence / absence” of the update information is changed from “none” to “present”. Then, “vulnerability-related access log name”, “vulnerability range”, and “response status” are updated.

  The embodiment has been described above. In the above, when a vulnerability related to the vulnerability-related access log name described in advance in the application update information is not found from the access log analysis result, the related rule is deleted from the policy. However, there is a possibility that the same vulnerability will be attacked again. Therefore, the rule deleted for a while is stored in a file different from the policy, and the access log is monitored periodically (for example, every day). If there is an access that exploits the same vulnerability, the rule deleted from another file may be copied to the policy to restore the rule.

(Third embodiment)
In the first embodiment, first, an access log is analyzed. If it can be considered that a specific application is being attacked, a policy update or new creation of the corresponding application is performed using a kernel thread. In the present embodiment, when an application does not support a known vulnerability, a policy update or new creation is performed based on the known vulnerability information using a kernel thread. This makes it possible to make an application correspond to a known vulnerability without manually updating or creating a new policy.

  This embodiment and the first embodiment are the same except for only a part of (logical configuration of OS 110) and (policy update processing), and the rest. Therefore, only the difference from the first embodiment of (OS 110 logical configuration) and (policy update processing) will be described below.

(Logical configuration of OS 110)
FIG. 10 is a schematic diagram showing a functional configuration of the OS 110 in the present embodiment. Note that each function of the OS 110 is realized by the CPU 101 executing the program code of the OS. The policy DB 113, the access control unit 115, the system call processing unit 116, and the process information 117 are the same as the units having the same names in FIG.

  The vulnerability information analysis unit 118 is a resident process that is activated when the OS 110 is activated. After startup, the newly acquired vulnerability information is periodically acquired from the known vulnerability information DB 120 through the communication network 119 outside the OS 110. The vulnerability information includes not only completely new vulnerability information but also vulnerability information in which information such as a function to which a corresponding application and a vulnerability are applicable among updated vulnerabilities is updated. The acquisition interval may be set, for example, every hour or every day. Vulnerability information that has become known is indicated by, for example, CVE (Common Vulnerabilities and Exposures) and is as shown in FIG. In addition, the original vulnerability information DB of the organization which operates this embodiment constructed based on CVE and other vulnerability information sites may be used. Then, after comparing the already-known vulnerability information with the application table as shown in FIG. 8B inside the OS 110, the already-known vulnerability information is analyzed. After the analysis, the analysis result is passed to the policy processing unit 114.

  When the policy processing unit 114 receives the analysis result of vulnerability information known from the vulnerability information analysis unit 118 or the system call and process information 117 of the application 111 to be controlled, the policy processing unit 114 performs the following processing. When the analysis result of the vulnerability information that has become known is received, the policy processing unit 114 updates or newly creates a policy based on the analysis result and passes it to the policy DB 113. On the other hand, when the system call and process information 117 is received, the policy processing unit 114 passes the policy corresponding to the system call to the access control unit 115.

  Here, as in the first embodiment, the policy processing unit 114 is a kernel thread having no user interface. This makes it possible to prevent takeover by a malicious person.

(Policy update process)
FIG. 5 is a flowchart showing details of policy update processing in the OS 110. A description will be given in association with each component in FIG. Note that this processing is periodically performed as in the first embodiment.

  First, in step S501 of FIG. 5, the vulnerability information analysis unit 118 of FIG. 2A acquires newly known vulnerability information from the known vulnerability information DB outside the OS 110. For example, vulnerability information as shown in FIG.

  Next, in step S502, the vulnerability information analysis unit 118 in FIG. 2A determines whether there is an application corresponding to the discovered vulnerability. This determination is made by comparing the application information described in the vulnerability information with the application table in the OS 110. Specifically, first, an existing character string search is performed to determine whether an application name described in the application table exists for the title or outline of vulnerability information. If there is an application name corresponding to the search, a character string search is performed in the same manner as to whether the version is applicable. For example, when the vulnerability information in FIG. 8A and the application table in FIG. 8B are used, when “App1 before 5” in 801a is viewed, first, the application name matches “App1” in 802a. I understand that. Next, since it can be seen from 801a that the version is “5 or earlier”, it can be seen that “4.2” in 802b is applicable. Therefore, it can be seen that the version does not support vulnerability information.

  If there is an application in which the vulnerability is found (YES), the process proceeds to step S503, and the vulnerability information is analyzed in step S503. The part of the application that is vulnerable is analyzed within a range that can be understood from a character string indicating a function or process such as “func” or “process”. For example, in the case of the vulnerability information in FIG. 8A, it can be seen from 801b that there is a vulnerability with the “hoge” function.

  On the other hand, when there is no application in which the vulnerability is found (NO), the process ends.

  In step S504, the policy processing unit 114 in FIG. 2A inputs a policy for each application from the policy DB 113.

  In step S505, the policy processing unit 114 in FIG. 2A determines whether there is a policy for an application in which an abnormality has been found. If there is a policy (YES), the process proceeds to step S506, where the policy processing unit 114 in FIG. 2A updates the policy and ends the process. For example, in the case of the vulnerability information in FIG. 8A, a rule for rejecting data related to the “hoge” function is added. In that case, the policy indicated by 601 in FIG. 6A is changed to the policy indicated by 604 in FIG. The rule indicated by 604b is a rule for rejecting data related to the “hoge” function. Further, as described in step S306 of the first embodiment, the range to be rejected may be expanded and added, or if there is another update method, the method may be applied.

  On the other hand, if there is no policy (NO), the process proceeds to step S507, where the policy processing unit 114 in FIG. 2A creates a new policy and ends the process. New policy creation may be performed in the same manner as in the example described in step S307 of the first embodiment.

  In the above embodiment, if there is an application corresponding to the already known vulnerability information, the policy is updated or newly created. However, it may be possible to reduce the load of policy update or newly created processing by dealing only with serious vulnerabilities and not dealing with minor vulnerabilities. Specifically, for example, CVE describes a base score of a common vulnerability assessment system CVSS (Common Vulnerability Scoring System) for vulnerabilities. The higher this score, the more serious the vulnerability. Therefore, the policy may be updated or newly created only when the base score is equal to or higher than a certain level.

(Fourth embodiment)
In the third embodiment, when an application does not cope with a known vulnerability, a policy update or new creation of the application is performed using a kernel thread. However, if the information on known vulnerabilities is updated or an application patch corresponding to the known vulnerabilities is applied, the policy may be relaxed or restored to the original policy in consideration of the application load. In this embodiment, policy update or new creation is performed in consideration of update of known vulnerability information and application patch adaptation. This makes it possible to respond to changes in known vulnerabilities without manually updating or creating a new policy.

  This embodiment and the third embodiment are the same except for only a part of (logical configuration of OS 110) and (policy update processing), and the rest. Therefore, only the difference from the first embodiment of (OS 110 logical configuration) and (policy update processing) will be described below.

(Logical configuration of OS 110)
FIG. 13 is a schematic diagram showing a functional configuration of the OS 110 in the present embodiment. Note that each function of the OS 110 is realized by the CPU 101 executing the program code of the OS.

  Further, the policy DB 113, the access control unit 115, the system call processing unit 116, the process information 117, the communication network 119, and the known vulnerability information DB 120 are the same as the respective parts having the same names in FIG.

  The vulnerability information analysis unit 118 is a resident process that is activated when the OS 110 is activated.

  After startup, the system vulnerability information acquired from the log DB 112 is analyzed periodically (for example, every hour or every day), and the analysis result is passed to the policy determination unit 121.

  The policy determination unit 121 acquires the current version and the last update date from the application 111. On the other hand, application update information is acquired from the policy DB 113 based on the name of the application 111. For example, the information shown in FIG. Among these items, items other than “vulnerability information” and “vulnerability range” are the same as the items having the same names as those in FIG. In the “vulnerability information”, for example, the CVE number is described as the vulnerability information that has been already described in the third embodiment. For example, “vulnerability range” indicates a range where there is a vulnerability that can be acquired from the vulnerability information name such as 801b in FIG. 8A, and a function name such as “funcL” is described.

  When the policy processing unit 114 receives the determination result of the policy determination unit 121 or the system call and process information 117 of the application 111 to be controlled, the policy processing unit 114 performs the following processing. When the policy is corrected and newly created, the policy processing unit 114 updates or newly creates the policy based on the application update information and the analysis result, and passes the policy to the policy DB 113. On the other hand, when the system call and process information 117 is received, the policy processing unit 114 passes the policy corresponding to the system call to the access control unit 115.

  Here, as in the third embodiment, the policy processing unit 114 is a kernel thread having no user interface. This makes it possible to prevent takeover by a malicious person.

(Policy update process)
FIG. 14 is a flowchart showing details of policy update processing in the OS 110. A description will be given in association with each component of FIG. This process is performed periodically. It may be performed at the timing when the application or vulnerability information is updated. Moreover, you may implement at the timing when the policy with respect to the vulnerability of the organization which uses this embodiment was decided.

  Steps S501 and S503 are the same as the steps having the same names in FIG. Note that step S502 does not exist. This is to determine whether there is an application that needs to be updated or newly created in step S509 described later.

  In step S508, the policy determination unit 121 in FIG. 11 acquires application update information from the policy DB 113 based on the name of the application 111.

  In step S509, the policy determining unit 121 in FIG. 11 determines whether there is an application that needs to be updated or newly created. The determination is made based on the access log analysis result, the application version and the last update date, and the application update information. If there is an application that needs to be updated or newly created (YES), the process proceeds to step S504. On the other hand, if there is no application that needs to be updated or newly created (NO), the process ends.

  Specifically, first, it is confirmed whether or not the application version and the last update date are newer than the update information. If it is new, it is confirmed whether or not the vulnerability information name described in the update information is supported from the description of the update history of the application as shown in FIG. 17B (example: “corresponds to CVE-2016-XXY”). To do.

  When it corresponds, it is considered that the vulnerability described in the policy is gone, and it is determined that the policy needs to be updated. Next, when the vulnerability range that is more detailed than the previously acquired vulnerability information is found as the analysis result of the vulnerability information, it is determined that the policy needs to be updated. For example, although only “funcL” is described in the update information, the analysis result is more concretely “modeZ of funcL”. If the update information has a vulnerability of “None”, it is determined that there is a vulnerability described in the policy, and it is determined that the policy needs to be updated or newly created.

  When the update information is changed, the “version” and the “last update date” are changed after the above determination process.

  Moreover, what was mentioned above was determined automatically. However, the final determination may be performed by the user. Therefore, similarly to step S308 in the second embodiment, a user interface as shown in FIG. 16 may be displayed to allow the user to make a final determination.

  Steps S504 and S505 are the same as the steps having the same names in FIG.

  Step S506 is basically the same as the step having the same name in FIG. 5, but is performed using the update information of the application. For example, if the vulnerability information name “CVE-2016-XXY” illustrated in FIG. 15B is not found from the vulnerability information acquired in step S501, the rule on the 11th line of the policy is deleted from “response status”. To do. Then, the vulnerability information related to the vulnerability information name “CVE-2016-XXY” is deleted from the update information of the application.

  Step S507 is basically the same as the step with the same name in FIG. 5, but is performed using the update information of the application. Since the policy is newly created, for example, in FIG. 15B, first, the “vulnerability presence” of the update information is changed from “none” to “present”. Then, the “vulnerability information name”, “vulnerability range”, and “response status” are updated.

(Fifth embodiment)
In the first embodiment, the access log is first analyzed. If it can be considered that an attack is being made on a specific application, the corresponding application is updated or newly created using a kernel thread that does not have a user interface.

  In the third embodiment, when an application is not compatible with a newly known vulnerability, the policy update of the application is performed based on the known vulnerability information using a kernel thread having no user interface. Or newly created.

  In the present embodiment, the above two embodiments are combined. As a result, it is possible to efficiently update or newly create a policy corresponding to both an unknown vulnerability and a newly known vulnerability.

  The first embodiment is different from the first embodiment only in a part of (logical configuration of OS 110) and (policy update processing), and is otherwise the same. Hereinafter, only the difference from the first embodiment (logical configuration of the OS 110) and (policy update processing) will be described.

(Logical configuration of OS 110)
Differences from the first embodiment are as follows. The vulnerability information analysis unit 118 is a resident process that is activated when the OS 110 is activated. After startup, the system access log acquired from the log DB 112 is analyzed periodically (for example, every hour or every day), and the analysis result is passed to the policy processing unit 114. In addition, the vulnerability information that is already known is acquired from the known vulnerability information DB 120 through the communication network 119 outside the OS 110 as shown in FIG. Then, the vulnerability information that has become known is compared with the application table as shown in FIG. After the comparison, the vulnerability information that has become known is analyzed, and the analysis result is passed to the policy processing unit 114.

  When the policy processing unit 114 receives the access log or the analysis result of the vulnerability information that has become known from the vulnerability information analysis unit 118, or the system call and process information 117 of the application 111 to be controlled, the policy processing unit 114 performs the following processing. To do. When the analysis result of the access log or the vulnerability information that has become known is received, the policy processing unit 114 updates or newly creates a policy based on the analysis result and passes it to the policy DB 113. On the other hand, when the system call and process information 117 is received, the policy processing unit 114 passes the policy corresponding to the system call to the access control unit 115.

  Here, as in the first embodiment, the policy processing unit 114 is a kernel thread that does not have a user interface. This prevents the attacker from hijacking. The above is the difference from the first embodiment, and the others are the same as in the first embodiment.

(Policy update process)
In the present embodiment, both (policy update processing) of the first embodiment and (policy update processing) of the third embodiment are periodically performed.

  In the above embodiment, the first embodiment and the third embodiment are combined, but the second embodiment and the fourth embodiment can be combined in the same manner. In this case, for example, the update information of the application may use FIGS. 15A and 15B together. 15A and 15B may be integrated with the item “vulnerability-related access log name” and the item “vulnerability information name” as “vulnerability-related access log name or vulnerability information name”. .

(Other examples)
The present invention supplies a program that realizes one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program This process can be realized. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

114 Policy processing section 118 Vulnerability information analysis section

Claims (12)

An information processing apparatus having a forced access control function,
Holding means for holding a security policy for managing access by the mandatory access control;
An acquisition means for acquiring application vulnerability information and application update information;
An information processing apparatus comprising: an updating unit that updates the security policy with a function of a kernel thread based on information acquired by the acquiring unit.   The information processing apparatus according to claim 1, wherein the information related to the vulnerability of the application is an access log by the application.   The information processing apparatus according to claim 1, wherein the update information of the application includes a vulnerability-related access log name related to the application. Based on the information acquired by the acquisition means, further comprising a determination means for determining whether the number of accesses to the predetermined file by the application is equal to or greater than a predetermined threshold;
The update means updates the security policy with a kernel thread function when the determination means determines that the number of accesses is greater than or equal to a predetermined value. The information processing apparatus according to item 1. Confirmation means for confirming whether the number of accesses to the predetermined file by the application is equal to or greater than a predetermined threshold based on the information acquired by the acquisition means;
Determination means for determining whether to update the security policy based on the result of the confirmation means and the update information of the application;
5. The update unit according to claim 1, wherein the update unit updates the security policy with a function of a kernel thread when the determination unit determines to update the security policy. 6. Information processing device.   The information processing apparatus according to claim 1, wherein the information related to the vulnerability of the application is information on a newly discovered vulnerability of the application.   The information processing apparatus according to claim 1, wherein the update information of the application includes a vulnerability information name related to the application.   The update unit according to claim 6, wherein, when an application corresponding to the newly discovered vulnerability exists in the information processing apparatus, the update unit updates the security policy with a function of a kernel thread. Information processing device. The updating means includes
9. The security policy according to claim 1, wherein the security policy is updated by adding a rule that denies a predetermined access by the application by a function of a kernel thread based on information acquired by the acquisition unit. The information processing apparatus described. The updating means includes
9. The security policy is updated by creating a new security policy including a rule that denies a predetermined access by the application by a function of a kernel thread based on information acquired by the acquisition unit. The information processing apparatus according to any one of claims. A method of controlling an information processing apparatus having a forced access control function,
Holding means for holding a security policy for managing access by the forced access control; and
An acquisition step in which the acquisition unit acquires information on the vulnerability of the application and update information of the application;
A control method for an information processing apparatus, comprising: an update unit that updates the security policy with a kernel thread function based on information acquired by the acquisition unit. Computer
An information processing apparatus having a forced access control function,
Holding means for holding a security policy for managing access by the mandatory access control;
An acquisition means for acquiring application vulnerability information and application update information;
A computer program for functioning as an information processing apparatus, comprising: an updating unit that updates the security policy with a function of a kernel thread based on information acquired by the acquiring unit.

Images