Notebook software vulnerability scanning method and system based on security policy

Abstract

The invention relates to a notebook software vulnerability scanning method based on a security policy. According to the method, firstly, a security policy library of a target notebook is obtained, and the security policy library comprises access control rules, data operation limiting conditions and vulnerability detection reference requirements for different software types; collecting software running data of the target notebook computer, wherein the software running data comprises current running process information, file system operation records, network connection states and software configuration parameters; performing matching analysis on the software operation data and the security policy library to generate a preliminary scanning result; evaluating the risk level of the software vulnerability according to the preliminary scanning result; and finally, based on the risk level and the repair guide terms in the security policy library, generating software vulnerability repair guide information. Therefore, notebook software vulnerabilities can be scanned comprehensively and accurately, and effective repair guidance is provided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software security, in particular to a notebook software vulnerability scanning system based on security policies. BACKGROUND

[0002] In the current era of rapid development of information technology, notebook computers, as a highly popular and powerful mobile computing device, are widely used in various fields such as office work, learning and entertainment. With the increasing diversity and complexity of software applications, the security threats faced by notebook software are becoming increasingly serious. Software vulnerabilities can be exploited maliciously, leading to data breaches, system crashes, cyber attacks and other serious consequences, causing significant losses to users.

[0003] Existing notebook software vulnerability scanning methods have many limitations. On the one hand, many traditional scanning methods mainly rely on a feature library of known vulnerabilities, and can only detect recorded vulnerabilities, making it difficult to effectively identify unknown vulnerabilities. This feature-based approach is not sufficient in the face of constantly changing attack methods and software security issues. On the other hand, existing scanning methods often lack comprehensive consideration of software usage scenarios and security policies. Different types of software, such as office software, development tools and entertainment applications, have different security needs and risk characteristics. However, existing methods usually use uniform standards for scanning, and cannot perform personalized vulnerability detection and risk assessment according to the specific characteristics and usage environment of the software.

[0004] In addition, in terms of vulnerability risk assessment, existing methods mostly focus on the severity of the vulnerability itself, ignoring factors such as the functional importance of software modules, the potential impact range of abnormal operations, and the historical vulnerability relevance. This makes it difficult to reasonably allocate resources when fixing vulnerabilities, which can result in some potentially large-impact low-risk vulnerabilities being overlooked, while some high-risk vulnerabilities with less impact on the system consume excessive repair resources.

[0005] Therefore, in order to improve the security of notebook software, a more intelligent and comprehensive vulnerability scanning method is needed that can combine security policies to accurately detect vulnerabilities and assess risks for different types of software, and provide effective repair guidance. SUMMARY

[0006] In view of the above, in order to at least partially solve the deficiencies in the prior art, in a first aspect, the embodiments of the present application provide a notebook software vulnerability scanning method based on security policies, the method comprising: obtaining a security policy library of a target notebook, the security policy library containing access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for different software types; collecting software running data of the target notebook, the software running data including current running process information, file system operation records, network connection status and software configuration parameters; matching and analyzing the software running data with the security policy library to generate a preliminary scanning result including identification of software modules not meeting the security policy and description of abnormal operation behaviors; evaluating a risk level of the software vulnerability according to the functional importance of the software modules, the potential impact range of the abnormal operation and the historical vulnerability correlation in the preliminary scanning result; generating software vulnerability repair guidance information including repair operation steps, repair priority identification and verification method description based on the risk level and repair instruction clauses in the security policy library.

[0007] In a second aspect, the embodiments of the present application further provide a notebook software vulnerability scanning system based on a security policy, comprising a processor and a machine readable storage medium, the machine readable storage medium is connected with the processor, the machine readable storage medium is used for storing programs, instructions or codes, and the processor is used for executing the programs, instructions or codes in the machine readable storage medium to realize the notebook software vulnerability scanning method based on a security policy.

[0008] In summary, the notebook software vulnerability scanning method and system based on a security policy provided by the embodiments of the present application realize comprehensive and accurate scanning of notebook software vulnerabilities by comprehensively using security policy library and software running data for matching analysis. This method can detect vulnerabilities individually for different types of software according to their specific security requirements and risk characteristics, greatly improving the accuracy and effectiveness of vulnerability detection. For example, in vulnerability risk assessment, the functional importance of software modules, the potential impact range of abnormal operation and the historical vulnerability correlation are fully considered, making the risk assessment result more scientific and reasonable. Through such comprehensive evaluation, the repair priority of the vulnerability can be determined more accurately, repair resources can be allocated reasonably, and repair efficiency can be improved. In addition, according to the risk level and repair instruction clauses in the security policy library, detailed software vulnerability repair guidance information is generated, including repair operation steps, repair priority identification and verification method description. This provides clear guidance for software vulnerability repair, making the repair process more standardized and reliable, and further improving the security and stability of notebook software.

[0009] Other features and advantages of the present application will be described in detail in the following specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description only show some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of the above drawings.

[0011] In order to more completely understand the present application and its beneficial effects, the following will be described in conjunction with the drawings, wherein the same reference numerals in the following description represent the same parts.

[0012] Figure 1 is a flow diagram of a notebook software vulnerability scanning method based on a security policy provided by the embodiments of the present application.

[0013] Figure 2 is an application scenario diagram of the notebook software vulnerability scanning method.

[0014] Figure 3 is a schematic diagram of a notebook software vulnerability scanning system based on a security policy provided by the embodiments of the present application. DETAILED DESCRIPTION

[0015] The technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort belong to the protection scope of the present application.

[0016] Please refer to Figure 1 and Figure 2 , Figure 1 is a flow diagram of a notebook software vulnerability scanning method based on a security policy provided by the embodiments of the present application, Figure 2 is an application scenario diagram of the notebook software vulnerability scanning method. Wherein, the application scenario includes at least one third-party security service platform and multiple notebooks for information interaction. Wherein, in the present embodiment, the third-party security service platform can be a server, a server cluster or other device with powerful data processing and storage capabilities, and the notebook can be a portable notebook computer or other device with data acquisition and transmission capabilities, and the present embodiment does not specifically limit this. Multiple notebooks collect their own software running data, such as current running process information, file system operation records, network connection status and software configuration parameters, and perform collaborative analysis with the third-party security service platform to evaluate software vulnerability risks and generate repair guidance information, so as to realize information interaction and collaborative work between the two and protect notebook software security.

[0017] AsFigure 1 As shown, the method comprises steps S110-S150, which are described in detail below.

[0018] Step S110: Obtain the security policy library of the target notebook, which contains access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for different software types In this embodiment, the security policy library of the target notebook is obtained as the basis for subsequent vulnerability scanning. The security policy library contains access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for different software types, which can assist in determining whether the software operation meets the security standards. In one possible example scenario of this embodiment, it is assumed that the target notebook is an office notebook used by an employee of an enterprise, and the notebook has installed various office software, development tools and entertainment applications. In order to ensure the security of the notebook software, the corresponding security policy library needs to be obtained.

[0019] Among them, step S110 can include steps S111-S115, which are described as follows.

[0020] Step S111: Extract the preset basic security policy from the system security configuration file of the target notebook, which contains general access control rules and default data operation restriction conditions at the operating system level In this embodiment, the basic security policy is extracted from the system security configuration file of the target notebook. The basic security policy can be pre-set by the operating system and contains general access control rules and default data operation restriction conditions. As an example, the basic security policy can be extracted by reading the system security configuration file of the target notebook. For example, the operating system stipulates that all software needs to be authorized when accessing system critical files, and prohibits software from modifying the system registry at will. The rules constitute part of the basic security policy.

