CN114417326A

CN114417326A - Abnormality detection method, abnormality detection device, electronic apparatus, and storage medium

Info

Publication number: CN114417326A
Application number: CN202111664920.XA
Authority: CN
Inventors: 吕晓滨
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2022-04-29

Abstract

The embodiment of the application discloses an anomaly detection method, an anomaly detection device, anomaly detection equipment and a storage medium, wherein the method comprises the following steps: acquiring an initial white list of a system, wherein the initial white list at least comprises a system list corresponding to a system process in the system; matching a process list currently operated by the system based on the system list to obtain at least one process to be confirmed; performing authority analysis on each process to be confirmed to obtain an authority analysis result; adding the processes to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list; and carrying out abnormity detection on the system based on the updated white list.

Description

Abnormality detection method, abnormality detection device, electronic apparatus, and storage medium

Technical Field

The embodiment of the application relates to the field of information security, and relates to but is not limited to an abnormality detection method, an abnormality detection device, electronic equipment and a storage medium.

Background

Currently, the main machine side (or the terminal side) in the industry has risks such as virus trojans (e.g., Lesson, mine excavation, botnet, etc.), data disclosure, tampering, etc., while the current protection methods include many terminal side and network side security protection software/devices such as antivirus software, EPP, EDR, firewall, etc., but there still exist viruses (e.g., Lesson virus, new virus, etc.) that cannot be protected. The reason is that the continuous countermeasures and attack and defense technologies of the defender and the attacker are continuously evolved, so that the safety protection software/equipment can only protect old/known threats and needs to be continuously updated to enhance the protection of new and popular threats and attack techniques. Such continuous countermeasure upgrades necessitate the user to continuously invest funds to secure the security construction, but are still fatiguing to the countermeasure.

Most attack threats eventually fall to the terminal side/host side. The terminal is protected in the last kilometer, bears the office business and data of the client, and how to effectively ensure the safety of the terminal is directly related to the safety guarantee of the business and the data, a more effective method is needed, and frequent upgrade countermeasures are not needed.

The related technology needs to artificially set a credible security process or characteristic information of the process in advance, has no real-time property, and cannot realize the detection of new threats.

Disclosure of Invention

In view of this, embodiments of the present application provide an abnormality detection method, an abnormality detection apparatus, an electronic device, and a storage medium.

The technical scheme of the embodiment of the application is realized as follows:

in a first aspect, an embodiment of the present application provides an anomaly detection method, where the method includes: acquiring an initial white list of a system, wherein the initial white list at least comprises a system list corresponding to a system process in the system; matching a process list currently operated by the system based on the system list to obtain at least one process to be confirmed; performing authority analysis on each process to be confirmed to obtain an authority analysis result; adding the processes to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list; and carrying out abnormity detection on the system based on the updated white list.

In a second aspect, an embodiment of the present application provides an abnormality detection apparatus, including: the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring an initial white list of a system, and the initial white list comprises a system list corresponding to a system process in the system; the matching module is used for matching the process list currently operated by the system based on the system list to obtain at least one process to be confirmed; the analysis module is used for carrying out authority analysis on each process to be confirmed to obtain an authority analysis result; the adding module is used for adding the processes to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list; and the detection module is used for carrying out abnormity detection on the system based on the updated white list.

In a third aspect, an embodiment of the present application provides an electronic device, including a memory and a processor, where the memory stores a computer program that is executable on the processor, and the processor implements the above method when executing the program.

In a fourth aspect, embodiments of the present application provide a storage medium storing executable instructions for causing a processor to implement the above method when executed.

In the embodiment of the application, all processes running at present are monitored, and the authority of each process to be confirmed is analyzed to obtain the updated white list (trusted process white list), namely, the updated white list is not set in advance, but is obtained by learning within a certain learning time, the trusted process white list can be automatically updated, and the attack of new and old threats can be effectively prevented without manually and frequently upgrading the rule base (or manually and previously setting the trusted white list).

Drawings

Fig. 1 is a schematic flow chart illustrating an implementation of an anomaly detection method according to an embodiment of the present application;

fig. 2 is a schematic flowchart of an anomaly detection method according to an embodiment of the present application;

fig. 3A is a trusted white list learning process of the whole host as a protection target according to an embodiment of the present application;

fig. 3B is a trusted white list learning process with a protection objective of a specified directory according to an embodiment of the present application;

fig. 4A is a schematic flowchart of a white list protection technique for protecting a whole host according to an embodiment of the present application;

