Method for security testing of a baseboard management controller and electronic device

Abstract

The application discloses a security test method of a baseboard management controller and electronic equipment, relates to the technical field of testing, and comprises the following steps: performing multi-domain hierarchical mapping on a security scheme of the baseboard management controller, generating a hierarchical test object set of a security domain, and extracting test objects corresponding to each domain security scheme; constructing an attack path across at least two types of test object sets and instantiating the attack path into a scene sample, reproducing complex working conditions of remote firmware upgrading and access control linkage; carrying out multi-dimensional cross-domain testing containing firmware upgrading and access control interaction based on the scene sample, collecting interactive test data sets containing execution data flow, actual response and expected response, and completely retaining multi-module linkage test data; performing feature analysis and result aggregation on the data set to generate a verification output set, so that the protection capability is systematically verified, the overall protection effect in a complex scene is accurately evaluated, and the defects that related technologies lack systematic testing means, protection capability verification and accurate evaluation of protection effect in a complex scene are solved.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a security testing method and electronic device for a baseboard management controller. Background Technology

[0002] In data center and enterprise-level business scenarios, servers undertake core computing and data storage tasks. Their operational stability and remote manageability directly impact the continuity of business operations. The Baseboard Management Controller (BMC) possesses hardware and firmware systems independent of the main processor, unconstrained by the server's operating system or power-on / off status. It enables power management, hardware monitoring, and remote start / stop operations, making it a core component for remote server maintenance. Related technologies rely on fixed models and threshold mechanisms for BMC anomaly detection, and are combined with remote firmware upgrades and access control to build a BMC security protection system. However, a systematic testing method for BMC security solutions is lacking, making it difficult to comprehensively verify protection capabilities and accurately assess the overall protection effect of the BMC in complex scenarios. Summary of the Invention

[0003] This application provides a security testing method and electronic device for a baseboard management controller (BMC), which at least solves the problems in the related art of lacking systematic testing methods for BMC security solutions, being unable to fully verify the protection effect, and being difficult to accurately evaluate the overall protection effect of BMC in complex scenarios.

[0004] This application provides a security testing method for a baseboard management controller, comprising: performing multi-domain layered mapping on the security scheme of the baseboard management controller to obtain layered test object sets categorized according to different security domains; each layered test object set includes test objects extracted from the security scheme of the corresponding security domain; constructing attack paths and instantiating the attack paths to obtain interactive scenario samples under a preset test environment; the attack paths include test objects from at least two layered test object sets; performing multi-dimensional cross-domain testing based on the interactive scenario samples to obtain an interactive test dataset; the multi-dimensional cross-domain testing includes remote firmware upgrade operations and cross-domain access control interactions; the interactive test dataset includes the execution data stream of the multi-dimensional cross-domain testing, as well as the actual response and the expected response; the actual response is the actual handling result of the execution data stream of the abnormal payload implantation based on the security scheme, and the expected response is the expected handling result of the execution data stream of the abnormal payload implantation based on the security scheme; performing feature analysis and result aggregation on the interactive test dataset to obtain a verification output set; the verification output set is used to evaluate the protection effect of the security scheme under the preset test environment.

[0005] This application also provides a security testing device for a baseboard management controller, comprising: The multi-domain hierarchical mapping module is used to perform multi-domain hierarchical mapping on the security scheme of the baseboard management controller to obtain hierarchical test object sets classified according to different security domains; each hierarchical test object set includes test objects extracted from the security scheme of the corresponding security domain. The building module is used to construct attack paths and instantiate attack paths to obtain interactive scenario samples in a preset test environment; the attack path includes test objects from at least two hierarchical test object sets; The multi-dimensional cross-domain testing module is used to perform multi-dimensional cross-domain tests based on interactive scenario samples and obtain interactive test datasets. Multi-dimensional cross-domain tests include remote firmware upgrade operations and cross-domain interactions for access control. The interactive test dataset includes the execution data stream of multi-dimensional cross-domain tests, as well as the actual response and expected response. The actual response is the actual handling result of the abnormal payload implantation execution data stream based on the security scheme, and the expected response is the expected handling result of the abnormal payload implantation execution data stream based on the security scheme. The feature analysis and result aggregation module is used to perform feature analysis and result aggregation on the interactive test dataset to obtain a verification output set; the verification output set is used to evaluate the protection effect of the security scheme in the preset test environment.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the security testing method for the baseboard management controller described above.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the security testing method for the aforementioned baseboard management controller.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the security testing method for the aforementioned baseboard management controller.

[0009] This application first implements multi-domain layered mapping for the security scheme of the baseboard management controller, dividing it into layered test object sets categorized by each security domain. Each layered test object set extracts corresponding test objects from the security scheme corresponding to its respective security domain. Then, it constructs attack paths covering test objects within at least two types of layered test object sets, and instantiates the attack paths into interactive scenario samples adapted to a preset test environment to reproduce complex interactive conditions. Based on the interactive scenario samples, it conducts multi-dimensional cross-domain tests, including remote firmware upgrade operations and cross-domain access control interactions, and collects interactive test datasets containing test execution data streams and actual and expected responses generated by the security scheme to abnormal payload implantation data streams, completely preserving the original data of the entire link interactive test under complex scenarios. Finally, it performs feature analysis and result aggregation processing on the interactive test dataset to generate a verification output set. Relying on the integrated quantitative and systematic output results, it comprehensively verifies the protection capabilities of the security scheme, accurately evaluates the comprehensive protection effect of the entire security protection system of the baseboard management controller under complex scenarios, and solves the technical defects of related technologies that lack systematic testing methods, cannot comprehensively verify protection capabilities, and are difficult to accurately evaluate the overall protection effect in complex scenarios. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic flowchart illustrating a security testing method for a baseboard management controller provided in an embodiment of this application; Figure 2 This is a schematic diagram of the standardized execution process for BMC multi-domain security coupling testing provided in an embodiment of this application; Figure 3 A schematic diagram illustrating the process of generating a verification output set provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a security testing device for a baseboard management controller provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To meet core operational and maintenance needs such as remote server management, daily troubleshooting, and hardware status monitoring, the industry commonly integrates a Baseboard Management Controller (BMC) into servers. The BMC has a hardware interface and firmware system independent of the server's main processor, and is not limited by the server's operating system status. It can independently perform operational and maintenance functions such as device power management, real-time hardware status monitoring, remote start / stop, and fault alarms. Even if the server system crashes or is completely shut down, it can still maintain normal communication through the remote management channel. It is an indispensable core module in the server's remote operation and maintenance, fault diagnosis, and security management system, playing a crucial role in ensuring the stable operation of the server and overall business.

[0015] In related technologies, anomaly monitoring and security protection for BMCs have become standard technical solutions. Regarding anomaly detection, the industry generally adopts a judgment mechanism based on fixed model assumptions and fixed thresholds to identify anomalies in BMC operating status and server hardware-related data. In terms of security protection, a basic security protection system for BMCs is mainly built by combining remote firmware upgrades and basic access control. This system mitigates security risks such as BMC malfunctions, unauthorized access, and firmware vulnerabilities, ensuring the basic operational security of the BMC and the entire server.

