A method and system for IP threat intelligence reasoning based on pluggable intelligence sources

Abstract

This invention discloses an IP threat intelligence reasoning method and system based on pluggable intelligence sources, belonging to the field of network security and threat intelligence analysis technology. This invention achieves loosely coupled access and standardized output of multi-source heterogeneous intelligence through pluggable threat intelligence plugins, constructing a unified profile of the IP to be analyzed; it identifies the infrastructure attributes of the IP through semantic enhancement, and completes risk correction and false alarm suppression by combining contextual information and noise features; finally, it integrates multi-source structured evidence to generate a threat adjudication result with a complete and interpretable evidence chain. This invention solves the problems of high coupling of intelligence source access, high false alarm rate, insufficient interpretability of analysis results, and poor security of open extensions in existing technologies, and can be widely applied to network security threat detection, security operations, intrusion prevention, and other scenarios.

Description

Technical Field

[0001] This invention belongs to the fields of network security, threat intelligence analysis, threat detection and security data processing technology, and specifically relates to an IP threat intelligence reasoning method and system based on pluggable intelligence sources. Background Technology

[0002] With the continuous escalation of cyberspace attack and defense confrontations, IP threat intelligence has become a core foundational capability in network security protection systems. Existing IP threat analysis systems typically employ an architecture of fixed intelligence source access + centralized normalization processing + unified rule-based scoring output. A typical architecture can be found in the appendix of this manual. Figure 1 The core technical approach can be summarized as: source-by-source data collection → central analysis / normalization → rule-based scoring → output conclusions.

[0003] Specifically, as shown in the appendix Figure 1 As shown, the existing system has several fixed intelligence source adapters pre-built into the system. When the user inputs the IP to be analyzed, each adapter initiates a query to the corresponding external threat intelligence source to obtain the raw return results. Subsequently, the system performs normalization transformation on the raw fields of different intelligence sources in the central processing module. Then, a unified scoring module performs risk assessment on the target IP based on preset rules, blacklist hits, historical reputation scores, or manually set thresholds. Finally, it outputs a risk score, risk level, or a simple blacklist / whitelist judgment result.

[0004] In the appendix Figure 1 In the existing technical architecture shown, the access to intelligence sources is usually fixed and pre-configured. When adding a new intelligence source, it is often necessary to modify multiple locations simultaneously, including adding a collector or adapter, modifying the central normalization logic, supplementing source-specific rules in the scoring module, adding corresponding configuration items, and, if necessary, modifying the presentation layer or external interface fields. This means that source-specific knowledge is scattered across multiple modules, the system is strongly coupled to specific intelligence sources, and the cost of expansion and maintenance is high.

[0005] In addition, Figure 1 The existing technical architectures shown typically focus more on "whether a particular intelligence source is hit" or "the final risk score," while rarely establishing a unified, structured evidence expression system. Different intelligence sources return data with varying formats, field meanings, and sources of credibility, but existing systems often only simplify these internally, ultimately outputting a single risk value or a simple conclusion. The lack of a unified organization of intermediate analytical evidence makes it difficult to truly form unified, interpretable, and verifiable analytical results from heterogeneous intelligence.

[0006] Furthermore, attached Figure 1In the existing technical architecture shown, risk assessment often relies too heavily on external reputation results, blacklist hits, or a limited set of rules, lacking comprehensive correction for the semantics of the infrastructure to which the target IP belongs, the business context, and background noise from the internet. For example, when the target IP actually belongs to a cloud vendor, CDN, enterprise SaaS service, or internet mapping infrastructure, if the system scores based solely on historical malicious records, open ports, or scanning traces, false alarms are likely to occur. Similarly, for normal office traffic, browser access, system update traffic, and other scenarios, the lack of contextual information such as hostname, process name, direction, and port can easily lead to misjudging normal behavior as high-risk communication.

[0007] In open extension scenarios that support third-party or community plugins, attached Figure 1 The existing technical architecture shown still has serious security vulnerabilities. Existing solutions either treat all plugins as trusted components and execute them directly in the main process, which directly affects the stability of the main platform if a plugin has abnormalities, infinite loops, excessive resource consumption, or malicious behavior; or they only use coarse-grained independent process execution, which lacks the determination of plugin trust boundaries, minimum environment exposure, unified communication protocol, and failure fallback mechanism, and cannot balance open expansion and platform operation security.

[0008] Therefore, appendix Figure 1 The existing technical architecture shown can achieve multi-source querying and risk output for a single IP to a certain extent, but it still has the following common and unresolved core technical defects: The intelligence source access is severely coupled: adding a new intelligence source requires modifications in multiple places, and source-specific knowledge is scattered across multiple modules such as collection, normalization, and scoring, resulting in extremely poor system scalability and maintainability; Heterogeneous results are difficult to unify: The return formats and field meanings of different intelligence sources vary greatly. Existing systems lack a unified structured evidence expression system, making it difficult for heterogeneous intelligence to form a unified and computable basis for fusion reasoning. The analysis chain is opaque and lacks interpretability: most systems only output a single risk score or black and white label, lacking a complete chain of evidence, making it impossible for security analysts to audit, review, and trace the results; The false positive rate remains high: the existing solution relies too much on external reputation results and blacklist hits, and lacks a comprehensive correction mechanism for the semantics of the infrastructure to which the IP belongs, business context, and Internet background noise, which makes it very easy to misjudge legitimate infrastructure and normal business traffic. Open expansion and operational security are difficult to balance: In scenarios that support third-party / community plugins, the lack of effective isolation and constraints on untrusted extension units makes it impossible to ensure the stability of the main platform and data security while enabling open expansion. Core modules continue to expand: As the number of access sources increases, the central normalization module and the central scoring module will continuously accumulate source-specific condition branches, leading to continuous degradation of the system architecture and insufficient long-term evolution capabilities.

[0009] In summary, existing technologies cannot simultaneously achieve loosely coupled heterogeneous intelligence source expansion, unified structured evidence organization, low false positive risk reasoning, interpretable result output, and secure open expansion capabilities. There is an urgent need for a novel IP threat intelligence reasoning technology solution to address these issues. Summary of the Invention