[0021] Step S112: Synchronize the industry-specific security policy updated from the third-party security service platform, which contains software type-specific access control rules and enhanced data operation restriction conditions related to the use scenario of the target notebook In this embodiment, the industry-specific security policy updated from the third-party security service platform is obtained. The policy is formulated according to the use scenario and software type of the target notebook, and has stronger pertinence and security. Among them, the step S112 can be implemented through the following sub-steps S1121-S1125, which are described as follows.

[0022] Step S1121: Obtain the usage scenario label of the target notebook, which is determined by analyzing the usage frequency and function focus direction of office software, development tools and entertainment applications in the historical software usage records.

[0023] In this embodiment, the usage scenario label of the target notebook is determined by analyzing the historical software usage records of the target notebook. The usage scenario label can reflect which aspects of work or entertainment the target notebook is mainly used for. For example, as an example, by analyzing the historical software usage records of the target notebook, it is found that the usage frequency of office software on the notebook is relatively high, and it is mainly used for document processing, data statistics and other work; the development tools also have a certain usage frequency, which are used for code writing and project development; the usage frequency of entertainment applications is relatively low. According to the analysis result, the usage scenario label of the notebook is determined as "mainly for office and development".

[0024] Step S1122: Send a policy synchronization request to the third-party security service platform according to the usage scenario label, which contains the operating system version, software installation list and industry attribution information of the target notebook.

[0025] In this embodiment, according to the determined usage scenario label, a policy synchronization request is sent to the third-party security service platform. The request contains the operating system version, software installation list and industry attribution information of the target notebook, so that the third-party security service platform can provide industry-specific security policies that meet the needs of the notebook.

[0026] As an example, based on the foregoing example, according to the usage scenario label of "mainly for office and development", a policy synchronization request is sent to the third-party security service platform. The request can list the operating system version (such as Windows 10) of the target notebook, the software installation list (such as Microsoft Office, Visual Studio, etc.) and the industry to which it belongs (such as information technology industry).

[0027] Step S1123: Receive the industry-specific security policy data packet returned by the third-party security service platform, which contains enhanced access control rules for office software, enhanced data operation restriction conditions for development tools and enhanced vulnerability detection benchmark requirements for entertainment applications.

[0028] In this embodiment, the received industry-specific security policy data packet returned by the third-party security service platform contains enhanced security policies for different software types. For example, the third-party security service platform returns an industry-specific security policy data packet according to the request. In the data packet, for office software, enhanced access control rules are included, such as limiting office software to access only the file server within the enterprise; for development tools, enhanced data operation restriction conditions are included, such as prohibiting development tools from performing file operations outside the project directory; and for entertainment applications, enhanced vulnerability detection benchmark requirements are included, such as requiring the network connection of the entertainment application to use an encryption protocol.

[0029] Step S1124: integrity check of the industry-specific security policy data packet, verifying whether the digital signature and the hash value of the data packet are consistent with the verification information provided by the third-party security service platform.

[0030] In this embodiment, the received industry-specific security policy data packet is subjected to integrity check to ensure that the data packet has not been tampered with during transmission. The integrity of the data packet is determined by verifying whether the digital signature and the hash value of the data packet are consistent with the verification information provided by the third-party security service platform.

[0031] As an example, in the process of integrity check of the industry-specific security policy data packet, the digital signature of the data packet can be verified first to ensure that it comes from a trusted third-party security service platform. Then, the hash value of the data packet is calculated and compared with the hash value provided by the third-party security service platform. If they are consistent, it means that the data packet is complete and correct.

[0032] Step S1125: parsing the industry-specific security policy data packet that passes the verification, extracting software type-specific access control rules and enhanced data operation restriction conditions matching the target notebook usage scenario label as industry-specific security policies In this embodiment, the industry-specific security policy data packet that passes the verification is parsed to extract software type-specific access control rules and enhanced data operation restriction conditions matching the target notebook usage scenario label as the final industry-specific security policies.

[0033] As an example, the industry-specific security policy data packet that passes the verification is parsed. For example, according to the usage scenario label of "office and development oriented", specific access control rules and enhanced data operation restriction conditions for office software and development tools are extracted. For example, the rule that office software can only access the file server within the enterprise, and the restriction condition that development tools are prohibited from performing file operations outside the project directory are extracted.

[0034] Step S113: Perform version verification on the basic security policy and the industry-specific security policy, identify policy clauses with version conflicts and mark them as items to be verified. In this embodiment, version verification may be performed on the basic security policy and the industry-specific security policy to identify policy clauses with version conflicts and mark them as items to be verified.

[0035] In one possible example of this embodiment, a version check is performed between the base security policy extracted from the system security configuration file and the industry-specific security policy synchronized from a third-party security service platform. During the check, if a conflict is found between the access rights for certain system files in the base security policy and those in the industry-specific security policy, the conflicting policy clauses may be marked as pending for verification to facilitate subsequent processing.

[0036] Step S114: Classify and integrate the policy clauses that are not marked as conflicting, and divide them into office software policy group, development tool policy group and entertainment application policy group according to software type. Each policy group contains the access control rules, data operation restrictions and vulnerability detection benchmark requirements of the corresponding software type. In this embodiment, unmarked conflicting policy clauses are categorized and integrated, and divided into different policy groups based on software type. Each policy group contains access control rules, data operation restrictions, and vulnerability detection benchmark requirements for the corresponding software type. For example, unmarked conflicting policy clauses are categorized and integrated. Policy clauses related to office software are integrated into the office software policy group, which contains the office software's access control rules (e.g., only access to internal enterprise file servers), data operation restrictions (e.g., prohibiting arbitrary modification of important documents), and vulnerability detection benchmark requirements (e.g., regularly checking for software updates); policy clauses related to development tools are integrated into the development tool policy group, which contains the development tool's access control rules (e.g., only access to project directories), data operation restrictions (e.g., prohibiting file operations in non-project directories), and vulnerability detection benchmark requirements (e.g., checking the security of code bases); and policy clauses related to entertainment applications are integrated into the entertainment application policy group, which contains the entertainment application's access control rules (e.g., only connection to official servers), data operation restrictions (e.g., prohibiting access to sensitive system information), and vulnerability detection benchmark requirements (e.g., checking the encryption of network connections).

[0037] Step S115: Manually review the conflicting policy clauses, retain the high-priority policy clauses based on the actual usage requirements of the target notebook, and generate the final security policy library. In this embodiment, the policy clauses with label conflicts are manually reviewed, and high-priority policy clauses are retained according to the actual use requirements of the target notebook, and finally a complete security policy library is generated. For example, in one possible example of this embodiment, the policy clauses with label conflicts are manually reviewed. Considering that the target notebook is mainly used for office and development work, and the enterprise has high requirements for data security, it is decided to retain the provisions for system file access permissions in the industry-specific security policy, because the provisions are more in line with the security requirements of the enterprise. After manual review and screening, all valid policy clauses are integrated to generate the final security policy library.

[0038] Step S120: Collect software running data of the target notebook, the software running data including current running process information, file system operation record, network connection state and software configuration parameters.