[0016] Existing BMC anomaly detection and security protection solutions suffer from numerous substantial deficiencies in practical applications, failing to meet the high-precision, high-reliability operation and security protection requirements of server BMCs under complex operating conditions. Firstly, fixed models and fixed thresholds for anomaly detection have extremely poor adaptability, failing to align with the real-world operating scenarios of data centers characterized by instability, fluctuating conditions, and high environmental noise. Faced with dynamically fluctuating real-time monitoring data, the accuracy of anomaly detection and system robustness are insufficient, easily leading to false alarms and missed alarms, resulting in operational misjudgments and the inability to promptly identify potential faults. Secondly, the current industry lacks a systematic and standardized testing framework and methods for BMC security protection solutions, making it impossible to effectively verify the overall protection capabilities of BMCs from all angles and dimensions, and hindering the control over the actual implementation effect of security protection solutions. Finally, related remote firmware upgrade mechanisms and access control mechanisms lack efficient linkage verification logic, creating security vulnerabilities where the protection verification process can be maliciously bypassed during operation. This results in a hidden attack surface remaining after BMC deployment, making it unable to effectively resist network attacks and malicious intrusions in complex scenarios, and making it difficult to quantitatively evaluate the overall security protection performance of BMCs, resulting in insufficient overall security protection reliability and integrity.

[0017] To address all or part of the aforementioned technical problems, this application provides a security testing method for a baseboard management controller. This method first performs multi-domain layered mapping on the baseboard management controller's security scheme, dividing it into layered test object sets categorized by security domain. Each layered test object set extracts corresponding test objects from the security scheme corresponding to its respective security domain, solving the problem of related technologies lacking a systematic standard for organizing test objects. Then, it constructs attack paths covering test objects within at least two types of layered test object sets, and instantiates these attack paths into interactive scenario samples adapted to a preset test environment. This reproduces the complex interactive conditions of remote firmware upgrades and multi-module linkage in access control, overcoming the shortcomings of related technologies that rely solely on fixed models and thresholds for single-point anomaly detection, failing to simulate multi-security domain linkage attack scenarios. Based on the interactive scenario samples, it conducts security testing including remote... Multi-dimensional cross-domain testing, including firmware upgrade operations and cross-domain access control interactions, collects interactive test datasets containing test execution data streams, actual handling results (actual responses) generated by security solutions for abnormal payload implantation data streams, and preset standard handling results (expected responses). This comprehensively preserves the original data from the entire interactive test chain under complex scenarios, overcoming the shortcomings of related technologies in comprehensively collecting data from the multi-module linkage protection process. Finally, feature analysis and result aggregation processing are performed on the interactive test datasets to generate verification output sets. The integrated, quantitative, and systematic output results comprehensively verify the security solution's protection capabilities and accurately evaluate the overall protection effect of the entire security protection system of the baseboard management controller under complex scenarios. This addresses the technical deficiencies of related technologies, such as the lack of systematic testing methods, the inability to comprehensively verify protection capabilities, and the difficulty in accurately assessing the overall protection effect in complex scenarios.

[0018] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] like Figure 1 As shown, an embodiment of this application provides a security testing method for a baseboard management controller, the method comprising the following steps: S101. Perform multi-domain hierarchical mapping on the security scheme of the baseboard management controller to obtain a hierarchical test object set classified according to different security domains.

[0020] The security solution for the Baseboard Management Controller (BMC) is designed for the BMC and covers security domains such as permission management, firmware verification, log auditing, access control, and attack defense. It is a complete set of protection strategies and mechanisms to ensure its operational security and prevent various security threats.

[0021] The access control domain covers identity authentication, account role authorization, and global access control policies; the firmware verification domain is responsible for verifying the corresponding firmware file digest and the legality of firmware digital signatures; the log audit domain corresponds to the integrity verification of operation logs and the audit of log timing compliance; the attack simulation domain is used to verify the BMC's proactive defense strategy against abnormal access requests and malicious attacks.

[0022] In some embodiments, during step S101, the security configuration information of the baseboard management controller is first obtained, and the security configuration information is standardized to obtain an initial test dataset. Then, based on the initial test dataset, a multi-domain hierarchical mapping is performed on the security scheme of the BMC to obtain a hierarchical test object set.

[0023] Among them, the security configuration information is a set of basic configuration data used to implement various security protection functions during the operation of the baseboard management controller, including the operation configuration parameters that characterize the security control rules of the whole machine and the management interface information used for external interaction control.

[0024] Standardization processing includes at least one of time synchronization, format unification, and missing value completion. The above embodiment first collects all security configuration information, such as BMC system operation configuration parameters and management interface information, fully covering the underlying basic data of security protection functions such as remote firmware upgrades and access control, avoiding omissions in the test data source. Standardization processing, including time synchronization, format unification, and missing value completion, eliminates test interference caused by disordered configuration data timing, heterogeneous formats, and incomplete data, generating a well-organized and unified initial test dataset to ensure the consistency of subsequent test data benchmarks. Based on the standardized initial test dataset, multi-domain layered mapping of the BMC security solution is carried out, accurately dividing the layered test object sets corresponding to each security domain. This ensures reliable layered mapping logic and complete and orderly extraction of test objects, improving the accuracy and reliability of subsequent cross-domain testing and protection effect evaluation from the data source level, and avoiding the problems of test layered division deviations and distorted test results caused by messy original configuration data.

[0025] Optionally, in the process of performing multi-domain hierarchical mapping on the security scheme of the baseboard management controller based on the initial test dataset, a hierarchical domain test framework is first constructed based on the initial test dataset, and then the hierarchical domain test framework is used to perform multi-domain hierarchical mapping on the security scheme to obtain a hierarchical test object set.

[0026] Among them, multi-domain layered mapping relies on the layered domain testing framework to divide the overall security protection scheme of BMC into domains and generate standardized test objects by matching matrix mapping relationships.

[0027] The layered domain testing framework is built using a matrix mapping structure. It establishes a correspondence between the protection policy under test, configuration items, management interfaces, and test cases according to security domains. Different security domains are represented as rows, and at least one of the following—configuration items, management interfaces, operation events, and expected responses—is represented as columns. In other words, the row dimensions of the matrix correspond to the permission management domain, firmware verification domain, log auditing domain, and attack simulation domain, respectively, while the column dimensions correspond to configuration items, management interfaces, operation events, and expected responses, respectively. Matrix units are used to establish the correspondence between protection policies, resources under test, and test cases, and to generate test objects accordingly.

[0028] Each test object in the layered test object set contains an attack entry point object that can form an attack path, intermediate verification objects, controlled target resources, inter-object relationships, and a preset potential damage level. Test objects include the following fields: object identifier, security domain, target protection policy, controlled target resources, test preconditions, test operation, expected response result, and preset potential damage level.

[0029] The aforementioned optional implementation relies on a standardized initial test dataset to build a matrix-style hierarchical domain testing framework. Each security domain is represented as a matrix row, and configuration items and management interfaces as matrix columns. By binding protection policies, tested resources, and test cases to matrix units, a clear and organized multi-dimensional correspondence is established, solving the problem of scattered security elements lacking a unified associated carrier. This matrix framework enables multi-domain hierarchical decomposition and matrix mapping of the BMC security solution, uniformly generating standardized hierarchical test objects. This avoids the shortcomings of inconsistent standards, omissions, and errors in manually dividing test objects. The generated hierarchical test objects fully encompass attack entry points, intermediate verification objects, controlled resources, relationships, damage levels, and multiple core fields, comprehensively covering all basic elements required for attack path construction. This supports rapid instantiation of subsequent cross-domain attack paths and construction of interactive scenario samples, enabling multi-security domain protection capability correlation testing and improving the completeness, standardization, and traceability of BMC complex attack scenario testing.

[0030] S102. Construct the attack path and instantiate the attack path to obtain interactive scenario samples in the preset test environment.

[0031] The attack path includes test objects from at least two hierarchical test object sets.