[0010] To address all the aforementioned shortcomings of existing technologies, this application proposes an IP threat intelligence reasoning scheme based on pluggable intelligence sources, fundamentally solving the core problems existing in the prior art and achieving the following core inventive objectives: 1. Unify the access of various external and internal threat intelligence sources through a self-contained plug-in approach to achieve loosely coupled and highly scalable intelligence source management; 2. Each plugin directly outputs structured evidence with a unified structure, constructing a standardized and computable evidence system to solve the problem of heterogeneous intelligence fusion; 3. Construct a unified profile of the target IP based on multi-source standardized data, and realize the architectural upgrade from "source-by-source judgment" to "unified reasoning around the target object"; 4. Perform semantic enhancement on target IPs to identify their potential service and infrastructure attributes, thereby reducing the probability of misjudging legitimate infrastructure from the source; 5. Combine contextual information such as flow direction, port, hostname, and process name to modify risks in a scenario-based manner, thereby upgrading from static intelligence analysis to dynamic scenario-based risk assessment; 6. Identify background internet noise and mapping / scanning traffic, distinguish between low-interest background activities and real high-threat attacks, and significantly reduce invalid alerts; 7. Integrate multi-source evidence with the correction results to output risk scores, risk levels, decision recommendations, and a complete and explainable chain of evidence, achieving full-process auditability and traceability; 8. While supporting the open plugin ecosystem, a hierarchical isolation execution mechanism is used to ensure system stability and data security, balancing open expansion with operational security; 9. Through caching, snapshots, and persistence mechanisms, it supports historical comparison, result reuse, and audit traceability, reducing system operating overhead.

[0011] To achieve the above-mentioned objectives, the present invention is implemented through the following technical solution: In a first aspect, the present invention provides an IP threat intelligence reasoning method based on pluggable intelligence sources, comprising the following core steps: Step S1: Receive the IP address to be analyzed, and optional context information, wherein the context information includes at least one or more of the following: connection direction, port, hostname, and process name; Step S2: Based on the object type, plugin configuration, and activation status of the IP to be analyzed, determine the set of available pluggable threat intelligence plugins, and concurrently schedule each plugin through the query orchestration module to execute the intelligence query task for the IP to be analyzed. Step S3: Obtain the unified format query results returned by each threat intelligence plugin. The query results include at least the data source, raw data, standardized data, and a set of structured evidence items. Step S4: Iterate through the results returned by each plugin, construct a unified profile of the IP to be analyzed based on standardized data, and fill the same profile field according to a preset priority strategy; Step S5: Perform semantic enhancement processing based on the unified profile of the IP to be analyzed, identify the service attributes and infrastructure attributes of the target IP, generate corresponding service semantic tags and write them back to the profile; Step S6: Calculate the basic risk based on the set of structured evidence items, then perform risk correction by combining service semantic tags and context information, and simultaneously perform background noise identification to finally obtain the corrected risk evidence; Step S7: Integrate all plug-in evidence, semantic tags, context-corrected evidence, noise evidence and other analytical evidence to generate a final ruling result. The final ruling result shall include at least a risk score, risk level, disposal recommendations and a complete and interpretable chain of evidence. Step S8: Cache and persistently store the unified profile of the IP to be analyzed and the final decision result. When refreshing the query, archive the historical snapshot first and then save the new result.

[0012] As a preferred technical solution, the plugin adopts a unified metadata description defined by a unified plugin contract, including information such as plugin name, display name, version, supported object types, whether an APIKey is required, rate limit, priority, tags, and description; the plugin execution method distinguishes between trusted and untrusted plugins, with trusted plugins executing in the main process and untrusted plugins executing in isolated child processes, in order to balance open extension and operational security.

[0013] As a preferred technical solution, each piece of evidence in the structured evidence set includes elements such as source, category, severity, title, description, score increment, and confidence level, ensuring that the entire analysis process is traceable and auditable.

[0014] As a preferred technical solution, when constructing a unified IP profile, the field filling strategies that can be adopted include, but are not limited to: high priority priority, last written priority, earliest written priority, authoritative source priority, high confidence priority, latest time priority, multi-source voting decision, unified decision after multiple values ​​coexist, and specifying different merging strategies for each field.

[0015] As a preferred technical solution, semantic enhancement processing can be implemented in ways including but not limited to: rule engines, machine learning classifiers, knowledge graph reasoning, graph matching, external semantic services, joint profiling services, or combinations thereof.

[0016] As a preferred technical solution, context risk correction can be implemented in ways including but not limited to: rule addition / deduction of scores, scoring cards, conditional probability models, Bayesian models, graphical models, supervised learning models, anomaly detection models, historical baseline deviation models, or combinations thereof.

[0017] As a preferred technical solution, noise analysis can be implemented in ways including but not limited to: external noise intelligence sources, scanning signature databases, statistical pattern recognition, connectivity breadth and frequency analysis, cluster analysis, time series pattern recognition, graph analysis, honeynet hit pattern analysis, or combinations thereof.

[0018] As a preferred technical solution, the implementation methods of fusion adjudication include, but are not limited to: rule fusion, weighted scoring, hierarchical scoring, probabilistic inference, Bayesian inference, factor graph reasoning, graph reasoning, ranking model, voting mechanism, classification model, deep learning model, large language model-assisted explanation, or a combination thereof.

[0019] Secondly, the present invention provides an IP threat intelligence reasoning system based on pluggable intelligence sources for implementing the above method, the system comprising at least the following modules: Input module: Used to receive the object to be analyzed and optional context. The preferred input object is an IP address. The query orchestration module is used to schedule plugins, analyzers, and adjudication modules according to the type of object to be analyzed, forming a complete pipeline. Plugin registration and discovery module: Used to automatically discover and load built-in plugins and community plugins based on configuration, and filter enabled plugins that support the current object type; Multiple pluggable threat intelligence plugin modules: Each plugin is a self-contained access unit responsible for collecting data from specific intelligence sources, generating standardized data, and outputting structured evidence; Profile building module: Apply the standardized data returned by each plugin to the target IP profile to form an IP profile that includes information such as organization, country, ASN, network segment, reverse DNS, hostname, and source data; Semantic enhancement module: used to identify whether a target IP belongs to a semantic category such as cloud service, CDN, Microsoft / Google service based on information such as service directory and tag rules; Context risk correction module: used to perform positive and negative corrections on target risks based on context such as connection direction, port, hostname, process name, etc. Noise analysis module: used to identify internet background noise, mapping infrastructure, and common scanners, avoiding their direct identification as high-threat attack sources; Fusion adjudication module: integrates plug-in evidence, semantic enhancement results, contextual evidence, and noisy evidence to generate the final risk score, level, decision, and summary; The results caching and persistence module is used to cache intermediate results and final decisions, and can archive historical snapshots when refreshing queries.

