Method, device, equipment, medium and product for evaluating security configuration items of services

Abstract

The present disclosure relates to a method, device, equipment, medium and product for evaluating security configuration items of a service. The method comprises: extracting security configuration items of a target service and configuration states of each security configuration item; constructing a behavior feature library containing behavior features corresponding to each security configuration item; detecting occurrence of each behavior feature in the behavior feature library in a target service execution process based on multi-source evidence in the target service execution process; for each security configuration item, determining a type of the security configuration item based on the configuration state of the security configuration item and occurrence of the corresponding behavior feature; and generating an evaluation report for the security configuration items of the target service based on the type of each security configuration item and the multi-source evidence. Through the present disclosure, unnecessary permission opening, configuration errors, conflicts or redundancies can be accurately identified, security risks caused by "configuration and behavior disconnection" are avoided, and the problem of inaccurate evaluation results obtained by related technologies is solved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, device, medium, and product for evaluating security configuration items of a service. Background Technology

[0002] In systemd-based Linux systems, the security of service processes relies on the per-service security / sandboxing mechanism provided by systemd. This mechanism primarily restricts the service's permission scope through a series of configuration items (such as CapabilityBoundingSet, SystemCallFilter, RestrictAddressFamilies, etc.) to reduce security risks. systemd-analyze security is a core security assessment tool built into systemd. By examining the service's systemd configuration items, it generates a numerical exposure level score from 0.0 to 10.0. A higher score indicates a higher service exposure level, while a lower score indicates stricter sandbox restrictions and a lower exposure level. This tool provides system administrators with a basic reference for assessing service security status and is widely used in Linux deployment scenarios such as servers and embedded devices.

[0003] With the increasing adoption of Linux systems in critical business scenarios, the appropriateness of service process security configurations directly impacts overall system security. However, current assessments of service security configuration items rely solely on static checks, making it difficult to accurately determine whether the configuration status of items is suitable for the corresponding business needs, or whether there are conflicts or redundancies. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, medium, and product for evaluating security configuration items of a service, to at least address the problem of inaccurate evaluation results obtained from related technologies.

[0005] According to a first aspect of the present disclosure, a method for evaluating security configuration items of a service is provided, comprising: extracting at least one security configuration item of a target service and the configuration state of each security configuration item; constructing a behavior feature library containing behavioral features corresponding to each security configuration item; detecting the occurrence of each behavioral feature in the behavior feature library during the execution of the target service based on multi-source evidence during the execution of the target service, wherein the multi-source evidence includes source code corresponding to the compilation target of the target service, unit test cases, and external symbols referenced in the source code; for each security configuration item, determining the type of the security configuration item based on the configuration state of the security configuration item and the occurrence of the corresponding behavioral feature, wherein the type of the security configuration item indicates whether the configuration state of the security configuration item matches the occurrence of the corresponding behavioral feature; and generating an evaluation report of the security configuration items for the target service based on the type of each security configuration item and the multi-source evidence.

[0006] Optionally, the occurrence of each behavioral feature during the execution of the target service can be categorized into three scenarios: first, the behavioral feature is guaranteed to occur during the execution of the target service; second, the behavioral feature is guaranteed not to occur during the execution of the target service; and third, it is impossible to determine whether the behavioral feature will occur during the execution of the target service.

[0007] Optionally, the security configuration item can be of any of the following types: Matching type, where the configuration state of a matching security configuration item matches the occurrence of its corresponding behavioral characteristic, wherein the security configuration item satisfies any of the following conditions to determine that its configuration state matches the occurrence of its corresponding behavioral characteristic: the security configuration item's configuration state is allowed and the occurrence of its corresponding behavioral characteristic is in the first case, or the security configuration item's configuration state is allowed or disallowed and the occurrence of its corresponding behavioral characteristic is in the third case; Non-matching type, where the security configuration item's configuration state does not match the occurrence of its corresponding behavioral characteristic, wherein the security configuration item's configuration state is disallowed and the occurrence of its corresponding behavioral characteristic is in the first case, or the security configuration item's configuration state is allowed and the occurrence of its corresponding behavioral characteristic is in the second case.

[0008] Optionally, before detecting the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence during the execution process of the target service, the method further includes: obtaining the source code package and compilation target of the target service; obtaining the source code corresponding to the compilation target and the unit test cases associated with the compilation target from the source code package by tracing the compilation process for the compilation target; obtaining the set of external symbols referenced in the source code by simulating the installation process of the target service; and using the set of external symbols, the source code, and the unit test cases as multi-source evidence.

[0009] Optionally, based on multi-source evidence during the execution of the target service, the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service is detected, including: extracting service behavioral fingerprints for the compilation target from external symbol sets, source code, and unit test cases; querying the behavioral features corresponding to the service behavioral fingerprints from a preset rule system, wherein the preset rule system contains the mapping relationship between service behavioral fingerprints and behavioral features; for predetermined behavioral features in the behavioral feature library, determining the occurrence of the predetermined behavioral features as the first case, wherein the predetermined behavioral features are the behavioral features queried from the preset rule system; for other behavioral features in the behavioral feature library besides the predetermined behavioral features, inputting the other behavioral features into a large language model to obtain the occurrence of each other behavioral feature.

[0010] Optionally, based on the type of each security configuration item and multi-source evidence, an evaluation report on the security configuration items for the target service is generated, including: determining configuration recommendations and evidence chains for the security configuration items based on the type of the security configuration items and multi-source evidence, wherein the evidence chain is evidence information for obtaining configuration recommendations; and generating an evaluation report on the security configuration items for the target service based on the type, configuration recommendations, evidence chains, and configuration status of each security configuration item.

[0011] According to a second aspect of the present disclosure, an apparatus for evaluating security configuration items of a service is provided, comprising: an extraction unit configured to extract at least one security configuration item of a target service and the configuration state of each security configuration item; a construction unit configured to construct a behavior feature library containing behavioral features corresponding to each security configuration item; a detection unit configured to detect the occurrence of each behavioral feature in the behavior feature library during the execution of the target service based on multi-source evidence during the execution of the target service, wherein the multi-source evidence includes source code corresponding to the compilation target of the target service, unit test cases, and external symbols referenced in the source code; a determination unit configured to determine the type of each security configuration item based on the configuration state of the security configuration item and the occurrence of the corresponding behavioral feature, wherein the type of the security configuration item indicates whether the configuration state of the security configuration item matches the occurrence of the corresponding behavioral feature; and a generation unit configured to generate an evaluation report of the security configuration items for the target service based on the type of each security configuration item and the multi-source evidence.

