Safelist management method

Abstract

To detect an item which has not been registered on a safelist, separately from detection of unauthorized operation.SOLUTION: On the basis of accesses to application programs, a safelist on which items to be allowed are registered is managed. The application program includes a first application in which predetermined content is described and a second application that notifies a management system designated in advance. An access control unit implemented in a system that operates according to the application program determines whether a predetermined instruction has been registered in the safelist, in accordance with receiving an access from the first application. When the predetermined content has not been registered on the safelist, the first application calls the second application. The second application transmits, to the management system, error information indicating that the predetermined content has not been registered on the safelist.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to a method for managing a safelist. [Background technology]

[0002] Security measures using safelists are implemented to counter threats such as information leaks and unauthorized access. Safelists register legitimate targets that should be permitted, and accesses not registered on the safelist are blocked. Therefore, safelists must register all necessary information. There is also known technology that automatically creates safelists by learning the behavior of a system during operation (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2018-106634 Summary of the Invention [Problem to be solved by the invention]

[0004] When creating a safelist by learning the system's behavior during operation, it is difficult to cover all behaviors in advance, so some items may be missed from registration (or learning). This makes it necessary to update the safelist based on anomalies detected during system operation. However, with conventional technology, it can be time-consuming and laborious to distinguish between cases where unauthorized access is denied based on the safelist and cases where legitimate access is denied due to a missed entry in the safelist.

[0005] An object of one aspect of the present invention is to distinguish from detection of unauthorized access and to detect cases in which legitimate access is denied due to failure to register on a safe list. [Means for solving the problem]

[0006] A safelist management method according to one aspect of the present invention manages a safelist in which targets to be permitted are registered, based on access from an application program. The application program includes a first application that describes predetermined content and a second application that notifies a pre-specified management system. An access control unit implemented in a system that operates in accordance with the application program determines whether the predetermined content is registered on the safelist in response to receiving access from the first application. If the predetermined content is not registered on the safelist, the first application calls the second application. The second application sends error information to the management system indicating that the predetermined content is not registered on the safelist. [Effects of the Invention]

[0007] According to the above-described aspect, it is possible to detect cases where legitimate access is denied due to a failure to register on the safe list, in distinction from the detection of unauthorized access. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an example environment in which a safelist management method according to an embodiment of the present invention is used. [Figure 2] FIG. 10 is a diagram illustrating an example of source code in which a main application calls a notification application. [Figure 3] FIG. 10 is a diagram illustrating an example of a safe list. [Figure 4] FIG. 10 is a diagram illustrating an example of a sequence in which all functions of a legitimate application program are registered in a safe list and a notification application is not invoked. [Figure 5] FIG. 10 is a diagram illustrating an example of a sequence in which some functions of a legitimate application program are not registered in the safe list and a notification application is called. [Figure 6]FIG. 10 is a diagram illustrating an example of a sequence of events occurring when an unauthorized application program that is not registered on a safe list accesses a computer. [Figure 7] 10 is a flowchart showing an example of processing of an application program according to an embodiment of the present invention. [Figure 8] FIG. 2 illustrates an example of a hardware configuration of a system. DETAILED DESCRIPTION OF THE INVENTION

[0009] 1 shows an example of an environment in which a safelist management method according to an embodiment of the present invention is used. In this example, a system that operates according to an application program is equipped with a safelist. The safelist management method according to an embodiment of the present invention detects any omissions in the safelist and notifies the management system.

[0010] The device 1 includes a system 10 and a group of applications 20. The system 10 includes hardware 11, resources 12, an access acceptance unit 13, a safe list 14, and an access control unit 15. Note that the system 10 may further include other elements or functions not shown in FIG. 1 .

[0011] The hardware 11 includes a CPU, memory, storage device, network device, etc. An operating system runs on the hardware 11. Furthermore, various software programs run on the operating system. The data file (data-a.txt), error information file (error.txt), and log file (log.txt), which will be described later, are stored in the memory or storage device.

[0012] The resource 12 is an interface between the operating system and the hardware 11, and includes various functions for actually operating the hardware 11 and functions for reading and writing data in file access.

[0013] The access receiving unit 13 receives access from an application program. Then, the access receiving unit 13 issues a corresponding instruction to the resource 12 in response to the access from the application program. Furthermore, the access receiving unit 13 transmits a processing result to the application program that is the access source, as necessary. The access receiving unit 13 is realized, for example, by an operating system (OS).

[0014] Legitimate targets that should be permitted are registered in the safe list 14. Legitimate targets that should be permitted are registered in the safe list 14, for example, by using a known tool. In this case, the safe list 14 is created by learning the behavior of application programs that are planned to be used by the system 10 when they are executed, before the system 10 is put into actual operation. Alternatively, the administrator of the system 10 may register the necessary information in the safe list 14.

[0015] The access control unit 15 determines whether to permit the access accepted by the access accepting unit 13. At this time, the access control unit 15 determines whether to permit the access by referring to the safelist 14. Specifically, if the access accepted by the access accepting unit 13 is registered in the safelist 14 as a legitimate target that should be permitted, the access control unit 15 permits the access. In other words, if the access accepted by the access accepting unit 13 is not registered in the safelist 14 as a legitimate target that should be permitted, the access accepting unit 13 cannot execute processing corresponding to the access. The access control unit 15 may be part of the operating system or may be implemented outside the operating system.

[0016] The log file (log.txt) 16 records accesses that are not registered in the safe list 14. Log information relating to cases in which the access control unit 15 has permitted access is generally not recorded because it would take up storage space.

[0017] The application group 20 is a plurality of application programs that realize the functions of the device 1. In this embodiment, the application group 20 includes a main application 21 and a notification application 22. The application group 20 is not particularly limited, but is implemented, for example, in a storage device (not shown) included in the system 10.

[0018] The main application (Apl-A) 21 is realized by program code that describes procedures for realizing the functions of the device 1 by utilizing the resources of the system 10. Therefore, the main application 21 includes one or more functions for realizing the functions of the device 1 by utilizing the resources of the system 10. The main application 21 also includes a notification application call code for calling the notification application 22.

[0019] 2 shows an example of source code in which the main application 21 calls the notification application 22. Note that FIG. 2 shows only a part of the source code of the main application 21.

[0020] 2, lines 38 to 43 correspond to the notification application call code for calling the notification application 22. In this example, the notification application call code is executed when a predetermined error xyz occurs. In this embodiment, the notification application call code performs the following processing.

[0021] (1) When a specific error xyz occurs, create an error message indicating the content of the error and write it to the error information file (error.txt). (2a) When the error information file cannot be opened, the notification application 22 is called with the location of the error (source code name and line number) as an argument. In this embodiment, when the error information file cannot be opened, error information indicating that an abnormality has occurred in "source code name: Apl-A, line number: 38" is created and passed to the notification application 22. (2b) When writing to the error information file fails, the notification application 22 is called with the location of the error operation as an argument. In this embodiment, when writing to the error information file fails, error information indicating that an abnormality has occurred in "source code name: Apl-A, line number: 41" is created and passed to the notification application 22.

[0022] The notification application (Sys-Notify) 22 is realized by program code that describes a procedure for sending error information created by the main application 21 to the management system 30. Therefore, the source code of the notification application 22 describes, for example, a function for sending data via TCP communication and the IP address of the management system 30 as destination information. The notification application 22 may also obtain log information corresponding to the error information created by the main application 21 from the log file 16. In this case, the notification application 22 includes a function for reading the log information from the log file 16. The notification application 22 is executed when called by the notification application call code of the main application 21.

[0023] The management system 30 is a server computer connected to a network, and receives and stores error information transmitted from the notification application 22. When log information is transmitted together with the error information, the management system 30 associates the error information with the log information and stores them.

[0024] 3 shows an example of the safe list 14. As described above, the safe list 14 registers legitimate targets that the system 10 should permit. The targets to be permitted consist of application programs and the access contents of resources from those application programs. In this embodiment, the safe list 14 registers a main application (Apl-A) 21 and a notification application (Sys-Notify) 22. The following three items are registered as the access contents from the main application 21: (1) file-write: data-a.txt (write data to the data file data-a.txt) (2) file-read: data-a.txt (read data from data file data-a.txt) (3) execute: Sys-Notify (execute notification app 22) In addition, the following two items are registered as access details from notification app 22. (1) file-read: log.txt (reads log information related to access control from the log file log.txt) (2) tcp-send: 192.168.0.10 (send data to IP address 192.168.0.10 via TCP communication)

[0025] The safelist 14 is created by a known safelist creation tool when an application program is executed. That is, the safelist 14 is created by learning the operation of the system 10 during operation. Therefore, application programs that are not executed or access contents that are not executed may not be registered on the safelist 14.

[0026] In this example, it is assumed that error xyz did not occur during execution of the application program. In this case, the code on lines 38 to 43 in the source code shown in FIG. 2 (i.e., the notification application call code) is not executed. Therefore, the notification application call code is not learned by the safe list creation tool and is not registered on the safe list 14. In other words, a "registration omission (or learning omission)" occurs for the notification application call code. Note that a registration omission refers to a state in which information that should have been registered has not been registered on the safe list 14.

[0027] Figure 4 shows an example of a sequence in which all functions of a legitimate application program are registered in the safe list 14 and the notification application 22 is not called. In this example, it is assumed that the safe list 14 shown in Figure 3 has been created. Then, it is assumed that the main application 21 updates the control data stored in the data file (data-a.txt).

[0028] In S1, the main application 21 requests the operating system to read a data file (data-a.txt). This request is received by the access receiving unit 13.

[0029] In S2, the access control unit 15 refers to the safe list 14 shown in FIG. 3 and determines whether to permit the access accepted by the access accepting unit 13 (i.e., the read request of S1). At this time, the access control unit 15 recognizes that the application program making the access is the main application 21 and the access content is "file-read: data-a.txt." The access control unit 15 then refers to the safe list 14 and confirms that the main application 21 is registered and that the access content "file-read: data-a.txt" is also registered. Therefore, the access control unit 15 permits the access accepted by the access accepting unit 13.

[0030] When the operating system (here, the access receiving unit 13) receives an access from an application program, it generates a corresponding system call. The access control unit 15 monitors this system call and does nothing if the access is registered in the safe list 14. On the other hand, if the access is not registered in the safe list 14, the access control unit 15 blocks the access. However, in FIG. 4, for ease of explanation, the determination result by the access control unit 15 is shown to be notified to the access receiving unit 13. The same applies to FIGS. 5 to 6, which will be described later.

[0031] When access is permitted by access control unit 15, access receiving unit 13 causes resource 12 to execute the read request received from main application 21 (i.e., the permitted read request) in S3. In response to this read request, resource 12 reads the specified control data from the data file (data-a.txt) and transmits it to access receiving unit 13. This control data is provided by access receiving unit 13 to main application 21. Thereafter, main application 21 processes (i.e., updates) the received control data.

[0032] In S4, the main application 21 generates a write request to write the processed control data into a data file. This write request is received by the access receiving unit 13.

[0033] In S5, the access control unit 15 refers to the safe list 14 and determines whether or not to permit the access accepted by the access accepting unit 13 (i.e., the write request of S4). At this time, the access control unit 15 recognizes that the application program making the access is the main application 21 and the access content is "file-write: data-a.txt." The access control unit 15 then refers to the safe list 14 and confirms that the main application 21 is registered and that the access content "file-write: data-a.txt" is also registered. Therefore, the access control unit 15 permits the access accepted by the access accepting unit 13.

[0034] When the access control unit 15 permits the access, the access accepting unit 13 causes the resource 12 to execute the write request received from the main application 21 (i.e., the permitted write request) in S6. The resource 12 then writes the processed control data to the data file in accordance with the write request. Thereafter, the resource 12 transmits an ACK message to the main application 21 indicating that the write process has been completed.

[0035] In this way, the access control unit 15 refers to the safe list 14 and determines whether or not to permit the access accepted by the access accepting unit 13. When the source application of the access accepted by the access accepting unit 13 and the access content are registered in the safe list 14, the resource 12 executes the corresponding process.

[0036] Figure 5 shows an example of a sequence in which some functions of a legitimate application program are not registered in the safe list 14 and the notification application 22 is called. In this example, it is assumed that the safe list 14 shown in Figure 3 has been created. It is also assumed that an error xyz shown in Figure 2 occurs in the main application 21 and the notification application read code is executed. However, in the following description, for simplicity, it is assumed that the code on lines 41 and 42 shown in Figure 2 is executed.

[0037] In S11, the main application 21 generates a write request to write information that an error xyz has occurred in an error information file (error.txt). The access receiving unit 13 receives this write request.

[0038] In S12, the access control unit 15 refers to the safe list 14 shown in FIG. 3 and determines whether or not to permit the access accepted by the access accepting unit 13 (i.e., the write request of S11). At this time, the access control unit 15 recognizes that the application program making the access is the main application 21 and the access content is "file-write: error.txt." Here, since the main application 21 is registered in the safe list 14, the access control unit 15 determines that the main application 21 is a legitimate application program. However, since the access content "file-write: error.txt" is not registered in the safe list 14, the access control unit 15 denies this access.

[0039] In this case, in S13, the access control unit 15 writes log information indicating that "the main application 21 is a legitimate application program, but the 'file-write: error.txt' by the main application 21 is not registered in the safe list 14" to the log file 16. Then, the access control unit 15 transmits a NG message to the access receiving unit 13. The NG message may be information indicating that the requested access has been rejected.

[0040] When receiving the NG message from the access control unit 15, the access receiving unit 13 calls the notification application 22 in S14 in accordance with the code on lines 41 and 42 shown in FIG. 2 and passes error information to the notification application 22. This error information indicates that an error has occurred in "Source code name: Apl-A, line number: 41." Note that the call to the notification application 22 is realized by a system call, for example, in response to a request from the main application 21 to execute the notification application 22. This request is then received by the access receiving unit 13.

[0041] In S15, the access control unit 15 refers to the safe list 14 and determines whether or not to permit the access accepted by the access accepting unit 13 (i.e., the execution request of S14). At this time, the access control unit 15 recognizes that the application program that is the access source is the main application 21 and the access content is "execute: Sys-Notify." The access control unit 15 then refers to the safe list 14 and confirms that the main application 21 is registered and that the access content "execute: Sys-Notify" is also registered. Therefore, the access control unit 15 permits the access accepted by the access accepting unit 13.

[0042] When the access control unit 15 permits the access, the access receiving unit 13 calls the notification application 22 by a system call in accordance with the execution request of S14 in S16. At this time, the access receiving unit 13 passes the error information generated by the main application 21 in S14 to the notification application 22.

[0043] In S17, the notification application 22 reads log information related to the received error information from the log file 16. As a result, the notification application 22 acquires the log information written in the log file 16 by the access control unit 15 in S13. Thereafter, in S18, the notification application 22 issues a transmission request to transmit the error information and log information via TCP communication. The destination (192.168.0.10) is specified within the notification application 22. This transmission request is then received by the access receiving unit 13.

[0044] In S19, the access control unit 15 refers to the safe list 14 and determines whether or not to permit the access accepted by the access accepting unit 13 (i.e., the transmission request of S18). At this time, the access control unit 15 recognizes that the application program that is the access source is the notification application 22 and the access content is "tcp-send: 192.168.0.10." The access control unit 15 then refers to the safe list 14 and confirms that the notification application 22 is registered and that the access content "tcp-send: 192.168.0.10" is also registered. Therefore, the access control unit 15 permits the access accepted by the access accepting unit 13.

[0045] When the access control unit 15 permits the access, the access receiving unit 13 instructs the resource 12 in S20 to transmit the error information and log information received from the notification application 22 to a specified destination. Then, in S21, the resource 12 transmits the error information and log information to the management system 30 using the communication I / F.

[0046] In this way, when the main application 21's access is not permitted by the access control unit 15, the main application 21 uses the notification application 22 to upload error information via a regular route for notifying the user of a missing entry on the safe list 14. At this time, the called notification application 22 transmits error information indicating the location of the error and log information recorded by the access control unit 15 to the management system 30. Therefore, based on the error information and log information received by the management system 30, the administrator of the system 10 can recognize that some of the functions of the main application 21 (in this embodiment, lines 38 to 43 of the source code shown in FIG. 2 ) are not registered on the safe list 14. Thereafter, the administrator of the system 10 registers the missing entry on the safe list 14. Note that, because unauthorized applications cannot upload error information via a regular route, error information resulting from access from unauthorized applications is not accumulated in the management system 30, thereby reducing the burden on the administrator of the system 10.

[0047] 6 shows an example of a sequence of events occurring when an access is received from a malicious application program (malicious application Apl-Z) that is not registered in the safe list 14. In this embodiment, it is assumed that the safe list 14 shown in FIG. 3 has been created.

[0048] In S31, the malicious application Apl-Z issues a write request to tamper with the error information file (error.txt). This write request is received by the access receiving unit 13.

[0049] In S32, the access control unit 15 refers to the safe list 14 shown in FIG. 3 and determines whether to permit the access accepted by the access accepting unit 13 (i.e., the write request of S31). At this time, the access control unit 15 recognizes that the application program that is the access source is the malicious application Apl-Z and the access content is "file-write: error.txt." The access control unit 15 then refers to the safe list 14 and confirms that the malicious application Apl-Z is not registered and that the access content "file-write: error.txt" is not registered either. Therefore, the access control unit 15 does not permit the access accepted by the access accepting unit 13 and writes log information indicating that an access not registered in the safe list 14 has been received to the log file 16. The access control unit 15 also sends an NG message to the malicious application Apl-Z.

[0050] In step S33, the malicious application Apl-Z, which has received the NG message, requests (execute: Sys-Notify) the execution of the notification application 22. The access receiving unit 13 receives this request.

[0051] In S34, the access control unit 15 refers to the safe list 14 and determines whether to permit the access accepted by the access accepting unit 13 (i.e., the execution request of S33). At this time, the access control unit 15 recognizes that the application program that is the access source is the malicious application Apl-Z and the access content is "execute: Sys-Notify." The access control unit 15 then refers to the safe list 14 and confirms that the malicious application Apl-Z is not registered. Furthermore, the safe list 14 does not register "file-write: error.txt" by the malicious application Apl-Z. Therefore, the access control unit 15 does not permit the access accepted by the access accepting unit 13, and writes log information indicating that an access not registered in the safe list 14 has been received to the log file 16. Furthermore, the access control unit 15 sends an NG message to the malicious application Apl-Z.

[0052] In this way, access from an application program (here, malicious application Apl-Z) that is not registered on the safe list 14 is rejected by the access control unit 15. At this time, no error information is sent from the malicious application Apl-Z to the management system 30. Furthermore, even if the malicious application Apl-Z has a notification function equivalent to that of the notification application 22, the notification function of the malicious application Apl-Z is not registered on the safe list 14, and therefore the notification function of the malicious application Apl-Z is not executed. Therefore, when access from a malicious application program is detected, no error information is sent to the management system 30. Therefore, it is possible to distinguish between the case in which some of the functions of a legitimate application program are not registered, as shown in FIG. 5, and the case in which access from a malicious application program is detected, as shown in FIG. 6.

[0053] 7 is a flowchart showing an example of processing of an application program according to an embodiment of the present invention. In this example, it is assumed that main application 21 is executed and access to resource 12 of system 10 shown in FIG.

[0054] In S51, the main application 21 accesses the resource 12 of the system 10. This access corresponds to the read request of S1 in the example shown in Fig. 4, and corresponds to the write request of S11 in the case shown in Fig. 5.

[0055] In S52, the main application 21 waits for a response from the operating system (or the access receiving unit 13 shown in FIG. 1). The operating system determines whether or not the access of S51 is registered in the safe list 14. If the access of S51 is registered in the safe list 14, the system 10 executes the corresponding process. If the access of S51 is not registered in the safe list 14, the operating system sends an NG message to the main application 21.

[0056] When an NG message is received, the main application 21 creates error information in S53. In the example shown in Fig. 2, error information indicating that an error has occurred in the code on line 38 or 41 is created. The main application 21 then requests execution of the notification application 22. In response, the access control unit 15 determines whether or not to permit access related to the execution of the notification application 22 by the main application 21.

[0057] When access related to the execution of the notification application 22 by the main application 21 is permitted in S54, the notification application 22 is called. In S55, the called notification application 22 reads log information from the log file 16. At this time, log information indicating an error related to non-registration in the safe list 14 is read. Then, in S56, the notification application 22 transmits the error information created by the main application 21 in S53 and the log information acquired in S56 to the management system 30.

[0058] <Hardware configuration> 8 shows an example of the hardware configuration of the system 10. The system 10 is realized by a computer system 100 including a processor 101, a memory 102, a storage device 103, an input / output device 104, a recording medium reader 105, and a communication interface 106.

[0059] The processor 101 executes an operating system and a safelist management program stored in the storage device 103. The processor 101 executes the operating system and the safelist management program to provide the functions of the resource 12, the access acceptance unit 13, and the access control unit 15 shown in FIG. 1. The memory 102 is used as a work area for the processor 101. The storage device 103 stores the operating system, the safelist management program, and other application programs. The application group 20 shown in FIG. 1 may be stored in the storage device 103.

[0060] The input / output device 104 may include input devices such as a keyboard, a mouse, a touch panel, and a microphone. The input / output device 104 may also include output devices such as a display device and a speaker. The recording medium reader 105 can acquire data and information recorded on the recording medium 110. The recording medium 110 is a removable recording medium that can be attached to or detached from the computer system 100. The recording medium 110 may be implemented, for example, as a semiconductor memory, a medium that records signals optically, or a medium that records signals magnetically. The safelist management program and various application programs may be provided to the computer system 100 from the recording medium 110. The communication interface 106 provides a function for connecting to a network. When the safelist management program and various application programs are stored on the program server 120, the computer system 100 may acquire the safelist management program and various application programs from the program server 120. [Explanation of symbols]

[0061] 1 device 10 Systems 11 Hardware 12 resources 13 Access Reception Department 14 Safelist 15 Access control section 16 Log files 20 apps 21 Main App 22 Notification App 30 Management Systems

Claims

1. A safelist management method for managing a safelist in which targets to be permitted are registered based on access from application programs, comprising: the application program includes a first application that describes predetermined content and a second application that notifies a pre-designated management system; an access control unit implemented in a system that operates in accordance with the application program, determining whether or not the predetermined content is registered on the safe list in response to receiving access from the first application; When the predetermined content is not registered in the safe list, the first application invokes the second application; The second application transmits error information indicating that the predetermined content is not registered on the safe list to the management system. A safelist management method comprising:

2. When the predetermined content is not registered in the safe list, the first application requests execution of the second application; the access control unit determines whether execution of the second application by the first application is registered in the safe list; When the execution of the second application by the first application is registered in the safe list, the second application transmits the error information to the management system. The safelist management method according to claim 1 .

3. The error information includes information indicating a location where the predetermined content is written in the source code of the first application. The safelist management method according to claim 1 .

4. The second application Acquires log information recorded when the predetermined content is not permitted from a log file that stores log information of the system; The log information obtained from the log file is sent to the management system together with the error information. The safelist management method according to claim 1 .

Images