[0020] Thirdly, the present invention provides an electronic device comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the IP threat intelligence reasoning method described in the first aspect.

[0021] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the IP threat intelligence reasoning method described in the first aspect.

[0022] The advantages and effects of this application are as follows: 1. Significantly reduces the cost of accessing new intelligence sources and achieves loosely coupled expansion: This invention uses a self-contained plug-in mechanism to completely converge the access of new sources from multi-module linkage modification to the addition of a single plug-in file and configuration item. The source-specific collection, standardization, and evidence generation logic are completely encapsulated within the plug-in. The platform core does not need to understand the private formats and rules of different sources, thereby significantly reducing system coupling and maintenance costs. According to actual tests, the development workload of new intelligence sources is reduced by more than 90% compared with existing technologies.

[0023] 2. Enhance the unified processing capability of multi-source heterogeneous intelligence and build a standardized evidence system: This invention converts the heterogeneous outputs of different intelligence sources into standardized data and structured evidence in a unified format through a unified plug-in return structure and a unified evidence item system. The outputs of all sources can enter the same adjudication framework, which completely solves the core problem of heterogeneous intelligence being difficult to integrate and unable to be uniformly calculated in the existing technology, and lays a standardized foundation for multi-source intelligence fusion reasoning.

[0024] 3. Significantly improves the interpretability and auditability of analysis results: The final output of this invention is not an unauditable black-box score, but a risk conclusion with a complete chain of evidence. Each conclusion has a corresponding source, severity, confidence level and weight description. Security analysts can completely trace every link in the analysis chain, fully meeting the full-process auditing needs of network security level protection, attack and defense drills, incident tracing and judicial evidence collection.

[0025] 4. Significantly reduce false positive rate and improve the accuracy of risk assessment: This invention uses a three-layer linkage of semantic service recognition, context behavior correction, and noise analysis to suppress false positives. It can accurately identify scenarios prone to misjudgment, such as cloud services, CDN, office services, surveying and mapping infrastructure, normal business traffic, and Internet background noise. According to actual tests, the false positive rate is reduced by more than 70% compared with existing technologies. At the same time, through a strong malicious evidence boundary constraint mechanism, it explicitly prohibits weak semantic signals from covering strong malicious evidence, thereby reducing false positives and completely eliminating the risk of missed reports.

[0026] 5. Balancing Open Expansion Ecosystem with Platform Operation Security: This invention employs a plugin trust level classification and isolation execution mechanism. For untrusted plugins, it utilizes a complete set of technical measures, including independent subprocess execution, minimal environment variable exposure, timeout and resource limits, unified request / response protocol, and fallback for abnormal failures. This allows the system to securely extend with community plugins and third-party plugins without affecting the stability and data security of the main platform, thus solving the core pain point in existing technologies where open expansion and operational security cannot be balanced.

[0027] 6. Avoiding the continuous expansion of the central normalization and scoring module, and improving the long-term stability of the architecture: This invention completely converges all source-specific processing logic into the plugin. The platform core no longer continuously accumulates source-specific branch code as the number of access sources increases. The central module remains stable and will not suffer from the architecture degradation problem of "the more access sources, the more bloated the system, and the more difficult the maintenance" in the existing technology. This greatly improves the long-term stability and maintainability of the system architecture.

[0028] 7. Supports historical snapshots and result reuse, reducing system operating overhead: This invention can significantly reduce the overhead of repeated third-party API calls and local computing overhead through caching and persistent snapshot mechanisms. At the same time, it provides complete data support for subsequent historical comparison, trend analysis, report generation, and audit traceability, and has strong engineering practicality.

[0029] 8. Possesses strong architectural scalability and evolution capabilities: This invention adopts a modular, loosely coupled, and pipelined architectural design. All modules can be independently extended and replaced. It can smoothly support more observable object types such as domain names, URLs, and file hashes in the future, and can expand more analytical capabilities. At the same time, it supports multiple deployment forms such as single machine, cluster, containerization, and SaaS, providing a solid foundation for the long-term evolution and ecosystem construction of the platform.

[0030] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the preferred embodiments of this application are described in detail below with reference to the accompanying drawings.

[0031] The above and other objects, advantages and features of this application will become more apparent to those skilled in the art from the following detailed description of specific embodiments in conjunction with the accompanying drawings. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In all drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0033] Figure 1 This is a schematic diagram of the architecture of an existing IP threat analysis system. Figure 2 This is a diagram illustrating the overall architecture of the IP threat intelligence reasoning system described in this invention. Figure 3 This is a flowchart of the IP threat intelligence reasoning method described in this invention; Figure 4 This is a schematic diagram of the unified return structure of the plugin described in this invention; Figure 5 This is a schematic diagram of the multi-source evidence fusion adjudication method described in this invention; Figure 6 This is a schematic diagram of plug-in isolated execution in a preferred embodiment of the present invention; Figure 7 This is a schematic diagram of the false alarm suppression processing link in a preferred embodiment of the present invention. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. In the following description, specific details such as specific configurations and components are provided merely to help fully understand the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. In addition, for clarity and brevity, descriptions of known functions and structures are omitted in the embodiments.

[0035] It should be understood that the phrase "an embodiment" or "this embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "an embodiment" or "this embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0036] Furthermore, reference numerals and / or letters may be repeated in different examples within this application. Such repetition is for the purpose of simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed.

[0037] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" in this article describes another type of relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " in this article generally indicates that the related objects before and after it are in an "or" relationship.

[0038] In this article, the term "at least one" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, "at least one of A and B" can mean: A exists alone, A and B exist simultaneously, or B exists alone.

[0039] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion.