[0012] Optionally, the occurrence of each behavioral feature during the execution of the target service can be categorized into three scenarios: first, the behavioral feature is guaranteed to occur during the execution of the target service; second, the behavioral feature is guaranteed not to occur during the execution of the target service; and third, it is impossible to determine whether the behavioral feature will occur during the execution of the target service.

[0013] Optionally, the security configuration item can be of any of the following types: Matching type, where the configuration state of a matching security configuration item matches the occurrence of its corresponding behavioral characteristic, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state matches the occurrence of its corresponding behavioral characteristic: the configuration state of the security configuration item is allowed and the occurrence of its corresponding behavioral characteristic is in the first case; or the configuration state of the security configuration item is allowed or disallowed and the occurrence of its corresponding behavioral characteristic is in the third case; Non-matching type, where the configuration state of a non-matching security configuration item does not match the occurrence of its corresponding behavioral characteristic, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state does not match the occurrence of its corresponding behavioral characteristic: the configuration state of the security configuration item is disallowed and the occurrence of its corresponding behavioral characteristic is in the first case; or the configuration state of the security configuration item is allowed and the occurrence of its corresponding behavioral characteristic is in the second case.

[0014] Optionally, the detection unit is further configured to, before detecting the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence in the target service execution process, obtain the source code package and compilation target of the target service; obtain the source code corresponding to the compilation target and the unit test cases associated with the compilation target from the source code package by tracing the compilation process for the compilation target; obtain the set of external symbols referenced in the source code by simulating the installation process of the target service; and use the set of external symbols, the source code, and the unit test cases as multi-source evidence.

[0015] Optionally, the detection unit is further configured to extract service behavior fingerprints for the compilation target from external symbol sets, source code, and unit test cases; query the behavior features corresponding to the service behavior fingerprints from a preset rule system, wherein the preset rule system contains the mapping relationship between service behavior fingerprints and behavior features; for predetermined behavior features in the behavior feature library, determine the occurrence of the predetermined behavior features as the first case, wherein the predetermined behavior features are the behavior features queried from the preset rule system; for other behavior features in the behavior feature library besides the predetermined behavior features, input the other behavior features into the large language model to obtain the occurrence of each other behavior feature.

[0016] Optionally, the generation unit is also configured to determine configuration recommendations and evidence chains for security configuration items based on the type of the security configuration item and multi-source evidence, wherein the evidence chain is evidence information for obtaining configuration recommendations; and to generate an evaluation report for the security configuration items of the target service based on the type, configuration recommendations, evidence chains and configuration status of each security configuration item.

[0017] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement an evaluation method for security configuration items of services according to the present disclosure.

[0018] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by at least one processor, causes at least one processor to perform the evaluation method for security configuration items of the services according to the present disclosure as described above.

[0019] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement an evaluation method for security configuration items of a service according to the present disclosure.

[0020] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: According to the evaluation method, apparatus, device, medium, and product for security configuration items of the service disclosed herein, the occurrence of each behavioral feature in the behavioral feature library is detected through multi-source evidence during the execution of the target service. Then, by comparing the occurrence of the behavioral features corresponding to the security configuration items of the target service with the static configuration state, it is determined whether the configuration state of the security configuration item matches the occurrence of the corresponding behavioral feature. Based on this determined matching information and multi-source evidence, a corresponding evaluation report for the target service is generated. The generated evaluation report can accurately identify unnecessary permission granting, configuration errors, conflicts, or redundancy, avoiding security risks caused by "configuration and behavior disconnect." Therefore, this disclosure solves the problem of inaccurate evaluation results obtained by related technologies.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0023] Figure 1 This is a flowchart illustrating a method for evaluating security configuration items of a service according to an exemplary embodiment; Figure 2 This is a schematic diagram illustrating a compiler target location according to an exemplary embodiment; Figure 3 This is a schematic diagram illustrating an evaluation system architecture according to an exemplary embodiment; Figure 4This is a block diagram illustrating an apparatus for evaluating security configuration items of a service according to an exemplary embodiment; Figure 5 This is a block diagram of an electronic device 500 according to an embodiment of the present disclosure. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0025] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0026] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0027] Currently, the static configuration evaluation method, with the systemd-analyze security tool at its core, has the following technical solution: 1) Obtaining the configuration items to be evaluated: The tool reads the systemd configuration file (such as the .service file) of the target service and extracts all the preset security sandbox configuration items of the target service, such as MemoryDenyWriteExecute, SystemCallFilter, RestrictAddressFamilies, ProtectKernelModules, etc. It should be noted that the number of configuration items is related to the software version of the systemd tool. For example, version 255 has 81 configuration items.

[0028] 2) Application of scoring rules: The tool has a built-in fixed scoring model that calculates the exposure level of each configuration item based on its enabled status and preset weight.

[0029] 3) Overall score generation: The scores of all configuration items are weighted and summed to output the overall exposure level of the target service (0.0~10.0), and the enabling status (enabled / disabled) of each configuration item is marked.

[0030] For example, after executing the command `systemd-analyze security sshd.service`, the tool will output the security assessment results of the SSHD service, including the check status of each configuration item and the final exposure level, for administrators to refer to.

[0031] However, the above technology has the following drawbacks: 1) Configuration adequacy cannot be verified: It can only determine whether the target service has enabled the security configuration items provided by the systemd tool, but it cannot verify whether the enabling status of these configuration items fully utilizes the security capabilities of systemd, that is, whether the target service has unnecessary permissions open, resulting in an excessively large exposure surface; 2) Inability to verify configuration authenticity: Evaluation based solely on static configuration files cannot determine whether the security configuration declared by the target service is consistent with its actual behavior, posing a risk of configuration errors, conflicts, or redundancy. For example, the target service may configure ProtectKernelModules=true (disable kernel module operations), but the actual source code contains rmmod (unload kernel modules) calls, and existing tools cannot identify this configuration conflict; 3) Lack of behavioral evidence: The evaluation results are based solely on the presence or absence of configuration items, without considering the actual operational behavior of the service (such as system calls, file operations, IPC interactions, etc.), resulting in a disconnect between the score and the actual security risks, and failing to provide accurate basis for configuration optimization.

[0032] To address the aforementioned issues, this disclosure provides a method for evaluating the security configuration items of a service. By analyzing multi-source evidence during the execution of the target service, the method detects the occurrence of each behavioral feature in the behavioral feature library during the service execution process. Furthermore, by comparing the occurrence of the behavioral features corresponding to the security configuration items of the target service during service execution with the static configuration state, the type of the security configuration item is determined. This means determining whether the configuration state of the security configuration item matches the occurrence of its corresponding behavioral feature. Through cross-validation of multi-source evidence and static configuration, unnecessary permission granting, configuration errors, conflicts, or redundancy can be accurately identified, avoiding security risks caused by a disconnect between configuration and behavior. Compared to existing technologies, the accuracy of security assessment is improved by more than 70%.