fig. 4B is a flowchart illustrating a white list protection technique for protecting a target specific directory according to an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of an abnormality detection apparatus according to an embodiment of the present disclosure;

fig. 6 is a hardware entity diagram of an electronic device according to an embodiment of the present disclosure.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, specific technical solutions of the embodiments of the present application will be described in further detail below with reference to the drawings in the embodiments of the present application. The following examples are intended to illustrate the present application but are not intended to limit the scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, references to the terms "first \ second \ third" are only to distinguish similar objects and do not denote a particular order, but rather the terms "first \ second \ third" are used to interchange specific orders or sequences, where appropriate, so as to enable the embodiments of the application described herein to be practiced in other than the order shown or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.

White list: the concept of white list corresponds to "black list". For example: in a computer system, a plurality of software is applied to a black and white list rule, an operating system, a firewall, antivirus software, a mail system, application software and the like, and the black and white list rule is almost applied in all aspects related to control. After the blacklist is enabled, users (or IP addresses, IP packets, mail, viruses, etc.) that are blacklisted cannot pass. If the white list is set up, users (or IP addresses, IP packets, mails and the like) in the white list can pass preferentially and cannot be rejected as junk mails, and the safety and the rapidness are greatly improved. The meaning of the application is expanded by one step, and the application with the blacklist function has the corresponding white list function.

The terminal agent: in the form of a software agent, specifically developed software is installed on a terminal (e.g., a personal computer or server host) to do what is needed. The agent in the embodiment of the application comprises Client software deployed on the terminal and Server software for uniformly managing the agents, and is based on a Client/Server (Client/Server) model. In the embodiment of the application, the terminal security products such as antivirus software and terminal Detection and Response (EDR) are taken as examples, and the software agents are client agents of the products.

EDR (electric double layer reactor): is a current popular terminal safety protection device. Agent software is deployed on a terminal host to perform a plurality of safety protections such as information acquisition, threat detection, threat defense, threat response and the like on the host. The protection device is provided with a management (Manager) end which exists in a Client/Server form, the acquisition and detection information of the Manager can be synchronously displayed and comprehensively detected by the Manager, and the Manager can transmit instructions to the Manager through issuing strategies and the like. The solution will illustrate with this product how the problem to be solved by the current solution is to be solved.

Terminal security protection platform (EPP): a solution deployed on an endpoint device to prevent file-based malware attacks, detect malicious activity, and provide the investigation and remediation functions needed to respond to dynamic security events and alerts.

An embodiment of the present application provides an anomaly detection method, as shown in fig. 1, the method includes:

step S110, obtaining an initial white list of a system, wherein the initial white list at least comprises a system list corresponding to a system process in the system;

here, a process is a unit of resource allocation by the operating system. A process may refer to an application that is running in the system, i.e., a process is an execution activity of a program on a computer, and running a program starts a process. The process can be divided into a system process and a user process, and the process for completing various functions of the operating system is the system process and is the operating system in a running state; user processes are all user initiated processes.

In the implementation process, a plurality of processes are correspondingly started because various functions of the operating system are completed. The system list corresponds to the plurality of processes.

Under the condition that the white list is set up, the processes in the white list and/or the read-write operation of the specified directory are allowed to be executed, and the safety of the system or the specified directory is improved. The list corresponding to the white list includes, but is not limited to, the following fields: process name, process path, description information, program icon, digital signature information, original file name, copyright.

In some embodiments, since the system list corresponding to the operating system process in the system is used for completing various functions of the operating system and is a compliant operation, the system list may be determined as the initial white list first.

In some embodiments, besides the system list, the user may also add processes corresponding to other compliance operations to the initial white list according to actual needs.

Step S120, matching a process list currently operated by the system based on the system list to obtain at least one process to be confirmed;

the corresponding process can be operated in the process by starting other software in the system, and the system list is in compliance, so that the system list can be removed from the process list currently operated by the system to obtain at least one process to be confirmed, wherein the process to be confirmed comprises a compliant process and a non-compliant process.

Step S130, performing authority analysis on each process to be confirmed to obtain an authority analysis result;

in some embodiments, the authority of each process to be confirmed may be obtained by performing authority analysis on each process to be confirmed based on a compliance process list set by a user according to actual needs, for example, a process to be confirmed in the compliance process list set by the user may be determined as a compliance process, and a process to be confirmed that is not in the compliance process list set by the user may be determined as an out-of-compliance process. Here, the information of the process includes at least one of: process name, process path, protection directory of attempted operation, operation authority (read-only or read-write), description information, program icon, digital signature information, original file name, and copyright information. For example, a process white list can be created by extracting information such as a process name, digital signature information, and an original file name (these three may be set as necessary information) of a process, and it is determined whether the process has a directory operation authority, so as to achieve the purpose of tamper resistance.