[0039] In this embodiment, by collecting software running data of the target notebook, the data is an important input for subsequent vulnerability scanning. The software running data includes current running process information, file system operation record, network connection state and software configuration parameters. Through analysis of the data, the running state and behavior of the software can be understood. For example, as an example, continuing to take the office notebook used by an employee of an enterprise as an example, the software running data of the notebook is collected.

[0040] The step S120 can include the following sub-steps S121-S125, which are described in detail as follows.

[0041] Step S121: Obtain a list of all currently running software processes through a system process monitoring interface, and record the name, start time, parent process identifier and system resource occupation of each process as current running process information.

[0042] In this embodiment, a list of all currently running software processes of the target notebook is obtained through a system process monitoring interface, and relevant information of each process is recorded, including process name, start time, parent process identifier and system resource occupation. For example, as an example, a list of all currently running software processes is obtained through a system process monitoring interface. For example, it is recorded that the name of the Microsoft Word process is “WINWORD.EXE”, the start time is 9:30 am, the parent process identifier is explorer.exe, and the CPU resource occupation is 5% and the memory resource occupation is 100 MB. Similarly, other running software processes are also recorded in detail.

[0043] Step S122: traversing the specified directory path of the file system, recording the timestamp, operation type and target file path of the file operation of the software module on the system file and user data file as the file system operation record; the file operation includes at least one of the read operation, the write operation and the delete operation In this embodiment, the specified directory path of the file system is traversed, and the file operation information of the software module on the system file and the user data file is recorded, including the timestamp, the operation type and the target file path. As an example, the specified directory path of the file system is traversed, such as the "Program Files" and "Users" directories of the C disk. It is recorded that the user data file "document.docx" is read by the office software at 10:15 am, and the system file "system.dll" is written by the development tool at 2:30 pm.

[0044] Step S123: monitoring the data stream transmission of the network interface, recording the target IP address, port number, transmission protocol type and data flow size of the network connection established by the software module as the network connection state.

[0045] In this embodiment, the data stream transmission of the network interface is monitored, and the relevant information of the network connection established by the software module is recorded. This can be realized through the following sub-steps S1231-S1236, which are described as follows.

[0046] Step S1231: enabling a network flow monitoring driver to capture data packets of all network interfaces of the target notebook.

[0047] In this embodiment, the network flow monitoring driver is enabled to capture data packets of all network interfaces of the target notebook. For example, a suitable network flow monitoring driver needs to be selected first. Different operating systems support different types of drivers, so the operating system used by the target notebook needs to be selected. For example, if the target notebook uses a Windows operating system, an open-source network packet capture driver such as WinPcap or Npcap can be selected; if a Linux operating system is used, a libpcap driver can be selected.

[0048] Step S1232: performing protocol analysis on the captured data packets to extract the source process identifier, target IP address, target port number, transmission protocol type and data packet size.

[0049] In this embodiment, the captured data packet is protocol parsed to extract key information such as source process identification, target IP address, target port number, transmission protocol type and data packet size. For example, the source process identification of a certain data packet is parsed as "WINWORD.EXE", the target IP address is "192.168.1.100", the target port number is "80", the transmission protocol type is "HTTP", and the data packet size is 1024 bytes.

[0050] Step S1233: According to the source process identification, the corresponding software module is associated to establish a mapping relationship between the software module and the network connection.

[0051] In this embodiment, for example, according to the source process identification "WINWORD.EXE", the data packet is associated to the Microsoft Word software module. In this way, a mapping relationship between the software module and the network connection is established, which facilitates subsequent analysis of the network behavior of the software.

[0052] Step S1234: The network connections established by the same software module within a preset time window are aggregated to count the connection times, total data flow size and average connection duration of each target IP address.

[0053] In this embodiment, as an example, the preset time window is 1 hour. The network connections established by the Microsoft Word software module within 1 hour are aggregated. Statistics show that the connection times between the software module and the target IP address "192.168.1.100" are 10 times, the total data flow size is 10 KB, and the average connection duration is 5 seconds.

[0054] Step S1235: Filter out the network connections related to system services and only keep the network connection information initiated by user-installed software modules.

[0055] In this embodiment, the network connections related to system services are filtered out, and only the network connection information initiated by user-installed software modules is kept, so as to more accurately analyze the network behavior of user software. For example, the network connections related to system services (such as Windows Update service) can be filtered out. Only the network connection information initiated by user-installed office software, development tools and entertainment applications and other software modules is kept.

[0056] Step S1236: The target IP address, port number, transmission protocol type and data flow size in the retained network connection information are sorted into network connection state records.

[0057] In this embodiment, the retained network connection information is sorted to form network connection state records.

[0058] As an example, the target IP address, port number, transmission protocol type and data flow size in the reserved network connection information are sorted out. For example, the network connection state record of the Microsoft Word software module and the target IP address "192.168.1.100" is sorted out, including the port number "80", the transmission protocol type "HTTP" and the data flow size 10KB.

[0059] Step S124: Read the configuration file and registry item of the software module, and extract the function enable state, permission setting parameter, data storage path and third party service integration information of the software as the software configuration parameter.

[0060] In this embodiment, the configuration file and registry item of the software module are read, and the related configuration parameters of the software are extracted, including the function enable state, permission setting parameter, data storage path and third party service integration information. As an example, the configuration file and registry item of an office software are read. The function enable state of the software is extracted from the configuration file, such as whether the automatic save function is enabled; the permission setting parameter is extracted from the registry item, such as whether the permission of modifying system files is possessed; at the same time, the data storage path is obtained, such as the default document saving path; and the third party service integration information is obtained, such as whether the cloud storage service is integrated. The information is sorted as the software configuration parameter, which is used for subsequent vulnerability scanning and analysis.

[0061] Step S125: Time stamp alignment is performed on the current running process information, the file system operation record, the network connection state and the software configuration parameter, to generate software running data with time sequence correlation.

[0062] In this embodiment, the previously collected current running process information, file system operation record, network connection state and software configuration parameter are aligned according to the time stamp, so that the data has time sequence correlation, forming complete software running data.

[0063] As an example, the data of different data sources is aligned based on the time stamp. For example, for a certain time point, the software process information, file operation record, network connection state and software configuration parameter corresponding to the time point are associated. If at 10:30 am, a certain office software process is running, a file reading operation is performed at the same time, and a network connection is established with a specific IP address, the information is integrated in time sequence to form software running data with time sequence correlation. In this way, the running state and behavior of the software at different time points can be more comprehensively and accurately understood.

[0064] Step S130: matching analysis of the software running data and the security policy library, generating a preliminary scanning result containing the software module identification not satisfying the security policy and the abnormal operation behavior description In this embodiment, the collected software running data is matched and analyzed with the security policy library to find out the software module not satisfying the security policy and the abnormal operation behavior, and generate a preliminary scanning result. As an example, continue to take the office notebook of an employee of a certain enterprise as an example, and perform detailed matching analysis of the previously generated software running data and the security policy library.

[0065] In this embodiment, the collected software running data is matched and analyzed with the security policy library to find out the software module not satisfying the security policy and the abnormal operation behavior, and generate a preliminary scanning result. As an example, continue to take the office notebook of an employee of a certain enterprise as an example, and perform detailed matching analysis of the previously generated software running data and the security policy library.

[0066] Step S131: extracting the access control rule of the office software policy group from the security policy library, checking whether the parent process identification of the office software process conforms to the preset trusted process chain requirement, and recording the office software module identification not conforming to the requirement and the parent process violation information.