[0040] Example 1: End-to-end threat intelligence inference for a single IP address Taking a specific IP address to be analyzed as an example, the user submits the target IP address to the system via CLI, web page, API interface, or batch task file, along with context information: the connection direction is outbound, the destination port is 443, the hostname is the office software domain name corresponding to office.com, and the process name is the Chrome browser process.

[0041] The complete execution flow and instruction manual for this embodiment are attached. Figure 3 The method flowchart shown corresponds completely, and the specific steps are as follows: Step S1: Receive the object to be analyzed and context information The input module receives the target IP and context information submitted by the user, performs format validation, and then passes it to the query orchestration module. This step corresponds to the appendix. Figure 2 Input modules in the system architecture.

[0042] Step S2: Determine the set of available plugins and execute queries concurrently. The query orchestration module identifies the object to be analyzed as an IP type and initiates a query to the plugin registration and discovery module. The plugin registration and discovery module then filters out registered plugins that support IP types and are currently enabled, forming a set of available plugins. In this embodiment, the set of available plugins includes built-in plugins such as AbuseIPDB, OTX, GreyNoise, VirusTotal, Shodan, RDAP, Reverse DNS, Honeynet, and Internal Flow, as well as third-party plugins enabled by the user.

[0043] The query orchestration module, through the plugin scheduling unit, concurrently calls all plugins in the available plugin set, passing the IP to be analyzed and execution parameters to each plugin. This step corresponds to the appendix. Figure 2 The system architecture includes a query orchestration module and a plugin registration and discovery module.

[0044] Step S3: Obtain the unified query results returned by each plugin. Each plugin independently initiates a query to its corresponding intelligence source, obtains the raw response data, completes the field standardization transformation and structured evidence item generation within the plugin, and finally returns the query results to the main platform through a unified result structure.

[0045] For the unified return structure of the plugins in this step, please refer to the attached manual. Figure 4 Each plugin returns the following results: data source, raw data, standardized data, evidence item set, execution status, and error information. The standardized data is used for subsequent IP profile construction, and each piece of evidence in the evidence item set includes source, category, severity, title, description, score increment, and confidence level, which are used for subsequent fusion adjudication.

[0046] In this embodiment, the plugin layer has completely integrated all source-specific logic for data collection, standardization, and evidence generation into the plugin itself, so the main platform does not need to write any specific parsing logic for different sources.

[0047] Step S4: Construct a unified profile of the target IP The profile building module iterates through the standardized data returned by all plugins and fills the standardized fields into the corresponding fields of the IP profile according to the preset priority of the plugins. For the same profile field, if it has been filled by a higher priority plugin, the original value is kept unchanged. Only when the higher priority plugin has not filled it, the content of the lower priority plugin is used to fill it.

[0048] In this embodiment, the final unified IP profile includes full-dimensional attributes such as organization information, country / region information, ASN information, network segment information, reverse DNS records, hostname information, service fingerprint information, and source data references. This step corresponds to the appendix... Figure 2 The profile building module in the system architecture.

[0049] Step S5: Perform semantic enhancement processing to generate service semantic tags. The semantic enhancement module reads organization information, hostname, service fingerprint, and network affiliation data from the unified IP profile. Using its built-in service semantic rule base and IP affiliation knowledge graph, it identifies that the IP belongs to Microsoft Office Services infrastructure, generates service semantic tags corresponding to "Microsoft Service," "Office Service," and "Legitimate Infrastructure," and writes these tags back to the IP profile. This step corresponds to the attached... Figure 2 Semantic enhancement module in system architecture, appendix Figure 7 The first layer of semantic recognition in the false alarm suppression link.

[0050] Step S6: Perform risk analysis and corrective action The risk correction module executes a complete risk analysis and correction process, specifically including: Basic risk calculation: Based on the set of structured evidence items returned by all plugins, calculate the basic risk score of the IP to be analyzed; Contextual Risk Correction: Based on the context information submitted by the user, this access is identified as an outbound port 443 access initiated by the browser process to the office service domain, which is normal office traffic. The basic risk score is then downgraded, and contextual correction evidence is generated. This step corresponds to the attached... Figure 2 The context risk correction module in the system architecture, and the appendix Figure 7 Second-layer context correction of the false alarm suppression link; Noise Analysis: Using data returned by the GreyNoise plugin and the built-in scanning feature library, this step confirms that the IP address does not belong to internet noise, mapping traffic, or common scanners, generating noise classification evidence. (This step corresponds to the attached document.) Figure 2 The noise analysis module in the system architecture, and the attached Figure 7 Third-layer noise analysis of the false alarm suppression link; Boundary constraint verification: Check all evidence items to confirm the absence of strong malicious evidence such as C2 communication, malicious sample distribution, and vulnerability exploitation attacks. Semantic tags and correction logic should function correctly. This step corresponds to the attached document. Figure 7 Boundary constraint control of the false alarm suppression link.

[0051] Finally, the context-corrected evidence and the noise classification evidence are merged to obtain the corrected risk evidence.

[0052] Step S7: Integrate multi-source evidence to generate the final ruling. The fusion adjudication module integrates all structured evidence items, service semantic tags, and corrected risk evidence returned by the plugin. Through weighted scoring and rule verification, it comprehensively calculates the final risk score, classifies the risk level as low risk, and generates a disposal suggestion of "allowing normal office traffic". At the same time, it summarizes all evidence items, tags, and correction basis to form a complete and interpretable evidence chain and outputs the final adjudication result.

[0053] The multi-source evidence fusion adjudication logic for this step is detailed in the appendix to the instruction manual. Figure 5 This step corresponds to the attached document. Figure 2 The fusion adjudication module in the system architecture.

[0054] Step S8: Caching and Persistent Storage The storage module writes the generated unified IP profile and the final ruling result to the cache, setting the cache validity period to 24 hours. Repeated queries within the validity period will directly return the cached results. Simultaneously, it writes all data to persistent storage and archives a snapshot of the current query. For refresh query scenarios, the system first archives historical snapshots and then saves the new results for subsequent historical comparison and audit tracing. This step corresponds to the attached... Figure 2 The result caching and persistence module in the system architecture.