[0032] The test object extracts attack entry points, intermediate verification objects, controlled target resources, and inter-object relationships that can form an attack path. These inter-object relationships include call relationships, authorization relationships, and data dependencies. The test object also includes preset potential damage levels.

[0033] In some embodiments, during step S102, the attack entry object, intermediate verification object, and controlled target resource contained in the test object are first connected to form an attack path. Then, the modeled attack path is instantiated according to the relationship between the objects to form a standardized interactive scenario sample. Each interactive scenario sample corresponds to one or more heterogeneous attack paths.

[0034] For example, by using the remote firmware upgrade interface as the attack entry point, authentication and access control as intermediate verification objects, and the firmware write area as the controlled target resource, a complete attack path can be formed. Taking the attack path consisting of the remote firmware upgrade interface, authentication and access control, and the firmware write area as an example, the cross-module linkage attack process under real BMC business can be accurately reproduced. This ensures that the test scenario closely matches the actual operating environment of the device, guaranteeing the authenticity, completeness, and standardization of subsequent multi-dimensional cross-domain test scenarios, and effectively improving the comprehensiveness of the protection capability verification under complex and composite attack scenarios of BMC.

[0035] The above embodiments construct a complete attack path by sequentially connecting the attack entry object, intermediate verification object, and controlled target resource within the test object. This fully reproduces the entire attack logic from attack initiation to target resource damage, covering multi-stage linked attack behaviors such as remote firmware upgrades and access control. Based on the preset object association relationships of the test object, the attack path is engineered and instantiated to uniformly generate standardized interactive scenario samples. A single sample can carry multiple heterogeneous attack paths, enabling simultaneous simulation of various types of composite attack scenarios. This solves the drawback of traditional testing, which can only test a single attack link and cannot reproduce multi-path concurrent heterogeneous attack scenarios.

[0036] Optionally, interaction coupling tests can be performed on the layered test objects to generate interaction scenario samples.

[0037] The interaction coupling test employs attack path modeling to quantify sample risk. First, the total number of attack paths is counted. Then, the normalized trigger probability and corresponding potential damage level of each attack path are determined. The trigger probability and potential damage level of a single attack path are multiplied to obtain its risk value. Finally, the risk values ​​of all attack paths are summed to calculate the overall risk exposure. This risk characteristic is then linked to the corresponding interaction scenario samples for prioritizing test execution and subsequent comprehensive risk assessment.

[0038] The model formula for attack path modeling is: ,in, The risk exposure of a scenario is a risk feature attached to the interactive scenario sample. It is used to determine the execution priority of the scenario and subsequent risk level calculation. It does not mean that the layered test object set itself is equivalent to the complete attack path. For the normalized first The trigger probability of each attack path is obtained by normalizing the results of repeated executions in similar scenarios or historical test statistics. For the first The preset potential damage levels for each attack path are pre-set based on the importance of the controlled target's resources and the impact of a successful anomaly. This represents the total number of attack paths within a single scenario.

[0039] The calculated risk exposure is bound to the corresponding interaction scenario sample for subsequent test execution priority ranking and comprehensive risk accounting.

[0040] Assuming four attack paths were tested, the trigger probability and potential damage level of each attack path are shown in Table 1.

[0041] Table 1

[0042] Based on the aforementioned embodiments, the risk exposure for each attack path was calculated as follows: R1=2, R2=2.25, R3=1.35, R4=2.45. The total risk exposure was further calculated to be R=8.05.

[0043] The aforementioned optional implementation method conducts interactive coupling tests on layered test objects and generates interactive scenario samples. It uses attack path modeling to quantify scenario risks. By statistically counting the total number of attack paths within the scenario, the trigger probability of each attack path is obtained by normalization based on historical test data. The damage level is pre-configured in conjunction with the importance of controlled resources. The risk value of a single path is obtained by multiplying the single path trigger probability by the damage level. The overall risk exposure of the scenario is calculated by accumulating the risk values ​​of all paths. The quantified risk exposure is used as a risk feature and bound to the corresponding interactive scenario samples. On the one hand, the test execution priority can be arranged in an orderly manner according to the risk value, and high-risk scenario tests can be carried out first to improve the detection efficiency of high-risk security vulnerabilities. On the other hand, it provides a quantitative basis for the comprehensive risk accounting of the entire BMC security protection system. By using a standardized mathematical model to uniformly quantify the risk degree of different heterogeneous attack path combination scenarios, it avoids the shortcomings of traditional testing that rely solely on subjective human judgment of scenario risks, inconsistent risk assessment standards, and the inability to quantify and compare the severity of scenarios. This makes the risk assessment of test scenarios objective, quantifiable, and comparable, further improving the accuracy and quantitative analysis capabilities of subsequent cross-domain testing and protection effect evaluation results.

[0044] like Figure 2 As shown, the standardized execution process of BMC multi-domain security coupling testing first performs interactive coupling testing, then enters the attack path modeling stage, and completes the attack link risk quantification calculation based on layered test objects; based on the modeling results, standardized interactive scenario samples are generated, carrying multiple heterogeneous composite attack paths; subsequently, multi-dimensional cross-domain testing is carried out. This stage executes two core test branches in parallel: one is the joint firmware upgrade operation (i.e., remote firmware upgrade operation), which collects standardized fields throughout the process to form an upgrade trigger dataset; the other is the access control cross-domain interaction, which connects the firmware verification domain and the permission management domain and generates a time-bound execution data stream; after the two branches complete the abnormal payload injection and the comparison between the actual and expected responses, the interactive test dataset is uniformly summarized and output, completely preserving the original test data of the entire process under the cross-domain linkage attack scenario, providing a complete data foundation for subsequent time-series consistency verification, security anomaly identification, and protection effect aggregation evaluation, realizing the systematic and standardized closed-loop testing of BMC firmware and access control multi-security domain linkage scenarios.

[0045] S103. Perform multi-dimensional cross-domain testing based on interactive scenario samples to obtain the interactive test dataset.

[0046] The multi-dimensional cross-domain test includes remote firmware upgrade operations and cross-domain interaction for access control.

[0047] In some embodiments, during step S103, a remote firmware upgrade operation is first performed on the interactive scenario sample to collect full-process event data and obtain an upgrade trigger dataset; then, access control cross-domain interaction is performed on the upgrade trigger dataset to obtain an execution data stream. An abnormal payload is executed in the execution data stream to determine the actual response and the expected response, thus obtaining an interactive test dataset.

[0048] The above embodiments, based on interactive scenario samples, first perform remote firmware upgrade operations and collect full-process event data to form an upgrade trigger dataset, completely retaining the original operational data of the firmware upgrade process and ensuring the traceability of firmware security-related behaviors; relying on the upgrade trigger dataset, cross-domain interactive processing of access control is carried out to generate execution data streams, reproducing the cross-security domain coupled operation of firmware upgrade and access control linkage, making up for the inability of single-module independent testing to simulate multi-functional linkage risks; abnormal payloads are injected into the execution data stream, and the actual response generated by the security solution is compared with the preset standard expected response and integrated to form an interactive test dataset, which fully includes all-dimensional comparative data of abnormal attacks and protection handling in cross-domain linkage scenarios, providing complete, real, and comparable standardized raw data for subsequent feature analysis and quantitative evaluation of protection effects, and fully supporting the systematic verification of BMC's protection capabilities in complex cross-domain scenarios.