[0033] This disclosure also utilizes a combined collection scheme that uses package management tools to locate source code packages, trace the compilation process, record installation files, and extract external symbol tables to achieve comprehensive coverage of behavioral characteristics that occur during service execution. This means that multi-source evidence is collected to verify the rationality of the configuration, enabling the deduction of necessary permissions based on the actual behavior of the service, identifying unnecessary open configuration items, providing a precise basis for tightening the service exposure surface, and reducing the average security exposure level of the service by 50%.

[0034] This disclosure also combines a rule system with a large language model, that is, it uses a pre-set rule system to ensure the standardization of parsing results, and combines the logical reasoning ability of LLM to parse complex source code behavior, thus taking into account both parsing ability and accuracy; moreover, it eliminates the need for manual line-by-line analysis of source code, greatly reducing the manpower cost of security assessment and significantly improving assessment efficiency.

[0035] It should be noted that the evaluation method disclosed herein applies to, but is not limited to, the following operating systems: systemd-based Linux desktop operating systems, Linux server operating systems, Linux cloud operating systems, domestically produced Linux distributions, and various systemd-based Linux distributions (such as UOS, deepin, openEuler, Debian, Ubuntu, Red Hat, etc.), with a wide range of application scenarios.

[0036] The evaluation methods disclosed herein can be used in the following scenarios, but are not limited to: Linux distribution development / customization scenarios, where operating system vendors verify the compliance of systemd security configurations for built-in services to improve the native security of the system; enterprise-level operation and maintenance security audit scenarios, where enterprise operation and maintenance teams conduct regular security audits of systemd services in the production environment to identify unreasonable configurations and eliminate risk points; and security vulnerability tracing scenarios, where this disclosure provides support for vulnerability analysis when security vulnerabilities such as service privilege abuse occur in Linux systems.

[0037] The evaluation method disclosed herein is applicable to, but not limited to, mainstream package management systems such as dpkg and rpm.

[0038] The following will describe in detail, with reference to the accompanying drawings, methods, apparatus, devices, media, and products for evaluating security configuration items of services according to exemplary embodiments of the present disclosure.

[0039] Figure 1 This is a flowchart illustrating a method for evaluating security configuration items of a service according to an exemplary embodiment, such as... Figure 1 As shown, the evaluation method for the security configuration items of a service includes the following steps: In step 101, at least one security configuration item of the target service and the configuration status of each security configuration item are extracted.

[0040] In step 102, a behavior feature library containing the behavior features corresponding to each security configuration item is constructed.

[0041] In step 103, based on multi-source evidence during the execution of the target service, the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service is detected. The multi-source evidence includes the source code corresponding to the compilation target of the target service, unit test cases, and external symbols referenced in the source code.

[0042] In step 104, for each security configuration item, the type of the security configuration item is determined based on the configuration status of the security configuration item and the occurrence of the corresponding behavioral characteristics. The type of the security configuration item indicates whether the configuration status of the security configuration item matches the occurrence of the corresponding behavioral characteristics.

[0043] In step 105, an evaluation report of the security configuration items for the target service is generated based on the type of each security configuration item and multi-source evidence.

[0044] As an example, taking a systemd service as the target service, for the target systemd service (such as sshd.service), execute the command `systemd-analyze security --json=pretty[service name]`; then, parse the JSON format data output by the command to extract all security configuration items of the target systemd service. These security configuration items may include, but are not limited to, `MemoryDenyWriteExecute`, `SystemCallFilter`, `RestrictAddressFamilies`, `ProtectKernelModules`, `CapabilityBoundingSet`, etc. Use these security configuration items to form an evaluation item list, and specify the configuration status of each security configuration item (such as true / false, ~@xxx / ~xxx, etc.).

[0045] As an example, the above configuration status can be either allowed or disallowed. A configuration status of allowed indicates that the security configuration item is configured and the configured value is positive. The configuration value can be true, false, or it can mean removing an item (such as ~AF_NETLINK). A positive configuration value means not disabling or removing the security configuration item, etc. A configuration status of disallowed indicates that the security configuration item is not configured or the security configuration item is configured but the configured value is negative. A negative configuration value means disabling or removing the security configuration item, etc.

[0046] As an example, the above-mentioned behavioral characteristics refer to system operations of the system where the target service resides, such as reading the / etc / myd.conf configuration file, creating the / run / myd.sock socket file, listening to a specific BusName on the system bus, writing data to the / etc directory, modifying the system clock, loading kernel modules, and accessing device nodes, etc. This disclosure does not limit these operations.

[0047] The aforementioned behavioral characteristics can be obtained as follows: First, based on the systemd version corresponding to the target service (e.g., version 255 has 81 security configuration items), identify the underlying behavioral characteristics corresponding to the security configuration items of that version. Then, deduplicate and categorize these behavioral characteristics to form, for example, a standardized behavioral characteristic library of 80 items. Each behavioral characteristic in the behavioral characteristic library is associated one-to-one with a systemd security configuration item. A small number of configuration items may correspond to the same behavioral characteristic, therefore the number of behavioral characteristics will be slightly less than the number of security configuration items.

[0048] It should be noted that the rules for setting up this behavioral feature library can be as follows: the behavioral features in the behavioral feature library are strongly bound to systemd security configuration items, dynamically adapt with systemd versions, the classification dimensions are consistent with the multi-source evidence extracted subsequently, and all behavioral features are specific behavioral features that can be verified by multi-source evidence; the definition basis of this behavioral feature library can be as follows: it can be based on the official mapping specification of systemd.exec (5) / systemd-analyze (1), combined with the corresponding systemd version for adaptation and practical refinement. For example, the behavioral feature library can be a general behavioral library for this version, adapting to all target services of the same version.

[0049] As an example, a pre-defined rule system can be used to detect the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service. Alternatively, the pre-defined rule system can be combined with a Large Language Model (LLM) to detect the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service. This disclosure does not limit this approach.

[0050] As an example, after obtaining the occurrence of each behavioral feature during the execution of the target service, the security configuration items can be classified in combination with their configuration status to determine the type of each security configuration item, i.e., whether the configuration status matches the occurrence of the corresponding behavioral feature. This clarifies whether the configuration of each security configuration item is reasonable, accurately identifying unnecessary permission openings, configuration errors, conflicts, or redundancies. Based on the determined type, an accurate evaluation report can then be generated.

[0051] According to an exemplary embodiment of this disclosure, the occurrence of each of the above behavioral features during the execution of the target service may include, but is not limited to, the following three situations: first, the behavioral feature must occur during the execution of the target service; second, the behavioral feature must not occur during the execution of the target service; and third, it is impossible to determine whether the behavioral feature occurs during the execution of the target service.

