A security baseline checking system developed based on a Python Flask framework

Abstract

The present application relates to a kind of systems, in particular to a kind of security reinforcement and management system.The system uses client-server (C / S) separation architecture, by cloud central management and client distributed execution combination, realize the automation detection and reinforcement of Windows system Linux system security configuration.The present application supports multiple rule types, can be flexibly combined according to demand;The system uses the uniform rule description language of JSON format, three rule types are distinguished by type field: command execution query, security policy, registry check, realize the flexible combination of multiple detection methods.The present application uses intelligent report processing function, automatically parses report content and calculates compliance rate;Support multi-dimensional report analysis (according to rule, host, time etc.);Provide intuitive visual display.The present application uses responsive design, adapts to various equipment, provides rich data visualization components, supports multiple display modes of report.

Description

Technical Field

[0001] This invention relates to a system, and more particularly to a security hardening and management system. Background Technology

[0002] As cybersecurity threats become increasingly complex, security baseline checks have become an essential part of enterprise IT infrastructure management. Traditional security baseline checks face three major challenges: 1. Technology fragmentation: It requires the simultaneous use of multiple independent tools, such as registry checking tools (e.g., RegEdit), command-line tools (e.g., PowerShell), and security policy editors (e.g., secpol.msc); 2. Low level of automation: Manual checks of security benchmarks such as CIS can take up to several hours, and the results recording depends on manual compilation; 3. Lack of standardization: Different teams use inconsistent inspection methods and report formats, making it difficult to conduct horizontal comparisons and trace historical data. Currently, the existing solutions are mainly as follows: 1. Script-based inspection tools: Typical example: PowerShell security baseline check script; Features: Independent scripts are written for specific inspection items and executed periodically through task scheduling; Limitations: There is no unified management among scripts, and results need to be manually summarized; 2. Security and Compliance Scanner: Typical example: OpenSCAP open-source solution; Features: Uses SCAP standards to define inspection rules and generates XML format reports; Limitations: The rule definition is complex, and it only supports Linux systems; 3. Commercial security configuration management tools: Typical example: Qualys Policy Compliance; Features: Provides cloud-based services and supports multi-platform inspection; Limitations: Charged per node, resulting in high deployment costs for small and medium-sized enterprises.

[0003] However, existing technologies have the following drawbacks: 1. The rules and inspection methods are scattered. Existing security baseline checking tools are typically distributed across different platforms and domains, such as command-line scripts, registry editors, and security policy management tools. They lack a unified management entry point, making it difficult to centrally maintain and reuse baseline rules.

[0004] 2. Insufficient automation and management capabilities Most traditional tools rely on single manual operations, have weak batch automation capabilities, and lack flexible batch rule management, continuous execution, and compliance rate statistics.

[0005] 3. Poor report standardization and traceability The generated inspection reports are inconsistent in format and difficult to archive and compare. Some tools cannot automatically associate inspection rules with host information, making it difficult to trace and summarize compliance history.

[0006] 4. Difficulty in extending rules Expanding existing inspection items or adding new inspection types often requires writing and maintaining scripts with different styles, making it difficult to adapt to rapidly changing security requirements.

[0007] 5. Lack of a unified visual operation and maintenance interface Most existing systems are command-line or desktop applications, lacking a modern web-based visual operation and maintenance interface, resulting in inconvenient operation and a poor user experience.

[0008] 6. Insufficient platform compatibility and openness Some commercial solutions are expensive and have closed architectures, while open-source solutions are complex to configure and restrict the platform, failing to meet the needs of small and medium-sized enterprises or customized needs. Summary of the Invention

[0009] To overcome the shortcomings of existing technologies, this invention provides a security reinforcement and management system.

[0010] This invention is achieved through the following technical solution: a security baseline checking system developed based on the Python Flask framework. The system adopts a client-server (C / S) separation architecture, combining centralized cloud management with distributed client execution to automate the detection and hardening of security configurations for Windows and Linux systems. The system architecture includes... Frontend: Build a responsive interface using the existing Bootstrap 5.3.2 framework and Material Icons; Backend: Based on the existing Python Flask 2.0.1 framework; Data storage: A file system is used for storage (rule files in JSON format and report files in CSV format); User authentication: Implemented using Flask-Login 0.5.0.