[0049] When performing remote firmware upgrades on interactive scenario samples, an upgrade trigger dataset is collected, containing a unified event identifier, operation subject, account role and permissions, firmware version information, signature verification result, authorization determination result, execution stage, and device operating status. This enables cross-domain data association and tracing of similar events. The upgrade trigger dataset fully describes a firmware upgrade request and its execution result, including at least the trigger event identifier, trigger source, user role, target BMC or target component, firmware version before upgrade, firmware version to be upgraded, firmware digest value, signature verification result, request time, authorization result, upgrade stage, and upgrade status. These fields allow for the association of processing records for the same upgrade event in the firmware verification domain and the permission management domain.

[0050] When performing remote firmware upgrades, a multi-dimensional standardized field is collected to form an upgrade trigger dataset, thus fully covering key information across the entire chain, such as event identifiers, account permissions, firmware version, signature verification, authorization determination, and device operating status. Relying on a unified event identifier to establish a cross-security domain data association link, various processing records generated in the firmware verification domain and permission management domain for a single firmware upgrade can be accurately bound and linked. The complete multi-type data fields can fully reproduce the details of the entire firmware upgrade process from request initiation to execution completion, enabling accurate tracing of similar events across domains and solving the problems of missing data fields in traditional test data, fragmented data between different security domains, and inability to trace the complete attack chain.

[0051] When performing cross-domain interaction for access control on the upgrade-triggered dataset, the firmware verification domain and the permission management domain are first associated based on the event identifier of the remote firmware upgrade operation in the upgrade-triggered dataset, and collaborative control, logical verification and permission check are triggered; the results of collaborative control, logical verification and permission check are associated with the timestamp to generate the execution data stream.

[0052] In practice, access control policies are used for cross-domain linkage processing, synchronously completing session validity verification, user permission verification, and access control policy determination. The permission verification log, firmware summary and signature verification log, and firmware execution log are concatenated in time sequence to generate an ordered cross-domain interactive data stream. The cross-domain interactive data stream is an ordered event stream formed by associating firmware upgrade events, authentication results, access control determination, firmware verification results, and subsequent execution status through unified event identifiers and timestamps.

[0053] At this point, we can obtain the cross-domain interaction data stream, which is the execution data stream included in the interaction test dataset.

[0054] For example, the execution data flow of a remote firmware upgrade operation is shown in Table 2.

[0055] Table 2

[0056] The execution data flow of cross-domain access control interactions is shown in Table 3.

[0057] Table 3

[0058] This approach leverages a unified event identifier within the upgrade-triggered dataset to establish data association between the firmware verification domain and the access control domain. It simultaneously triggers multiple interconnected security mechanisms, including cross-domain collaborative management, logical verification, and access control checks. This accurately reflects the actual operational logic of multi-security-domain collaborative protection in BMC firmware upgrade scenarios. By binding three types of verification results to corresponding timestamps to generate execution data streams, it comprehensively preserves the time-sequential handling records of cross-domain interactions. This ensures that the timing of management behaviors across different security domains is traceable and that behaviors are correlated, addressing the shortcomings of independent domain testing in reproducing cross-module collaborative protection processes and the difficulty in matching and tracing the timing of various verification results. The time-sequential, cross-domain linked execution data stream can fully carry all management information in the coupled scenario of remote firmware upgrades and access control. It provides a standardized data carrier with complete timing and clear inter-domain associations for subsequent injection of abnormal payloads and comparison of actual and expected responses to construct interactive test datasets, ensuring that subsequent test analysis can fully reconstruct the entire cross-domain protection handling process.

[0059] In the process of implanting abnormal payloads into the execution data stream and determining the actual and expected responses to obtain the interaction dataset, specifically, abnormal payloads are implanted into the execution data stream under a preset test environment to simulate different attack scenarios. The abnormal payloads include at least one of the following: illegally signed firmware, version rollback instructions, unauthorized credentials, session replay messages, and malformed interface parameters. The actual response of the baseboard management controller to the abnormal payload implantation in the execution data stream is determined based on the security scheme under different attack scenarios. When the actual response differs from the expected response, security vulnerability candidates are generated. The execution data streams, security vulnerability candidates, and expected responses of the interaction scenario samples are summarized to obtain the interaction test dataset.

[0060] It is understandable that an abnormal payload is injected into the execution data stream, the actual handling result of the security scheme for this operation is determined, and this is taken as the actual response included in the interactive test dataset; and the expected handling result of the security scheme for the abnormal payload injection is determined, and this is taken as the expected response included in the interactive test dataset.

[0061] Specifically, in an isolated simulation test environment, abnormal payloads such as illegal firmware programs, firmware version rollback commands, unauthorized access credentials, session replay messages, and malformed interface parameters are injected into cross-domain interactive data streams. Comprehensive operational metrics of the BMC (Browser Management Center) for anomaly identification, access interception, security alarms, and fault recovery are collected. This simulates an attack scenario to test the BMC's capabilities in anomaly identification, interception, alarming, and recovery. The actual response of the device based on the security scheme can be compared with the expected response. If there is a discrepancy, the test is marked as failed and a vulnerability candidate is generated. Based on this, potential security vulnerabilities in the remote firmware upgrade and access control process can be located, and the vulnerability chain can be traced. The firmware upgrade event operation logs, identity verification records, access control judgments, firmware verification data, abnormal loads, and response comparison results of all interaction scenario samples are summarized and uniformly organized into an interaction test dataset.

[0062] The expected response to the implantation of abnormal loads is shown in Table 4.

[0063] Table 4

[0064] This application implants multiple types of anomalous payloads into the execution data stream under a standardized testing environment, simulating diverse real-world attack scenarios such as unauthorized firmware, unauthorized access, and session attacks. It comprehensively covers typical security threats to the BMC firmware and access control links, overcoming the shortcomings of traditional testing methods that rely on single attack samples and incomplete scenario coverage. By collecting the actual responses of the BMC security mechanism to various anomalous payloads and comparing them with preset standard expected responses, it automatically generates security vulnerability candidates when discrepancies exist, achieving automated vulnerability identification and labeling. The entire execution data stream, actual responses, and expected responses are uniformly summarized into an interactive test dataset, completely preserving full comparison data of cross-domain protection interactions under various attack scenarios. This provides complete and clearly categorized standardized original evidence for subsequent data feature analysis and protection effect aggregation evaluation, enabling precise location of failure points in the BMC multi-domain linkage protection mechanism and improving the comprehensiveness and intuitiveness of security vulnerability discovery.

[0065] The interactive test dataset of this application can record all executed test scenarios and their process data, including firmware upgrade events, authentication results, access control judgments, firmware verification results, exception injection content, expected responses, actual responses, and evidence logs.

[0066] Thus, the interactive test dataset of this application comprehensively collects all executed test scenarios and full-process process data, uniformly including multi-dimensional information such as firmware upgrade events, identity authentication, access control, firmware verification, abnormal injection payloads, expected responses, actual responses, and evidence logs. This enables a single dataset to carry the original credentials of the entire BMC cross-domain protection test chain. Various test process datasets are centrally retained and correspond one-to-one, solving the problems of traditional test data being scattered and data fragmentation in various protection links, and the lack of a complete evidence chain for vulnerability tracing. This provides a complete, verifiable, and traceable data foundation for subsequent dataset feature extraction and test result aggregation analysis, facilitating intuitive comparison of the differences between the security solution's handling behavior and standard expectations, quickly locating protection failure nodes. At the same time, the complete evidence logs can support security vulnerability determination and quantitative evaluation of protection effectiveness, improving the credibility and reproducibility of BMC security test results.

[0067] S104. Perform feature analysis and result aggregation on the interactive test dataset to obtain the verification output set.

[0068] The verification output set is used to evaluate the protection effectiveness of the security solution under a preset test environment.