[0052] In this embodiment, behavioral characteristics are classified into three categories of factual items: certain to occur, certain not to occur, and possible to occur. This forms a standardized description of permission requirements based on behavioral evidence, enabling a precise mapping between behavioral evidence and security configuration items.

[0053] As an example, the behavioral features in the behavioral feature library can be divided into the following three categories based on the occurrence of each behavioral feature during the execution of the target service: Certain behaviors: These are the actual behavioral characteristics of a service that have been confirmed through cross-verification using multiple sources of evidence (such as source code, compilation traces, installation records, and sets of external symbols). In other words, they represent the behavior that is the first scenario. For example, it will definitely read the ` / etc / myd.conf` configuration file; it will definitely create the ` / run / myd.sock` socket file; it will definitely listen on a specific `BusName` of the system bus; it will definitely call the external helper program ` / usr / libexec / foo-helper`; there will be `insmod / rmmod` (kernel module loading / unloading) calls; and it will write data to the ` / sys / fs / xxx` path, etc.

[0054] Behaviors that are certain to not occur: After excluding the above "certain behaviors" from the behavior feature library (e.g., a total of 80 items), behaviors that are confirmed through cross-verification of multi-source evidence to have no call traces and no actual usage requirements for the service, i.e., behaviors that fall under the second scenario. For example, there is never any indication of raw socket usage; no need to write data to the / etc directory; no need to modify the system clock, load kernel modules, or access device nodes; no need to use the AF_NETLINK network address family, etc.

[0055] Possible behaviors: Behavioral features not classified into the above two categories are identified from the behavioral feature library. These are behavioral features that only have partial code traces but cannot be accurately determined whether they actually occurred through multi-source evidence; that is, behavioral features that fall under the third scenario. For example, calling dbus_send_message without specifying the target service's BusName, interface, or path makes it impossible to determine whether privileged service interaction is involved; the source code contains logic for dynamically concatenating external command parameters using execve, but the parameter value range and the final called program are not clearly defined; using dlopen to load plugins without specifying a fixed plugin path makes it impossible to determine the additional permission requirements that the plugin might introduce, etc.

[0056] According to exemplary embodiments of this disclosure, the type of the security configuration item can be, but is not limited to, any of the following types: Matching type, where the configuration state of the matching security configuration item matches the occurrence of the corresponding behavioral feature, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state matches the occurrence of the corresponding behavioral feature: the configuration state of the security configuration item is allowed and the occurrence of the corresponding behavioral feature is a first case; the configuration state of the security configuration item is allowed and the occurrence of the corresponding behavioral feature is a second case; the configuration state of the security configuration item is allowed or disallowed and the occurrence of the corresponding behavioral feature is a third case; Non-matching type, where the configuration state of the non-matching security configuration item does not match the occurrence of the corresponding behavioral feature, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state does not match the occurrence of the corresponding behavioral feature: the configuration state of the security configuration item is disallowed and the occurrence of the corresponding behavioral feature is a first case.

[0057] This embodiment, based on the occurrence of behavioral features, enables the classification and determination of configuration permission and behavior support, configuration permission but behavior support, configuration conflict or error (configuration disallowed but behavior supported), and dynamic verification required for determination, and divides them into matching and non-matching categories, thereby accurately identifying the rationality of the configuration.

[0058] As an example, the decision logic for each of the above types can be as follows: The matching type judgment logic includes, but is not limited to, any of the following judgment logics: 1) The configuration status is allowed and the corresponding behavioral evidence appears, which is the first case. That is, the service configuration allows the permission / behavior of the security configuration item, and the collected multi-source evidence (source code, compilation or unit test, etc.) clearly shows behavioral evidence corresponding to the corresponding behavioral feature (i.e., the extracted behavior). For example, SystemCallFilter=@mount and there is a mount system call in the source code. 2) The corresponding behavioral feature appears, which is the third case. That is, the relationship between the configuration status and the corresponding behavioral feature cannot be determined, and dynamic verification is required. That is, there are only vague behavioral traces (such as general dbus message sending but the target service cannot be determined), and multi-source evidence is insufficient to accurately match the configuration item. Further verification is required in conjunction with runtime monitoring.

[0059] The judgment logic for mismatch types can be, but is not limited to, any of the following: 1) The configuration status is allowed, but the corresponding behavioral evidence is in the second case, that is, the service configuration allows the permission / behavior of the security configuration item, but no behavioral evidence corresponding to the corresponding behavioral feature is found in the collected multi-source evidence. For example, the service configuration allows the AF_UNIX address family, but the source code has no UNIX socket calls. 2) The configuration status is disallowed, and the corresponding behavioral evidence is in the first case, that is, the configuration and behavioral feature conflict or the configuration is incorrect, that is, the service configuration and behavioral evidence do not match. For example, RestrictAddressFamilies=~AF_NETLINK (disallows AF_NETLINK address family) but the source code has netlinksocket creation logic, or ProtectKernelModules=true (disallows kernel module operations) but the source code contains rmmod calls; According to an exemplary embodiment of this disclosure, before detecting the occurrence of each behavioral feature in the behavioral feature library in the target service execution process based on multi-source evidence in step 103 above, the source code package and compilation target of the target service can also be obtained; by tracing the compilation process for the compilation target, the source code corresponding to the compilation target and the unit test cases associated with the compilation target can be obtained from the source code package; by simulating the installation process of the target service, the set of external symbols referenced in the source code can be obtained; and the set of external symbols, the source code, and the unit test cases are used as multi-source evidence.

[0060] This implementation achieves comprehensive coverage of behavioral characteristics that occur during service execution by using a combination of methods, including locating source code packages using package management tools, tracing the compilation process, recording installation files, and extracting external symbol tables.

[0061] As an example, comprehensive evidence of the service's actual behavior, i.e., multi-source evidence, can be collected through package management tools, source code compilation tracing, installation process logs, etc. The specific process may include the following parts: Source package location and acquisition: Locate the source package corresponding to the target service using the system package management tool (rpm), and then download the complete source package using commands such as dnf download, which may support src deb or rpm source formats. It should be noted that the source package can also be imported manually, and this disclosure does not limit this method.

[0062] Compilation target location: The `ExecStart`, `ExecStartPre`, `ExecReload`, and `ExecStartPost` fields in the target service's configuration file are parsed to determine the executable file path used to start the target service, thereby locating the compilation target for the source code. For example, using the `sshd.service` service... Figure 2 As shown, the executable file path corresponding to the ExecStart configuration in the rectangle is / usr / sbin / sshd, where sshd is the compilation target for subsequent analysis.