[0067] In this embodiment, the access control rule is extracted from the office software policy group of the security policy library, and the parent process identification of the office software process is checked to see whether it conforms to the preset trusted process chain requirement.

[0068] As an example, the office software policy group stipulates that the parent process of the office software must come from a trusted system process. For example, the parent process of Microsoft Word should normally be explorer.exe. In the checking process, it is found that the parent process identification of a certain Microsoft Word process is an unknown process, which does not conform to the preset trusted process chain requirement. The office software module identification is recorded as "WINWORD.EXE", and the parent process violation information is "the parent process identification is an unknown process, which does not conform to the trusted process chain requirement".

[0069] Step S132: checking whether the write operation of the development tool to the system file is only directed to the allowed temporary directory path according to the data operation limitation condition of the development tool policy group, and recording the development tool module identification performing write operation in the non-allowed directory and the file path violation information.

[0070] In this embodiment, according to the data operation restriction condition of the development tool policy group in the security policy library, it is checked whether the write operation of the development tool to the system file conforms to the regulation. As an example, the development tool policy group stipulates that the write operation of the development tool to the system file can only be performed in the allowed temporary directory path. For example, a development tool Visual Studio is allowed to perform file write operation in a specific project temporary directory. In the checking process, it is found that the development tool performs write operation in a non-allowed system critical directory. The module identification of the development tool is recorded as "devenv.exe", and the file path violation information is "write operation is performed in a non-allowed system critical directory (such as C:\Windows\System32)".

[0071] Step S133: According to the network connection restriction condition of the entertainment application policy group, it is verified whether the target IP address of the network connection established by the entertainment application belongs to the whitelist range, and the module identification of the entertainment application connected to the non-whitelist IP address and the IP address violation information are recorded.

[0072] In this embodiment, according to the network connection restriction condition of the entertainment application policy group in the security policy library, it is verified whether the target IP address of the network connection established by the entertainment application is within the whitelist range. As an example, the entertainment application policy group stipulates that the entertainment application can only connect to the IP addresses within the whitelist. For example, a certain entertainment application game A is allowed to connect to the IP address of the official server of the game. In the verification process, it is found that the entertainment application establishes a network connection with a non-whitelist IP address. The module identification of the entertainment application is recorded as "gameA.exe", and the IP address violation information is "connected to a non-whitelist IP address (such as 192.168.1.200)".

[0073] Step S134: Extract the vulnerability detection benchmark requirement of each policy group in the security policy library, and compare whether the permission setting in the software configuration parameter reaches the minimum permission level of the benchmark requirement, and record the software module identification and permission parameter violation information of the permission setting exceeding the standard.

[0074] In this embodiment, the vulnerability detection benchmark requirement is extracted from each policy group in the security policy library, and the permission setting in the software configuration parameter is compared with it to find out the software module whose permission setting exceeds the standard. The implementation can be realized through the following sub-steps S1341-S1346, and the specific description is as follows.

[0075] Step S1341: Extract the minimum permission level requirement of the office software from the office software policy group, and the minimum permission level requirement includes only allowing to read the user document directory, prohibiting to write to the system critical directory, and only allowing to connect to the enterprise internal network.

[0076] In this embodiment, the minimum privilege level requirement of the office software is extracted from the office software policy group. As an example, the minimum privilege level requirement of the office software specified by the office software policy group includes only allowing reading the user document directory, such as "C:\Users\username\Documents"; prohibiting writing to the system critical directory, such as "C:\Windows"; and only allowing connecting to the enterprise internal network, such as the IP address segment 192.168.1.0-192.168.1.255.

[0077] Step S1342: Extracting the minimum privilege level requirement of the development tool from the development tool policy group, which includes only allowing accessing the project working directory, prohibiting directly modifying the system registry, and only allowing connecting to the IP specified by the code hosting platform.

[0078] In this embodiment, the minimum privilege level requirement of the development tool is extracted from the development tool policy group. As an example, the minimum privilege level requirement of the development tool specified by the development tool policy group includes only allowing accessing the project working directory, such as "C:\Projects\ProjectA"; prohibiting directly modifying the system registry; and only allowing connecting to the IP address specified by the code hosting platform, such as the IP address of GitHub.

[0079] Step S1343: Extracting the minimum privilege level requirement of the entertainment application from the entertainment application policy group, which includes only allowing accessing the user media file directory, prohibiting reading the system sensitive information, and only allowing connecting to the official server of the application.

[0080] In this embodiment, the minimum privilege level requirement of the entertainment application is extracted from the entertainment application policy group. As an example, the minimum privilege level requirement of the entertainment application specified by the entertainment application policy group includes only allowing accessing the user media file directory, such as "C:\Users\username\Music"; prohibiting reading the system sensitive information, such as the critical information in the registry; and only allowing connecting to the IP address of the official server of the application.

[0081] Step S1344: Obtaining the actual privilege settings in the software configuration parameters, including the file access path range, the registry modification privilege, and the network connection target range.

[0082] In this embodiment, the actual privilege settings in the software configuration parameters are obtained, including the file access path range, the registry modification privilege, and the network connection target range. As an example, for a certain office software, the actual file access path range obtained from the software configuration parameters includes the system critical directory, the registry modification privilege is modifiable, and the network connection target range includes the external network. The actual privilege settings will be used for comparison with the minimum privilege level requirement.

[0083] Step S1345: Comparing the actual permission settings with the minimum permission level requirements of the corresponding policy group, identifying software modules whose file access paths exceed the allowed range, whose registry modification permissions are too high, and whose network connection targets exceed the specified range.

[0084] In this embodiment, the actual permission settings of the software are compared with the minimum permission level requirements of the corresponding policy group to identify software modules with excessive permission settings. As an example, the actual permission settings of an office software are compared with the minimum permission level requirements of the office software policy group. It is found that the file access path of the software exceeds the allowed user document directory range, the registry modification permission is too high, and the network connection target exceeds the enterprise intranet range. The software module is determined to be a software module with excessive permission settings.

[0085] Step S1346: Recording the identification of the software module with excessive permission settings and the corresponding file access path violation information, registry permission violation information, and network connection target violation information as the permission parameter violation information.

[0086] In this embodiment, the identification of the software module with excessive permission settings and the related violation information are recorded. As an example, the identification of the office software module with excessive permission settings is recorded as "WINWORD.EXE", the file access path violation information is "file access path exceeds the allowed user document directory range, including system critical directory", the registry permission violation information is "registry modification permission is too high, allowing modification of system registry", and the network connection target violation information is "network connection target exceeds the enterprise intranet range, including external network".

[0087] Step S135: Integrating all software module identifications that do not meet the security policy and the corresponding parent process violation information, file path violation information, IP address violation information, and permission parameter violation information to generate a preliminary scan result.

[0088] In this embodiment, all software module identifications that do not meet the security policy and the related violation information recorded previously are integrated to generate a preliminary scan result. As an example, the parent process violation information of the office software module "WINWORD.EXE", the permission parameter violation information, the file path violation information of the development tool module "devenv.exe", and the IP address violation information of the entertainment application module "gameA.exe" are integrated. The preliminary scan result contains software module identifications that do not meet the security policy and detailed descriptions of abnormal operation behaviors, providing a basis for subsequent vulnerability risk assessment.