[0069] In some embodiments, during step S104, feature analysis is first performed on the interactive test dataset to obtain a comprehensive test result set. Then, based on the interactive scenario samples and different security domains, the comprehensive test results are aggregated to obtain a verification output set.

[0070] Feature analysis includes consistency analysis and security feature extraction. Consistency analysis uses a log sequence comparison method with a unified timestamp, using a globally unique event identifier as the retrieval index to verify the time synchronization of cross-domain interaction events and investigate three types of timing anomalies: missing logs, out-of-order logs, and abnormal event delays. Consistency analysis uses a unified event identifier as the index to compare the timestamps of cross-domain interaction events with the log sequence to determine whether each processing step belongs to the same event and whether there are any missing, out-of-order, or abnormal delays.

[0071] Security feature extraction employs feature vector filtering based on anomaly pattern recognition to identify unauthorized access behaviors during firmware upgrades and access control. Furthermore, based on the deviation between the actual and expected responses after anomaly injection, security feature extraction uses feature vector filtering and anomaly pattern recognition algorithms to identify security anomalies such as unauthorized access, firmware signature verification bypass, firmware version rollback, and missing audit logs.

[0072] The above embodiments first conduct feature analysis on the interactive test dataset, including consistency analysis and security feature extraction, to generate a comprehensive test result set. The consistency analysis relies on globally unique event identifiers as retrieval indexes and uses a unified timestamp log sequence comparison method to verify the timing status of cross-domain interactive events. It accurately identifies timing defects such as missing logs, out-of-order logs, and abnormal event delays, ensuring that the timing of the handling records generated by each security domain for the same attack event is matched and the attribution is unified, eliminating misjudgments caused by cross-domain log timing disorder. The security feature extraction relies on feature vector filtering and abnormal pattern recognition algorithms. Based on the deviation data between the actual response and the expected response, it automatically identifies various security anomalies such as unauthorized access, firmware verification bypass, version rollback, and missing logs, realizing automated identification of multiple typical security risks and reducing the cost of manual analysis and the probability of missed detection. Subsequently, the comprehensive test results are aggregated in layers by combining interactive scenario samples and various security domain dimensions to obtain a verification output set. This integrates and summarizes the scattered single-scenario and single-domain test anomaly information, realizing a centralized presentation of the protection effect by domain and scenario. This provides time-series compliance and complete quantitative support for the systematic evaluation of the entire BMC security protection system, comprehensively improving the efficiency of security problem location and the comprehensiveness and objectivity of protection effect evaluation.

[0073] Optionally, in the process of performing feature analysis on the interactive test dataset to obtain a comprehensive test result set, consistency analysis and security feature extraction are performed on the interactive test dataset to verify the synchronization of event time and identify unauthorized behavior. Various test results are extracted from each security domain to obtain a comprehensive test result set.

[0074] Specifically, feature analysis is performed on the interactive test dataset, and the log sequences of cross-domain interactive events are compared to verify the synchronization of events. Based on the anomaly injection response, unauthorized access events in the firmware upgrade process and access control process are identified. Then, the execution results of the interactive scenarios, anomaly types, evidence logs, and security vulnerability candidates are integrated to generate a comprehensive test result set.

[0075] The aforementioned optional implementation method simultaneously conducts consistency analysis and security feature extraction on the interactive test dataset. On the one hand, it compares the cross-domain interactive event log sequence to complete the event timing synchronization verification, ensuring that the timing of the handling records for the same attack event in different security domains matches and the data corresponds. On the other hand, it relies on the response data after anomaly injection to identify security risks such as unauthorized access in firmware upgrades and access control processes, accurately capturing various cross-domain protection failure behaviors. Then, it uniformly integrates multi-dimensional information such as scenario execution records, anomaly types, evidence logs, and security vulnerability candidates to generate a comprehensive test result set. This integrates and unifies the fragmented test information scattered in various security domains and test scenarios, avoiding the omissions and misjudgments that are easily caused by analyzing single-dimensional data separately. It provides a regular, complete, and traceable intermediate result carrier for subsequent domain-specific aggregation to generate verification output sets, simplifying the overall evaluation process of BMC cross-domain protection effectiveness and improving the completeness and analysis efficiency of security anomaly location.

[0076] Optionally, in the process of performing feature analysis on the interactive test dataset to obtain a comprehensive test result set, the timestamps and log sequences of cross-domain interactive events in the interactive test dataset are compared to verify the synchronization of events; it is determined whether there are missing, out-of-order, or abnormal delays in the processing steps of the same cross-domain interactive event; based on the deviation between the abnormal implanted response and the expected response in the interactive test dataset, abnormal security behaviors are identified; and the feature analysis results are integrated to generate a comprehensive test result set.

[0077] The above-mentioned optional implementation method completes synchronization verification by comparing the timestamps of cross-domain interaction events with the log sequence within the interaction test dataset. This can accurately identify timing defects such as missing logs, out-of-order logs, and abnormal delays in each processing stage of the same cross-domain interaction event, eliminating the problem of misjudgment of test results caused by cross-domain log timing disorder. By relying on the deviation data between the actual response and the expected response after the abnormal payload is implanted, various security anomalies can be identified, which can accurately capture the failure vulnerabilities in the BMC cross-domain linkage protection mechanism. The results of timing verification and anomaly identification are integrated into a comprehensive test result set, which uniformly collects timing defects, security anomalies, and supporting test raw data. This provides a complete and well-organized intermediate analysis carrier for subsequent domain-specific aggregation to generate verification output sets, ensuring that the subsequent evaluation of the overall protection effect of BMC has both timing compliance judgment and security risk identification as a dual basis, and improving the comprehensiveness and credibility of test analysis results.

[0078] In some embodiments, the verification output set may include test coverage, vulnerability location information, and security risk level, which are used to verify the overall protection effectiveness of the server BMC security solution in complex operating environments.

[0079] Optionally, during the process of aggregating the comprehensive test result set to obtain the verification output set, the comprehensive test result set is integrated and calculated to statistically analyze the test coverage and vulnerability location information of each security domain and to calculate the security risk level.

[0080] The aforementioned optional implementation method integrates and calculates the comprehensive test result set, automatically compiles the test coverage and vulnerability location information corresponding to each security domain, and quantifies and calculates the security risk level, uniformly aggregating them into the verification output set. The verification output set simultaneously carries multi-dimensional evaluation indicators, which can intuitively reflect the test completeness of each security domain of BMC, the location of vulnerability occurrence, and the corresponding degree of harm, solving the shortcomings of traditional testing that can only output anomaly records in a scattered manner and cannot systematically quantify the evaluation. Based on the multi-dimensional evaluation indicators obtained by standardized aggregation calculation, it can fully verify the overall protection capability of the server BMC security solution in a complex operating environment with multiple attack paths intertwined, clearly and intuitively present the weak links and risk severity of the entire protection system, and provide quantitative and implementable data support for BMC security solution optimization and risk remediation.

[0081] The test coverage includes the coverage ratio of the multi-domain hierarchical mapping and the number of interaction scenarios covered. The calculation process of the test coverage includes: based on the comprehensive test result set, counting the total number of test cases and the number of executions for each security domain; calculating the test coverage ratio for each security domain based on the total number of test cases and the number of executions for each security domain; and averaging the test coverage ratios of each security domain to obtain the test coverage.

[0082] For example, assuming the total number of test cases and execution counts for different security domains are shown in Table 5, the test coverage ratio for each security domain can be calculated.

[0083] Table 5

[0084] The average test coverage of all security domains can be calculated as (85%+90%+80%+74.3%) / 4=82.5%, and the test coverage that the verification output set can include is 82.5%, thus transforming the abstract test adequacy into a quantifiable and comparable standardized indicator.

