A third party security capability platform access method

Abstract

The application discloses a third-party security capability platform access method applied to a cloud security management portal of a cloud security resource pool, and has the characteristics that the method comprises the following steps: S1, checking metadata compliance according to a preset access standard, and generating a unique access instance ID when the checking is passed; S2, receiving original security logs and alarm data output by a third-party security capability platform through a data channel; S3, performing tenant label encapsulation on the received original security logs, and adding an access instance ID and a tenant identity label to each log; S4, performing format normalization processing on the encapsulated logs; and S5, performing capability availability checking at regular time intervals, and triggering an alarm and isolating the third-party security capability instance when the checking is abnormal. The application realizes the standardized and rapid access of a third-party security capability, capability effectiveness checking, security data tenant label encapsulation, adapts to a multi-tenant cloud security resource pool and an internal and external network isolation deployment architecture, and realizes accurate alarm analysis by connecting a situation awareness platform.

Description

Technical Field

[0001] This invention relates to the field of cloud security resource pool technology, specifically a method for accessing a third-party security capability platform. Background Technology

[0002] As enterprises migrate their businesses to the cloud on a large scale, cloud security resource pools have become the core infrastructure for cloud platform security protection. Cloud security resource pools can provide various virtualized security components internally, enabling tenants to enable and elastically schedule security capabilities on demand. Under the existing Huaneng Cloud security resource pool architecture, the number of natively built-in security components is limited. Relying solely on self-developed security capabilities makes it difficult to quickly adapt to the differentiated security protection needs of different business tenants. It is necessary to introduce a third-party security capability platform to supplement the capabilities.

[0003] Most existing access methods use hard-coded coupling. For each new type of third-party security platform, it is necessary to redevelop an adaptation plugin for that vendor's interface. This results in a long development cycle, high iteration costs, and poor interface compatibility. When the third-party platform's interface version is upgraded, the original adaptation code is very easy to become invalid, requiring secondary modifications to the program. This makes it impossible to achieve rapid hot access and is not conducive to the rapid expansion of cloud security resource pool capabilities.

[0004] Meanwhile, in cloud environments, there are scenarios with overlapping IP addresses and isolated deployments of internal and external networks. Alarms and audit logs output by third-party security platforms lack tenant identity tags. When these logs are directly output to the situation awareness platform, log paradigm confusion and incorrect identification of threat alarm attribution occur. This makes it impossible for the upper-layer situation awareness platform to accurately distinguish the tenant to which the alarm belongs, resulting in a decrease in the accuracy of security data analysis in multi-tenant scenarios. Existing technologies lack a standardized adaptation, tag encapsulation, and integrated access solution for capability verification. Summary of the Invention

[0005] This invention overcomes the shortcomings of existing technologies, such as hard-coded coupling, low adaptation efficiency, and disordered multi-tenant log ownership. It provides a method for accessing third-party security capability platforms, enabling standardized and rapid access to third-party security capabilities, capability validity verification, and security data tenant tag encapsulation. It adapts to the multi-tenant, internal and external network isolation deployment architecture of cloud security resource pools and connects to the situational awareness platform to achieve accurate alarm analysis.

[0006] A method for accessing a third-party security capability platform, applied to the cloud security management portal of a cloud security resource pool, includes the following steps: S1: Receives access registration requests submitted by third-party security capability platforms, reads capability metadata reported by third-party security capability platforms, and the capability metadata includes interface protocol, capability type, alarm output mode, and capability verification parameters; verifies the compliance of the metadata according to preset access standards, and generates a unique access instance ID if the verification is successful. S2: Based on standardized adaptation templates, an adaptation driver is automatically generated to establish control and data channels between the cloud security management portal and third-party security capability platforms. The control channel is used to issue security policies and start / stop scheduling commands. The data channel receives raw security logs and alarm data output by the third-party security capability platforms. S3: Encapsulate the received raw security logs with tenant tags, and attach the access instance ID and tenant identity tag to each log; S4: Normalize the format of the encapsulated logs, and output them to the log aggregation system according to the output configuration, selecting either KAFKA or syslog mode. The log aggregation system then forwards the logs to the network situation awareness security operation platform. S5: Performs periodic capability availability checks. If the check fails, an alarm is triggered and the third-party security capability instance is isolated.

[0007] Preferably, in S1, the metadata compliance verification, including the calculation of capability completeness score, uses the following formula:

[0008] in, The completeness score is calculated as follows: A represents the interface protocol compliance coefficient; B represents the alarm output mode completeness coefficient; and C represents the verification parameter completeness coefficient. , , These are the weighting coefficients. ;when The metadata verification was deemed successful. This is a preset admission threshold.

[0009] Preferably, the standardized adaptation templates in S2 include control interface templates and data feedback templates, which do not require hard-coding development and automatically fill template parameters to generate adaptation drivers based on capability metadata.

[0010] Preferably, the S3 tenant label encapsulates the label data structure, which includes the tenant number, access instance ID, and network domain flag bit. The network domain flag bit is used to mark the intranet zone or the Internet zone, adapting to the cloud security resource pool's internal and external network isolation deployment architecture.

[0011] Preferably, S3 log normalization processing is used to map and transform log fields, and the log matching degree is calculated using Formula 2:

[0012] in, Map matching degree to log fields; The number of times a field was successfully mapped to a standard field; This represents the total number of fields in the original third-party logs; when M is lower than the preset matching threshold, an alarm for missing fields will be output.

[0013] Preferably, for S4 output configuration, when deploying third-party capabilities in the cloud security resource pool intranet zone, the KAFKA mode output should be selected first; when deploying third-party capabilities in the Internet zone, the syslog mode output should be selected first.

[0014] Preferably, the S5 periodic execution capability availability verification includes connectivity detection and alarm simulation feedback verification; it sends simulation detection commands to a third-party security capability platform, compares the returned alarm data, and determines whether the capability instance is working properly.

[0015] Preferably, when the verification determines that a third-party security capability instance is abnormal, the control channel and data channel are cut off, the faulty instance is isolated, and the normal operation of other security components in the cloud security resource pool is not affected.

[0016] Preferably, it also includes a capability measurement and statistics step, which counts the number of calls to the third-party security capability platform and the throughput of log processing, and generates tenant security service billing data for display in the tenant self-service module.

[0017] Preferably, it also includes a version adaptive update step, which monitors changes in the interface version of third-party security capability platforms. When an interface version iteration is detected, the standardized adaptation template is automatically reloaded and the adaptation driver is updated, without the need for manual redevelopment of adaptation code.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. Template-driven automatic generation mechanism: Abandoning traditional hard-coded integration, it automatically generates adaptation drivers based on access metadata and standardized adaptation templates, enabling hot-swappable and rapid integration of third-party security capabilities and significantly reducing the workload of third-party platform integration development.

[0019] 2. Multi-tenant tagging encapsulation technology: Complete the tagging of log tenants and network domain markers on the cloud security resource pool side, solve the problem of log ownership confusion in the situational awareness platform under the scenario of overlapping multi-tenant IPs in the cloud, and improve the accuracy of threat judgment on the upper-layer platform.

[0020] 3. Dual-formula quantitative admission and log quality assessment: The capability completeness score enables quantitative screening for third-party platform admission; the log field matching quantification assesses the normalization effect, enabling quantifiable evaluation of the entire access process.

[0021] 4. Differentiated output scheduling for internal and external networks: Automatically selects log output protocols for isolated deployment environments in the internal network zone and the Internet zone of the cloud security resource pool, and provides availability verification and fault instance isolation to prevent fault propagation and ensure the overall stability of the cloud security resource pool; it also supports version adaptive updates and capacity metering statistics to adapt to tenant self-service business scenarios. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the overall architecture for accessing the third-party security capability platform of this invention; Figure 2 This is a schematic diagram of the tenant tag encapsulation for the multi-tenant security log of the present invention; Figure 3 This is a schematic diagram comparing the embodiments of the present invention with the comparative experiments. Detailed Implementation

[0023] The method of this invention is applied to the Huaneng Cloud Security Resource Pool Cloud Security Management Portal, connecting with the Huaneng Blue Shield Log Aggregation System and the Huaneng Blue Shield Network Situation Awareness Security Operation Platform, and setting weights. Admission threshold The log mapping matching threshold is set to 0.8.

[0024] Example 1 (Internal network zone, multi-tenant, overlapping tenant IPs, access to a third-party data anonymization and security platform) Environment: Deployed in the intranet area of ​​Huaneng Cloud Security Resource Pool, with a total of 3 business tenants. The private network IP address ranges of the tenants overlap, and it is connected to a third-party data anonymization and security capability platform; the cloud security resource pool intranet environment and internal message queue service are available.