[0011] Furthermore, the security baseline inspection system backend includes a server-side module, which adopts a lightweight architecture design and includes: Web service layer: Uses the Flask framework to provide RESTful API interfaces, supporting core functions such as rule management, report uploading, and user authentication; User authentication module: integrates Flask-Login to implement a session-based user authentication mechanism, and uses the Werkzeug security library to encrypt and store passwords using SHA-256 hashing. Data storage layer: A file system storage scheme is adopted, rules are stored in JSON format, reports are stored in CSV format, and metadata is managed independently for easy retrieval and distribution; Rule validation engine: Implements a rule format validator, supporting syntax and semantic validation for three rule types: command execution (cmd), security policy (sec), and registry (reg).

[0012] Furthermore, the front end of the security baseline inspection system includes a client module. The client is developed using Python and packaged into a standalone executable file using PyInstaller, requiring no Python environment installation on the target system and supporting a minimum system version of Windows Server 2008. The client module includes: a rule management subsystem, a client core module, an auxiliary function subsystem, a report processing subsystem, and a hardening execution subsystem.

[0013] Furthermore, the rule management subsystem includes a rule acquisition module, which dynamically retrieves the latest security detection rules from the server via the HTTP protocol, supporting both cloud-based and local rule loading methods. The core client module includes a system detection engine, which encapsulates Windows APIs and system commands to read and detect the registry, security policies, and system configurations. The hardening execution subsystem includes a security hardening engine, which provides hardening capabilities such as registry modification, security policy configuration, and system parameter adjustment. The report processing subsystem includes a report generation module, which automatically generates CSV format test reports and hardening reports, containing detailed information such as test items, current values, standard values, and compliance status. Furthermore, each rule contains required fields and type-specific fields, and the system automatically dispatches it to the corresponding processing function based on the type value; command execution rules use the subprocess module to call Windows system commands to obtain information; security policy rules use the secedit command to export and configure local security policies, supporting password policies, account lockout, user permissions, audit policies, etc.; registry rules use the winreg module to read and write the registry, supporting multiple data types such as DWORD, String, and Binary.

[0014] Furthermore, the client's security_check and security_hardening functions adopt a unified loop structure, using if-elif to check the value of the type field, and calling the corresponding dedicated functions execute_cmd, check_security_policy, and check_registry to process different types of rules, ultimately generating a unified CSV detection report.

[0015] Furthermore, the server receives CSV report files uploaded by the client through the / report interface and uses Python's csv module to parse the report content. The system first reads the CSV header row to identify the column structure and adopts different parsing strategies according to the report type. For detection reports, the system uses regular expression matching to find key columns in the header row, then iterates through the data rows and uses a keyword matching algorithm to determine the compliance status of each row: defining a list of compliant keywords, a list of non-compliant keywords, and a list of manually checked keywords, converting the result values ​​to lowercase, matching the keywords one by one, and counting the number of compliant items, the number of non-compliant items, and the number of manually checked items. For reinforcement reports, the system identifies the "original value", "standard value", "reinforced value", and "remarks" columns, and determines whether the reinforcement is successful by comparing whether the standard value and the reinforced value are equal, while parsing the keywords in the remarks column to assist in the judgment.

[0016] Furthermore, the client employs the `load_rules_from_cloud` and `load_rules_from_local` functions to support flexible rule retrieval methods. In cloud mode, the rule list is retrieved from the server's ` / rules / list` interface via an HTTP GET request using the `requests` library. After the user selects a rule, the JSON content of the specified rule file is downloaded and parsed into memory. Timeout retries and disabling SSL verification are supported to adapt to different network environments. In local mode, the local JSON file is read directly, and the rule content is parsed using UTF-8 encoding. The rule ID is extracted from the file path for subsequent report association. Both modes use a unified rule data structure, and the loaded rules are stored in the same `self.rules` list, eliminating the need to distinguish between rules in subsequent detection and hardening processes.

[0017] Furthermore, the report generation adopts a local-first strategy. The save_report function uses the Python csv module to write the detection results to a local CSV file, and uses UTF-8-sig encoding to ensure that Chinese characters are displayed correctly in Excel. The report is uploaded through the send_report_to_cloud function, which uses the multipart / form-data format of the requests library to POST the file to the server's / report interface, and supports resuming interrupted uploads and retrying on failure.