[0055] The overall system architecture used in this embodiment is consistent with the appendix to the specification. Figure 2 The overall system architecture diagram shown is a perfect match.

[0056] Example 2: Implementation of Plug-in Extension for Adding Intelligence Sources In this embodiment, the platform administrator needs to add a new source of business threat intelligence. (See attached...) Figure 1In the existing technologies shown, it is usually necessary to add a collector, modify the central normalization module, modify the unified scoring logic, and add configuration items, covering multiple core modules; however, in this embodiment, adding an intelligence source only requires two steps and does not require modification of the platform's core code: Write a plugin file that conforms to the unified plugin contract of this invention. Within the plugin, fully encapsulate the API calls, raw data collection, field standardization transformation, and structured evidence generation logic of the intelligence source. The plugin's return results strictly adhere to the appendix. Figure 4 The unified structure shown; Add the plugin's activation configuration, priority, API Key authentication parameters, timeout, resource limits, and other runtime parameters to the external configuration file.

[0057] When the system starts, the plugin registration and discovery module automatically scans the preset plugin directory, discovers the new plugin, reads the plugin metadata and completes the integrity and legality verification, and completes the plugin registration. During runtime, the query orchestration module can schedule the plugin to perform query tasks normally according to the object type and activation status. The results returned by the plugin can be normally incorporated into the entire process of profile construction, analysis and adjudication, realizing true low coupling and non-intrusive extension.

[0058] Example 3: Secure Isolation Execution Implementation Method for an Open Plugin Ecosystem In this embodiment, the platform supports third-party plugins from the community to access the analysis link. To ensure the stability of the main platform and data security, the system executes a complete isolated execution process, as detailed in the appendix of the specification. Figure 6 The details are as follows: Plugin trust level determination: The system determines official built-in plugins as trustworthy plugins based on the plugin source directory, configuration rules, and whitelist rules, and determines community third-party plugins and user-defined plugins as untrustworthy plugins.

[0059] Execution path routing: For trusted plugins, they are executed directly in the main process, reducing execution overhead; for untrusted plugins, they enter an isolated execution path, where the isolated execution control module manages their entire lifecycle.

[0060] The entire process of isolating untrusted plugins: Read the isolated execution configuration of the untrusted plugin, including execution timeout, memory limit, CPU limit, required environment variables and authentication parameters; Construct a standardized request object, including plugin identifier, IP to be analyzed, object type, runtime configuration, and resource limit parameters; Filter out the minimum necessary environment variables, and only pass the corresponding intelligence source authentication parameters required for the execution of the plugin to the plugin, without exposing other plugins' API keys, platform global session keys, system sensitive information and other irrelevant content; Start an independent child process as an isolated execution space, and pass the standardized request object and restricted environment variables to the child process; After receiving the request, the child process applies the preset timeout and resource limits, loads the target plugin, injects configuration and environment variables, executes the plugin query logic, and converts the execution result into a unified response object to return to the main process. Abnormal fallback handling: If a plugin encounters a timeout, infinite loop, crash, exit exception, or returns an illegal format during execution, the main process will immediately terminate the child process, reclaim system resources, generate standardized failure results, and continue executing the main analysis process, ensuring that the overall analysis task is not interrupted due to a single plugin exception.

[0061] Example 4: Implementation of Multi-Level False Alarm Suppression In this embodiment, the system executes a complete three-layer false positive suppression process for scenarios with high false positive rates, while avoiding false negatives through a boundary constraint mechanism. For details of the processing chain, please refer to the appendix of the specification. Figure 7 The details are as follows: First layer: Semantic service recognition layer Based on the target IP's basic profile, it identifies whether it belongs to legitimate semantic categories such as cloud service providers, CDN, office services, system update services, and internet mapping infrastructure, and generates corresponding service semantic tags to provide a basis for subsequent risk correction, thereby avoiding misjudging legitimate infrastructure as high-threat targets from the root.

[0062] Second layer: Context correction layer By combining contextual information such as connection direction, port, hostname, and process name, risks can be modified in a scenario-based manner, distinguishing between normal office traffic, browser access, system update traffic, and malicious access. This enables differentiated risk assessment of the same IP in different business scenarios, avoiding misjudgments caused by static intelligence analysis.

[0063] Third layer: Noise analysis layer Identify whether the target belongs to low-interest background activities such as Internet background noise, mapping traffic, common scanner activities, or research scans, and downgrade its weight to significantly reduce invalid alarms.

[0064] Boundary constraint control The system has pre-defined rules for judging strong malicious evidence. When a target has strong malicious evidence such as C2 communication, malicious sample distribution, vulnerability exploitation attacks, or clear intrusion behavior, semantic tags and corrective evidence are prohibited from directly overriding the basic risk judgment to ensure that there will be no missed reports due to excessive weighting.

[0065] Finally, the basic threat evidence, semantic tags, context correction results, and noise analysis results are input into the fusion adjudication module to generate a final adjudication result that balances low false positives and low false negatives, while ensuring the interpretability of the result.

[0066] Furthermore, in a preferred embodiment of the present invention, a technical approach is adopted that includes pluggable intelligence source access, unified result object, target object profile construction, semantic enhancement, context correction, noise analysis, and fusion adjudication to achieve multi-source threat intelligence reasoning and interpretable judgment of the object to be analyzed. However, the present invention is not limited to the aforementioned specific implementation. Any equivalent substitution, modification, combination, or simplification made to the relevant structure, modules, connection relationships, data organization forms, processing steps, execution sequence, deployment form, or implementation method without departing from the core concept of the present invention should be considered as an alternative to the present invention and should fall within the protection scope of the present invention.

[0067] 1. Alternative solutions for the object to be analyzed In a preferred embodiment, the object to be analyzed is preferably an IP address, and a target profile is constructed around the IP address, followed by semantic enhancement, contextual analysis, noise analysis, and final adjudication. However, this invention is not limited to using IP addresses as the sole object type. Alternatively, the object to be analyzed can also be a domain name, URL, file hash, email address, certificate fingerprint, hostname, autonomous system number, account identifier, session identifier, terminal identifier, asset identifier, or other observable objects. Furthermore, the object to be analyzed can be a combination of multiple objects, such as composite objects like "IP + domain name," "IP + URL," "IP + port," "IP + process name," or "domain + URL + certificate fingerprint." Any method that enables multi-source intelligence access, structured evidence generation, object profile construction, and risk adjudication falls under the category of equivalent alternatives to this invention.