In some embodiments, the antivirus software may be used to perform a permission analysis on each process to be confirmed to obtain the permission of each process to be confirmed, for example, the process containing the virus is an out-of-compliance process based on the confirmation of the antivirus software. In some embodiments, the permission analysis result may be obtained based on antivirus software and the compliance process list in combination with the process permission analysis. Here, the method of the authority analysis is not limited.

Step S140, adding the processes to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list;

in the implementation process, the process to be confirmed with the authority, i.e. the process in compliance, may be added to the initial white list to form an updated white list.

And S150, carrying out abnormity detection on the system based on the updated white list.

In the implementation process, if all running processes in the system are in the update white list, the system can be characterized to have no abnormal operation, if the running processes in the system are not in the update white list, the system is indicated to have the abnormal operation, the abnormal operation can be intercepted, prompt information is output to prompt a user to confirm the abnormal operation, and the abnormal operation can be recorded while being intercepted and fed back to the user within a certain time period, so that the user can uniformly process a plurality of abnormal operations, and the efficiency of the user in processing the abnormal operation is improved.

In the embodiment of the application, all processes running at present are monitored, and the authority of each process to be confirmed is analyzed to obtain the updated white list (trusted process white list), namely, the updated white list is not set in advance, but is obtained by learning within a certain learning time, the trusted process white list can be automatically updated, a rule base does not need to be updated manually frequently, namely, the trusted white list does not need to be set manually in advance, and new and old threat attacks can be effectively prevented. The problem that the related technology needs to artificially set a credible security process or characteristic information of the process in advance, has no real-time performance and cannot realize the detection of new threats is solved.

In some embodiments, the step S110 "obtaining an initial white list of a system" may be implemented by:

step 111, determining a system list corresponding to the system process based on the process name, the digital signature information and the copyright information corresponding to the system process of the system;

in the implementation process, at least one of the following information corresponding to the operating system process running the operating system may be determined first: and determining a system list corresponding to the operating system process by the process name, the digital signature information and the copyright information.

In the implementation process, a process completely matched with any one of the process name, the digital signature information or the copyright information of the operating system process can be determined as a system process; a process that exactly matches the process name, digital signature information, and copyright information of the operating system process may also be determined as a system process. Preferably, matching is carried out based on the combination of the process name, the original file name and the digital signature, so that the situation that the name is easy to forge because only the process name is used for some non-compliant operation cannot be detected is avoided.

Step 112, determining the system list as the initial white list.

In the embodiment of the application, the system list corresponding to the system process can be effectively determined based on the process name, the digital signature information and the copyright information corresponding to the system process of the system.

In some embodiments, the step S120 "performing the permission analysis on each process to be confirmed to obtain the permission analysis result" may be implemented by:

step 121, performing virus analysis on each process to be confirmed, and determining a threat process from the at least one process to be confirmed;

here, the threat process may be a process carrying a virus, such process being required to be disabled. In the implementation process, virus analysis can be performed on each process to be confirmed by using antivirus software installed in the system, and a threat process is determined from the at least one process to be confirmed.

Step 122, eliminating a threat process in the at least one process to be confirmed;

and removing the threat process from the at least one process to be confirmed, namely completing the confirmation of part of the threat processes in the at least one process to be confirmed.

And 123, performing authority analysis on each process to be confirmed which is left after the threat process is eliminated, so as to obtain the authority analysis result.

In the implementation process, each of the remaining processes to be confirmed may be a process corresponding to software newly installed by the user, or may be a newly added threat process that is not identified by virus software. And performing authority analysis on each process to be confirmed which is left after the threat process is eliminated to obtain the authority analysis result.

In the embodiment of the application, firstly, virus analysis is carried out on each process to be confirmed, and a threat process is determined from the at least one process to be confirmed; then eliminating the threat process in the at least one process to be confirmed; and finally, performing authority analysis on each process to be confirmed which is left after the threat process is eliminated to obtain an authority analysis result. In this way, threat processes may first be culled from processes to be validated based on virus analysis.

In some embodiments, the system includes a system program, the exception detection method is used for exception detection of the system program; in the step S130, "performing authority analysis on each of the processes to be confirmed remaining after the threat process is removed to obtain the authority analysis result" may be implemented by the following processes:

and analyzing the operation permission of each process to be confirmed which is left after the threat process is eliminated to obtain a permission analysis result of the system program.

Here, the system program includes a program of an operating system and a program of user startup software. Operating a corresponding system process by a program of an operating system; and the program of the user starting software runs the corresponding user process. And eliminating each process to be confirmed, namely the user process, which is remained after the threat process is eliminated. In the implementation process, the operation permission analysis needs to be performed on the user process to obtain a permission analysis result of the user process.

In the embodiment of the application, when the abnormality detection object is a system program, the system program needs to start a corresponding process when running, so that the running permission of the process to be confirmed can be analyzed, and the permission analysis result of the system program is obtained.

In some embodiments, the system includes a preset directory in a system program, and the anomaly detection method is used for performing anomaly detection on the preset directory; in the step S130, "performing authority analysis on each of the processes to be confirmed remaining after the threat process is removed to obtain the authority analysis result" may be implemented by the following processes:

and analyzing the read-write permission corresponding to the preset directory to obtain a permission analysis result.

Here, the user may specify a directory or a file that needs to be subjected to abnormality detection, that is, may specify a preset target. The abnormal detection of the preset target includes abnormal detection of read/write operations of the preset directory, for example, a user may execute the preset target with only read operations, and if it is detected that the preset directory is in progress with write operations, it may be determined that the write operations are abnormal operations.

In the implementation process, the read-write permission corresponding to the preset directory may be analyzed based on a compliance operation list set by the user according to actual requirements, so as to obtain the read-write permission corresponding to the preset directory, for example, the read-write permission corresponding to the preset directory in the compliance operation list set by the user may be determined to be only provided with the read permission.

Correspondingly, the step S140 "add the process to be confirmed with authority to the initial white list to form an updated white list based on the authority analysis result of each process to be confirmed", which may be implemented by the following processes:

and adding the preset directory with the authority into the initial white list based on the read-write authority corresponding to the preset directory to form the updated white list.

In the embodiment of the application, under the condition that the abnormal detection object is the preset directory, the process of reading or writing the preset directory is monitored and analyzed, information of the process is obtained through learning, a trusted process white list is obtained, and then the authority analysis result is obtained.

In some embodiments, the system includes a system program, the exception detection method is used for exception detection of the system program; the step S150 "performing anomaly detection on the system based on the updated white list" may be implemented by the following steps:

step 151, acquiring a current process of the system in a current running state;

step 152, determining the current process which is not in the updated white list as a new process based on the updated white list;

step 153, intercepting the newly added process;

step 154, performing authority analysis on the newly added process to obtain a newly added authority analysis result;

and step 155, adding the newly added process to the updated white list and operating the newly added process under the condition that the analysis result of the newly added authority indicates that the newly added process has the operation authority.

In the embodiment of the application, the newly added process which is not in the updated white list is intercepted, and the running of the user process without permission can be effectively prevented; under the condition that the newly added process is analyzed to have the operation authority, the newly added process is added to the updated white list, so that the white list is automatically updated, a rule base does not need to be manually and frequently updated, the frequent updating confrontation process can be effectively avoided, and the attack of new threats and old threats is effectively prevented.

In some embodiments, the system includes a preset directory in a system program, and the anomaly detection method is used for performing anomaly detection on the preset directory; the step S150 "performing anomaly detection on the system based on the updated white list" may be implemented by the following steps:

step 156, obtaining read-write operation of a preset directory in the system program;

step 157, intercepting read and/or write operations of the preset directory not in the updated white list based on the updated white list.

In the embodiment of the application, reading or writing operations of a preset target which are not in compliance can be effectively intercepted based on the updated white list, so that attacks of new threats and old threats can be effectively prevented.

Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

From the perspective of attack and defense research, most threats enter the terminal in the following three ways, which further affect the terminal:

the method I is entered in a mode of adding files/new processes and non-local existing files, such as downloading virus files, executing virus files and the like. Lesoviruses, Trojan horses, etc. are typically entered via this type.

And secondly, operating the non-original standard object (for example, the office file is opened by office or wps, but the office file is opened after the virus file is invaded, and the standard object is changed). Generally, the type of phenomenon can occur in threats such as tampering and vulnerability attack, and for example, the office document is tampered by virus files to be infected.

And thirdly, system white process utilization (the existing local file/process is utilized to execute the behavior which is beyond the file/process and cannot occur) occurs, for example, the illegal operation is executed by utilizing the PowerShell of the system process without file attack, wherein the PowerShell can refer to Windows PowerShell, and the Windows PowerShell is a command line shell program and a script environment.