[0025] Implementation process: 1) The third-party data anonymization and security capability platform initiates access registration and reports capability metadata; substitutes the metadata into Formula 1 to calculate the capability completeness score. =0.88, which is greater than the threshold of 0.75. The verification passed, and a unique access instance ID was assigned. 2) The system automatically loads standardized adaptation templates to generate adaptation drivers and builds control and data channels; 3) Receive raw de-identified audit logs from the third-party platform, encapsulate tenant number, instance ID, and intranet network domain tag; calculate the log field mapping matching degree M=0.92 using Formula 2, which is higher than the threshold, and complete log normalization; 4) Based on the intranet environment, automatically select the KAFKA mode to output and encapsulate the logs to the Blue Shield log aggregation system, and then forward them to the situation awareness platform; 5) Perform availability checks every 5 minutes, issue simulated de-identified events, and verify alarm feedback; simultaneously, calculate capability call throughput, generate metering bills; monitor third-party platform interface versions, and implement driver adaptive updates; 6) Statistical indicators: access time, log normalization success rate, alarm attribution identification accuracy, and fault isolation effective time.

[0026] Example 2 (Internet zone, single tenant, no IP overlap, access to a third-party web vulnerability scanning security platform) Environment: Deployed in the Internet zone of the cloud security resource pool, with only 1 business tenant, no overlap in tenant IPs, connected to a third-party web vulnerability scanning security platform, and the internal network message queue is not directly accessible.

[0027] Implementation process: 1) Submit access registration to a third-party web vulnerability scanning platform, report capability metadata, and calculate using Formula 1. =0.81, verification passed, generate access instance ID; 2) Automatically generate adapter drivers and establish dual channels; 3) Receive raw vulnerability scan alerts, encapsulate tenant tags and internet domain tags; Formula 2 yields M=0.87, completing normalization; 4) The Internet zone environment automatically selects the syslog protocol to output logs; 5) Scheduled availability verification, measurement statistics, and version adaptive updates; record various test indicators.

[0028] Comparative Example 1 (Multi-tenant IP overlap scenario in the intranet area, using traditional hard-coding to connect to a third-party data anonymization platform) Environment: The hardware, network, and tenant business environment are completely consistent with those in Example 1; the access scheme adopts the existing hard-coded development plugin, without automatic template driving, and the logs do not have tenant tags attached.

[0029] Implementation process: 1) Developers write hard-coded adaptation plugins for third-party platform interfaces to complete interface integration testing; 2) Receive raw security logs and forward them directly to the log aggregation system without tagging the logs with tenants; 3) Completeness score and log mapping matching metric verification are not performed; when the version of a third-party interface changes, the adaptation code is manually modified. 4) Record access time, log normalization success rate, alarm attribution identification accuracy, and fault isolation effective time.

[0030] Comparative Example 2 (Single-tenant IPs in the Internet zone with no overlap, traditional hard-coded connection to a third-party Web vulnerability scanning platform) Environment: Completely consistent with the hardware network service environment of Example 2; traditional hard-coded plug-in interface, no templated driver, and no automatic protocol selection logic.

[0031] Implementation process: 1) Manually develop hard-coded adaptation plugins and integrate them with third-party web vulnerability scanning platforms; 2) Raw logs are forwarded directly without label encapsulation, and the output protocol is manually configured. 3) When updating the version of a third-party interface, the code needs to be modified manually, and all test metrics need to be recorded.

[0032] The experimental results are compared in Table 1 below:

[0033] Table 1 The experimental results are analyzed as follows: 1. Access time: The embodiment of this invention relies on template to automatically generate drivers, and the access time is only a few minutes; the traditional hard-coding solution requires manual coding, debugging and integration, which takes up to hundreds of minutes, thus greatly improving access efficiency.

[0034] 2. Alarm attribution identification accuracy: In the scenario of overlapping multi-tenant IPs in the intranet, Comparative Example 1 lacks tenant tags, and a large number of alarms cannot be distinguished by tenant attribution, with an accuracy rate of only 63.5%; After adding tenant tag encapsulation in Example 1, the alarm attribution identification accuracy rate reaches 99.2%, solving the pain point of log confusion caused by overlapping multi-tenant IPs.

[0035] 3. Log normalization success rate: This invention introduces a field matching degree formula for quantitative verification, which can promptly detect missing fields and achieves a normalization success rate that is significantly higher than that of traditional solutions.