[0085] This application defines the test coverage from two dimensions: the coverage ratio of multi-domain layered mapping and the number of interaction scenarios covered. Based on the comprehensive test result set, the total number of test cases and the actual number of executions for each security domain are statistically analyzed. After calculating the test coverage ratio of each domain, the overall test coverage is obtained by averaging. The quantified test coverage is included in the verification output set, which can intuitively reflect the overall completeness of BMC multi-security domain testing, clearly expose the blind spots of single-domain testing, and avoid the problems of ambiguity and inconsistent standards caused by traditional manual qualitative judgment of test coverage. It provides intuitive quantitative basis for judging whether BMC security verification work is sufficient and for identifying uncovered risk scenarios, supporting a comprehensive and objective evaluation of the verification completeness of the entire BMC security protection solution.

[0086] Vulnerability location information is recorded in the form of resource identifiers. The process of determining vulnerability location information includes: determining the vulnerability location information based on the resource identifiers of the security vulnerability candidates in the comprehensive test result set. Resource identifiers include file paths, interface port numbers, and firmware version numbers.

[0087] For example, vulnerability location information is shown in Table 6. This vulnerability location information will provide the development team with a basis for locating and remediating vulnerabilities.

[0088] Table 6

[0089] This application uses resource identifiers to store vulnerability location information. It determines the precise vulnerability location based on resource identifiers such as file paths, interface port numbers, and firmware version numbers corresponding to security vulnerability candidates within the comprehensive test result set. By binding multi-dimensional information such as vulnerability, storage path, access port, and firmware version, it completely marks the software and hardware locations where vulnerabilities occur. This directly identifies the file path, interaction interface, and corresponding firmware version of the vulnerability, overcoming the shortcomings of traditional testing which can only generally label vulnerability types and cannot accurately locate the source of the problem. The structured and standardized vulnerability location information can be directly delivered to developers as an intuitive basis for vulnerability investigation and iterative remediation, shortening the vulnerability tracing and location cycle, improving the efficiency and accuracy of BMC security vulnerability remediation, and simultaneously enriching the evaluation dimensions of the verification output set, thus improving the comprehensive quantitative evaluation capability of BMC security protection system defects.

[0090] The calculation process for the safety risk level includes: calculating the score and weight of each safety indicator based on the comprehensive test result set, and then summing the scores to obtain the safety risk level value; and finally determining the safety risk level based on the safety risk level value.

[0091] Safety risk levels include low risk, medium risk, and high risk. The weighted average method is used to calculate the overall risk level, and the model formula is as follows: ,in, This represents the safety risk level value. For the first The weighting coefficients of each safety indicator For the first The score of each safety indicator, This represents the total number of safety indicators.

[0092] For example, the score values ​​and weights of some security indicators are shown in Table 7.

[0093] Table 7

[0094] The risk level value S, calculated using the weighted average method, is 6.3, classifying it as a medium risk level.

[0095] This application employs a weighted comprehensive method to quantify and calculate security risk levels. Based on a comprehensive test result set, it extracts the corresponding scores for each security indicator and configures appropriate weighting coefficients. A standardized weighted average model is used to calculate a unified security risk level value, which is then divided into low, medium, and high risk levels according to the numerical range. By leveraging weights, it differentiates the impact of different security indicators on the overall security of the BMC, avoiding the evaluation distortion caused by equal calculation of various risk elements. This allows for an objective distinction between the risk contribution of core security domains such as firmware verification and access control, and secondary security items. A standardized mathematical model unifies the risk quantification judgment logic, eliminating subjective bias in manual rating, and outputs quantifiable and comparable security risk level values, which are then included in the verification output set. This provides a direct representation of the overall risk level of the entire BMC security protection system, offering an objective quantitative evaluation basis for security solution optimization priority allocation and risk rectification and control.

[0096] like Figure 3 As shown, the comprehensive test result set is processed through unified result aggregation to generate a verification output set. The core processing node is result aggregation, which outputs three core evaluation elements in parallel: first, test coverage, which quantifies the completeness of the entire domain test based on the execution data of test cases in each security domain; second, vulnerability location information, which accurately marks the location of vulnerabilities through resource identifiers such as file paths, interface ports, and firmware versions; and third, security risk level, which uses a weighted comprehensive model to quantify standardized risk values ​​and divides them into low, medium, and high risk levels. The three types of data—test coverage, vulnerability location information, and security risk level—are simultaneously incorporated into the verification output set, forming a multi-dimensional, quantifiable, and traceable integrated evaluation carrier. This carrier fully supports the three core evaluation indicators of BMC security solution test completeness, defect location, and overall risk level, achieving a systematic and comprehensive presentation of the overall security protection effect of BMC in complex scenarios. It provides complete and standardized data basis for security capability assessment, vulnerability remediation, and protection strategy iteration.

[0097] The above examples demonstrate the analysis of test coverage, vulnerability location information, and security risk levels. The evaluation results indicate that the server BMC security solution exhibits varying levels of effectiveness across multiple security domains, and contains potential vulnerabilities and a moderate level of security risk. This conclusion pertains to the isolated test environment established in the examples and its loaded BMC configuration image, and does not directly equate to the final security conclusions for the production environment. Developers can further refine their security strategies based on vulnerability resource identifiers and failed test items before retesting.

[0098] The comprehensive test result set data can be aggregated bidirectionally from both the security domain and interactive test scenario dimensions. This allows for the statistical analysis of the total number of test cases, the actual number of executions, the number of passed test cases, the number of failed test cases, and explanations of the reasons for non-execution test cases for each security domain. It also binds the security vulnerability number and unique resource identifier to each failed test case. Thus, the verification output set, aggregated from both the security domain and interactive scenario dimensions, includes the total number of test cases, the actual number of executions, the number of passed cases, the number of failed cases, the reasons for non-execution, the security vulnerabilities and resource identifiers corresponding to the failed items, and the scores, weights, overall risk values, and risk levels of each security indicator.

[0099] In summary, this application abandons the single static judgment logic and builds a layered matrix testing framework that includes permissions, firmware verification, log auditing, and attack simulation. It generates a standardized dynamic test dataset based on real BMC security configurations, and collects massive interactive data under dynamic operating conditions by relying on attack path modeling and multi-dimensional cross-domain anomaly injection. It identifies various dynamic anomalies by comparing log time-series consistency and extracting anomaly pattern feature vectors, adapting to variable and high-noise operating environments, improving detection accuracy and robustness, and reducing false positives and false negatives.

[0100] The system designs a complete and standardized end-to-end testing framework, sequentially completing the entire process of configuration standardization, multi-security domain layering, attack path coupling modeling, cross-domain interaction testing, feature analysis, and result layering and aggregation. Relying on a matrix mapping framework, it achieves a one-to-one correspondence between protection strategies, interfaces, configurations, and test cases, covering independent scenarios in multiple security domains and interactive scenarios involving multiple modules. It quantifies and statistically analyzes the test coverage ratio, fully records test execution, failures, and vulnerability evidence, forming a quantifiable and comprehensive systematic testing capability to achieve all-round verification of the entire BMC security protection solution.