Fig. 2 is a schematic flowchart of a method for protecting a host/terminal according to an embodiment of the present disclosure, where agent software is deployed on the host or the terminal, or the method is applicable to security software with a terminal agent. The method comprises the following steps:

step S210, setting a protection target;

in some embodiments, the protection target may be set to protect the entire host/end system, taking the entire system environment as protection, avoiding new threats to enter and execute.

In some embodiments, the protection target may also be set to protect the specified critical directory(s) for tamper-proof protection.

Here, different protection targets are set, which will affect the content of the trusted white list learning.

In the case of deploying agent software on the host or the terminal, or in the case of security software with a terminal agent, protection of the agent may be added to avoid that the protection function will fail in case the agent is disabled or abnormal.

Step S220, learning a credible white list;

in the implementation process, the terminal agent learns credible progress information through automatic learning at a certain time, for example, setting the learning period to be one week. When the guard target selection is different, the contents of learning are also different. For example, in the case where the protection target is the entire host, the learned contents are the process list and information that the current host is running.

Fig. 3A is a trusted white list learning process with a protection target of a whole host according to an embodiment of the present application, including the following steps:

s301, acquiring all processes running by a host;

step S302, extracting key information corresponding to each process;

here, the key information includes at least one of: process name, process path, protection directory of attempted operation, operation authority (read only, read and write), description information, program icon, digital signature information, original file name, and copyright information. For example, the process white list may be created by extracting information such as the process name of the process, digital signature information, and the original file name (these three may be set as necessary information).

Step S303, adding key information corresponding to each process into a learning list;

in practice, the list includes, but is not limited to, the following fields: process name, process path, description information, program icon, digital signature information, original file name, copyright.

Step S304, judging whether the learning time is expired;

here, a learning period may be set according to an actual demand to learn a newly added process that is not in the white list within the learning period, and in a case where it is determined that the learning time is due, the learning is ended; in the case where it is determined that the learning time has not expired, step S305 is executed.

Step S305, adding the key information corresponding to each process into a learning list;

and S306, monitoring and discovering the newly added process creating behaviors.

In implementation, the system continuously listens for new process creation information. In the case where the creation of the new added process is not found, step S304 is performed to determine whether the learning time is expired; if the new process is found to be created, step S302 is executed to extract key information corresponding to the new process.

In the embodiment of the present application, when the learning time expires, the process information list is generated, but the white list is not generated yet, and the white list may be generated only by performing threat identification and confirmation of the next step (i.e., step S230 described below).

In the case that the protection target is a designated directory, the content of learning is to monitor whether there is process list information attempting to read or write to the designated directory, and read or write actions and corresponding rights. Fig. 3B is a trusted white list learning process with a protection target of a specified directory according to an embodiment of the present application, including the following steps:

step S310, monitoring the read or write condition of the specified target;

step S311, judging whether a process tries to read or write the specified directory;

in the case that it is determined that no process attempts to read or write the specified directory, executing step S310 to continue monitoring the case that the specified directory is read or written; in the case where it is determined that an attempt to read or write the specified directory is made, step S312 is performed.

Step S312, extracting key information corresponding to the process under the condition that the process tries to read and write is monitored;

step 313, recording the operation (read or write) attempted by the process;

step S314, updating process information and operating to a learning list;

here, the list includes, but is not limited to, the following fields: process name, process path, protection directory of attempted operation, operation authority (read only, read and write), description information, program icon, digital signature information, original file name, copyright.

Compared with the protection target being a host or the whole system, the list mostly records the operation of the protection target on a specific directory for confirmation (permission confirmation) after threat authentication.

Step S315, judging whether the learning time is expired.

In a case where it is determined that the learning time has expired, the learning ends; in the case where it is determined that the learning time has not expired, the flow returns to continue to perform step S310, and the case where the specified directory is read or written is continuously monitored.

In this embodiment, after the step S310 to the step S315 are executed, the representation learning is completed and the list information is generated when the learning cycle is finished.

Step S230, threat identification and confirmation;

the step confirms the list which is completed with learning, and eliminates the unnecessary process list or the list with threat.

And performing basic virus threat identification and system file identification on all files in the list through threat identification, confirming whether threats exist, eliminating the list with the threats, and reserving non-threat files and system files. The virus identification operation of the file can be identified by antivirus software, and if the technology is integrated in apparatuses with file identification capability, such as antivirus software, EDR, EPP and the like, the operation can be automatically identified. The system file can judge whether the system file is the system file according to the collected signature information and copyright information.