[0018] Furthermore, the client uses PyInstaller to package it into a standalone executable file, configuring onefile mode to package all dependencies into a single exe file, eliminating the need for a Python environment to be installed on the target system. On Windows platforms, the winreg module manipulates the registry, and subprocess calls the secedit system command, supporting Windows Server 2008 and later. On Linux platforms, os.system executes shell commands and reads configuration files to perform security policy checks, requiring GLIBC 2.27 and later. The system automatically identifies the operating system type using platform.system(). The client uses the socket module to automatically obtain the hostname and IP address, and the datetime module to generate timestamps, ensuring compatibility across different system environments.

[0019] Compared with the prior art, the advantages of the present invention are as follows: 1. Flexible rule management mechanism It supports multiple rule types (command execution, security policy, registry check) and can be flexibly combined according to needs. This system adopts a unified rule description language in JSON format, and distinguishes three rule types through the type field: command execution query, security policy, and registry check, so as to realize the flexible combination of multiple detection methods.

[0020] 2. Intelligent report processing function Automatically parses report content and calculates compliance rate; supports multi-dimensional report analysis (by rule, host, time, etc.); provides intuitive visualization.

[0021] 3. A highly customizable user interface with a responsive design, adaptable to various devices, providing rich data visualization components and supporting multiple report display methods (tables, charts, etc.). Attached Figure Description

[0022] The invention will now be further described with reference to the accompanying drawings.

[0023] Figure 1 This is a client architecture diagram of the present invention; Figure 2 This is a diagram of the server architecture of the present invention. Detailed Implementation

[0024] The invention will be further described below with reference to the accompanying drawings. A security baseline checking system developed based on the Python Flask framework. The system adopts a client-server (C / S) separation architecture, combining centralized cloud management with distributed client execution to automate the detection and hardening of security configurations on Windows and Linux systems. The system architecture includes... Frontend: Build a responsive interface using the existing Bootstrap 5.3.2 framework and Material Icons; Backend: Based on the existing Python Flask 2.0.1 framework; Data storage: A file system is used for storage (rule files in JSON format and report files in CSV format); User authentication: Implemented using Flask-Login 0.5.0.

[0025] The server-side web application service is built on the Python Flask framework and adopts a lightweight architecture design. Web service layer: Uses the Flask framework to provide RESTful API interfaces, supporting core functions such as rule management, report uploading, and user authentication.

[0026] User authentication module: integrates Flask-Login to implement a session-based user authentication mechanism, and uses the Werkzeug security library to encrypt and store passwords using SHA-256 hashing. Data storage layer: A file system storage scheme is adopted, rules are stored in JSON format, reports are stored in CSV format, and metadata is managed independently for easy retrieval and distribution; Rule validation engine: Implements a rule format validator, supporting syntax and semantic validation for three rule types: command execution (cmd), security policy (sec), and registry (reg).

[0027] like Figure 1 As shown, the client module includes: a rule management subsystem, a client core module, an auxiliary function subsystem, a report processing subsystem, and a hardening execution subsystem.

[0028] Client: The client is developed using Python and can be packaged into a standalone executable file using PyInstaller. It does not require the target system to have a Python environment installed and supports a minimum system version of Windows Server 2008.

[0029] Rule Acquisition Module: Dynamically retrieves the latest security detection rules from the server via the HTTP protocol, supporting both cloud-based and local rule loading methods.

[0030] System detection engine: Encapsulates Windows APIs and system commands to read and detect the registry, security policies, and system configurations.

[0031] Security hardening engine: Provides hardening capabilities such as registry modification, security policy configuration, and system parameter adjustment.

[0032] The core client module also includes a system detection engine, which encapsulates Windows APIs and system commands to read and detect the registry, security policies, and system configurations. The hardening execution subsystem includes a security hardening engine, which provides hardening capabilities such as registry modification, security policy configuration, and system parameter adjustment. The report processing subsystem includes a report generation module, which automatically generates CSV format test reports and hardening reports, containing detailed information such as test items, current values, standard values, and compliance status. The rule management subsystem includes a rule acquisition module, which dynamically retrieves the latest security detection rules from the server via the HTTP protocol, supporting both cloud-based and local rule loading methods.