[0101] This application also addresses the issues of remote firmware upgrades and access control linkage being easily bypassed, having hidden attack surfaces, and being difficult to assess overall protection effectiveness. First, it conducts cross-domain coupling tests on firmware upgrades and access control, using a unified event identifier to connect the entire process of identity authentication, permission verification, firmware signature verification, and log auditing, establishing a collaborative verification link between the two mechanisms. Second, it proactively discovers and locates vulnerabilities in the verification process by simulating bypass attacks such as unauthorized firmware, unauthorized tokens, and session replay through anomaly injection. Third, it calculates the risk exposure in a single scenario using an attack path model, and then outputs a quantitative comprehensive security risk level based on a multi-security indicator weighted algorithm. This provides a direct and quantitative assessment of the overall protection effectiveness of BMC in complex interaction scenarios, exposes hidden attack surfaces, and completes vulnerability localization, thus overcoming the shortcomings of the original linkage mechanism's lack of verification and inability to quantitatively assess protection effectiveness.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0103] like Figure 4 As shown, embodiments of this application also provide a security testing device for a baseboard management controller, the device comprising: The multi-domain hierarchical mapping module 401 is used to perform multi-domain hierarchical mapping on the security scheme of the baseboard management controller to obtain hierarchical test object sets classified according to different security domains; each hierarchical test object set includes test objects extracted from the security scheme of the corresponding security domain. Module 402 is used to construct attack paths and instantiate attack paths to obtain interactive scenario samples in a preset test environment; the attack path includes test objects from at least two hierarchical test object sets. The multi-dimensional cross-domain testing module 403 is used to perform multi-dimensional cross-domain tests based on interactive scenario samples and obtain interactive test datasets. Multi-dimensional cross-domain tests include remote firmware upgrade operations and cross-domain interactions for access control. The interactive test dataset includes the execution data stream of the multi-dimensional cross-domain tests, as well as the actual response and the expected response. The actual response is the actual handling result of the abnormal payload implantation execution data stream based on the security scheme, and the expected response is the expected handling result of the abnormal payload implantation execution data stream based on the security scheme. The feature analysis and result aggregation module 404 is used to perform feature analysis and result aggregation on the interactive test dataset to obtain a verification output set; the verification output set is used to evaluate the protection effect of the security scheme in the preset test environment.

[0104] In some embodiments, the multi-domain hierarchical mapping module 401 is used to: obtain security configuration information of the baseboard management controller; perform standardization processing on the security configuration information to obtain an initial test dataset; wherein, the standardization processing includes at least one of time synchronization, format unification and missing value completion; and perform multi-domain hierarchical mapping on the security scheme based on the initial test dataset to obtain a hierarchical test object set.

[0105] In some embodiments, the multi-domain layered mapping module 401 performs multi-domain layered mapping on the security scheme based on the initial test dataset to obtain a layered test object set. Specifically, it is used to: construct a layered domain test framework based on the initial test dataset; the layered domain test framework uses different security domains as rows and at least one of configuration items, management interfaces, operation events, and expected responses as columns; perform multi-domain layered mapping on the security scheme according to the layered domain test framework to obtain a layered test object set; each test object in the layered test object set includes an attack entry object that can form an attack path, an intermediate verification object, a controlled target resource, the relationship between objects, and a preset potential damage level.

[0106] In some embodiments, the construction module 402 is used to: connect the attack entry object, intermediate verification object and controlled target resource contained in the test object into an attack path; and instantiate the attack path according to the relationship between the objects to obtain an interaction scenario sample.

[0107] In some embodiments, the multi-dimensional cross-domain testing module 403 is used to: perform a remote firmware upgrade operation on the interactive scenario sample, collect full-process event data to obtain an upgrade trigger dataset; the upgrade trigger dataset is used to describe the firmware upgrade request and execution result of the remote firmware upgrade operation; perform access control cross-domain interaction on the upgrade trigger dataset to obtain an execution data stream; and inject abnormal payloads into the execution data stream to determine the actual response and the expected response to obtain an interactive test dataset.

[0108] In some embodiments, the multi-dimensional cross-domain testing module 403 performs cross-domain access control interaction on the upgrade trigger dataset to obtain an execution data stream, which is used to: associate the firmware verification domain and the permission management domain based on the event identifier of the remote firmware upgrade operation in the upgrade trigger dataset, and trigger collaborative management, logical verification and permission verification; associate the collaborative management results, logical verification results and permission verification results with the timestamp to generate the execution data stream.

[0109] In some embodiments, the multi-dimensional cross-domain testing module 403 implants abnormal payloads into the execution data stream, determines the actual response and the expected response, and obtains an interactive test dataset. This dataset is used to: implant abnormal payloads into the execution data stream under a preset test environment to simulate different attack scenarios; the abnormal payloads include at least one of illegally signed firmware, version rollback instructions, unauthorized credentials, session replay messages, and malformed interface parameters; determine the actual response of the baseboard management controller to the implanted abnormal payloads into the execution data stream based on security schemes under different attack scenarios; generate security vulnerability candidates when the actual response differs from the expected response; and summarize the execution data streams, security vulnerability candidates, and expected responses of the interactive scenario samples to obtain the interactive test dataset.

[0110] In some embodiments, the feature analysis and result aggregation module 404 is used to: perform feature analysis on the interactive test dataset to obtain a comprehensive test result set; the comprehensive test result set includes at least one of the following: interactive scenario execution results, exception types, evidence logs, and security vulnerability candidates; and aggregate the comprehensive test result set based on interactive scenario samples and different security domains to obtain a verification output set; the verification output set includes at least one of the following: test coverage, vulnerability location information, and security risk level.

[0111] In some embodiments, the feature analysis and result aggregation module 404 performs feature analysis on the interactive test dataset to obtain a comprehensive test result set, which is used to: perform consistency analysis and security feature extraction on the interactive test dataset, verify the synchronization of event time and identify unauthorized behavior, extract various test results from each security domain, and obtain a comprehensive test result set.

[0112] In some embodiments, the feature analysis and result aggregation module 404 performs feature analysis on the interactive test dataset to obtain a comprehensive test result set, which is used to: compare the timestamps and log sequences of cross-domain interactive events in the interactive test dataset to verify event synchronization; determine whether there are missing, out-of-order, or abnormal delays in the processing steps of the same cross-domain interactive event; identify abnormal security behaviors based on the deviation between the abnormal implanted response and the expected response in the interactive test dataset; and integrate the feature analysis results to generate a comprehensive test result set.

[0113] In some embodiments, the feature analysis and result aggregation module 404 aggregates the comprehensive test result set to obtain a verification output set, which is used to: integrate and calculate the comprehensive test result set, statistically analyze the test coverage and vulnerability location information of each security domain, and calculate the security risk level.

[0114] In some embodiments, the verification output set includes test coverage; the feature analysis and result aggregation module 404 aggregates the results of the comprehensive test result set to obtain the verification output set, which is used to: count the total number of test cases and the number of executions for each security domain based on the comprehensive test result set; calculate the test coverage ratio for each security domain based on the total number of test cases and the number of executions for each security domain; and perform an average calculation on the test coverage ratios for each security domain to obtain the test coverage.

[0115] In some embodiments, the verification output set includes vulnerability location information; the feature analysis and result aggregation module 404 aggregates the results of the comprehensive test result set to obtain the verification output set, which is used to: determine the vulnerability location information based on the resource identifiers of the security vulnerability candidates in the comprehensive test result set, wherein the resource identifiers include file path, interface port number and firmware version number.

[0116] In some embodiments, the verification output set includes a security risk level; the feature analysis and result aggregation module 404 aggregates the results of the comprehensive test result set to obtain the verification output set, which is used to: calculate the score value and weight of each security indicator based on the comprehensive test result set, and obtain the security risk level value by weighted summation; and determine the security risk level based on the security risk level value.

[0117] For a description of the features in the embodiment corresponding to the security testing device for the baseboard management controller, please refer to the relevant description of the embodiment corresponding to the security testing method for the baseboard management controller, which will not be repeated here.