Files identified as threats are removed, system processes and unknown processes are left in the learning list, and the unknown processes can be sent to business personnel to judge whether the unknown processes are necessary processes of the business and whether the unknown processes have corresponding authority of the key directory.

In the embodiment of the present application, the lists generated finally are all trusted process lists (after being confirmed by service staff). And under the condition that the protection target is the host, the finally generated list is a process white list allowed to be operated by the current host. And under the condition that the protection target is the designated key directory, the finally generated list is a process white list allowing the designated directory to be read or written, and the process white list designates read-only and read-write permissions which can be performed by a specific white list process.

In some embodiments, in case the user confirms that the learning is insufficient, the learning time may be supplemented and the step S220 is performed back.

Step S240, the white list protection technology takes effect;

in the implementation process, the protection of the credible white list can take effect after confirmation. This process is a continuous monitoring, continuous guarding process until the function is shut down or the system is shut down. In the case where the user confirms that the learning is insufficient, the learning time may be supplemented, and step S220 is performed. Alternatively, in other embodiments, the protection target may also be switched to relearn, i.e., step S210 is performed.

Fig. 4A is a schematic flowchart of a white list protection technique for protecting a whole host according to an embodiment of the present application, including the following steps:

s401, traversing all currently running processes;

s402, extracting key information of all processes;

step S403, determining whether the key information of all the processes is matched with a white list;

executing step S404 under the condition that the key information of all the processes is determined to be matched with the white list; in the case where it is determined that there is no process key information in the white list, the process not in the white list is terminated, and step S404 is performed.

Step S404, determining whether all running processes are traversed and finished;

executing step S405 under the condition that all running processes are determined to be traversed and ended; in a case where it is determined that all the processes are not traversed, step S401 is performed.

S405, circularly monitoring a new process;

step S406, determining whether a new process exists;

in a case where it is determined that the new process exists, executing step S407; in the case where it is determined that there is no new process, execution returns to step S405.

Step S407, extracting key information of the new process;

and step S408, determining whether the key information for extracting the new process is matched with a white list.

Under the condition that the key information of the newly-built process is determined to be matched with the white list, the newly-built process is not intercepted, and the step S405 is executed; and under the condition that the key information of the newly-built process is determined to be not matched with the white list, intercepting the newly-built process, namely, ending the newly-built process.

Here, the "extracting key information of all processes" at step S402 and the "extracting key information of all processes" at step S407 in fig. 4A may coincide with the extracted process information content of the "extracting key information corresponding to the" extracting process "at step S302 in fig. 3A. In some embodiments, matching can be performed based on the process name, the original file name and the digital signature, and the situation of bypassing the protection is avoided, for example, only the process name is used, and the protection is easily bypassed due to the forged name.

Fig. 4B is a schematic flowchart of a white list protection technique for protecting a target specific directory according to an embodiment of the present application, including the following steps:

step S410, monitoring the condition that the specified directory is read or written;

step S411, judging whether a process tries to read or write the appointed directory or not;

in a case where it is determined that there is a process of performing a read or write operation on the specified directory, executing step S412; in the case where it is determined that no process performs a read or write operation on the specified directory, execution returns to step S410.

Step S412, extracting key information corresponding to the process;

step S413, judging whether the key information is matched with a white list or not;

in the case where it is determined that the key information matches the white list, performing step S414; in case it is determined that the key information does not match the white list, step S416 is performed to intercept the corresponding read or write operation.

Step S414, recording the authority operation (reading or writing) attempted by the process;

step S415, determining whether the read or write operation matches the permitted authority in the white list;

in the case that it is determined that the read or write operation matches the permitted authority in the white list, executing the corresponding read or write operation, and returning to execute step S410; in case that it is determined that the read or write operation does not match the allowed permissions in the white list, step S416 is performed to intercept the corresponding read or write operation.

Step S416, intercept this action (read or write).

The process information and white list matching process extracted in the flow shown in fig. 4B is the same as the process information and white list matching process extracted by the protection target being the host, and the judgment of whether the operation authority attempted by the current process is in the white list is added. The difference from the flow where the protection target is the host is on the protection actions for processes that are not whitelisted. When the protection target is the host, the illegal process execution is forbidden, and the system is protected from being damaged and viruses cannot be executed. When the protection target is the designated directory, the key directory is prevented from being illegally tampered or information is prevented from being leaked.