[0068] 2. Alternative input methods In a preferred embodiment, the object to be analyzed can be input into the system via command line, API call, web page, or batch task file. However, the present invention is not limited to these input methods. Alternatively, the object to be analyzed can also be actively pushed or triggered by message queues, streaming processing platforms, timed scheduling systems, external security devices, log platforms, terminal probes, email systems, gateway devices, browser extensions, SIEM platforms, SOAR platforms, or other third-party systems. The specific form of the input channel is not a limiting feature of the present invention; any input channel that can subsequently enter the multi-source analysis and fusion decision-making chain of the present invention is applicable.

[0069] 3. Alternative solutions for intelligence source access units In a preferred embodiment, each threat intelligence source is connected to the system as a plug-in and uniformly scheduled by the query orchestration module. However, this invention is not limited to the specific form of a "plug-in file". As an alternative, the intelligence source access unit can also adopt a script module, dynamic link library, local command adapter, HTTP adapter, RPC adapter, gRPC service, independent microservice, remote agent, database interface, message subscriber, function computing unit, container service, or other access forms that can be uniformly scheduled and can return analysis results. In other words, this invention does not require the code encapsulation method of the access unit, but rather its ability to connect to different intelligence sources and return unified or uniformly processed analysis products to the platform.

[0070] 4. Alternative solutions for intelligence source discovery and registration methods In a preferred embodiment, the system can discover built-in source access units and community source access units by scanning a preset directory and register them into a unified scheduling system. However, the present invention is not limited to the directory scanning method. As alternatives, the intelligence source discovery and registration method can also adopt the registry method, database list method, configuration center distribution method, remote plug-in repository retrieval method, control plane dynamic distribution method, whitelist activation method, manual registration method, or other automatic or semi-automatic discovery methods. As long as a management and calling relationship of multiple available intelligence source access units can be formed, it can be regarded as an equivalent solution of the present invention.

[0071] 5. Alternative solutions for intelligence source configuration methods In a preferred embodiment, the start / stop, priority, authentication parameters, timeout, resource limits, and other operational parameters of the intelligence source can be managed through an external configuration file. However, this invention is not limited to YAML or any particular configuration carrier. Alternatively, the source configuration can come from JSON, TOML, XML, INI, database configuration tables, environment variables, configuration centers, key management systems, Kubernetes configuration objects, SaaS management backends, or other configuration mechanisms. Changes in the configuration method do not affect the essential content of this invention.

[0072] 6. Alternatives to a unified result structure In a preferred embodiment, the source access unit returns a unified result object, which preferably includes raw data, standardized data, a set of evidence items, execution status, and error information. However, the present invention is not limited to this field organization format. As an alternative, the unified result object can also take the form of "raw payload + profile patch + risk contribution item", "source response + structured assertion + risk correction item", "collection layer result + standardization layer result + inference layer result", or streaming segmented return, etc. As long as it can support subsequent profile construction, risk correction, and fusion adjudication, it can be considered an alternative implementation of the present invention.

[0073] 7. Alternative formats for expressing evidence items In a preferred embodiment, multiple source access units and analysis modules all express results around structured evidence items, which are then summarized and adjudicated by subsequent modules. However, this invention is not limited to the name "evidence item" or a flat list structure. As an alternative, evidence can also be represented as evidence entries, risk factors, hit events, rule hit records, attribute assertions, scoring contributions, feature vectors, graph nodes, graph edges, event clusters, time series segments, or other intermediate analysis units that can be used for interpretation and adjudication. The name, data structure, and storage format of the evidence can all vary, as long as it can carry the conclusions of multi-source analysis and participate in the final adjudication, it belongs to the equivalent alternatives of this invention.

[0074] 8. Alternative solutions to target profile construction methods In a preferred embodiment, the system constructs a target object profile based on standardized data returned by multiple source access units. The profile preferably uses an object model to express the target's organization, geography, network, service, hostname, tags, and other attributes. However, this invention is not limited to the object model format. Alternatively, the target profile can also be expressed using a key-value structure, document structure, graph structure, time-series structure, vector structure, multi-layer profile structure, or multi-table association structure. Furthermore, the field set, field naming, and hierarchical organization of the profile can also be varied.

[0075] In a preferred embodiment, different intelligence sources can employ a predetermined priority strategy to populate the same profile field. However, this invention is not limited to the current priority population logic. As alternatives, profile merging strategies can also employ methods such as last-written priority, earliest-written priority, authoritative source priority, high-confidence priority, latest time priority, multi-source voting decision, unified decision after multiple values ​​coexist, and specifying different merging strategies for each field. Any approach that can create an object profile usable for subsequent analysis falls under the category of alternatives to this invention.

[0076] 9. Alternatives to source execution and orchestration processes In a preferred embodiment, multiple intelligence source access units can be invoked concurrently, forming a processing chain of "collection—standardization—enhancement—analysis—adjudication". However, the present invention is not limited to this specific execution method or fixed order. As alternatives, the access units can also be executed serially, concurrently using thread pools, concurrently using process pools, using an Actor model, using a task queue, distributed tasks, in a streaming pipeline, or in stages. The processing order can also be replaced with "collection—enhancement—analysis—adjudication", "collection—initial adjudication—enhancement correction—final adjudication", "parallel collection and enhancement—unified analysis—adjudication", or other processes that can achieve the same purpose as the invention.

[0077] Furthermore, this invention also allows for a layered invocation mechanism, such as first invoking a lightweight intelligence source to form a preliminary judgment, and then triggering a heavyweight intelligence source based on the preliminary result; or first providing a preliminary output based on the cached result, and then performing a refresh query to form the final result. As long as multi-source intelligence reasoning and interpretable adjudication can still be completed in the end, it falls within the protection scope of this invention.