[0089] Step S140: According to the function importance of the software module in the preliminary scanning result, the potential impact range of abnormal operation and the historical vulnerability correlation, the risk level of the software vulnerability is evaluated.

[0090] In this embodiment, according to the preliminary scanning result, the function importance of the software module, the potential impact range of abnormal operation and the historical vulnerability correlation are comprehensively considered to evaluate the risk level of the software vulnerability. As an example, the risk level of the software module in the preliminary scanning result is evaluated in detail, taking the office notebook of an employee of a certain enterprise as an example. Step S140 can include the following sub-steps S141-S145, which are described in detail below.

[0091] Step S141: Obtain the function description information of each software module in the preliminary scanning result from the software management database of the target notebook, and divide the function importance of the software module into critical, important or general levels according to whether the software module involves core business processing, user data storage or system critical function operation.

[0092] In this embodiment, the function description information of the software module is obtained from the software management database of the target notebook, and is divided according to its function importance. As an example, the function description information of the software module in the preliminary scanning result is obtained from the software management database. For example, a certain office software is used to process core business data of the enterprise, involving important document editing and data statistics, and its function importance is divided into critical level; a certain development tool is used for daily code development, but has little effect on the operation of the system core function, and its function importance is divided into important level; a certain entertainment application is mainly used for leisure and entertainment, and does not involve core business processing and user data storage, and its function importance is divided into general level.

[0093] Step S142: Analyze the operation type involved in the abnormal operation, determine the impact range corresponding to the abnormal operation, and generate a potential impact range description; the potential impact range description includes whether it can cause data leakage, system crash or third-party attack entry.

[0094] In this embodiment, the type of abnormal operation is analyzed, the possible impact range is determined, and a potential impact range description is generated. As an example, for the abnormal operation of a certain office software, such as setting the permission beyond the standard to access system critical files and external network, the operation type is analyzed as unauthorized access. This abnormal operation can cause data leakage because system critical data can be obtained and transmitted to the external network; it can also become a third-party attack entry, and external attackers can attack through the abnormal permission of the software. The generated potential impact range description is "may cause data leakage and become a third-party attack entry".

[0095] Step S143: Query the vulnerability history database to obtain the historical vulnerability records of the software module and the repair situation of the corresponding abnormal operation type, and count the probability of causing a security event in the same abnormal operation history as the historical vulnerability correlation probability.

[0096] In this embodiment, the vulnerability history database is queried to obtain the historical vulnerability records of the software module and the repair situation of the abnormal operation, and the probability of causing a security event in the same abnormal operation is counted. As an example, the vulnerability history database is queried, and for the abnormal operation of unauthorized access of an office software, it is found that similar unauthorized access operations in a certain number of cases have caused security events. The probability of causing a security event by the unauthorized access operation in the cases is counted as the historical vulnerability correlation probability of the abnormal operation of this software module.

[0097] Step S144: Establish risk level evaluation rules, wherein: if the function importance is critical, the potential impact range includes data leakage or system crash, and the historical vulnerability correlation probability exceeds a preset threshold, it is rated as high risk level; if the function importance is important, the potential impact range includes third-party attack entry, or the function importance is critical but the historical vulnerability correlation probability does not exceed the threshold, it is rated as medium risk level; and the rest is rated as low risk level.

[0098] In this embodiment, risk level evaluation rules are established, and the risk level is evaluated according to the function importance, potential impact range and historical vulnerability correlation probability of the software module. As an example, the preset threshold is a pre-set probability value. If the function importance of a software module is critical, the potential impact range includes data leakage or system crash, and the historical vulnerability correlation probability exceeds the preset threshold, it is rated as high risk level; if the function importance of the software module is important, the potential impact range includes third-party attack entry, or the function importance is critical but the historical vulnerability correlation probability does not exceed the threshold, it is rated as medium risk level; and the rest is rated as low risk level.

[0099] Step S145: According to the function importance division result, the potential impact range description and the historical vulnerability correlation probability, the risk level of each software module vulnerability in the preliminary scanning result is evaluated.

[0100] In this embodiment, according to the previous division results and statistical data, the risk level of each software module vulnerability in the preliminary scanning result is evaluated. As an example, for the office software "WINWORD.EXE", the function importance is critical level, the potential influence range includes data leakage and third-party attack entrance, the historical vulnerability correlation probability exceeds the preset threshold, and the evaluation is high risk level; for the development tool "devenv.exe", the function importance is important level, the potential influence range includes third-party attack entrance, and the evaluation is medium risk level; for the entertainment application "gameA.exe", the function importance is general level, the potential influence range is relatively small, and the evaluation is low risk level.

[0101] Step S150: based on the risk level and the repair guidance clauses in the security policy library, generating software vulnerability repair guidance information including repair operation steps, repair priority identification and verification method description.

[0102] In this embodiment, according to the risk level of the vulnerability and the repair guidance clauses in the security policy library, detailed software vulnerability repair guidance information is generated. As an example, continuing to take the office notebook of an employee of a certain enterprise as an example, according to the previously evaluated software module vulnerability risk level and the repair guidance clauses in the security policy library, repair guidance information is generated.

[0103] Among them, step S150 can be realized through the following sub-steps S151-S157, which are described in detail as follows.

[0104] Step S151: extracting the repair guidance clauses corresponding to each risk level from the security policy library, the high risk level corresponds to the emergency repair clause, the medium risk level corresponds to the regular repair clause, and the low risk level corresponds to the optimized repair clause.

[0105] In this embodiment, the repair guidance clauses corresponding to different risk levels are extracted from the security policy library. As an example, the security policy library sets emergency repair clauses for high-risk level vulnerabilities, such as immediately stopping the violation process, limiting the operation permission of the violation file, etc.; sets regular repair clauses for medium-risk level vulnerabilities, such as adjusting software configuration parameters, updating software version patches, etc.; sets optimized repair clauses for low-risk level vulnerabilities, such as closing unnecessary function modules, adjusting data storage path, etc.

[0106] Step S152: for high-risk level vulnerabilities, according to the requirements of the emergency repair clauses, operation instructions for terminating the running of the violation process, limiting the operation permission of the violation file, and blocking the violation network connection are formulated.

[0107] In this embodiment, for high-risk level vulnerabilities, specific operation guidelines are formulated according to the emergency repair clause. As an example, for the office software "WINWORD.EXE" rated as high-risk level, according to the emergency repair clause, the operation guidelines are as follows: terminate the running of the violation process, forcibly terminate the software process through the system process management tool; limit the file operation permission of the violation, modify the file access permission of the software, and only allow access to the user document directory; block the violation network connection, and prohibit the software from connecting to the external network through the firewall setting.

[0108] Step S153: For medium-risk level vulnerabilities, according to the provisions of the regular repair clause, generate operation steps to adjust software configuration parameters, update software version patches, and re-bind trusted parent processes.

[0109] In this embodiment, for medium-risk level vulnerabilities, operation steps are generated according to the regular repair clause. As an example, for the development tool "devenv.exe" rated as medium-risk level, according to the regular repair clause, the operation steps are as follows: adjust software configuration parameters, modify the registry permission and network connection settings of the software to meet the minimum permission level requirements; update software version patches, download and install the latest software version patches from the official channel; re-bind trusted parent processes, ensure that the parent process of the development tool is a trusted system process through system settings.