[0033] This system uses a unified rule description language in JSON format, and distinguishes three rule types through the type field: command execution query, security policy, and registry check, enabling flexible combinations of various detection methods.

[0034] Technical Implementation: Each rule contains required fields (name, type) and type-specific fields. The system automatically dispatches the rule to the corresponding processing function based on the type value. Command execution rules use the subprocess module to call Windows system commands to obtain information; security policy rules use the secedit command to export and configure local security policies, supporting password policies, account lockout, user permissions, audit policies, etc.; registry rules utilize the winreg module to read and write the registry, supporting multiple data types such as DWORD, String, and Binary.

[0035] Flexible combination mechanism: Rules are stored as JSON arrays. A single rule file can contain any number and type of rules, which the system executes sequentially. The server-side `validate_rule` function verifies the rule format, ensuring that required fields are complete and operation types are valid (Equal, Greater, Less, ExactlyContains). The client-side `security_check` and `security_hardening` functions use a unified loop structure, using if-elif statements to check the value of the `type` field and calling corresponding dedicated functions such as `execute_cmd`, `check_security_policy`, and `check_registry` to process different rule types, ultimately generating a unified CSV detection report.

[0036] Extensible Design: The system supports flexible mapping of field names (e.g., regpath / path and regitem / English are interchangeable), ensuring compatibility with rule files from different sources. Adding a new rule type only requires adding new processing logic to the type judgment branch, without modifying the core architecture. Rules are separated from code; administrators can create and edit rule sets through a web interface, while clients dynamically retrieve the latest rules via a RESTful API, enabling centralized management and rapid distribution of rules to meet the detection needs of different security compliance standards.

[0037] Dual system management supports Linux and Windows systems The rules are stored in JSON format, which facilitates expansion and modification. The unique rule metadata management mechanism provides better rule classification and management capabilities. 2. Intelligent report processing function Automatically parse report content and calculate compliance rate Technical implementation: such as Figure 2As shown, the server receives CSV report files uploaded by the client through the ` / report` interface and uses Python's `csv` module to parse the report content. The system first reads the CSV header row to identify the column structure and employs different parsing strategies based on the report type (check report or rsf reinforcement report). For check reports, the system uses regular expressions to search for key columns such as "qualified," "result," and "compliant" in the header row. Then, it iterates through the data rows, using a keyword matching algorithm to determine the compliance status of each row: defining a compliance keyword list (compliant, passed, yes, meets requirements, etc.), a non-compliance keyword list (non-compliant, failed, no, etc.), and a manual check keyword list (N / A, manual, human-made, etc.). After converting the result values ​​to lowercase, it matches the keywords one by one, counting the number of compliant, non-compliant, and manually checked items. For reinforcement reports, the system identifies columns such as "original value," "standard value," "reinforced value," and "remarks." It determines whether reinforcement was successful by comparing the standard value with the reinforced value, and simultaneously parses keywords such as "meets standards" and "reinforcement successful" in the remarks column to assist in the judgment.

[0038] Compliance rate calculation: The system automatically counts the total number of inspection items, the number of compliant items, the number of non-compliant items, and the number of manually inspected items. The compliance rate is calculated using the formula: Compliance Rate = Number of compliant items ÷ (Total number of items - Number of manually inspected items) × 100%. The statistical results are stored in the report metadata. When the / reports / list interface returns a report list, it displays summary information such as the number of reports for each rule, the average compliance rate, and the latest report time, grouped by rule ID. The front-end uses chart components to visually display compliance trends, supporting filtering and comparative analysis by host, rule, time, and other dimensions.

[0039] Supports multi-dimensional report analysis (by rules, host, time, etc.) Provides intuitive visualizations 3. Highly customizable user interface Adopting a responsive design, it adapts to various devices. Provides a rich set of data visualization components Supports multiple report display formats (tables, charts, etc.) 4. Comprehensive security mechanism User authentication and authorization management Password encrypted storage Session management and security control 5. High client adaptability Supports loading rules from both the cloud and local systems. Supports cloud-based report uploading and local generation. It supports over 80% of operating systems, including Windows Server 2008 and above, and Linux GLIBC version 2.27 and above, including domestic operating systems such as UnionTech UOS, Kylin, Huawei Euler, and Alibaba Dragon Lizard. The client of this system is developed using Python. It achieves high adaptability through PyInstaller packaging technology and cross-platform API encapsulation, and supports dual-mode operation in the cloud and local.