[0078] 10. Alternatives to semantic enhancement methods In a preferred embodiment, the system uses a semantic enhancement module to perform service identification, infrastructure identification, or semantic tag supplementation on the target object to reduce false positives and enhance interpretability. However, the present invention is not limited to implementations based on rule directories or service directories. As alternatives, the semantic enhancement module can also be implemented using rule engines, machine learning classifiers, knowledge graph reasoning, graph matching, external semantic services, joint profiling services, or combinations thereof. The data upon which semantic enhancement is based is not limited to the current profiling fields, but may also include certificate information, domain name resolution chains, banner information, port distribution, organizational relationships, historical access patterns, asset context, etc.

[0079] Furthermore, semantic enhancement does not necessarily have to be performed only after standardization and before analysis. As alternatives, semantic enhancement can be performed directly after data collection, gradually during the profile building process, as a post-correction step before the final decision, or repeatedly during multi-stage analysis.

[0080] 11. Alternatives to context correction methods In a preferred embodiment, the system adjusts the risk of the target object by adding or subtracting weights based on contextual information such as direction, port, hostname, and process name. However, the present invention is not limited to rule-based weighting. As an alternative, the context adjustment module can also employ scoring cards, conditional probability models, Bayesian models, graphical models, supervised learning models, anomaly detection models, historical baseline deviation models, or other implementations capable of adjusting risk based on context.

[0081] Furthermore, contextual input is not limited to the current field. As an alternative, contextual information may also include user identity, device type, asset classification, business system category, traffic volume, connection duration, DNS resolution chain, access time, time zone, terminal behavior, session chain, user operation records, geographical location, network partition information, or other auxiliary information that can reflect the environment and behavioral background of the object.

[0082] 12. Alternative solutions to noise analysis methods In a preferred embodiment, the system uses a noise analysis module to distinguish between internet background noise, mapping traffic, and common scanning activities to reduce false alarms caused by background activity. However, this invention is not limited to relying on a single external noise source or a single scanning identification method. Alternatively, the noise analysis module can be implemented based on external noise intelligence sources, scanning signature databases, statistical pattern recognition, connectivity breadth and frequency analysis, cluster analysis, time series pattern recognition, graph analysis, honeynet hit pattern analysis, or a combination thereof. The noise output category is also not limited to the current classification method and can be background noise, opportunistic scanning, mapping activities, research scanning, bulk probing activities, low-concern noise activities, or other classification systems.

[0083] 13. Alternatives to the integrated adjudication approach In a preferred embodiment, the system integrates multi-source evidence, semantic tags, context correction, and noise analysis results, and the adjudication module outputs a risk score, risk level, disposal recommendation, and evidence chain. However, this invention is not limited to a single fixed scoring method. As an alternative, the fusion adjudication module can employ rule fusion, weighted scoring, hierarchical scoring, probabilistic inference, Bayesian inference, factor graph reasoning, graph reasoning, ranking models, voting mechanisms, classification models, deep learning models, large language models for auxiliary interpretation, or combinations thereof.

[0084] Furthermore, the adjudication module can also adopt forms such as one-time adjudication, hierarchical adjudication, two-stage adjudication, multi-candidate adjudication, coarse adjudication followed by fine adjudication, and real-time adjudication followed by offline re-adjudication. The final output risk value can be numerical, or it can be graded, labeled, Boolean, probabilistic, or range-based. As long as the results of multi-source structured analysis are aggregated into an interpretable final judgment, it can be considered an alternative to the present invention.

[0085] 14. Alternatives to caching, snapshots, and persistence methods In a preferred embodiment, the system can combine caching and persistence mechanisms to save intermediate snapshots and final rulings, and archive old snapshots upon refresh. However, this invention is not limited to a single caching or persistence medium. As alternatives, memory caching, key-value stores, Redis, relational databases, document databases, graph databases, time-series databases, object storage, log-based storage, event sourcing storage, or combinations thereof can be used. Snapshot saving methods can also be replaced with full snapshots, incremental snapshots, compressed archiving, version chain storage, saving only the final ruling, or saving only the evidence chain, etc.

[0086] Furthermore, the cache hit strategy, refresh strategy, obsolescence determination strategy, history retention strategy, and result isolation strategy can all be varied. As long as they still serve the purposes of multi-source analysis reuse, historical comparison, result tracing, and output reuse of this invention, they should all be considered as equivalent alternatives to this invention.

[0087] 15. Alternative solutions for output methods In a preferred embodiment, the system may output structured results, Markdown reports, HTML reports, or narrative reports. However, the invention is not limited to these output formats. Alternatively, the system may also output alarm events, work orders, API callbacks, SOAR actions, message notifications, emails, chat messages, blacklist / whitelist synchronization results, asset tag write-back, graph views, visual dashboards, evidence materials, or other formats. Changes in output format do not affect the essential content of the invention.

[0088] 16. Alternative deployment methods In a preferred embodiment, the present invention can be manifested as a query analysis platform or service system. However, the present invention is not limited to a single-machine or single-service deployment. Alternatively, it can be deployed as a multi-process system, microservice system, containerized system, Kubernetes cluster service, SaaS platform, edge node service, gateway component, security operations center backend module, SIEM embedded analysis module, SOAR linkage module, EDR / NDR extension module, or cloud-native analysis platform. Changes in the deployment environment and system boundaries do not affect the inventive purpose and core technical concept of the present invention.

[0089] 17. Alternative Implementation of the Complete Technical Solution In addition to the aforementioned substitutions for local structures, steps, or modules, this invention also allows for equivalent substitutions using complete technical routes. For example, in one alternative, instead of using a local plugin for unified scheduling, multiple remote intelligence microservices return profile patches, risk factors, and explanatory entries, which are then used by a central analyzer for object profile construction and fusion adjudication. Another alternative involves abandoning the explicit "standardized data + evidence item set" result structure, instead having each access unit directly output object profile assertions, risk contribution vectors, and explanatory text, with the final output completed by a unified adjudication module. As long as the aforementioned complete alternatives still achieve the inventive objectives of "multi-source intelligence access, structured analysis product generation, target object profile construction, risk correction, and interpretable adjudication," they should be included within the scope of protection of this invention.

[0090] The above description is merely a preferred embodiment of the present invention and does not limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any changes, modifications, substitutions, integrations, and parameter alterations to these embodiments within the spirit and principles of the present invention, achieved through conventional substitutions or by achieving the same function without departing from the principles and spirit of the present invention, fall within the scope of protection of the present invention.