[0063] Compilation process tracing: The compilation process for a target can be traced by executing the Make[target] command, which records all source code files and unit test cases associated with the target, and clarifies the code logic that the service actually depends on during compilation. This step is necessary because the source code corresponding to the target may not correspond to all source code packages, so the compilation process can be traced back to the source code corresponding to the target.

[0064] Installation process log: The installation process of the target service can be simulated by executing the make install command, recording all installed files related to the target (including binary files, library files, configuration files, documents, etc.), and extracting external symbols referenced in the source code (such as system calls, syscalls, dbus interfaces, IPC mechanisms, kernel capabilities, etc.).

[0065] After obtaining the aforementioned multi-source evidence, the occurrence of each behavioral feature in the behavioral feature database can be detected based on this evidence.

[0066] According to an exemplary embodiment of this disclosure, step 103 above, which detects the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence during the execution of the target service, may include: extracting service behavioral fingerprints for the compilation target from external symbol sets, source code, and unit test cases; querying the behavioral features corresponding to the service behavioral fingerprints from a preset rule system, wherein the preset rule system contains a mapping relationship between service behavioral fingerprints and behavioral features; determining the occurrence of a predetermined behavioral feature in the behavioral feature library as a first case, wherein the predetermined behavioral feature is a behavioral feature queried from the preset rule system; and inputting other behavioral features in the behavioral feature library besides the predetermined behavioral features into a large language model to obtain the occurrence of each other behavioral feature.

[0067] This embodiment combines a rule system and a large language model, using a pre-defined rule system to ensure the standardization of parsing results and combining the logical reasoning capabilities of an LLM to parse complex source code behavior, thus balancing parsing ability and accuracy; moreover, it eliminates the need for manual line-by-line analysis of source code, significantly reducing the manpower cost of security assessment and greatly improving assessment efficiency.

[0068] As an example, service behavior fingerprints that appear during the execution of the target service can be parsed from source code, unit test cases, and external symbol sets. The extracted service behavior fingerprints collectively constitute a unique identifier for the target service at the system interaction level. For example, the aforementioned service behavior fingerprints may include, but are not limited to, the following: Configuration load point: open / openat / fopen / g_key_file_ The configuration file path called by QSettings, YAML parser, TOMLparser, etc.; External process calls: external programs called by execve, execvpe, posix_spawn, system, popen, subprocess, etc. D-Bus interaction: Bus names and interfaces associated with sd-bus, GDBus, QtDBus, raw libdbus, etc. Dynamic extensions: dlopen calls, plugin directory scanning, etc.; File system operations: write operations to the status directory, log directory, PID file, cache, socket path, etc. Network behavior: listening address, initiating connections, and network address families used (such as AF_INET, AF_NETLINK, etc.); Permission changes: uid / gid modification, capability (kernel capability) invocation, namespace operations, mount, chroot, etc.; Reload path: SIGHUP handler, reload method, watch loop, etc.; helper protocol: rules for concatenating external commands and parameters.

[0069] Then, after extracting the service behavior fingerprint, a pre-defined rule system and LLM can be used to parse the collected service behavior fingerprint and generate a standardized document containing a list of fact items, such as the "Intermediate Representation of Permission Requirements". This document can contain fact items divided into three categories: Certain behavior: The actual behavioral characteristics of the service confirmed by cross-validation of multiple sources of evidence (source code, compilation trace, installation records, external symbol tables), that is, the behavioral characteristics that occur in the first scenario; Behaviors that are certain to not occur: After excluding the above "certain behaviors" from the behavior feature library (e.g., a total of 80 items), the behavior features that are confirmed by cross-verification of multi-source evidence to have no call traces and no actual usage needs are the behavior features that fall under the second scenario.

[0070] Possible behaviors: Find behavioral features in the behavioral feature library that are not classified into the above two categories, and find behavioral features that only have partial code traces but cannot be accurately determined whether they actually occurred through multi-source evidence, i.e. behavioral features that fall under the third category.

[0071] As an example, the aforementioned preset rule system can be a pre-defined rule base. For instance, this rule base may include the following mapping relationships: 1) Mapping relationships for system call rules, such as `mount` representing `CAP_SYS_ADMIN`, and `socket` representing behavior requiring network permissions; 2) Mapping relationships for kernel capability rules, such as `CAP_NET_ADMIN` representing behavior requiring network management capabilities, and `CAP_SYS_TIME` representing clock modification; 3) Mapping relationships for D-Bus interaction rules, such as `sd_bus_call` representing D-Bus behavior, and `shmget` representing shared memory behavior; 4) Mapping relationships for file system rules, such as ` / run` representing runtime file operations; 5) Mapping relationships for network address rules, such as `AF_INET` representing IPv4, `AF_UNIX` representing local sockets, and `AF_NETLINK` representing kernel communication; 6) Mapping relationships for helper rules, such as `modprobe` representing kernel module operations, and `iptables` representing firewall operations.

[0072] The extracted service behavior fingerprint is used to query the corresponding behavior feature in the rule system. If the feature is found, it means that the behavior feature is a certain behavior feature. For behavior features that are not found in the behavior feature library, the behavior feature can be input into the large language model. The input can also include the service behavior fingerprint, source code, unit test cases and external symbol set, etc. This disclosure does not limit this. The large language model then determines the occurrence of the remaining behavior features.