[0040] Dual-mode rule loading: The client implements the `load_rules_from_cloud` and `load_rules_from_local` functions to support flexible rule retrieval methods. In cloud mode, a list of rules is retrieved from the server's ` / rules / list` interface via an HTTP GET request using the `requests` library. After the user selects a rule, the JSON content of the specified rule file is downloaded and parsed into memory. Timeout retries and disabling SSL verification are supported to adapt to different network environments. In local mode, the local JSON file is read directly, and the rule content is parsed using UTF-8 encoding. The rule ID is extracted from the file path for subsequent report association. Both modes use a unified rule data structure, and loaded rules are stored in the same `self.rules` list. Subsequent detection and hardening processes do not need to distinguish the rule source, achieving transparent switching between rule retrieval methods.

[0041] The report processing operates in two modes: Local report generation prioritizes local processing. The `save_report` function uses the Python `csv` module to write the detection results to a local CSV file. The filename includes the computer name, IP address, timestamp, and rule ID for easy traceability. UTF-8 encoding is used to ensure correct display of Chinese characters in Excel. Report uploading is achieved through the `send_report_to_cloud` function, using the `requests` library's multipart / form-data format POST upload to the server's ` / report` interface. It supports resumeable uploads and retries on failure. Users can choose to save locally only or upload to the cloud simultaneously, meeting the needs of both offline detection and centralized management scenarios.

[0042] Cross-platform adaptation technology: The client uses PyInstaller to package it into a standalone executable file, configuring onefile mode to package all dependencies into a single exe file, eliminating the need for a Python environment to be installed on the target system. On Windows platforms, the winreg module manipulates the registry, and subprocess calls system commands such as secedit, supporting Windows Server 2008 and later versions. On Linux platforms, os.system executes shell commands and reads configuration files such as / etc / security to perform security policy checks, requiring GLIBC 2.27 and later. The system automatically identifies the operating system type using platform.system(), calling the corresponding APIs and commands for different platforms, achieving coverage of over 80% of mainstream operating systems, including domestic operating systems such as UnionTech UOS, Kylin, Huawei Euler, and Alibaba Dragon Lizard. The client uses the socket module to automatically obtain the hostname and IP address, and the datetime module to generate timestamps, ensuring compatibility across different system environments.

Claims

1. A security baseline checking system developed based on the Python Flask framework, characterized in that, The system adopts a client-server (C / S) separation architecture, combining centralized cloud management with distributed client execution to achieve automated detection and hardening of security configurations for Windows and Linux systems. The system architecture includes... Frontend: Build a responsive interface using the existing Bootstrap 5.3.2 framework and Material Icons; Backend: Based on the existing Python Flask 2.0.1 framework; Data storage: The system uses a file system to store rules files in JSON format and report files in CSV format. User authentication: Implemented using Flask-Login 0.5.

0.

2. The security baseline inspection system based on the Python Flask framework as described in claim 1, characterized in that, The security baseline check system backend includes a server module, which adopts a lightweight architecture and includes: Web service layer: Uses the Flask framework to provide RESTful API interfaces, supporting core functions such as rule management, report uploading, and user authentication; User authentication module: integrates Flask-Login to implement a session-based user authentication mechanism, and uses the Werkzeug security library to encrypt and store passwords using SHA-256 hashing. Data storage layer: A file system storage scheme is adopted, rules are stored in JSON format, reports are stored in CSV format, and metadata is managed independently for easy retrieval and distribution; Rule validation engine: Implements a rule format validator, supporting syntax and semantic validation for three rule types: command execution (cmd), security policy (sec), and registry (reg).

3. The security baseline checking system based on the Python Flask framework as described in claim 1, characterized in that, The front end of the security baseline inspection system includes a client module. The client is developed in Python and packaged into a standalone executable file using PyInstaller. It does not require the target system to install a Python environment and supports a minimum system version of Windows Server 2008. The client module includes: a rule management subsystem, a client core module, an auxiliary function subsystem, a report processing subsystem, and a hardening execution subsystem.