[0118] like Figure 5 As shown, embodiments of this application also provide an electronic device, including a memory 501 and a processor 502. The memory 501 stores a computer program, and the processor 502 is configured to run the computer program to perform the steps in any of the above-described embodiments of the security testing method for a baseboard management controller.

[0119] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the security testing method for a baseboard management controller.

[0120] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0121] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the security testing method for a baseboard management controller.

[0122] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the security testing method for a baseboard management controller.

[0123] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-chip (SoC), a complex programmable logic device (CPLD), a microcontroller unit (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0124] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0125] The foregoing has provided a detailed description of a security testing and electronic device for a baseboard management controller provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A security testing method for a baseboard management controller, characterized in that, include: The security scheme of the baseboard management controller is mapped in multiple domains to obtain a set of hierarchical test objects classified according to different security domains; Each layer of test object set includes test objects extracted from the security scheme of the corresponding security domain; An attack path is constructed, and the attack path is instantiated to obtain an interactive scenario sample under a preset test environment; the attack path includes test objects of at least two of the layered test object sets; Based on the interaction scenario samples, perform multi-dimensional cross-domain tests to obtain an interaction test dataset; the multi-dimensional cross-domain tests include remote firmware upgrade operations and cross-domain access control interactions; the interaction test dataset includes the execution data stream of the multi-dimensional cross-domain tests, as well as the actual response and the expected response; The actual response is based on the actual handling result of the security scheme when abnormal loads are implanted into the execution data stream, and the expected response is based on the expected handling result of the security scheme when abnormal loads are implanted into the execution data stream. Feature analysis and result aggregation are performed on the interactive test dataset to obtain a verification output set; the verification output set is used to evaluate the protection effect of the security scheme in the preset test environment.

2. The method according to claim 1, characterized in that, The security scheme for the baseboard management controller is mapped in a multi-domain layered manner to obtain a set of layered test objects categorized according to different security domains, including: Obtain the security configuration information of the baseboard management controller; The security configuration information is standardized to obtain an initial test dataset; wherein the standardization process includes at least one of time synchronization, format unification, and missing value completion; Based on the initial test dataset, the security scheme is mapped in a multi-domain manner to obtain the hierarchical test object set.

3. The method according to claim 2, characterized in that, The step of performing multi-domain hierarchical mapping on the security scheme based on the initial test dataset to obtain the hierarchical test object set includes: Based on the initial test dataset, a hierarchical domain testing framework is constructed; the hierarchical domain testing framework uses different security domains as rows and at least one of the following as columns: configuration items, management interfaces, operation events, and expected responses. The security scheme is mapped to multiple domains according to the layered domain testing framework to obtain the layered test object set; each test object in the layered test object set includes an attack entry object that can form an attack path, an intermediate verification object, a controlled target resource, the relationship between objects, and a preset potential damage level.

4. The method according to claim 3, characterized in that, The construction of the attack path, and the instantiation of the attack path to obtain interactive scenario samples in a preset test environment, includes: The attack path is formed by connecting the attack entry object, intermediate verification object, and controlled target resource contained in the test object. The attack path is instantiated based on the relationships between the objects to obtain the interaction scenario sample.

5. The method according to claim 1, characterized in that, The step of performing multi-dimensional cross-domain testing based on the interaction scenario samples to obtain an interaction test dataset includes: The remote firmware upgrade operation is performed on the interactive scenario sample, and the entire process event data is collected to obtain an upgrade trigger dataset; the upgrade trigger dataset is used to describe the firmware upgrade request and execution result of the remote firmware upgrade operation; The upgrade trigger dataset is subjected to cross-domain access control interaction to obtain the execution data stream; The abnormal payload is implanted into the execution data stream to determine the actual response and the expected response, thereby obtaining the interactive test dataset.

6. The method according to claim 5, characterized in that, The execution of cross-domain access control interaction on the upgrade trigger dataset to obtain the execution data stream includes: Based on the event identifier of the remote firmware upgrade operation in the upgrade trigger dataset, the firmware verification domain and the permission management domain are associated, and collaborative control, logical verification and permission check are triggered. The collaborative management results, logical verification results, and permission verification results are associated with timestamps to generate the execution data stream.

7. The method according to claim 5, characterized in that, The process of injecting an abnormal payload into the execution data stream, determining the actual response and the expected response, and obtaining the interaction test dataset includes: In the preset test environment, the abnormal payload is injected into the execution data stream to simulate different attack scenarios; the abnormal payload includes at least one of the following: illegal signature firmware, version rollback instruction, unauthorized credentials, session replay message, and malformed interface parameters. Determine the actual response of the baseboard management controller to the execution data stream implanted with abnormal payloads under different attack scenarios, based on the security scheme; In cases where the actual response differs from the expected response, security vulnerability candidates are generated. The interaction test dataset is obtained by summarizing the execution data stream of the interaction scenario samples, the security vulnerability candidates, and the expected response.

8. The method according to claim 1, characterized in that, The step of performing feature analysis and result aggregation on the interactive test dataset to obtain a verification output set includes: Feature analysis is performed on the interactive test dataset to obtain a comprehensive test result set; the comprehensive test result set includes at least one of the following: interactive scenario execution results, exception types, evidence logs, and security vulnerability candidates. Based on the interaction scenario samples and different security domains, the comprehensive test result set is aggregated to obtain the verification output set; the verification output set includes at least one of the following: test coverage, vulnerability location information, and security risk level.

9. The method according to claim 8, characterized in that, The feature analysis of the interactive test dataset yields a comprehensive test result set, including: Consistency analysis and security feature extraction are performed on the interactive test dataset to verify event time synchronization and identify unauthorized behavior. Various test results are extracted from each security domain to obtain the comprehensive test result set.

10. The method according to claim 8, characterized in that, The feature analysis of the interactive test dataset yields a comprehensive test result set, including: The timestamps and log sequences of cross-domain interaction events in the interaction test dataset are compared to verify the synchronization of the events. Determine whether there are any missing, out-of-order, or abnormally delayed processing steps for the same cross-domain interaction event; Based on the deviation between the abnormal implanted response and the expected response in the interactive test dataset, abnormal security behaviors are identified. The integrated feature analysis results are used to generate the comprehensive test result set.

11. The method according to claim 8, characterized in that, The aggregation of the comprehensive test result set to obtain the verification output set includes: The comprehensive test result set is integrated and calculated to statistically analyze the test coverage and vulnerability location information of each security domain, and to calculate the security risk level.

12. The method according to claim 8, characterized in that, The verification output set includes test coverage; The aggregation of the comprehensive test result set to obtain the verification output set includes: Based on the comprehensive test result set, the total number of test cases and the number of executions for each security domain are counted. Calculate the test coverage ratio of each security domain based on the total number of test cases and the number of executions in each security domain; The average test coverage ratio of each security domain is calculated to obtain the test coverage range.

13. The method according to claim 8, characterized in that, The verification output set includes vulnerability location information; The aggregation of the comprehensive test result set to obtain the verification output set includes: Based on the resource identifiers of the security vulnerability candidates in the comprehensive test result set, the vulnerability location information is determined. The resource identifiers include file path, interface port number, and firmware version number.

14. The method according to claim 8, characterized in that, The verification output set includes security risk levels; The aggregation of the comprehensive test result set to obtain the verification output set includes: Based on the comprehensive test result set, the score and weight of each safety indicator are calculated, and the safety risk level value is obtained by weighted summation. The security risk level is determined based on the security risk level value.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the security testing method for the baseboard management controller as described in any one of claims 1 to 14 when executing the computer program.

Images