Claims

1. A method for IP threat intelligence reasoning based on pluggable intelligence sources, characterized in that, Includes the following steps: Step S1: Receive the IP address to be analyzed, and optional context information; Step S2: Based on the object type of the IP to be analyzed, determine and schedule the corresponding set of pluggable threat intelligence plugins, and concurrently execute the intelligence query task for the IP to be analyzed. Step S3: Obtain the query results returned by each threat intelligence plugin. The query results include at least raw data, standardized data, and a set of structured evidence items. Step S4 constructs a unified profile of the IP to be analyzed based on the standardized data returned by each threat intelligence plugin; Step S5: Perform semantic enhancement processing based on the unified profile of the IP to be analyzed to generate service semantic tags corresponding to the IP to be analyzed; Step S6 performs risk analysis and correction processing based on the structured evidence item set, service semantic tags, and context information to obtain corrected risk evidence; Step S7: Integrate all structured evidence items, service semantic tags, and corrected risk evidence to generate a final ruling result. The final ruling result includes at least a risk score, risk level, disposal recommendation, and an interpretable chain of evidence. Step S8: Cache and persistently store the unified profile of the IP to be analyzed and the final decision result.

2. The IP threat intelligence reasoning method based on pluggable intelligence sources according to claim 1, characterized in that, The threat intelligence plugin describes its capabilities through unified metadata defined by the unified plugin contract. The metadata includes at least the plugin name, display name, version, supported object types, whether an APIKey is required, rate limit, priority, tags, and description. Each threat intelligence plugin is a self-contained access unit, which internally completes the collection of raw data from the corresponding intelligence source, the standardization and transformation of fields, and the generation of structured evidence items. When scheduling plugins, the set of executable plugins is selected based on object type, plugin activation status, priority, and running conditions.

3. The IP threat intelligence reasoning method based on pluggable intelligence sources according to claim 1, characterized in that, When constructing a unified profile of the IP to be analyzed, the same profile field is filled according to the preset priority of the plugins. Only when a high-priority plugin does not fill the field is the standardized data of the low-priority plugins used to fill it. The unified profile includes at least the organization information, country / region information, ASN information, network segment information, reverse DNS records, hostname information, service fingerprint information, and source data references of the IP to be analyzed.

4. The IP threat intelligence reasoning method based on pluggable intelligence sources according to claim 1, characterized in that, The semantic enhancement process specifically involves: based on the organization information, hostname, service fingerprint, and network affiliation information in the unified profile, identifying the infrastructure attributes and service attributes corresponding to the IP to be analyzed through one or more of the rule base, knowledge graph, and machine learning classifier, and generating corresponding service semantic tags. The service semantic tags include at least cloud services, CDN, office services, system update services, and Internet mapping infrastructure.

5. The IP threat intelligence reasoning method based on pluggable intelligence sources according to claim 1, characterized in that, The context information includes at least one or more of the following: connection direction, port, hostname, and process name; The risk analysis and correction process is as follows: First, the basic risk score of the IP to be analyzed is calculated based on the set of structured evidence items. Then, the basic risk is adjusted by adding or subtracting weights in a scenario-based manner in combination with contextual information. At the same time, the Internet background noise, mapping traffic, and common scanner activity characteristics corresponding to the IP to be analyzed are identified and noise classification evidence is generated. Finally, the corrected risk evidence is obtained by merging them. Furthermore, a pre-defined boundary constraint rule for strong malicious evidence is established. When there is strong malicious evidence that conforms to the rule in the set of structured evidence items, the service semantic tags and the corrected risk evidence are prohibited from directly overriding the judgment result of the basic risk score.

6. The IP threat intelligence reasoning method based on pluggable intelligence sources according to claim 1, characterized in that, The process of scheduling plugins also includes a trust level determination step: Based on plugin source, directory, whitelist rules, and explicit configuration, plugins are divided into trusted plugins and untrusted plugins; Trusted plugins execute within the main process, while untrusted plugins execute in an isolated execution space within an independent child process. Execution timeout limits, resource consumption limits, and minimum necessary environment variable injection are imposed on untrusted plugins. Data exchange is conducted through a standardized request / response protocol, and unified process recycling and failover handling are implemented in case of anomalies.

7. The IP threat intelligence reasoning method based on pluggable intelligence sources according to claim 1, characterized in that, When persisting storage, for refresh query scenarios, the snapshot data of historical queries are archived first, and then the unified profile and final adjudication result of the current query are saved. When caching, the cache validity period and staleness judgment strategy are set. Repeated queries within the validity period directly return the cached adjudication result. Both incremental snapshot and full snapshot storage methods are supported.

8. An IP threat intelligence reasoning system based on pluggable intelligence sources, characterized in that, include: The input module is used to receive the IP address to be analyzed, as well as optional context information; The query orchestration module is used to schedule the corresponding set of pluggable threat intelligence plugins, analyzers and adjudication modules according to the object type of the IP to be analyzed, forming a complete analysis pipeline. The plugin management module is used to register, discover, verify, filter, and manage the lifecycle of threat intelligence plugins. Multiple pluggable threat intelligence plugins are used to connect to corresponding threat intelligence sources, perform data collection, and return query results containing raw data, standardized data, and a set of structured evidence items. The profile building module is used to build a unified profile of the IP to be analyzed based on the standardized data returned by each threat intelligence plugin; The semantic enhancement module is used to perform semantic enhancement processing based on the unified profile of the IP to be analyzed, and generate corresponding service semantic tags; The risk correction module is used to perform risk analysis and correction processing based on the set of structured evidence items, service semantic tags, and contextual information to obtain corrected risk evidence. The fusion adjudication module is used to merge all structured evidence items, service semantic tags, and corrected risk evidence to generate a final adjudication result that includes risk score, risk level, disposal recommendations, and an interpretable chain of evidence. The storage module is used to cache, archive snapshots, and persistently store the unified profile of the IP to be analyzed and the final decision result.

9. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the IP threat intelligence reasoning method based on a pluggable intelligence source as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the IP threat intelligence reasoning method based on pluggable intelligence sources as described in any one of claims 1-7.

Images