[0073] As an example, to better understand the detection process of behavioral features, the following JSON-formatted code logic can be used for illustration. For example, it may include, but is not limited to, the following logic: { Basic Information: { Target service:"sshd.service", "Source package path":" / usr / src / openssh-9.0-1.src.rpm", "Compilation target":"sshd", "Executable file path":" / usr / sbin / sshd", "Analysis Tools": "LLM + Rule System (The rule base covers the behavior associated with systemd security configuration items, LLM uses...") (For complex source code logic analysis) }, "Actions that are certain to occur": [ { "Behavior Type": "Configuration Loading", Evidence states: "In the source code src / servconf.c, line 2700, the fopen() function is called to read the configuration file / etc / ssh / sshd_config." }, { "Behavior Type": "Network Behavior" "Evidence": "In the source code src / sshd.c, line 456, the socket() function is called to create a socket in the AF_INET (IPv4) and AF_INET6 (IPv6) address families, listening on port 22. The compilation log shows related netlink symbols." }, { "Behavior Type": "External Process Call" "Evidence": "In line 789 of the source code src / session.c, the execve() function is called to execute the / usr / bin / ssh-keygen helper program for key verification." }, { "Behavior Type": "Permission Change" "Evidence": "Line 345 of the source code src / auth.c calls the setuid() function to switch user identities, used for permission downgrading after client login." }, { "Behavior Type": "File System Operation" "Evidence states": "Line 678 of the source code src / log.c writes logs to the path / var / log / sshd.log, and the installation process records this path as the service's default log output path." } ], "Actions that will definitely not be performed": [ { "Behavior Type": "Memory Execution" "Evidence": "No memory-writable and executable calls such as mprotect(PROT_EXEC) and mmap(PROT_EXEC) were found in the source code, compilation logs, or unit tests." }, { "Behavior Type": "Kernel Module Operation", "Evidence states": "There are no system calls such as insmod, rmmod, and delete_module, and no kernel module loading / unloading logic." }, { "Behavior Type": "Raw Socket Usage", "Evidence Statement": "No calls related to the AF_PACKET address family were found, and there were no traces of raw socket usage." }, { "Behavior Type": "System Clock Modification" "Evidence states": "No system calls such as clock_settime or adjtimex are needed, and there is no need to modify the system hardware clock or system clock." }, { "Behavior Type": "Mount Operation" "Evidence Description": "No system calls such as mount or umount were made, no mounting-related services such as udisks were associated, and there was no file system mount / unmount behavior." } ], "Possible behaviors": [ { "Behavior Type":"D-Bus Interaction", "Evidence Explanation": "In the source code src / notify.c, line 234 calls the dbus_send_message() function to send a message, but the BusName and interface of the target service are dynamic parameters (dynamically read from the configuration file). Static analysis cannot determine the target service or whether privileged interaction is involved." }, { "Behavior Type": "External Command Invocation" "Evidence Explanation": "In line 567 of the source code src / helper.c, there is logic in the execve() function to dynamically concatenate external command parameters. The parameter values ​​are dynamically passed in from the client request, and the final calling program and permission requirements cannot be determined." }, { "Behavior Type": "Dynamic Plugin Loading", "Evidence Explanation": "In line 890 of the source code src / plugin.c, the dlopen() function is called to load plugins, but a fixed plugin path is not specified. It only configures the plugin scanning directory as / usr / lib / sshd / plugins, making it impossible to determine any additional permissions that the plugin might introduce." }, { "Behavior Type": "Network Behavior" "Evidence Explanation": "The source code contains general socket() creation logic. Besides the explicit AF_INET and AF_INET6, the possibility of using AF_NETLINK cannot be ruled out, but there are no clear call traces, making it impossible to accurately determine whether it was triggered." } ], } It should be noted that this embodiment can also standardize behavioral evidence based on a preset regular expression and syntax parsing rule base, and this disclosure does not limit it in this way. This method has higher execution efficiency, but poor adaptability to complex source code structures (such as nested calls and dynamically loaded plugins), and requires continuous maintenance of the rule base; this disclosure, based on the rule system, incorporates LLM, which has stronger logical reasoning and complex scenario adaptability capabilities, and is more suitable for diverse service source code scenarios.

[0074] According to an exemplary embodiment of this disclosure, the step 105 above, which generates an evaluation report of security configuration items for a target service based on the type of each security configuration item and multi-source evidence, may include: determining configuration recommendations and evidence chains for security configuration items based on the type of security configuration items and multi-source evidence, wherein the evidence chain is evidence information for obtaining configuration recommendations; and generating an evaluation report of security configuration items for a target service based on the type of each security configuration item, configuration recommendations, evidence chains, and configuration status.

[0075] Through this embodiment, the generated evaluation report includes a chain of evidence, so that each evaluation conclusion is associated with a specific source code fragment, compilation log or installation record. The evaluation results are interpretable and reproducible, solving the problem of lack of support for the evaluation conclusions of the prior art.

[0076] As an example, based on the types of multi-source evidence and security configuration items obtained above, corresponding configuration suggestions can be obtained through a large language model. This disclosure does not limit this.

[0077] After receiving the configuration recommendation, the following can be combined: the configuration recommendation, the type of the security configuration item, the configuration status of the security configuration item, and the evidence chain for obtaining the configuration recommendation (such as source file path, symbol call location, compilation log fragments, etc.) to form an evaluation report for the security configuration item. For example, if MemoryDenyWriteExecute= is configured as false, and the evidence chain shows that the source code does not contain the mprotect(PROT_EXEC) call, then the configuration recommendation is to adjust this configuration to true.

[0078] The following examples illustrate relevant information about several security configuration items in the assessment report.

[0079] 1) MemoryDenyWriteExecute (basic security item), its relevant information is as follows: Security configuration item: MemoryDenyWriteExecute= Configuration status: false Judgment type: Mismatch type Chain of evidence: No memory execution related calls such as mprotect(PROT_EXEC) and mmap(PROT_EXEC) were found in the source code, and no related behavior records were found in the unit tests.

[0080] Configuration recommendation: true, disables memory writability and execution, and improves vulnerability protection capabilities.

[0081] 2) ProtectKernelModules, the relevant information of which is as follows: Security configuration item: ProtectKernelModules=true Configuration status: true Judgment type: Mismatch type Evidence chain: The source src / module.c contains the __NR_delete_module system call on line 82, which is used to unload the kernel module. This contradicts the configuration "disable kernel module operations", meaning they do not match.

[0082] Configuration suggestion: False or remove the kernel module operation logic from the source code.

[0083] 3) AmbientCapabilities, the relevant information of which is as follows: Security configuration item: AmbientCapabilities= Configuration status: true Judgment type: Matching type Evidence chain: The service has no specific kernel capability items configured, and the environment capability set is empty; through source code retrieval, compilation symbol analysis, and unit test verification, the service has not performed any privileged operations that require additional environment capabilities, and the empty capability set can meet the normal operation requirements of the service.

[0084] Configuration recommendation: Keep the existing configuration.

[0085] 4) RestrictAddressFamilies, the relevant information is as follows: Security configuration item: RestrictAddressFamilies=~AF_NETLINK Configuration status: false Judgment type: Matching type Chain of evidence: The source code contains general socket() creation logic, but does not explicitly use address families such as AF_NETLINK, and static analysis cannot determine the actual type used.

[0086] Configuration Recommendation: It is recommended to check the address family usage through eBPF runtime monitoring before imposing restrictions.

[0087] 5) The CapabilityBoundingSet permission item has the following related information: Security item: CapabilityBoundingSet=~CAP_KILL Configuration status: false Judgment type: Matching type Evidence chain: Source code retrieval revealed no process termination-related system calls such as kill(), tkill(), pkill(), ioctl()KDSIGACCEPT; the compilation log contained no CAP_KILL capability dependency declaration; unit tests did not include scenarios related to "terminating other processes," and the service does not require the privilege to actively terminate other processes during operation.

[0088] Configuration recommendation: Keep the existing configuration, i.e., remove CAP_KILL from the capability set.

[0089] To better understand this disclosure, the following is in conjunction with... Figure 3 Provide a systematic explanation.