According to the embodiment of the application, the threat defense mode through traditional characteristic identification and the like is abandoned, and the frequently-upgraded countermeasure process can be effectively avoided; and a credible learning mechanism is introduced to avoid intercepting normal business behaviors and influencing the business. Moreover, the attack of new and old threats can be effectively protected, and various countermeasures such as a rule base do not need to be frequently upgraded. The technology is used for reinforcing and protecting the self safety of network equipment, safety equipment, printing equipment, dumb terminals and other equipment, so that the threat is prevented from entering; the technology is used on terminal protection devices such as antivirus software, EDR (enhanced data Rate), EPP (extended Peer protocol) and the like to perform safety protection on a host or a terminal; the technology is used for preventing destructive threats such as tampering, lasso and virus.

Based on the foregoing embodiments, an anomaly detection apparatus provided in an embodiment of the present application includes modules, each module includes sub-modules, and the modules can be implemented by a processor in an electronic device; of course, the implementation can also be realized through a specific logic circuit; in implementation, the processor may be a Central Processing Unit (CPU), a Microprocessor (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.

Fig. 5 is a schematic structural diagram of a component of an abnormality detection apparatus according to an embodiment of the present application, and as shown in fig. 5, the apparatus 500 includes:

an obtaining module 510, configured to obtain an initial white list of a system, where the initial white list includes a system list corresponding to a system process in the system;

a matching module 520, configured to match a process list currently running in the system based on the system list to obtain at least one process to be confirmed;

an analysis module 530, configured to perform permission analysis on each process to be confirmed to obtain a permission analysis result;

an adding module 540, configured to add, based on an authority analysis result of each to-be-confirmed process, a to-be-confirmed process having an authority to the initial white list, so as to form an updated white list;

a detection module 550, configured to perform anomaly detection on the system based on the updated white list.

In some embodiments, the obtaining module 510 includes a first determining submodule and a second determining submodule, where the first determining submodule is configured to determine a system list corresponding to a system process of the system based on a process name, digital signature information, and copyright information corresponding to the system process; the second determining submodule is configured to determine the system list as the initial white list.

In some embodiments, the analysis module 530 includes a first analysis submodule, a culling submodule, and a second analysis submodule, where the first analysis submodule is configured to perform virus analysis on each of the processes to be confirmed, and determine a threat process from the at least one process to be confirmed; the eliminating module is used for eliminating the threat process in the at least one process to be confirmed; and the second submodule is used for carrying out authority analysis on each process to be confirmed which is left after the threat process is eliminated, so as to obtain the authority analysis result.

In some embodiments, the system includes a system program, the exception detection method is used for exception detection of the system program; and the second analysis submodule is also used for analyzing the operation permission of each process to be confirmed which is left after the threat process is eliminated, and obtaining a permission analysis result of the system program.

In some embodiments, the system includes a preset directory in a system program, and the anomaly detection method is used for performing anomaly detection on the preset directory; the second analysis submodule is further used for analyzing the read-write permission corresponding to the preset directory to obtain a permission analysis result; correspondingly, the adding module 540 is further configured to add the preset directory with the permission to the initial white list based on the read-write permission corresponding to the preset directory, so as to form the updated white list.

In some embodiments, the detection module 550 includes a first obtaining sub-module, a third determining sub-module, an intercepting sub-module, an analyzing sub-module, and an adding and running sub-module, where the first obtaining sub-module is configured to obtain a current process in a current running state of the system; the third determining submodule is used for determining the current process which is not in the updated white list as a new process based on the updated white list; the interception submodule is used for intercepting the newly added process; the analysis submodule is used for carrying out authority analysis on the newly added process to obtain a newly added authority analysis result; and the adding and running submodule is used for adding the newly added process to the updated white list and running the newly added process under the condition that the analysis result of the newly added authority indicates that the newly added process has the running authority.

In some embodiments, the detection module 550 includes a second obtaining sub-module and a second intercepting sub-module, where the second obtaining sub-module is configured to obtain a read-write operation of a preset directory in the system program; the second intercepting submodule is used for intercepting the reading and/or writing operation of the preset directory which is not in the updated white list based on the updated white list.

The above description of the apparatus embodiments, similar to the above description of the method embodiments, has similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be noted that, in the embodiment of the present application, if the method is implemented in the form of a software functional module and sold or used as a standalone product, the method may also be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing an electronic device (which may be a mobile phone, a tablet computer, a notebook computer, a desktop computer, etc.) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

Correspondingly, the present application provides a storage medium, on which a computer program is stored, which when executed by a processor implements the steps in the abnormality detection method provided in the above-described embodiments.

Correspondingly, an embodiment of the present application provides an electronic device, and fig. 6 is a schematic diagram of a hardware entity of the electronic device provided in the embodiment of the present application, as shown in fig. 6, the hardware entity of the electronic device 600 includes: comprising a memory 601 and a processor 602, said memory 601 storing a computer program operable on said processor 602, said processor 602 implementing the steps in the anomaly detection method provided in the above described embodiments when executing said program.

The Memory 601 is configured to store instructions and applications executable by the processor 602, and may also buffer data (e.g., image data, audio data, voice communication data, and video communication data) to be processed or already processed by the processor 602 and modules in the electronic device 600, and may be implemented by a FLASH Memory (FLASH) or a Random Access Memory (RAM).

Here, it should be noted that: the above description of the storage medium and device embodiments is similar to the description of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the storage medium and apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units; can be located in one place or distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for realizing the method embodiments can be completed by hardware related to program instructions, the program can be stored in a computer readable storage medium, and the program executes the steps comprising the method embodiments when executed; and the aforementioned storage medium includes: various media that can store program codes, such as a removable Memory device, a Read Only Memory (ROM), a magnetic disk, or an optical disk.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing an electronic device (which may be a mobile phone, a tablet computer, a notebook computer, a desktop computer, etc.) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a magnetic or optical disk, or other various media that can store program code.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.

The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.

The above description is only for the embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An anomaly detection method, characterized in that it comprises:

acquiring an initial white list of a system, wherein the initial white list at least comprises a system list corresponding to a system process in the system;

matching a process list currently operated by the system based on the system list to obtain at least one process to be confirmed;

performing authority analysis on each process to be confirmed to obtain an authority analysis result;

adding the processes to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list;

and carrying out abnormity detection on the system based on the updated white list.

2. The method of claim 1, wherein the obtaining an initial white list of systems comprises:

determining a system list corresponding to the system process based on the process name, the digital signature information and the copyright information corresponding to the system process of the system;

determining the system list as the initial white list.

3. The method of claim 1, wherein the performing the permission analysis on each process to be confirmed to obtain a permission analysis result comprises:

performing virus analysis on each process to be confirmed, and determining a threat process from the at least one process to be confirmed;

removing the threat process in the at least one process to be confirmed;

and performing authority analysis on each process to be confirmed which is left after the threat process is eliminated to obtain an authority analysis result.

4. The method of claim 3, wherein the system includes a system program, the exception detection method being for exception detection of the system program; the permission analysis of each process to be confirmed remaining after the threat process is removed to obtain the permission analysis result includes:

5. The method according to claim 3, wherein the system comprises a preset directory in a system program, and the abnormality detection method is used for performing abnormality detection on the preset directory; the permission analysis of each process to be confirmed remaining after the threat process is removed to obtain the permission analysis result includes:

analyzing the read-write permission corresponding to the preset directory to obtain a permission analysis result;

correspondingly, the adding the process to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list, including:

6. The method of claim 4, wherein the detecting anomalies in the system based on the updated white list comprises:

acquiring a current process of the system in a current running state;

determining the current process which is not in the updated white list as a new process based on the updated white list;

intercepting the newly added process;

performing authority analysis on the newly added process to obtain a newly added authority analysis result;

and adding the newly added process to the updated white list and operating the newly added process under the condition that the analysis result of the newly added authority indicates that the newly added process has the operation authority.

7. The method of claim 5, wherein the detecting anomalies in the system based on the updated white list comprises:

acquiring read-write operation of a preset directory in the system program;

intercepting read and/or write operations of the preset directory which is not in the update white list based on the update white list.

8. An abnormality detection apparatus, characterized in that the apparatus comprises:

the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring an initial white list of a system, and the initial white list comprises a system list corresponding to a system process in the system;

the matching module is used for matching the process list currently operated by the system based on the system list to obtain at least one process to be confirmed;

the analysis module is used for carrying out authority analysis on each process to be confirmed to obtain an authority analysis result;

the adding module is used for adding the processes to be confirmed with the authority into the initial white list based on the authority analysis result of each process to be confirmed to form an updated white list;

and the detection module is used for carrying out abnormity detection on the system based on the updated white list.

9. An electronic device comprising a memory and a processor, the memory storing a computer program operable on the processor, wherein the processor implements the steps of the method of any one of claims 1 to 7 when executing the program.

10. A storage medium having stored thereon executable instructions for causing a processor to perform the steps of the method of any one of claims 1 to 7 when executed.