4. A security baseline checking system based on the Python Flask framework as described in claim 3, characterized in that, The rule management subsystem includes a rule acquisition module, which dynamically retrieves the latest security detection rules from the server via the HTTP protocol, supporting both cloud-based and local rule loading methods. The core client module includes a system detection engine, which encapsulates Windows APIs and system commands to read and detect the registry, security policies, and system configurations. The hardening execution subsystem includes a security hardening engine, which provides hardening capabilities such as registry modification, security policy configuration, and system parameter adjustment. The report processing subsystem includes a report generation module, which automatically generates CSV format test reports and hardening reports, containing detailed information such as test items, current values, standard values, and compliance status.

5. A security baseline inspection system based on the Python Flask framework according to claim 1, characterized in that, Each rule contains required fields and type-specific fields. The system automatically dispatches the rule to the corresponding processing function based on the type value. Command execution rules obtain information by calling Windows system commands through the subprocess module. Security policy rules use the secedit command to export and configure local security policies, supporting password policies, account lockout, user permissions, audit policies, etc.; registry rules use the winreg module to read and write the registry, supporting multiple data types such as DWORD, String, and Binary.

6. A security baseline inspection system based on the Python Flask framework according to claim 1, characterized in that, The client's security_check and security_hardening functions use a unified loop structure. They use if-elif statements to check the value of the type field and call the corresponding dedicated functions execute_cmd, check_security_policy, and check_registry to process different types of rules, ultimately generating a unified CSV detection report.

7. A security baseline checking system based on the Python Flask framework according to claim 1, characterized in that, The server receives CSV report files uploaded by the client through the ` / report` interface and uses Python's `csv` module to parse the report content. The system first reads the CSV header row to identify the column structure and employs different parsing strategies based on the report type. For detection reports, the system uses regular expressions to find key columns in the header row, then iterates through the data rows, using a keyword matching algorithm to determine the compliance status of each row: defining a list of compliant keywords, a list of non-compliant keywords, and a list of manually checked keywords; converting the result values ​​to lowercase and matching the keywords one by one, counting the number of compliant items, non-compliant items, and manually checked items. For hardening reports, the system identifies the "original value," "standard value," "hardened value," and "remarks" columns, comparing the standard value with the hardened value to determine if the hardening was successful, while also parsing keywords in the remarks column to assist in the judgment.

8. A security baseline inspection system based on the Python Flask framework according to claim 1, characterized in that, The client uses the `load_rules_from_cloud` and `load_rules_from_local` functions to support flexible rule retrieval methods. In cloud mode, the rules list is retrieved from the server's ` / rules / list` interface via an HTTP GET request using the `requests` library. After the user selects a rule, the JSON content of the specified rule file is downloaded and parsed into memory. Timeout retries and disabling SSL verification are supported to adapt to different network environments. In local mode, the local JSON file is read directly, and the rule content is parsed using UTF-8 encoding. The rule ID is extracted from the file path for subsequent report association. Both modes use a unified rule data structure, and the loaded rules are stored in the same `self.rules` list, eliminating the need to distinguish between rules in subsequent detection and hardening processes.

9. A security baseline inspection system based on the Python Flask framework according to claim 1, characterized in that, The report generation adopts a local-first strategy. The save_report function uses the Python csv module to write the detection results to a local CSV file, and uses UTF-8-sig encoding to ensure that Chinese characters are displayed correctly in Excel. The report is uploaded through the send_report_to_cloud function, which uses the multipart / form-data format of the requests library to POST the file to the server's / report interface, and supports resuming interrupted uploads and retrying on failure.

10. A security baseline inspection system based on the Python Flask framework according to claim 1, characterized in that, The client uses PyInstaller to package it into a standalone executable file, configuring onefile mode to package all dependencies into a single .exe file, eliminating the need for a Python environment to be installed on the target system. On Windows platforms, the winreg module manipulates the registry, and subprocess calls the secedit system command, supporting Windows Server 2008 and later. On Linux platforms, os.system executes shell commands and reads configuration files to perform security policy checks, requiring GLIBC 2.27 and later. The system automatically identifies the operating system type using platform.system(). The client uses the socket module to automatically obtain the hostname and IP address, and the datetime module to generate timestamps, ensuring compatibility across different system environments.

Images