[0090] Figure 3 The evaluation system architecture of this disclosure is shown, such as Figure 3 As shown, the evaluation method disclosed herein involves three core modules, and the functions of each core module are as follows: The assessment item collection module is responsible for extracting security configuration items of the target service from the systemd tool, organizing them into a security assessment item table, and extracting a behavioral feature library to provide a basic benchmark for subsequent verification. Multi-source behavioral evidence collection module: Collects cross-validation data of the actual behavior of the target service through source code analysis, compilation tracing, installation process recording, etc., such as service behavior fingerprints in the above embodiment; Evidence analysis and evaluation module: Using a preset rule system and LLM, the behavioral feature library is converted into an intermediate representation of permission requirements. Based on this intermediate representation of permission requirements and the configuration status of each configuration item, each security configuration item is classified and judged, and an evaluation report is generated.

[0091] The generated assessment report will be transmitted to the user or system administrator.

[0092] In summary, this disclosure collects multi-source evidence from the service, combines a pre-defined rule system and LLM to perform standardized analysis of the behavioral feature library, and achieves accurate verification of the configuration of systemd security configuration items based on the analysis results (i.e., the occurrence of the situation).

[0093] Figure 4 This is a block diagram illustrating an apparatus for evaluating security configuration items of a service according to an exemplary embodiment. (Refer to...) Figure 4 The device includes: Extraction unit 40 is configured to extract at least one security configuration item of the target service and the configuration state of each security configuration item; construction unit 42 is configured to construct a behavior feature library containing the behavior features corresponding to each security configuration item; detection unit 44 is configured to detect the occurrence of each behavior feature in the behavior feature library during the execution of the target service based on multi-source evidence during the execution of the target service, wherein the multi-source evidence includes the source code corresponding to the compilation target of the target service, unit test cases, and external symbols referenced in the source code; determination unit 46 is configured to determine the type of each security configuration item based on the configuration state of the security configuration item and the occurrence of the corresponding behavior feature, wherein the type of the security configuration item indicates whether the configuration state of the security configuration item matches the occurrence of the corresponding behavior feature; generation unit 48 is configured to generate an evaluation report of the security configuration items for the target service based on the type of each security configuration item and the multi-source evidence.

[0094] According to an exemplary embodiment of this disclosure, the occurrence of each behavioral feature during the execution of the target service includes the following three scenarios: First, the behavioral feature is guaranteed to occur during the execution of the target service; second, the behavioral feature is guaranteed not to occur during the execution of the target service; and third, it is impossible to determine whether the behavioral feature occurs during the execution of the target service. Through this embodiment, behavioral features are categorized into three factual items: guaranteed to occur, guaranteed not to occur, and possible to occur, thereby forming a standardized permission requirement description based on behavioral evidence and achieving accurate mapping between behavioral evidence and security configuration items.

[0095] According to an exemplary embodiment of this disclosure, the type of security configuration item is any of the following: Matching type, where the configuration state of a matching security configuration item matches the occurrence of its corresponding behavioral feature, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state matches the occurrence of its corresponding behavioral feature: the configuration state of the security configuration item is allowed and the occurrence of its corresponding behavioral feature is a first case; the configuration state of the security configuration item is allowed or disallowed and the occurrence of its corresponding behavioral feature is a third case; Mismatching type, where the configuration state of a mismatching security configuration item does not match the occurrence of its corresponding behavioral feature, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state does not match the occurrence of its corresponding behavioral feature: the configuration state of the security configuration item is allowed and the occurrence of its corresponding behavioral feature is a second case; the configuration state of the security configuration item is disallowed and the occurrence of its corresponding behavioral feature is a first case. Through this embodiment, based on the occurrence of behavioral features, classification judgments are achieved for configuration allowed and behavior supported, configuration allowed but behavior not supported, configuration conflict or error, and cases where dynamic verification is required but cannot be determined, and these are divided into mismatching and matching categories, thereby accurately identifying the rationality of the configuration.

[0096] According to an exemplary embodiment of this disclosure, the detection unit 44 is further configured to, before detecting the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence during the execution process of the target service, obtain the source code package and compilation target of the target service; obtain the source code corresponding to the compilation target and the unit test cases associated with the compilation target from the source code package by tracing the compilation process for the compilation target; obtain the external symbol set of external symbols referenced in the source code by simulating the installation process of the target service; and use the external symbol set, source code, and unit test cases as multi-source evidence. Through this implementation, a combined collection scheme of locating the source code package using a package management tool, tracing the compilation process, recording installation files, and extracting the external symbol table achieves comprehensive coverage of the behavioral features occurring during service execution.

[0097] According to an exemplary embodiment of this disclosure, the detection unit 44 is further configured to extract service behavior fingerprints for the compilation target from an external symbol set, source code, and unit test cases; query the behavior features corresponding to the service behavior fingerprints from a preset rule system, wherein the preset rule system contains a mapping relationship between service behavior fingerprints and behavior features; for predetermined behavior features in the behavior feature library, determine the occurrence of the predetermined behavior features as a first case, wherein the predetermined behavior features are the behavior features queried from the preset rule system; for other behavior features in the behavior feature library besides the predetermined behavior features, input the other behavior features into the large language model to obtain the occurrence of each other behavior feature. Through this embodiment, the rule system and the large language model are combined, that is, the preset rule system is used to ensure the standardization of the parsing results, and the logical reasoning capability of LLM is combined to parse complex source code behavior, thereby balancing parsing capability and accuracy; moreover, there is no need for manual line-by-line analysis of the source code, significantly reducing the manpower cost of security assessment and greatly improving assessment efficiency.

[0098] According to an exemplary embodiment of this disclosure, the generation unit 48 is further configured to determine configuration recommendations and evidence chains for security configuration items based on the type of the security configuration item and multi-source evidence, wherein the evidence chain is evidence information for obtaining configuration recommendations; and to generate an evaluation report for the security configuration items of the target service based on the type, configuration recommendation, evidence chain, and configuration status of each security configuration item. Through this embodiment, the generated evaluation report includes evidence chains, ensuring that each evaluation conclusion is associated with specific source code fragments, compilation logs, or installation records. The evaluation results are interpretable and reproducible, solving the problem of insufficient support for evaluation conclusions in existing technologies.

[0099] According to embodiments of this disclosure, an electronic device may be provided. Figure 5 This is a block diagram of an electronic device 500 according to an embodiment of the present disclosure. The electronic device includes at least one memory 501 and at least one processor 502. The at least one memory stores a set of computer-executable instructions. When the set of computer-executable instructions is executed by the at least one processor, an evaluation method for security configuration items of a service according to an embodiment of the present disclosure is performed.