[0110] Step S154: For low-risk level vulnerabilities, according to the optimization repair clause, provide optimization suggestion steps to close unnecessary function modules, adjust data storage paths, and narrow network connection permissions.

[0111] In this embodiment, for low-risk level vulnerabilities, optimization suggestion steps are provided according to the optimization repair clause. As an example, for the entertainment application "gameA.exe" rated as low-risk level, according to the optimization repair clause, the optimization suggestion steps are as follows: close unnecessary function modules, such as closing the advertisement push function in the application; adjust the data storage path, adjust the data storage path of the application from the system critical directory to the user-specified safe directory; narrow the network connection permission, limit the application to only connect to the official server of the application.

[0112] Step S155: Assign priority identifiers to each repair operation step according to the risk level, mark the high-risk vulnerability repair step as the highest priority, mark the medium-risk as the second highest priority, and mark the low-risk as the general priority.

[0113] In this embodiment, the priority identification is assigned to the repair operation step according to the risk level. As an example, the repair operation step of the office software "WINWORD.EXE" with high risk level is marked as the highest priority; the repair operation step of the development tool "devenv.exe" with medium risk level is marked as the second highest priority; and the repair operation step of the entertainment application "gameA.exe" with low risk level is marked as the general priority.

[0114] Step S156: design a verification method for each repair operation step, including verifying whether the repaired process meets the trusted process chain requirement, whether the file operation is only for the allowed directory, whether the network connection is only connected to the white list IP address, and whether the configuration parameter reaches the minimum permission level.

[0115] In this embodiment, a verification method is designed for each repair operation step, which can be implemented by the following sub-steps S1561-S1565, as follows.

[0116] Step S1561: for the repair step of terminating the running of the violation process, the verification method is designed as follows: after the repair operation is executed, the system process monitoring interface is used to check whether the process of the corresponding software module has been terminated and has not been restarted within a preset time.

[0117] In this embodiment, a verification method is designed for the repair step of terminating the running of the violation process. As an example, for the repair step of terminating the running of the violation process of the office software "WINWORD.EXE", the verification method is designed as follows: after the repair operation is executed, the system process monitoring interface is used to check whether the process of the software has been terminated. And within a preset period of time, such as 10 minutes, it is continuously monitored whether the process is restarted. If it is not restarted within the preset time, the verification is passed.

[0118] Step S1562: for the repair step of limiting the violation file operation permission, the verification method is designed as follows: simulate the file write operation of the software module, check whether the operation is only allowed to be completed in the directory path specified by the security policy, and whether the write operation in the non-allowed directory is rejected by the system.

[0119] For the repair step of limiting the file operation permission of the violation, designing a reasonable verification method is the key to ensure the repair effect. Take the office software "WINWORD.EXE" as an example, its file operation permission is limited in the repair operation, and it is stipulated that it can only perform file operation in the user document directory. When verifying, simulate the file write operation of the office software. File operation interface provided by the system can be used to attempt file write operation in different directory paths. First, write operation is performed in the user document directory specified by the security policy, and it is checked whether the operation can be completed normally. If the write operation is successful, it means that the software can normally perform file operation in the allowed directory. Then, attempt to perform write operation in the non-allowed system critical directory, and observe whether the system rejects the operation. If the system rejects the write operation and prompts that there is no permission or the operation fails, it means that the repair of the file operation permission limitation of the office software is effective and meets the requirements of the security policy.

[0120] Step S1563: For the repair step of blocking the violation network connection, the verification method is designed as follows: attempt to connect the non-whitelist IP address by the software module, check whether the network connection request is intercepted by the firewall, and whether the connection state is displayed as rejected.

[0121] For the repair step of blocking the violation network connection, a corresponding verification method needs to be designed to confirm whether the repair is successful. Take the entertainment application "gameA.exe" as an example, its network connection permission is limited in the repair process, and it is stipulated that it can only connect to the IP addresses in the whitelist. When verifying, attempt to connect the non-whitelist IP address by the entertainment application. The connection request can be sent to the non-whitelist IP address by simulating network request. At the same time, check the firewall log and the connection state of the software. If the firewall log shows that the connection request is intercepted, and the connection state of the software shows that it is rejected, such as the prompt "connection is rejected" "cannot connect to the specified server" and other information, it means that the repair of the violation network connection of the entertainment application is effective, and the connection between the software and the non-whitelist IP address is successfully blocked, which meets the requirements of the security policy.

[0122] Step S1564: For the repair step of adjusting the software configuration parameter, the verification method is designed as follows: read the software configuration file and registry item, and confirm that the configuration parameter has been modified to the minimum permission level required by the security policy, including the file access path range, the registry modification permission, and the network connection target range.

[0123] Adjusting software configuration parameters is an important part of repairing software vulnerabilities. In order to ensure that the configuration parameters are adjusted to the minimum permission level that meets the security policy, a corresponding verification method needs to be designed. Taking the development tool "devenv.exe" as an example, its configuration parameters are adjusted during the repair process to meet the minimum permission level requirements of the development tool policy group. During verification, the configuration file and registry entries of the development tool are read. Through the file reading interface and registry access interface provided by the system, the actual configuration parameters of the software are obtained. Then, the actual file access path range, registry modification permissions, and network connection target range are compared with the minimum permission level required by the security policy. For example, check if the file access path is limited to the allowed project temporary directory, if the registry modification permission is prohibited from direct modification, and if the network connection target is only the IP address specified by the code hosting platform. If the actual configuration parameters are consistent with the minimum permission level required by the security policy, it indicates that the configuration parameter adjustment repair for the development tool is effective, and the permission settings of the software meet the regulations of the security policy.

[0124] Step S1565: For the repair step of updating the software version patch, the verification method is designed as follows: check if the version number of the software module is consistent with the patch version specified by the security policy, and verify the integrity of the patch installation through the official interface of the software.

[0125] Among them, updating the software version patch is a necessary node for repairing software vulnerabilities. In order to ensure that the patch is installed successfully and effectively, a corresponding verification method needs to be designed. Taking the office software "WINWORD.EXE" as an example, the software version patch is updated for it during the repair process. During verification, first check the version number of the software module. The current version number of the software can be obtained through the version information viewing function provided by the software itself or the software management tool of the system. Then compare the version number with the patch version specified by the security policy. If the version numbers are consistent, it means that the software has been updated to the specified patch version. Next, verify the integrity of the patch installation through the official interface provided by the software. The software official usually provides some verification tools or interfaces to check if the patch is installed correctly. For example, call the official interface to perform file integrity check, signature verification, etc. If the verification result shows that the patch is installed completely without file damage, signature inconsistency, etc., it indicates that the version patch update repair for the office software is effective, and the software has installed the correct and complete patch, which can effectively repair the related vulnerabilities.

[0126] Step S1566: For the repair step of re-binding the trusted parent process, the verification method is designed as follows: monitor the process startup process of the software module, and check if the parent process identifier of the newly started process belongs to the legal process in the trusted process chain specified by the security policy.