[0036] 4. Fault isolation effective time: This invention detects anomalies and directly cuts off the channel for isolation, completing fault isolation in seconds; traditional hard-coded plugin faults often require service restart, resulting in longer isolation times.

[0037] 5. Interface version iteration: This invention can automatically reload the template update driver; traditional hard-coded solutions require manual code modification, resulting in high maintenance costs.

Claims

1. A method for accessing a third-party security capability platform, applied to a cloud security management portal of a cloud security resource pool, characterized in that, Includes the following steps: S1: Receives access registration requests submitted by third-party security capability platforms, and reads capability metadata reported by third-party security capability platforms. Capability metadata includes interface protocol, capability type, alarm output mode, and capability verification parameters. The metadata is verified for compliance according to the preset access standards. If the verification is successful, a unique access instance ID is generated. S2: Automatically generates adaptation drivers based on standardized adaptation templates, establishing control and data channels between the cloud security management portal and third-party security capability platforms; the control channel is used to issue security policies and start / stop scheduling commands. The data channel receives raw security logs and alarm data output by third-party security capability platforms; S3: Encapsulate the received raw security logs with tenant tags, and attach the access instance ID and tenant identity tag to each log; S4: Normalize the format of the encapsulated logs, and output them to the log aggregation system according to the output configuration, selecting either KAFKA or syslog mode. The log aggregation system then forwards the logs to the network situation awareness security operation platform. S5: Performs periodic capability availability checks. If the check fails, an alarm is triggered and the third-party security capability instance is isolated.

2. The method for accessing a third-party security capability platform according to claim 1, characterized in that, In S1, metadata compliance verification, including capability completeness score calculation, uses the following formula: in, The completeness score is calculated as follows: A represents the interface protocol compliance coefficient; B represents the alarm output mode completeness coefficient; and C represents the verification parameter completeness coefficient. , , These are the weighting coefficients. ;when The metadata verification was deemed successful. This is a preset admission threshold.

3. The method for accessing a third-party security capability platform according to claim 2, characterized in that, The standardized adaptation templates in S2 include control interface templates and data feedback templates. No hard-coding development is required; the template parameters are automatically filled in based on the capability metadata to generate the adaptation driver.

4. The method for accessing a third-party security capability platform according to claim 3, characterized in that, S3 tenant tag encapsulation: The tag data structure includes tenant number, access instance ID, and network domain flag bit; the network domain flag bit is used to mark the intranet zone or the Internet zone, adapting to the cloud security resource pool's internal and external network isolation deployment architecture.

5. The method for accessing a third-party security capability platform according to claim 4, characterized in that, S3 log normalization processes log field mapping and transformation, and uses Formula 2 to calculate the log matching degree: in, Map matching degree to log fields; The number of times a field was successfully mapped to a standard field; This represents the total number of fields in the original third-party logs; when M is lower than the preset matching threshold, an alarm for missing fields will be output.

6. The method for accessing a third-party security capability platform according to claim 5, characterized in that, When configuring S4 output, if third-party capabilities are deployed in the cloud security resource pool intranet area, the KAFKA mode output should be selected first. When deploying third-party capabilities in the Internet zone, syslog mode output should be prioritized.

7. The method for accessing a third-party security capability platform according to claim 6, characterized in that, S5 periodically performs capability availability checks, including connectivity detection and alarm simulation feedback verification; it sends simulated detection commands to a third-party security capability platform, compares the returned alarm data, and determines whether the capability instance is working properly.

8. The method for accessing a third-party security capability platform according to claim 7, characterized in that, If the verification determines that a third-party security capability instance is abnormal, the control channel and data channel will be cut off, the faulty instance will be isolated, and the normal operation of other security components in the cloud security resource pool will not be affected.

9. The method for accessing a third-party security capability platform according to claim 8, characterized in that, It also includes capability measurement and statistics steps, which count the number of calls to the third-party security capability platform and the throughput of log processing, and generate tenant security service billing data for display in the tenant self-service module.

10. A method for accessing a third-party security capability platform according to claim 9, characterized in that, It also includes a version adaptive update step, which monitors changes in the interface version of third-party security capability platforms. When an interface version iteration is detected, it automatically reloads the standardized adaptation template and updates the adaptation driver, eliminating the need for manual redevelopment of adaptation code.

Images