[0100] As an example, electronic device 500 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 500 is not necessarily a single electronic device, but may be a collection of any devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 500 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0101] In electronic device 500, processor 502 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 502 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0102] The processor 502 can execute instructions or code stored in memory, and the memory 501 can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transmission protocol.

[0103] The memory 501 may be integrated with the processor 502, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 501 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 501 and the processor 502 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 502 to read files stored in the memory 501.

[0104] In addition, the electronic device 500 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0105] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes to perform an evaluation method for security configuration items of services according to embodiments of this disclosure. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0106] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions, and an evaluation method for security configuration items that implement the services of this disclosure when the computer instructions are executed by a processor.

[0107] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0108] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for evaluating security configuration items of a service, characterized in that, include: Extract at least one security configuration item from the target service and the configuration status of each security configuration item; Construct a behavior feature library containing the behavior features corresponding to each security configuration item, wherein the behavior features are the system operation behaviors of the system where the target service is located; Based on multi-source evidence during the execution of the target service, the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service is detected. The multi-source evidence includes the source code corresponding to the compilation target of the target service, unit test cases, and external symbols referenced in the source code. The occurrence of each behavioral feature during the execution of the target service falls into three categories: first, the behavioral feature definitely occurs during the execution of the target service; second, the behavioral feature definitely does not occur during the execution of the target service; third, it cannot be determined whether the behavioral feature occurs during the execution of the target service. For each security configuration item, the type of the security configuration item is determined based on its configuration status and the occurrence of its corresponding behavioral characteristics, wherein the type of the security configuration item indicates whether the configuration status of the security configuration item matches the occurrence of its corresponding behavioral characteristics; Based on the type of each security configuration item and the multi-source evidence, an evaluation report on the security configuration items for the target service is generated; The step of detecting the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence during the target service execution process includes: From the external symbols, the source code, and the unit test cases, service behavior fingerprints for the compilation target are extracted, wherein the service behavior fingerprint is a category of behavioral features that appear during the execution of the target service and constitute a unique identifier of the target service at the system interaction level; the behavioral features corresponding to the service behavior fingerprint are queried from a preset rule system, wherein the preset rule system contains a pre-defined mapping relationship between service behavior fingerprints and behavioral features; for predetermined behavioral features in the behavioral feature library, the occurrence of the predetermined behavioral features is determined as the first case, wherein the predetermined behavioral features are behavioral features queried from the preset rule system; for other behavioral features in the behavioral feature library besides the predetermined behavioral features, the other behavioral features are input into a large language model to obtain the occurrence of each of the other behavioral features.

2. The evaluation method as described in claim 1, characterized in that, The security configuration item can be of any of the following types: The matching type is defined as follows: the configuration status of the security configuration item of the matching type is matched with the occurrence of the corresponding behavioral feature. The security configuration item is determined to match the configuration status with the occurrence of the corresponding behavioral feature if it satisfies any of the following conditions: the configuration status of the security configuration item is allowed and the occurrence of the corresponding behavioral feature is the first condition; or the configuration status of the security configuration item is allowed or not allowed and the occurrence of the corresponding behavioral feature is the third condition. A mismatch type, wherein the configuration state of the security configuration item does not match the occurrence of the corresponding behavioral feature, wherein the security configuration item satisfies any of the following conditions to determine that the configuration state does not match the occurrence of the corresponding behavioral feature: the configuration state of the security configuration item is not allowed and the occurrence of the corresponding behavioral feature is the first case; the configuration state of the security configuration item is allowed and the occurrence of the corresponding behavioral feature is the second case.

3. The evaluation method as described in claim 1, characterized in that, Before detecting the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence during the target service execution process, the method further includes: Obtain the source code package and compilation target of the target service; By tracing the compilation process for the compilation target, the source code corresponding to the compilation target and the unit test cases associated with the compilation target are obtained from the source code package; By simulating the installation process of the target service, the set of external symbols referenced in the source code is obtained; The external symbol set, the source code, and the unit test cases are used as the multi-source evidence.

4. The evaluation method as described in claim 1, characterized in that, The process of generating an evaluation report for the security configuration items of the target service based on the type of each security configuration item and the multi-source evidence includes: Based on the type of the security configuration item and the multi-source evidence, a configuration recommendation and a chain of evidence are determined for the security configuration item, wherein the chain of evidence is evidence information for obtaining the configuration recommendation; An evaluation report on the security configuration items for the target service is generated based on the type, configuration recommendation, evidence chain, and configuration status of each security configuration item.

5. An evaluation device for security configuration items of a service, characterized in that, include: The extraction unit is configured to extract at least one security configuration item of the target service and the configuration status of each security configuration item; The building unit is configured to build a behavior feature library containing behavior features corresponding to each security configuration item, wherein the behavior features are the system operation behaviors of the system where the target service is located; The detection unit is configured to detect the occurrence of each behavioral feature in the behavioral feature library during the execution of the target service based on multi-source evidence during the execution process. The multi-source evidence includes the source code corresponding to the compilation target of the target service, unit test cases, and external symbols referenced in the source code. The occurrence of each behavioral feature during the execution of the target service falls into three categories: first, the behavioral feature definitely occurs during the execution of the target service; second, the behavioral feature definitely does not occur during the execution of the target service; third, it cannot be determined whether the behavioral feature occurs during the execution of the target service. The determining unit is configured to, for each security configuration item, determine the type of the security configuration item based on the configuration state of the security configuration item and the occurrence of the corresponding behavioral feature, wherein the type of the security configuration item indicates whether the configuration state of the security configuration item matches the occurrence of the corresponding behavioral feature; The generation unit is configured to generate an evaluation report of the security configuration items for the target service based on the type of each security configuration item and the multi-source evidence. The detection unit is further configured to extract service behavior fingerprints for the compilation target from the external symbols, the source code, and the unit test cases. The service behavior fingerprint is a category of behavioral features that appears during the execution of the target service and constitutes a unique identifier for the target service at the system interaction level. The unit also queries a preset rule system for the behavioral features corresponding to the service behavior fingerprints, where the preset rule system includes a pre-defined mapping relationship between service behavior fingerprints and behavioral features. For predetermined behavioral features in the behavioral feature library, the occurrence of the predetermined behavioral features is determined as the first case, where the predetermined behavioral features are behavioral features queried from the preset rule system. For other behavioral features in the behavioral feature library besides the predetermined behavioral features, the other behavioral features are input into a large language model to obtain the occurrence of each of the other behavioral features.

6. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method for evaluating the security configuration items of the service as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the processor to perform an evaluation method for the security configuration items of the service as described in any one of claims 1 to 4.

8. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method for evaluating the security configuration items of the service as described in any one of claims 1 to 4.

Images