[0127] Rebinding the trusted parent process is a key step in repairing software vulnerabilities. To ensure that the parent process binding repair is effective, a corresponding verification method needs to be designed. Taking the office software "WINWORD.EXE" as an example, the operation of rebinding the trusted parent process is performed during the repair process. During verification, the process startup process of the office software module is monitored. The process startup situation of the software can be monitored in real time through the system process monitoring tool or the related system interface. When the software starts, the parent process identifier of the newly started process is obtained. Then, the parent process identifier is compared with the legal processes in the trusted process chain specified by the security policy. The security policy usually specifies which processes can be used as the parent process of the software to form a trusted process chain. For example, it is specified that the parent process of the office software must be a system trusted process such as explorer.exe. If the parent process identifier of the newly started process belongs to the legal processes in the trusted process chain, it indicates that the rebinding of the trusted parent process of the office software is effective, and the startup process of the software meets the requirements of the security policy, thereby reducing the security risks caused by the untrusted parent process.

[0128] Step S157: integrating the repair operation steps, the repair priority identifiers, and the verification method descriptions to generate software vulnerability repair guidance information Specifically, the repair operation steps designed for different risk level software modules, the priority identifiers assigned to the steps, and the verification method descriptions corresponding to each repair step can be integrated to finally generate comprehensive software vulnerability repair guidance information. Taking the office software "WINWORD.EXE", the development tool "devenv.exe", and the entertainment application "gameA.exe" as examples, the repair operation steps of the office software such as terminating the running of the illegal process, limiting the operation permission of the illegal file, adjusting the software configuration parameters, updating the software version patch, and rebinding the trusted parent process, as well as the corresponding highest priority identifier and detailed verification method description are collected. Similarly, the repair operation steps of the development tool and the entertainment application, the next highest priority and general priority identifiers, and the corresponding verification method descriptions are collected. Then, the software modules are classified and arranged according to their different types to form a guidance document containing the vulnerability repair information of all software modules. The document records in detail the repair operation steps, priority order, and how to verify whether the repair is successful for each software module, providing clear and accurate guidance for users to repair software vulnerabilities, helping users to efficiently and safely repair software vulnerabilities, and improving the security and stability of the notebook software.

[0129] In summary, the notebook software vulnerability scanning method based on the security policy mentioned above, by obtaining the security policy library of the target notebook, collecting software running data, matching and analyzing the two to generate preliminary scanning results, then evaluating the vulnerability risk level according to the preliminary scanning results, and finally generating repair guidance information according to the risk level and the security policy library, forms a complete and systematic software vulnerability scanning and repair system. This method fully considers the characteristics and security requirements of different software types, combines multiple factors for vulnerability detection and risk assessment, can accurately find vulnerabilities in software, and provides effective repair solutions, providing strong protection for the safe operation of notebook software. At the same time, through the detailed verification method description, the effectiveness and reliability of the repair operation are ensured, making the entire vulnerability scanning and repair process more scientific and rigorous.

[0130] On the basis of the above, Figure 3 As shown in FIG. 1, it is a schematic diagram of a notebook software vulnerability scanning system based on a security policy provided by an embodiment of the present application. The notebook software vulnerability scanning system includes a processor, a machine-readable storage medium, an input / output device and the like components, the machine-readable storage medium and the processor are connected, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to realize the notebook software vulnerability scanning method based on the security policy mentioned above. Wherein, the notebook software vulnerability scanning system based on the security policy can be understood as part of the notebook in the application scenario shown in FIG. 1, or it can also be the notebook itself. Figure 2 As shown in FIG. 1, it is a schematic diagram of a notebook software vulnerability scanning system based on a security policy provided by an embodiment of the present application. The notebook software vulnerability scanning system includes a processor, a machine-readable storage medium, an input / output device and the like components, the machine-readable storage medium and the processor are connected, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to realize the notebook software vulnerability scanning method based on the security policy mentioned above. Wherein, the notebook software vulnerability scanning system based on the security policy can be understood as part of the notebook in the application scenario shown in FIG. 1, or it can also be the notebook itself.

[0131] Wherein, the machine-readable storage medium can be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) and the like. Wherein, the machine-readable storage medium is used to store programs, and the processor executes the programs after receiving the execution instructions.

[0132] The processor can be an integrated circuit chip with processing capability. The processor can be, but is not limited to, a general purpose processor, including a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like.

[0133] In summary, the notebook software vulnerability scanning method and system based on security policy provided by the embodiments of the present application can realize comprehensive and accurate scanning of notebook software vulnerabilities by comprehensively using security policy library and software running data for matching analysis. The method can perform personalized vulnerability detection according to specific security requirements and risk characteristics of different types of software, greatly improving the accuracy and effectiveness of vulnerability detection. For example, in vulnerability risk assessment, various factors such as the functional importance of software modules, the potential impact range of abnormal operations, and the historical vulnerability correlation are fully considered, so that the risk assessment result is more scientific and reasonable. Through such comprehensive evaluation, the priority of vulnerability repair can be more accurately determined, repair resources can be reasonably allocated, and repair efficiency can be improved. In addition, according to the risk level and the repair guidance clauses in the security policy library, detailed software vulnerability repair guidance information is generated, including repair operation steps, repair priority identification, and verification method description. This provides clear guidance for software vulnerability repair, making the repair process more standardized and reliable, and further improving the security and stability of notebook software.

[0134] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments. The embodiments of the present application, the implementation manners and the related technical features can be combined, replaced or modified without conflict, as long as they do not deviate from the technical solutions of the present application. The above is only a preferred embodiment of the present application, and does not limit the present application in any form. Any simple modification, equivalent change and modification made according to the technical essence of the present application to the above embodiments, without deviating from the technical solutions of the present application, are still within the scope of the technical solutions of the present application.

Claims

1. A notebook software vulnerability scanning method based on a security policy, characterized in that, The method comprises: acquiring a security policy library of the target notebook, the security policy library containing access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for different software types; collecting software running data of the target notebook, the software running data containing current running process information, file system operation records, network connection states and software configuration parameters; matching and analyzing the software running data and the security policy library to generate a preliminary scanning result containing software module identification that does not meet the security policy and abnormal operation behavior description; evaluating the risk level of software vulnerability according to the functional importance of the software module in the preliminary scanning result, the potential impact range of abnormal operation and historical vulnerability correlation; generating software vulnerability repair guidance information containing repair operation steps, repair priority identification and verification method description based on the risk level and repair instruction clauses in the security policy library.

2. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The acquisition of the security policy library of the target notebook comprises: extracting a preset basic security policy from the system security configuration file of the target notebook, the basic security policy containing general access control rules and default data operation restriction conditions at the operating system level; synchronously updating an industry-specific security policy from a third-party security service platform, the industry-specific security policy containing software type-specific access control rules and enhanced data operation restriction conditions related to the use scenario of the target notebook; performing version checking on the basic security policy and the industry-specific security policy, identifying policy clauses with version conflicts and marking them as to-be-checked items; classifying and integrating policy clauses that are not marked as conflicting, dividing them into an office software policy group, a development tool policy group and an entertainment application policy group according to software types, each group containing access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for the corresponding software type; manually reviewing policy clauses marked as conflicting, retaining high-priority policy clauses according to the actual use requirements of the target notebook, and generating a final security policy library.

3. The security policy based notebook software vulnerability scanning method of claim 2, wherein, The synchronously updated industry-specific security policy from the third-party security service platform comprises: acquiring a use scenario label of the target notebook, the use scenario label being determined by analyzing the use frequency and functional focus of the office software, development tools and entertainment applications in historical software use records; sending a policy synchronization request to the third-party security service platform according to the use scenario label, the policy synchronization request containing the operating system version, software installation list and industry affiliation information of the target notebook; receiving an industry-specific security policy data packet returned by the third-party security service platform, the data packet containing enhanced access control rules for the office software, enhanced data operation restriction conditions for the development tools and enhanced vulnerability detection benchmark requirements for the entertainment applications; performing integrity checking on the industry-specific security policy data packet to verify whether the digital signature and hash value of the data packet are consistent with the verification information provided by the third-party security service platform; The industry-specific security policy data packet that passes the analysis check is parsed, and software type-specific access control rules and enhanced data operation restriction conditions that match the target notebook use scenario label are extracted as industry-specific security policies.

4. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The software running data of the collected target notebook includes: Obtaining a list of all currently running software processes through a system process monitoring interface, recording the name, start time, parent process identifier and system resource occupation of each process as current running process information; Traversing the specified directory path of the file system, recording the timestamp, operation type and target file path of the file operation of the software module on the system file and user data file as file system operation records; the file operation includes at least one of read operation, write operation and delete operation; Monitoring the data stream transmission of the network interface, recording the target IP address, port number, transmission protocol type and data flow size of the network connection established by the software module as network connection state; Reading the configuration file and registry item of the software module, extracting the function enable state, permission setting parameter, data storage path and third-party service integration information of the software as software configuration parameters; Timestamp alignment of the current running process information, file system operation records, network connection state and software configuration parameters is performed to generate software running data with time sequence correlation.

5. The security policy based notebook software vulnerability scanning method of claim 4, wherein, The monitoring of the data stream transmission of the network interface, the recording of the target IP address, port number, transmission protocol type and data flow size of the network connection established by the software module as network connection state includes: Enabling a network traffic monitoring driver to capture data packets of all network interfaces of the target notebook; Protocol analysis is performed on the captured data packets to extract source process identifier, target IP address, target port number, transmission protocol type and data packet size; According to the source process identifier, the corresponding software module is associated to establish a mapping relationship between the software module and the network connection; The network connections established by the same software module within a preset time window are aggregated to count the connection times, total data flow size and average connection duration of each target IP address; Filter out network connections related to system services, and only keep network connection information initiated by user-installed software modules; The target IP address, port number, transmission protocol type and data flow size in the retained network connection information are arranged into network connection state records.

6. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The matching analysis of the software running data and the security policy library generates a preliminary scanning result containing software module identifiers that do not meet the security policy and abnormal operation behavior descriptions, including: Extracting access control rules of the office software policy group from the security policy library, checking whether the parent process identifier of the office software process meets the preset trusted process chain requirement, and recording the office software module identifier and parent process violation information that do not meet the requirement; According to the data operation restriction conditions of the development tool policy group, check whether the write operation of the development tool on the system file is only for the allowed temporary directory path, and record the development tool module identifier and file path violation information that perform write operation in non-allowed directory; According to the network connection restriction condition of the entertainment application strategy group, it is verified whether the target IP address of the network connection established by the entertainment application belongs to the whitelist range, and the entertainment application module identifier and IP address violation information of the connected non-whitelist IP address are recorded; The vulnerability detection benchmark requirement of each strategy group in the security policy library is extracted, and it is compared whether the permission setting in the software configuration parameter reaches the minimum permission level of the benchmark requirement, and the software module identifier and permission parameter violation information of the permission setting exceeding the standard are recorded; All software module identifiers and corresponding parent process violation information, file path violation information, IP address violation information, and permission parameter violation information that do not meet the security policy are integrated to generate a preliminary scanning result.

7. The security policy based notebook software vulnerability scanning method of claim 6, wherein, The extraction of the vulnerability detection benchmark requirement of each strategy group in the security policy library, the comparison of whether the permission setting in the software configuration parameter reaches the minimum permission level of the benchmark requirement, and the recording of the software module identifier and permission parameter violation information of the permission setting exceeding the standard include: The minimum permission level requirement of the office software is extracted from the office software strategy group; The minimum permission level requirement of the development tool is extracted from the development tool strategy group; The minimum permission level requirement of the entertainment application is extracted from the entertainment application strategy group; The actual permission setting in the software configuration parameter is obtained, including the file access path range, the registry modification permission, and the network connection target range; The actual permission setting is compared with the minimum permission level requirement of the corresponding strategy group to identify software modules whose file access path exceeds the allowed range, whose registry modification permission is too high, and whose network connection target exceeds the specified range; The software module identifier and corresponding file access path violation information, registry permission violation information, and network connection target violation information of the permission setting exceeding the standard are recorded as the permission parameter violation information.

8. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The risk level of the software vulnerability is evaluated according to the function importance of the software module in the preliminary scanning result, the potential impact range of the abnormal operation, and the historical vulnerability correlation, including: The function description information of each software module in the preliminary scanning result is obtained from the software management database of the target notebook, and the function importance of the software module is divided into critical, important, or general level according to whether it involves core business processing, user data storage, or system critical function operation; The operation type involved in the abnormal operation is analyzed, the corresponding impact range of the abnormal operation is determined, and the potential impact range description is generated; the potential impact range description includes whether it can cause data leakage, system crash, or third-party attack entry; The historical vulnerability record of the software module and the repair situation of the corresponding abnormal operation type are obtained by querying the vulnerability history database, and the probability of causing a security event in the same abnormal operation history is calculated as the historical vulnerability correlation probability; The risk level assessment rules are established, wherein: if the function importance is critical, the potential impact range contains data leakage or system collapse, and the historical vulnerability correlation probability exceeds a preset threshold, the risk level is high; if the function importance is important, the potential impact range contains a third-party attack entrance, or the function importance is critical but the historical vulnerability correlation probability does not exceed the threshold, the risk level is medium; and the rest is low. According to the division result of the function importance, the potential impact range description, and the historical vulnerability correlation probability, the risk level of each software module vulnerability in the preliminary scanning result is assessed.

9. The security policy based notebook software vulnerability scanning method of claim 8, wherein, The software vulnerability repair guidance information including repair operation steps, repair priority identification, and verification method description is generated based on the risk level and the repair guidance clauses in the security policy library, including: The repair guidance clauses corresponding to each risk level are extracted from the security policy library, wherein the high risk level corresponds to an emergency repair clause, the medium risk level corresponds to a regular repair clause, and the low risk level corresponds to an optimized repair clause; For high-risk-level vulnerabilities, operation guidelines for terminating the running of illegal processes, limiting the operation permissions of illegal files, and blocking illegal network connections are developed according to the requirements of the emergency repair clause; For medium-risk-level vulnerabilities, operation steps for adjusting software configuration parameters, updating software version patches, and re-binding trusted parent processes are generated according to the provisions of the regular repair clause; For low-risk-level vulnerabilities, optimization suggestion steps for shutting down unnecessary function modules, adjusting data storage paths, and narrowing network connection permissions are provided according to the guidelines of the optimized repair clause; The priority identification is assigned to each repair operation step according to the risk level; The verification method description is designed for each repair operation step, including verifying whether the processes after repair meet the trusted process chain requirements, whether the file operations are only for allowed directories, whether the network connections are only connected to white-listed IP addresses, and whether the configuration parameters reach the minimum permission level; The software vulnerability repair guidance information is generated by integrating the repair operation steps, the repair priority identification, and the verification method description.

10. A security policy based notebook software vulnerability scanning system, comprising: The processor, the machine readable storage medium, the machine readable storage medium and the processor are connected, the machine readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine readable storage medium to realize the method in any one of claims 1-9.

Images