A security test method based on an IT support core BOSS system
By constructing a security testing methodology for the core IT support BOSS system, we achieved full-process coverage and early intervention, solved the problem of incomplete security testing, improved testing efficiency and accuracy, and ensured the continuous improvement of the system's security level.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SI-TECH INFORMATION TECH CO LTD
- Filing Date
- 2025-12-29
- Publication Date
- 2026-05-29
Smart Images

Figure CN122111834A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of security testing technology, specifically a security testing method based on an IT support core BOSS system. Background Technology
[0002] With the vigorous expansion of government and enterprise businesses and the shift to an integrated operation, installation, and maintenance management approach, especially with the nationwide broadcasting network and 5G services becoming key initiatives within the broadcasting system, the rapid development of these businesses is supported by BOSS upgrades. This has placed higher demands on the security of the operation and management system. Security testing needs are also gradually increasing, and the complexity of systems is growing. The comprehensiveness and realism of security testing have become prerequisites for evaluating system capabilities and assisting in system optimization and improvement. Security testing and analysis are not new issues in the software industry. However, as business data becomes increasingly complex and its scope expands, system security risks and optimizations will inevitably increase, placing higher demands on software systems. Early and routine testing becomes essential, as discovering various software quality issues only at the end of a project will lead to higher repair costs.
[0003] In conclusion, implementing security testing systematically to expose security risks as early as possible has become an urgent issue to be addressed. Summary of the Invention
[0004] To address the problems in existing technologies, this invention provides a security testing method based on an IT support core BOSS system.
[0005] The technical solution adopted by this invention to solve its technical problem is: a security testing method based on an IT support core BOSS system, comprising the following closed-loop iterative process: Security testing preparation: Based on the software security requirements of the IT support core BOSS system upgrade project, complete the systematic planning of the test environment, test tools and test data; Test objectives and constraints: Based on the overall project design, construct a security test objective system covering the code layer, application system layer, server resource layer, and core function layer, clarify the test constraints and prerequisites, and synchronize them with all project stakeholders; Multi-dimensional testing methodology design: Constructing a verification system that includes code security testing, application and server security testing, and core module security testing; Full-process test management: Execute test design, environment preparation, functional verification, security testing, test monitoring, result recording, result analysis, and result submission according to preset steps, and iterate and repeat security testing until result submission based on the analysis results, so as to realize the full life cycle management of system security risks.
[0006] The beneficial effects of this invention are as follows: This invention improves the coverage of security testing types and the completeness of test cases after deployment in BOSS cloud upgrade projects. Through different levels of security testing, combined with test scenario design, the security test scenario coverage reaches 100%. Increased complexity in security testing reduces rework time, improves work efficiency, and effectively verifies the compliance of security design requirements. Test accuracy is greatly improved. Relying on iterative combinations of security test scenarios, after all test scenarios pass, the accuracy of security design requirements is ensured to reach 100%. The system security level and risk degree can be effectively assessed, providing the project team with decision-making basis and risk management strategies. The system's security can be quantitatively assessed, thereby enabling the formulation of corresponding management strategies and control measures. Attached Figure Description
[0007] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0008] Figure 1 The flowchart of the entire test management process provided by this invention; Figure 2 The overall method closed-loop iterative flowchart provided by this invention; Figure 3 The test execution and repair loop diagram provided for this invention. Detailed Implementation
[0009] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.
[0010] like Figure 1 - Figure 3 As shown, the security testing method based on the IT support core BOSS system of this invention includes the following closed-loop iterative process: Security testing preparation: Based on the software security requirements of the IT support core BOSS system upgrade project, complete the systematic planning of the test environment, test tools and test data; Test objectives and constraints: Based on the overall project design, construct a security test objective system covering the code layer, application system layer, server resource layer, and core function layer, clarify the test constraints and prerequisites, and synchronize them with all project stakeholders; Multi-dimensional testing methodology design: Constructing a verification system that includes code security testing, application and server security testing, and core module security testing; Full-process test management: Execute test design, environment preparation, functional verification, security testing, test monitoring, result recording, result analysis, and result submission according to preset steps, and iterate and repeat security testing until result submission based on the analysis results, so as to realize the full life cycle management of system security risks.
[0011] By introducing a structured and iterative security testing process throughout the project lifecycle, security risk identification, verification, remediation, and re-verification are organically embedded into the entire system development and delivery process, thereby enabling the continuous discovery and gradual convergence of system security risks.
[0012] This method first systematically prepares the test environment, testing tools, and test data before testing begins, ensuring the security tests have the necessary foundation for execution. Then, based on the overall system design and business architecture, it constructs a security testing target system covering the code layer, application system layer, server resource layer, and core business function layer, simultaneously defining the constraints and prerequisites for security testing to ensure testing activities are initiated at the appropriate development stage and conducted under compliance. During the test execution phase, a multi-dimensional security testing methodology is designed, dividing security testing into three levels: code security testing, application and server security testing, and core module security testing. Static analysis, penetration testing, and interactive verification of business scenarios are employed to address the security risk characteristics at each level, achieving comprehensive coverage of system security issues. In terms of test management, this method uses a unified, end-to-end test management mechanism to systematically manage test design, environment preparation, functional verification, security test execution, process monitoring, result recording, result analysis, and result submission. After each round of testing, the analysis results drive adjustments and regression testing for the next round, achieving closed-loop iteration of the testing process and thus enabling full lifecycle control of system security risks.
[0013] First, by unifying the planning of the testing environment, tools, and data during the security testing preparation phase, the testing environment maintains a high degree of consistency with the production environment in terms of architecture and configuration. This significantly improves the realism and reliability of security vulnerability reproduction, preventing test results from becoming disconnected from the actual operating environment. Second, by constructing a multi-level, multi-dimensional security testing objective system, security testing expands from a single technical perspective to the business process and system architecture levels. This not only enables the discovery of traditional technical vulnerabilities but also effectively identifies business security issues with a greater impact on the core BOSS system, such as unauthorized access and business logic bypassing.
[0014] Furthermore, by introducing clear testing constraints and prerequisites, security testing is closely integrated with the development schedule, requiring developers to consider the initiation requirements of security testing during the development phase. This promotes the forward shift of security testing requirements and reduces the time and cost risks associated with concentrated rectification of security issues later in the system.
[0015] Furthermore, by implementing full-process test management and iterative testing mechanisms, test results can form traceable and auditable security test records, and the priority of remediation can be reasonably ranked based on the severity level of vulnerabilities, thereby improving the ability of project stakeholders to judge security risks when making system launch decisions.
[0016] Finally, by continuously optimizing the testing focus, test cases, tool configurations, and testing processes through multiple rounds of testing, and forming a testing experience library, this method is not only applicable to a single project, but can also provide a standardized reference for the security testing of similar IT support core BOSS systems in the future, demonstrating good reusability and promotional value.
[0017] First, a test environment identical to the production environment is built based on the system's deployment architecture, and the corresponding application servers, databases, middleware, and network topology are configured. Simultaneously, security testing tools covering code auditing, vulnerability scanning, and penetration testing scenarios are selected, and anonymized simulated business data and boundary data used to trigger abnormal scenarios are prepared to meet test execution and data compliance requirements.
[0018] During the test objective setting phase, based on the BOSS system's business processes and data flow paths, potential security risks are analyzed to formulate security test objectives covering the code layer, application system layer, server resource layer, and core business modules. The development progress thresholds, code completion requirements, and environment readiness standards to be met before test initiation are clearly defined. Simultaneously, test permission configuration, data anonymization status, and the completeness of interface documentation are confirmed as prerequisites for testing, ensuring coordinated development and testing activities.
[0019] During the testing process, code security testing is first conducted on the modules that have been coded during the development phase. The source code is scanned and inspected using static code analysis tools in conjunction with manual auditing to promptly identify and fix security issues such as missing input validation, SQL injection, and improper access control. Regression testing is then performed after the fixes to ensure that security defects at the code level are effectively eliminated.
[0020] Subsequently, application and server security tests were conducted while the system was running. By simulating hacker attacks, the web interface, server ports, system configuration, and access control were verified. The vulnerability trigger paths, impact scope, and exploitation conditions were recorded, and vulnerability exploitation reports and remediation recommendations were generated.
[0021] Based on this, security testing was conducted on the core business modules of the system. By simulating real user operation scenarios, interactive verification was performed on user authorization processes, session management, data transmission, and the integrity of business logic. The focus was on checking for security risks such as unauthorized access, session hijacking, or business process bypass.
[0022] Throughout the testing process, the testing progress and system operation status were monitored in real time. If any test anomalies or system failures occurred, the established emergency handling procedures were followed to sequentially complete fault location, root cause analysis, temporary repairs, and solution optimization, with the repair results synchronously updated into the test plan. After each round of testing, the test results were recorded and analyzed, and vulnerabilities were graded and assessed according to their severity. A security test report was then prepared and submitted to relevant project stakeholders. If system modifications were required, iterative and regression testing were conducted based on the modifications until the overall system security level met project requirements. Simultaneously, the experience and solutions accumulated during the testing process were compiled into a test experience library to provide a reference for security testing of similar systems in the future.
[0023] As a preferred technical solution, in the preparation of security testing, the test environment planning matches the deployment architecture of the IT support core BOSS system upgrade project, and the test tool selection covers core scenarios such as code auditing, vulnerability scanning, and penetration testing. The test data includes simulated business data and extreme boundary data, and all data meets data security compliance requirements.
[0024] The testing environment planning must be consistent with the deployment architecture of the core BOSS system upgrade project supported by IT. From hardware configuration and network topology to software version, it must fully match the production environment to ensure that the test scenarios are consistent with the real-world operating scenarios, avoiding test result distortion caused by environmental differences. The selection of testing tools must comprehensively cover the three core testing scenarios: code auditing, vulnerability scanning, and penetration testing, ensuring that the tool capabilities are precisely matched to the testing objectives, and that core testing tasks can be completed without the need for additional tools. Test data preparation must balance comprehensiveness and compliance, including simulated business data that mimics real business processes, as well as extreme boundary data covering abnormal input scenarios. All data must undergo anonymization and other processing to meet relevant data security compliance requirements, ensuring the authenticity of the tests while mitigating the risk of data leakage.
[0025] By configuring the test and production environments identically, we ensure that test results accurately reflect the actual security status of the system, effectively avoiding the common problem of "tests passing but vulnerabilities still existing in the production environment." Comprehensive coverage of core scenarios by the testing tools reduces the time cost of tool switching and replenishment, significantly improving testing efficiency. Test data encompasses multiple scenarios, including normal, abnormal, and boundary scenarios, ensuring that test cases comprehensively verify system security performance and enhancing test effectiveness. Simultaneously, the data compliance processing mechanism effectively mitigates data security risks during testing, guaranteeing the legal and compliant conduct of project testing.
[0026] In terms of test environment planning, a test environment completely identical to the production environment was built, configured with three 2-core 8GB ECS instances, two MySQL databases using a master-slave replication architecture, and one Nginx load balancer. The network topology adopts a layered architecture of "public network → load balancer → application server → database server," consistent with the production environment. Regarding test tool selection, SonarQube 9.9 was chosen as the code auditing tool, supporting vulnerability detection in multiple languages such as Java and Python; Nessus 10.1 was chosen as the vulnerability scanning tool, covering server port and system configuration vulnerability detection; and Metaspatial was chosen as the testing tool. loitFramework 6.0, as a penetration testing tool, supports SQL injection, XSS, and other attack simulations, comprehensively covering core testing scenarios. Regarding test data preparation, it generates 50,000 simulated data entries containing user names, anonymized mobile phone numbers, payment amounts, and business types, simulating normal business scenarios such as user account opening, payment, and account cancellation. It also prepares extreme boundary data including extremely long strings containing 1000 special characters, null values, SQL injection special characters, and amounts exceeding the billing range. All sensitive user information is processed using professional anonymization tools. The test data is used only for this test and is automatically destroyed after the test, strictly meeting data security compliance requirements.
[0027] As a preferred technical solution, in the step test target setting and constraints, the construction of the security test target system is combined with the business processes, data flow paths and potential security risk points of the IT support core BOSS system; Constraints include development progress thresholds for test initiation, code completion requirements, and environment readiness standards; Prerequisites include test permission configuration, data anonymization completed, and API documentation confirmed; Developers formulate development plans based on constraints, embed security testing requirements into the development process, and meet test initiation requirements through phased deliverables, thereby achieving collaborative progress between development and testing.
[0028] The construction of a security testing target system must be closely integrated with the business processes, data flow paths, and potential security risks of the core IT support BOSS system. For key business processes such as user account opening, billing, and invoice inquiries, the flow path of user data from the application layer to the database layer, and common risks in historical projects such as weak passwords and SQL injection, test targets must be precisely set to ensure a high degree of alignment between testing and business needs and risk control requirements. Constraints should clearly define the core thresholds for test initiation, including development progress thresholds, code completion requirements, and environment readiness standards, to avoid ineffective testing due to premature initiation. Prerequisites should clearly define the basic guarantees for test execution, including test permission configuration, data anonymization completion, and interface documentation confirmation, to ensure smooth test execution. Simultaneously, developers should embed constraints into the development plan, achieving deep integration of testing requirements and development processes through phased deliverables after the completion of core modules, forming a closed-loop collaborative mechanism of "development-testing" to avoid a disconnect between testing and development.
[0029] The deep integration of test objectives with business processes and risk points effectively avoids setting invalid objectives that are irrelevant to the business, significantly improving test relevance; the clear definition of constraints and preconditions reduces test interruptions or distorted results due to insufficient preparation, ensuring a smooth testing process; the collaborative advancement mechanism between development and testing enables early intervention and incremental development of testing work, exposing security vulnerabilities in advance and significantly reducing vulnerability remediation costs; at the same time, the synchronized understanding of objectives and constraints by all relevant parties avoids project progress obstacles caused by cognitive biases, improving overall project progress efficiency.
[0030] In terms of building a security testing target system, the following objectives were set: "Preventing bypass of user identity verification" and "Preventing tampering of package information" in conjunction with the 5G package account opening process; "Hierarchical control of dedicated line permissions" in conjunction with the dedicated line management process for government and enterprise customers; "Encrypted verification of data transmission" for the flow path of user payment data from the application layer to the database layer; and "Clearing weak server passwords" and "Preventing SQL injection into input boxes" in conjunction with common vulnerabilities in historical projects. Regarding the definition of constraints and prerequisites, the constraints were clearly defined as 80% completion of development progress, completion of all core module coding, and network connectivity and normal service startup in the test environment. The prerequisites were that test accounts were granted only the minimum necessary permissions, sensitive user data was anonymized, and interface documents were confirmed and signed by both the development and testing teams. In terms of development and testing collaboration, the development team formulated an iterative development plan based on the constraints. Each completed core module was simultaneously submitted to the testing team for incremental testing. When the testing team discovered vulnerabilities such as flaws in user identity verification logic, they immediately provided feedback to the development team, which responded and fixed them within one business day. This achieved efficient closed-loop collaboration between development and testing, avoiding the passive situation of concentrated vulnerability fixing at the end of the project.
[0031] As a preferred technical solution, code security testing employs a combination of static code analysis tools and manual auditing to perform a full scan of the application source code of the core IT support BOSS system, focusing on detecting security issues such as missing input validation, buffer overflows, SQL injection vulnerabilities, cross-site scripting vulnerabilities, improper access control, and code logic defects. Code security testing is introduced early in the development phase, with incremental testing performed on completed modules. Security issues are promptly reported to developers for fixes, and regression testing is executed after fixes are completed to ensure that security vulnerabilities at the code level are eliminated.
[0032] In terms of testing methods, the automated advantages of static code analysis tools and the refined advantages of manual auditing are combined. Static code analysis tools can quickly scan the entire code and efficiently cover common security defects such as syntax vulnerabilities and unvalidated input. Manual auditing, on the other hand, conducts refined checks on the complex business logic of core modules such as billing and access control, making up for the tool's inadequacy in identifying complex logic vulnerabilities. In terms of testing timing, we break away from the traditional model of concentrated testing at the end of a project and intervene early in the development phase. Testing is carried out immediately after the module coding is completed, so as to achieve "early detection and early fix" of security vulnerabilities. In terms of testing process, we adopt a combination of incremental testing and regression testing. Incremental testing is carried out on modules after the coding is completed to avoid the waste of efficiency caused by repeated testing of the entire code. Regression testing is performed immediately after the vulnerability is fixed to ensure that the fix is effective and no new vulnerabilities are introduced, so as to achieve the goal of eliminating security vulnerabilities at the code level.
[0033] The complementary advantages of automated tools and manual auditing not only improve the efficiency of code vulnerability identification but also ensure its accuracy, effectively avoiding the problems of "tools missing detections and manual inefficiency." Early intervention in the development phase significantly reduces the cost of vulnerability remediation, avoiding project delays and increased costs caused by concentrated remediation at the end of the project. Incremental testing mode significantly improves testing efficiency, while regression testing ensures the thoroughness of vulnerability remediation, ultimately achieving zero high-risk vulnerabilities at the code level and controlling the proportion of medium and low-risk vulnerabilities to an extremely low level. At the same time, the test covers multiple types of code security issues such as missing input validation, buffer overflows, and SQL injection, comprehensively improving the system's code security baseline.
[0034] In terms of testing configuration, SonarQube 9.9 was selected as the static code analysis tool, and a Java language rule set containing 120 security rules, including SQL injection, XSS, and improper access control, was enabled. A human auditing team consisting of two senior Java developers and one security test engineer was also formed, focusing on the complex business logic of the billing and settlement module and the access control module. Regarding testing timing and process, the development team submitted the user management module for testing immediately after completing the code. SonarQube quickly scanned and found three low-risk input length limitation vulnerabilities and one medium-risk missing permission verification logic vulnerability. The manual audit team conducted a detailed inspection of the authentication logic of this module and discovered a high-risk vulnerability where the user ID parameter could be tampered with, leading to unauthorized queries. After receiving the vulnerability feedback, the development team quickly took remedial measures, including setting the input length limit to 50 characters, supplementing the permission verification logic, and encrypting the user ID parameter. After the remediation was completed, the testing team used the same tools to scan and perform regression testing with the manual audit plan, confirming that all vulnerabilities were fixed and no new vulnerabilities were introduced. Following the above process, the testing of core modules such as billing and settlement and access control was completed in sequence, ultimately achieving zero high-risk vulnerabilities at the code level, and the proportion of medium and low-risk vulnerabilities was less than 0.5%.
[0035] As a preferred technical solution, application and server security testing adopts penetration testing methods that simulate hacker attacks. Attack tests are carried out on the core IT support BOSS system applications and servers in operation. The testing scope includes web application interfaces, server ports, system configuration, permission management, and file operations. The focus is on detecting security vulnerabilities such as SQL injection, cross-site scripting (XSS), cross-site request forgery, file upload vulnerabilities, weak server passwords, and configuration file leakage. Before testing, clearly define the authorized scope and prohibited operations. During the testing process, adopt a progressive attack strategy, record the attack path, vulnerability triggering conditions and impact range in real time, and generate a vulnerability exploitation report and remediation suggestions after the test is completed.
[0036] In terms of testing methods, penetration testing is used to simulate hacker attacks, probing for exploitable security vulnerabilities from an external perspective, which is closer to real-world security risk scenarios than static testing. Regarding the testing scope, it precisely covers the main target areas for hacker attacks, such as web application interfaces, server ports, system configurations, access control, and file operations, avoiding blind spots. In terms of the testing process, it strictly follows the standardized process of "authorization-probing-exploitation-logging," clearly defining the authorized scope and prohibited operations before testing to prevent illegal testing and system damage. During testing, a progressively deeper attack strategy is adopted, from peripheral scanning to vulnerability detection and then to vulnerability exploitation, ensuring that the test is safe and controllable. In terms of result processing, attack paths, vulnerability triggering conditions, and impact scope are recorded in real time, generating vulnerability exploitation reports with detailed remediation suggestions, providing the development team with clear remediation guidelines.
[0037] The testing method, which simulates real hacker attacks, can accurately discover "practical vulnerabilities" in the runtime state. These vulnerabilities are often difficult to identify through static testing such as code scanning, effectively improving the practical capabilities of system security protection. The testing scope focuses on the critical parts of the application and server, ensuring that testing resources are concentrated on high-risk areas and improving the targeting of the tests. The standardized testing process not only avoids accidental damage to the system during testing but also ensures the legality and compliance of the testing process. Detailed vulnerability records and remediation suggestions reduce the cost of vulnerability location and remediation for the development team and improve the efficiency and accuracy of vulnerability remediation.
[0038] The testing authorization scope was clearly defined as the system's web application and three ECS servers. Prohibited operations included prohibiting modification of database data and initiating DoS attacks. During the testing process, a perimeter scan was first performed using the Nessus tool, which revealed that port 8080 was open and had a weak Tomcat password vulnerability (username admin, password 123456). Subsequently, SQL injection statements such as "or 1= 1--" were attempted to be entered into the web application's billing query interface. It was found that the interface did not perform input filtering and could query all user bills. Finally, by logging into the server management backend using the weak Tomcat password, a malicious JSP script was uploaded. It was found that the file upload function did not perform type validation and could be uploaded successfully. During the testing process, the testing team recorded the attack path, vulnerability triggering conditions, and impact scope in real time. After the testing was completed, a detailed remediation suggestion was generated. After the development team implemented the vulnerability remediation based on the report, the testing team conducted regression testing to confirm that all vulnerabilities had been remediated and the application and server security baselines met the standards.
[0039] As a preferred technical solution, core module security testing simulates real user operation scenarios to conduct interactive testing on the core business modules of the IT support core BOSS system. The test content includes input verification mechanism, user authorization process, session creation and destruction, data encryption transmission, and business logic integrity, with a focus on detecting security vulnerabilities such as unauthorized access, session hijacking, data tampering, and business process bypass. The test steps are designed based on business scenario test cases, covering scenarios such as normal operation, abnormal input, boundary conditions, and concurrent access. The test results are accurate and comprehensive by combining automated testing tools with manual verification.
[0040] In terms of test scenario design, the tests simulate real-world user actions such as login, inquiry, and payment to ensure that the tests are aligned with actual business needs rather than simply scanning for technical vulnerabilities. Regarding test content, the tests target key security points in core modules such as input validation mechanisms, user authorization processes, session creation and destruction, encrypted data transmission, and business logic integrity—areas most prone to security risks within the business process. In terms of scenario coverage, the tests comprehensively include various scenarios such as normal operation, abnormal input, boundary conditions, and concurrent access, avoiding the omission of vulnerabilities due to testing only one scenario. In terms of testing methods, the tests combine the advantages of automated testing and manual verification. Automated testing tools improve the efficiency of testing batch scenarios, while manual verification accurately detects complex business logic vulnerabilities such as billing errors caused by concurrent access, ensuring accurate and comprehensive test results.
[0041] Simulating real user interaction test scenarios effectively uncovers "business logic vulnerabilities" in business processes. These vulnerabilities often cannot be identified through code scanning or penetration testing, filling a gap in traditional testing. Comprehensive scenario coverage ensures no blind spots in core modules, especially accurately identifying vulnerabilities in extreme scenarios such as abnormal input and concurrent access. The complementary advantages of automated and manual testing guarantee both testing efficiency and the accuracy of identifying complex business logic vulnerabilities, avoiding the problem of "automated testing missing complex logic and manual testing being inefficient." Simultaneously, testing focuses on core business modules, ensuring the security and stability of critical system functions and preventing significant economic losses and reputational damage caused by core business vulnerabilities.
[0042] As a preferred technical solution, the specific steps of full-process test management include: S1. Test Design: Based on the security requirements and test objectives of the IT support core BOSS system, formulate a test plan that includes test scope, test strategy, resource configuration, and time plan. Use a combination of equivalence class partitioning, boundary value analysis, and error guessing to write test cases that cover all security test points. Design test scenarios that include normal business scenarios, abnormal attack scenarios, and boundary extreme scenarios. Deliver the test plan, test cases, and test scenarios. S2. Environment Preparation: Set up a test environment that is identical to the production environment, configure the network topology, server parameters, application deployment version, and prepare anonymized test data. S3. Functional Verification: Conduct comprehensive verification of the network connectivity, application service availability, data access validity, and interface call correctness of the test environment to ensure that the test environment meets the conditions for security test execution. S4. Security Testing: Based on test cases and test scenarios, execute code security testing, application and server security testing, and core module security testing in sequence, and record the test execution process and real-time results. S5. Test Monitoring: Establish a real-time monitoring mechanism for the test process to dynamically track test progress, resource usage, and vulnerability triggering. If an abnormal test environment, test tool failure, or system anomaly caused by a security vulnerability occurs, initiate an emergency handling process that includes fault location, cause analysis, temporary repair, and solution optimization. Use a combination of log analysis, tool monitoring, and manual investigation to quickly locate the root cause of the problem and restore the test process. S6. Record test results: Based on the standardized test result recording template, record in detail the execution time, test scope, testers, vulnerability information, test operation steps, test logs and other information for each test to form a complete test record; S7. Analyze test results: Using a combination of quantitative and qualitative analysis methods, based on indicators such as vulnerability distribution, severity level percentage, and test coverage, analyze the rationality and effectiveness of the security design, and evaluate the overall security level and potential risk of the IT support core BOSS system. S8. Test Result Submission: Prepare a test report including test overview, test process, result analysis, risk assessment, and remediation suggestions, and submit it to the project stakeholders. Based on the conclusions of the test report, determine whether the system needs to be modified. If modification is required, adjust the test plan and test scheme. S9. Iterative Testing: Repeat steps S4 to S8, design additional test cases for the modified parts of the system and focus on regression testing, summarize testing experience and optimize the test plan until the system security level meets the project requirements.
[0043] The testing process is broken down into nine sequentially linked steps, each with clearly defined core tasks and deliverables, forming a complete chain of "test design – environment preparation – functional verification – security testing – test monitoring – result recording – result analysis – result submission – iterative testing". The preceding steps provide foundational support for subsequent steps: test design provides test case support for test execution; environment preparation provides environmental support for test execution; and functional verification ensures the test environment meets execution requirements. The test monitoring step tracks test progress, resource usage, and vulnerability triggering in real time, promptly handling test anomalies and ensuring test stability. The result recording and analysis step provides data support for project decision-making, assessing system security level and risk severity by meticulously recording the test process and results, combined with quantitative and qualitative analysis methods. The iterative testing step continuously optimizes based on test results, repeatedly executing the "security testing – result submission" step to supplement testing on modified parts of the system, ensuring effective vulnerability patching without introducing new vulnerabilities, and achieving continuous improvement in system security level.
[0044] The standardized execution of steps completely solves the problems of "chaotic processes and lack of rules" in traditional testing, significantly improving the controllability and standardization of the testing process. The close connection and dependency between steps ensure the smooth progress of the testing process and avoid test interruptions caused by insufficient preparation of previous steps. The traceability mechanism of the whole process, through clear deliverables and execution results, meets the requirements of project audit and compliance, and facilitates the tracing of problems. The iterative testing mechanism ensures the "closed-loop repair" of security vulnerabilities, continuously optimizes the test plan and system security performance until the system security level meets the project requirements, effectively improving the overall quality of system security testing.
[0045] As a preferred technical solution, the severity level of vulnerabilities is divided into four levels: critical, high-risk, medium-risk, and low-risk. The classification is based on the ease with which the vulnerability can be exploited, the scope of its impact, and the severity of the damage caused. Different levels of vulnerabilities correspond to different remediation priorities and regression testing requirements.
[0046] The standardized execution of steps completely solves the problems of "chaotic processes and lack of rules" in traditional testing, significantly improving the controllability and standardization of the testing process. The close connection and dependency between steps ensure the smooth progress of the testing process and avoid test interruptions caused by insufficient preparation of previous steps. The traceability mechanism of the whole process, through clear deliverables and execution results, meets the requirements of project audit and compliance, and facilitates the tracing of problems. The iterative testing mechanism ensures the "closed-loop repair" of security vulnerabilities, continuously optimizes the test plan and system security performance until the system security level meets the project requirements, effectively improving the overall quality of system security testing.
[0047] Clear vulnerability classification standards avoid the waste of resources or the omission of high-risk vulnerabilities caused by treating all vulnerabilities the same way, ensuring that testing and remediation resources are concentrated on key risk points; differentiated remediation priorities ensure that high-risk vulnerabilities can be responded to and remediated quickly, significantly reducing the risk of system attacks; differentiated regression testing requirements, while ensuring core security, avoid the extended testing cycle caused by full regression testing, thus improving testing efficiency; and quantified classification criteria provide precise data support for the project team to assess system security risks, facilitating the project team to make scientific and reasonable risk management decisions.
[0048] As the preferred technical solution, the emergency response process involves four steps: fault location, cause analysis, temporary repair, and solution optimization. This ensures that the testing process can be quickly resumed after an interruption, and the repair solution is updated in the test solution document to provide a reference for subsequent tests.
[0049] In terms of process execution, a logical progression is followed. First, fault location is determined by combining log analysis, tool monitoring, and manual investigation to identify the type and location of the anomaly. Next, the root cause of the anomaly is analyzed in depth to provide a basis for repair. Then, temporary repair measures are taken to quickly restore the testing process and reduce test interruption time. Finally, the test plan is optimized, and the repair experience is recorded in the test documentation. In terms of experience recording, the temporary repair plan is updated to the test plan document to form an experience reuse mechanism, providing a reference for subsequent tests and avoiding test interruptions caused by the recurrence of similar anomalies.
[0050] The four-step closed-loop emergency response process ensures that anomalies during testing can be resolved quickly and systematically, significantly reducing test downtime and improving testing efficiency. Fault localization employs a combination of logs, tools, and manual intervention, improving the accuracy of problem identification and avoiding wasted time due to blind troubleshooting. Repair solutions are documented in test files, enabling effective reuse of experience and reducing the anomaly rate in subsequent tests. The entire emergency response process ensures the stability and controllability of the testing process, preventing distorted test results or project delays caused by improper anomaly handling.
[0051] During application and server security testing, the penetration testing tool Metasploit suddenly became unable to connect to the test server, causing the testing process to be interrupted. Based on this claim, the following emergency handling was implemented: First, fault localization was performed. The testing team checked the server's ` / var / log / secure` logs and found a large number of SSH connection failure records. Using Zabbix monitoring, the server's CPU usage was observed to be at 95%. Manual login to the server confirmed that the high number of concurrent connections from the tool was causing the server's SSH service to be temporarily unavailable. Further analysis revealed that Metasploit's default concurrent connection limit was set to 50, exceeding the test server's maximum SSH connection limit of 30, leading to service overload. A temporary fix was then implemented: the `systemctl restartsshd` command was executed to restart the SSH service. After adjusting the Metasploit concurrent connection limit to 20 and re-initiating connections, the testing process quickly resumed. Finally, the solution was optimized. This emergency handling took only 40 minutes, the testing process quickly recovered, and the optimized solution did not exhibit similar problems in subsequent iterations of testing, effectively improving the stability of the testing process.
[0052] As a preferred technical solution, during the test case writing process, each security test point corresponds to at least one independent test case. The test case includes the test purpose, test prerequisites, test steps, expected results, and judgment criteria to ensure the repeatability of test execution and the objectivity of result judgment.
[0053] In terms of coverage principles, each security test point should correspond to at least one independent test case to avoid missing vulnerabilities caused by a single test case covering multiple test points, ensuring that test coverage is without blind spots. In terms of structural design, a standardized test case structure is adopted, which includes five core elements: test purpose, test prerequisites, test steps, expected results, and judgment criteria. This clarifies the test objectives, execution conditions, operation procedures, and judgment criteria, ensuring that test cases are "repeatable, verifiable, objective, and unambiguous," so that different testers can obtain consistent results when executing them.
[0054] The coverage principle of "one test point corresponds to one test case" ensures that each security test point is fully verified, avoiding test blind spots and vulnerability omissions. The standardized test case structure gives test cases a unified execution logic and judgment criteria, ensuring consistent operation when different testers execute tests, thus improving the consistency and repeatability of test results. Clear expected results and judgment criteria avoid subjective judgment of test results, ensuring the objectivity and accuracy of judgment results. At the same time, the standardized test case design facilitates the management, maintenance and reuse of test cases. Subsequent similar tests can directly reuse or modify the template, reducing the cost of test case design.
[0055] As a preferred technical solution, during the iterative testing process, the security testing plan is optimized from four dimensions: test focus, test cases, tool configuration, and process design, based on the test results. At the same time, a test experience library containing test experience, problem solutions, and optimization suggestions is formed, providing a standardized reference template for subsequent security testing of similar IT support core BOSS systems.
[0056] In terms of optimization mechanisms, based on the test results of each iteration, the test plan is dynamically optimized from four dimensions: adjusting the test focus to concentrate on core risk points, supplementing test cases to cover missed detection scenarios, optimizing tool configuration to improve vulnerability detection rate, and simplifying process design to improve test efficiency, ensuring that the test plan continuously adapts to the system security status. In terms of experience reuse mechanisms, the test experience (such as core risk points and efficient test methods), problem solutions (such as vulnerability repair ideas), and optimization suggestions (such as tool selection suggestions) from the iteration process are systematically organized into a standardized experience library, providing a reference for subsequent security testing of similar IT support core BOSS systems, and achieving standardization and efficiency in testing work.
[0057] The four-dimensional optimization mechanism ensures that the test plan can be dynamically adjusted according to the system security status, avoiding the inefficiency or missed detections caused by using the same solution for everything, and continuously improving the relevance and accuracy of the test. The accumulation of experience base enables the effective reuse of testing experience from similar projects, significantly reducing the design cost of subsequent test plans and shortening the project cycle. The continuously optimized test plan accelerates the improvement of the system security level, ensuring that the system can quickly meet security requirements. At the same time, the experience base accumulates valuable security testing assets for enterprises, forming a technical barrier and enhancing the enterprise's market competitiveness in similar projects.
[0058] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0059] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of protection claimed by the present invention. The scope of protection of the present invention is defined by the appended claims and their equivalents.
Claims
1. A security testing method based on an IT support core BOSS system, characterized in that: The process includes the following steps to form a closed-loop iteration: Security testing preparation: Based on the software security requirements of the IT support core BOSS system upgrade project, complete the systematic planning of the test environment, test tools and test data; Test objectives and constraints: Based on the overall project design, construct a security test objective system covering the code layer, application system layer, server resource layer, and core function layer, clarify the test constraints and prerequisites, and synchronize them with all project stakeholders; Multi-dimensional testing methodology design: Constructing a verification system that includes code security testing, application and server security testing, and core module security testing; Full-process test management: Execute test design, environment preparation, functional verification, security testing, test monitoring, result recording, result analysis, and result submission according to preset steps, and iterate and repeat security testing until result submission based on the analysis results, so as to realize the full life cycle management of system security risks.
2. The security testing method based on the IT support core BOSS system according to claim 1, characterized in that: In the security testing preparation, the test environment planning matches the deployment architecture of the IT support core BOSS system upgrade project, and the test tool selection covers core scenarios such as code auditing, vulnerability scanning, and penetration testing. The test data includes simulated business data and extreme boundary data, and all data meets data security compliance requirements.
3. The security testing method based on the IT support core BOSS system according to claim 1, characterized in that: In the steps of setting test objectives and constraints, the construction of the security test objective system is combined with the business processes, data flow paths and potential security risk points of the IT support core BOSS system; Constraints include development progress thresholds for test initiation, code completion requirements, and environment readiness standards; Prerequisites include test permission configuration, data anonymization completed, and API documentation confirmed; Developers formulate development plans based on the aforementioned constraints, embed security testing requirements into the development process, and meet test initiation requirements through phased deliverables, thereby achieving collaborative progress in development and testing.
4. The security testing method based on the IT support core BOSS system according to claim 1, characterized in that: The code security test employs a combination of static code analysis tools and manual auditing to perform a full scan of the application source code of the IT support core BOSS system, focusing on detecting security issues such as missing input validation, buffer overflows, SQL injection vulnerabilities, cross-site scripting vulnerabilities, improper access control, and code logic defects. Code security testing is introduced early in the development phase, with incremental testing performed on completed modules. Security issues are promptly reported to developers for fixes, and regression testing is executed after fixes are completed to ensure that security vulnerabilities at the code level are eliminated.
5. A security testing method based on an IT support core BOSS system according to claim 3, characterized in that: The application and server security tests employ penetration testing methods that simulate hacker attacks. Attack tests are conducted on the IT support core BOSS system applications and servers in operation. The test scope includes web application interfaces, server ports, system configurations, permission management, and file operations. The focus is on detecting SQL injection, cross-site scripting, cross-site request forgery, file upload vulnerabilities, weak server passwords, and configuration file leakage security vulnerabilities. Before testing, clearly define the authorized scope and prohibited operations. During the testing process, adopt a progressive attack strategy, record the attack path, vulnerability triggering conditions and impact range in real time, and generate a vulnerability exploitation report and remediation suggestions after the test is completed.
6. A security testing method based on an IT support core BOSS system according to claim 5, characterized in that: The core module security test simulates real user operation scenarios to conduct interactive tests on the core business modules of the IT support core BOSS system. The test content includes input verification mechanism, user authorization process, session creation and destruction, data encryption transmission, and business logic integrity. The focus is on detecting security vulnerabilities such as unauthorized access, session hijacking, data tampering, and business process bypass. The test steps are designed based on business scenario test cases, covering normal operation, abnormal input, boundary conditions, and concurrent access scenarios. The test results are accurate and comprehensive by combining automated testing tools with manual verification.
7. A security testing method based on an IT support core BOSS system according to claim 1, characterized in that: The specific steps of the full-process test management include: S1. Test Design: Based on the security requirements and test objectives of the IT support core BOSS system, formulate a test plan that includes test scope, test strategy, resource configuration, and time plan. Use a combination of equivalence class partitioning, boundary value analysis, and error guessing to write test cases that cover all security test points. Design test scenarios that include normal business scenarios, abnormal attack scenarios, and boundary extreme scenarios. Deliver the test plan, test cases, and test scenarios. S2. Environment Preparation: Set up a test environment that is identical to the production environment, configure the network topology, server parameters, application deployment version, and prepare anonymized test data. S3. Functional Verification: Conduct comprehensive verification of the network connectivity, application service availability, data access validity, and interface call correctness of the test environment to ensure that the test environment meets the conditions for security test execution. S4. Security Testing: Based on test cases and test scenarios, execute code security testing, application and server security testing, and core module security testing in sequence, and record the test execution process and real-time results. S5. Test Monitoring: Establish a real-time monitoring mechanism for the test process to dynamically track test progress, resource usage, and vulnerability triggering. If an abnormal test environment, test tool failure, or system anomaly caused by a security vulnerability occurs, initiate an emergency handling process that includes fault location, cause analysis, temporary repair, and solution optimization. Use a combination of log analysis, tool monitoring, and manual investigation to quickly locate the root cause of the problem and restore the test process. S6. Record test results: Based on the standardized test result recording template, record in detail the execution time, test scope, testers, vulnerability information, test operation steps, and test log information for each test to form a complete test record; S7. Analyze test results: Using a combination of quantitative and qualitative analysis methods, based on test records, we will analyze the rationality and effectiveness of the security design, and evaluate the overall security level and potential risk of the core IT support BOSS system. S8. Test Result Submission: Prepare a test report including test overview, test process, result analysis, risk assessment, and remediation suggestions, and submit it to the project stakeholders. Based on the conclusions of the test report, determine whether the system needs to be modified. If modification is required, adjust the test plan and test scheme. S9. Iterative Testing: Repeat steps S4 to S8, design additional test cases for the modified parts of the system and focus on regression testing, summarize testing experience and optimize the test plan until the system security level meets the project requirements.
8. A security testing method based on an IT support core BOSS system according to claim 7, characterized in that: The vulnerability severity levels are divided into four levels: critical, high-risk, medium-risk, and low-risk. The classification is based on the ease with which the vulnerability can be exploited, the scope of its impact, and the severity of the damage caused. Different levels of vulnerabilities correspond to different remediation priorities and regression testing requirements.
9. A security testing method based on an IT support core BOSS system according to claim 7, characterized in that: The emergency response process involves four steps: fault location, cause analysis, temporary repair, and solution optimization. This ensures that the testing process can be quickly resumed after a test interruption, and the repair solution is updated in the test solution document to provide a reference for subsequent tests.
10. A security testing method based on an IT support core BOSS system according to claim 7, characterized in that: During the test case writing process, each security test point corresponds to at least one independent test case. The test case includes the test purpose, test prerequisites, test steps, expected results, and judgment criteria to ensure the repeatability of test execution and the objectivity of result judgment. Alternatively, during the iterative testing process, the security testing plan is optimized based on the test results from four dimensions: test focus, test cases, tool configuration, and process design. At the same time, a test experience library containing test experience, problem solutions, and optimization suggestions is formed, providing a standardized reference template for subsequent security testing of similar IT support core BOSS systems.