Cyber space asset dynamic authentication risk detection method and system and medium

Abstract

The present application relates to the technical field of information security, and in particular to a network space asset dynamic authentication risk detection method, system and medium. The method comprises: collecting structured asset basic data and unstructured security operation data, constructing a multi-dimensional asset vector for each asset, and performing multi-source evidence fusion and confidence quantification to obtain an asset cognitive label; performing entity extraction on the security operation data to form an attack knowledge graph, and then performing rule induction to obtain a rule knowledge base; under the constraint of the asset cognitive label and the rule knowledge base, a password candidate set for each asset is generated; the target asset is authenticated by using the password candidate set, and a hit result is generated; and the password template in the attack knowledge graph and the rule knowledge base is updated according to the hit result. Thus, the asset semantic-oriented and continuously evolving directed authentication risk detection is realized, and the efficiency and accuracy of weak password detection are significantly improved under limited detection resources.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a method, system, and medium for dynamic authentication risk detection of cyberspace assets. Background Technology

[0002] With the development of cloud computing, the Industrial Internet, remote work, zero-trust access, and interconnection of multiple branches, the scale of assets exposed both internally and externally within organizations continues to expand. Numerous cyberspace assets, including web systems, VPNs, bastion hosts, databases, middleware, servers, network devices, and security equipment, rely on account passwords or key-based credentials for authentication. As the number of authentication entry points increases, weak passwords, default passwords, legacy passwords, duplicate passwords, and unrectified credentials become significant entry points for attackers to gain access to internal networks, move laterally, and expand their influence. Weak passwords typically refer to passwords with low strength, easy guessing, or that can be cracked using automated tools. Weak password detection is the most fundamental, urgent, and indispensable part of authentication risk management.

[0003] However, the effectiveness of weak password detection relies heavily on the accurate simulation of attacker behavior, but attacker behavior patterns are precisely the most dynamic, covert, and difficult to predefine. As a result, existing authentication risk detection technologies still face the following unresolved technical problems:

[0004] First, there is a cognitive gap between asset semantics and detection strategies. While existing technologies can discover asset IPs, ports, and login points through network scanning, their understanding of assets remains at the level of flat network layer characteristics. They fail to grasp the asset's true business attributes, security level, the importance of authentication entry points, and historical risk background. For example, the same Redis server might be a production node carrying core transaction data or an unmaintained test instance. The attack risks and required detection strategies for these two are vastly different. However, due to a lack of semantic understanding, existing technologies can only apply the same generic password generation strategy to all similar assets. This results in insufficient detection of high-value assets, missing critical authentication risks, while wasting significant detection resources on low-value assets and even leading to false positives.

[0005] Secondly, attack experience cannot be reused. Because unstructured data such as network security attack and defense reports are highly domain-specific (dense technical terms, strong context dependence, embedded sensitive information, attack path narratives, etc.), they are difficult for existing technologies to identify, extract, and structure, let alone convert into machine-usable rules, graphs, or model training data. Therefore, the sources of cryptographic knowledge for existing technologies are usually limited to leaked password databases on the Internet and common organizational characteristics (such as company names and domain names). This results in the authentication risk detection capabilities of existing technologies always lagging behind attackers, and they cannot learn and grow from each network attack practice.

[0006] Third, there is a feedback gap between detection results and strategy optimization. Although existing technologies have a closed-loop business process from discovery to rectification to retesting, this closed loop only operates at the management level and does not involve the data level at all. This means that existing authentication risk detection systems do not become more intelligent with the increase in the number of runs. With the same assets and the same attack patterns, the next detection still needs to traverse the password dictionary to attempt authentication, and it is impossible to use historical experience to make targeted enhancements or ineffective evasion. Summary of the Invention

[0007] To address the aforementioned technical issues, this invention proposes a dynamic authentication risk detection method, system, and medium for cyberspace assets. The aim is to break down the semantic barrier between the physical characteristics of assets and the attacker's practical cryptographic knowledge, and to achieve targeted authentication risk detection that is semantically oriented and continuously evolving. This significantly improves the efficiency and accuracy of weak password detection with limited detection resources.

[0008] Firstly, this application provides a method for dynamic authentication risk detection of cyberspace assets, including the following steps:

[0009] Collect structured asset-based data and unstructured security operation data within the authorized scope;

[0010] Based on asset base data and security operation data, a multi-dimensional asset vector is constructed for each asset.

[0011] Multi-source evidence fusion and confidence quantification are performed on multi-dimensional asset vectors to obtain asset cognitive labels. Each asset cognitive label includes content, source, basis, and comprehensive confidence level.

[0012] Entity extraction and relationship construction are performed on unstructured security operation data to form an attack knowledge graph. The attack knowledge graph is then used to summarize rules to obtain a rule knowledge base that includes account rules, password templates, and industry terminology rules.

[0013] Under the constraints of asset cognitive tags and rule knowledge base, a set of candidate passwords is generated for each asset in a targeted manner;

[0014] The target asset is authenticated using a set of password candidates within the authorized scope, and a successful authentication result is generated.

[0015] Update the attack knowledge graph and password templates in the rule knowledge base based on the hit results.

[0016] Secondly, this application provides a dynamic authentication risk detection system for cyberspace assets, including:

[0017] The data acquisition module is used to collect structured asset-based data and unstructured security operation data within the authorized scope.

[0018] The asset cognition module is used to construct a multi-dimensional asset vector for each asset based on basic asset data and security operation data, and to perform multi-source evidence fusion and confidence quantification on the multi-dimensional asset vector to obtain asset cognition labels. Each asset cognition label includes content, source, basis and comprehensive confidence level.

[0019] The attack knowledge learning module is used to extract entities and construct relationships from unstructured security operation data to form an attack knowledge graph. The attack knowledge graph is then used to summarize rules to obtain a rule knowledge base that includes account rules, password templates, and industry root word rules. The attack knowledge graph and the password templates in the rule knowledge base are updated based on the hit results of the authentication risk detection module.

[0020] The targeted password generation module is used to generate a set of candidate passwords for each asset under the constraints of asset cognitive tags and rule knowledge base;

[0021] The authentication risk detection module is used to attempt to authenticate the target asset within the authorized scope using a set of password candidates and generate a hit result.

[0022] Thirdly, a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the aforementioned method for dynamic authentication risk detection of cyberspace assets, a method, system, and medium for dynamic authentication risk detection of cyberspace assets.

[0023] The beneficial technical effects of the present invention include at least the following:

[0024] 1. A dynamic authentication risk detection method, system, and medium for cyberspace assets are adopted. Through a collaborative mechanism based on asset cognition, guided by attack knowledge, and supported by closed-loop feedback, invalid detection requests are significantly reduced, minimizing disruption to normal business systems and the risk of false locking. Furthermore, the authentication risk detection system is endowed with self-learning and continuous evolution capabilities. Under the constraints of limited authorization time and computing resources, the efficiency, coverage accuracy, and practical combat capability for discovering weak passwords and credentials risks are significantly improved. Specifically, firstly, data silos are broken down during the data collection phase, simultaneously collecting structured asset basic data and unstructured security operation data to provide comprehensive raw materials for subsequent in-depth understanding. Secondly, during the asset cognition phase, the collected data is upgraded to multi-dimensional asset vectors, and a multi-source evidence fusion and confidence quantification mechanism is designed to output asset cognition labels with clear evidence and credibility. This allows the system to see through the business attributes behind asset IPs and ports, the importance of authentication entry points, and historical risk backgrounds, thereby accurately distinguishing core assets from edge test nodes. This completely eliminates the cognitive gap between asset characteristics and detection strategies, allowing detection resources to be allocated on demand. Building upon this foundation, this application directly addresses the challenge of processing unstructured attack and defense data. During the attack knowledge learning phase, it employs entity extraction and relation construction techniques to transform the hidden attack experiences scattered in vulnerability reports and penetration test reports into structured attack knowledge graphs and executable account rules, password templates, and industry terminology rules. This successfully activates the organization's internal asset practical experience, enabling cryptographic knowledge to no longer solely rely on outdated external network leak databases. Subsequently, asset cognitive tags were creatively and dynamically bound to the rule knowledge base, allowing for the creation of differentiated password candidate sets tailored to each asset. This fundamentally improved the targeting and success rate of weak password guessing. Next, targeted authentication attempts were conducted using the password candidate sets, and the results of weak password hits were recorded. Finally, a decision feedback loop was formed based on the hit results, feeding back the lessons learned from each authentication risk detection into the password templates of the attack knowledge graph and rule knowledge base. This drove the dynamic optimization of rules and the continuous evolution of password candidate sets with asset scenarios and attack knowledge. The authentication attempts with the fewest password candidates covered the highest probability of weak password risks, realizing a leap from "indiscriminate blind testing" to "precise countermeasures based on asset cognition and guided by attack knowledge" in the authentication risk detection of cyberspace assets.

[0025] 2. This application fundamentally solves the fatal flaws of existing technology assets such as missing semantics, idle attack experience, and rigid strategies by synergistically constructing multidimensional asset vectors, constructing attack knowledge graphs, and summarizing rules, thereby achieving continuous evolution of authentication risk detection capabilities. Specifically, on the asset recognition side, the system innovatively standardizes the fields of the structured asset base data, actively brute-forces the path, and parses the pages. Combined with the correlation matching of historical risk knowledge index, it constructs a multi-dimensional asset vector for each asset, encompassing network layer facts, application layer semantics, and historical risk experience. This completely breaks the limitation of traditional port scanning, which can only obtain flat features, and elevates assets from "network coordinates" to "business entities." Subsequently, it cleverly introduces an asset identification rule base and a multi-source evidence fusion confidence quantification mechanism to transform heterogeneous evidence such as ports, services, favicons, TLS certificates, historical risk records, and even comprehensive judgments from large models into candidate labels with basic confidence levels. It also innovatively outputs interpretable asset recognition labels containing content, source, basis, and comprehensive confidence levels through consistency fusion and conflict reduction algorithms. This makes asset identification no longer a black-box guess, but a traceable and auditable reasoning process, fundamentally eliminating the cognitive gap between asset semantics and detection strategies. On the attack knowledge side, a dual-track parallel mechanism of "large model semantic extraction + rule deterministic extraction" is adopted to extract entities and relationships from unstructured security operation data. Account roles, password structures, asset types, component services, hit conditions, attack paths, etc. are mapped to nodes and edges of the attack knowledge graph. The advantage of the attack knowledge graph structure is that it can naturally express the multi-hop association relationship between entities, which is convenient for subsequent path reasoning and condition matching. Then, the attack knowledge graph is summarized into account rules, password templates, and industry root rules, and new asset identification rules can be published in reverse to enrich the asset identification rule base, forming a two-way empowerment closed loop of "experience extraction - graph accumulation - rule publication - cognition enhancement". Crucially, the multi-dimensional asset vector scheme and the attack knowledge graph scheme achieve high-precision synergy: fields such as asset type, component, and business attributes in the asset cognitive tags can be directly semantically aligned with nodes in the graph. This means that the generation of password candidate sets for each asset is no longer a general dictionary traversal, but rather a targeted evolution process based on its own business attributes and historical risk records, overlaid with organizational industry terminology, component-specific password templates, and account role rules. This allows for the generation of targeted candidate password sets and the coverage of the highest probability weak password risks with the fewest attempts. At the same time, the hit feedback of authentication attempts continuously feeds back into the attack knowledge graph and rule knowledge base, enabling the system to have self-evolution capabilities. This three-in-one collaborative architecture of "deep asset cognition × attack knowledge graph × closed-loop feedback" significantly improves the targeting, hit rate, and interpretability of weak password detection with limited detection resources, fundamentally solving the industry problems of existing authentication risk detection technologies lagging behind attackers, wasting detection resources, and failing to accumulate practical experience.

[0026] 3. This application fundamentally changes the inefficient "broad-based" approach to weak password detection by finely linking asset cognitive tags and a rule knowledge base. Traditional methods apply the same universal password structure dictionary to all assets, resulting in a massive enumeration of irrelevant password combinations for database assets, while ignoring high-probability structures such as "organization abbreviation + year" for VPN assets. This application, however, precisely defines password generation strategies based on asset cognitive tags, establishing root word sources and password template preferences. It then extracts highly relevant key words from the asset cognitive tags and rule knowledge base; next, it uses historical hit data to calculate the conditional probability of each password template under specific asset types, achieving dynamic sorting and optimization of templates, ensuring that only high-probability password structures valid for similar assets are retained; finally, the optimized password structures are combined with selected key words in a targeted manner. This collaborative mechanism ensures that each generated password candidate carries historical practical experience and business logic for the current asset, eliminating tens of thousands of impossible password combinations from the source. This significantly reduces invalid authentication attempts, lowers business disruption and false positive risks, while significantly improving the hit efficiency and detection accuracy of weak passwords.

[0027] Other features and advantages of the present invention will be disclosed in detail in the following detailed description and accompanying drawings. Attached Figure Description

[0028] The invention will be further described below with reference to the accompanying drawings:

[0029] Figure 1 This is a schematic diagram of the dynamic authentication risk detection method for cyberspace assets according to Embodiment 1 of the present invention.

[0030] Figure 2 This is a schematic diagram of the process for forming an asset recognition tag according to Embodiment 1 of the present invention.

[0031] Figure 3 This is a schematic diagram of the process for forming an attack knowledge graph according to Embodiment 1 of the present invention.

[0032] Figure 4 This is a schematic diagram of the method for generating a candidate set of cryptographic keys for each asset according to Embodiment 1 of the present invention.

[0033] Figure 5 This is a schematic diagram of the structure of the dynamic authentication risk detection system for cyberspace assets according to Embodiment 3 of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of the present invention and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of the present invention.

[0035] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to facilitate the description of embodiments and simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0036] Example 1:

[0037] Please see the appendix Figure 1 , Figure 1 This specification illustrates a flowchart of a dynamic authentication risk detection method for cyberspace assets provided in one embodiment.

[0038] like Figure 1 As shown, the dynamic authentication risk detection method for cyberspace assets may include at least the following steps:

[0039] S1 collects structured asset-based data and unstructured security operation data within the authorized scope.

[0040] Before data collection, the authorization scope can be initialized. The system administrator enters or imports the authorized asset scope for this detection task into the central management platform. This scope includes at least the asset IP, domain name, network segment, detection time window, allowed detection protocol types, maximum concurrency, failure threshold, responsible department, and approval records. The system generates a unique task identifier for this task and writes the authorization boundaries into the audit module to ensure that all subsequent operations are performed within the authorized scope, avoiding legal and business risks caused by unauthorized scanning.

[0041] In this embodiment, the asset basic data is collected through existing network detection units (such as active scanning and passive monitoring). This data includes internal and external IP addresses, domain names, ports, service banners, HTTP headers, web titles, TLS certificates, operating system fingerprints, and middleware characteristics. By collecting extended fields such as TLS certificate information, operating system fingerprints, and middleware characteristics, this embodiment allows for the inference of the true asset type and business attributes from multiple dimensions during the subsequent asset recognition phase, avoiding misjudgments based solely on port numbers.

[0042] This embodiment also simultaneously collects security operation data, including unstructured text such as historical vulnerability scan results, attack and defense exercise reports, penetration test reports, vulnerability notifications, security incident cases, and remediation work orders. This security operation data contains rich attack experience, historical weak passwords, and password patterns specific to certain devices.

[0043] S2 constructs a multi-dimensional asset vector for each asset based on asset base data and security operation data.

[0044] It is understandable that the multidimensional asset vector in this embodiment is the asset profile, which is a bridge connecting the data collection stage and the asset cognition stage, and is also the first level of abstraction for the entire system to move from "raw data" to "deep cognition".

[0045] Specifically, in this embodiment, based on asset base data and security operation data, a multi-dimensional asset vector is constructed for each asset, including:

[0046] S21, standardize the structured asset base data to obtain standardized asset records.

[0047] This process involves standardizing fields, unifying time signatures, identifying sources, anonymizing sensitive fields, and merging duplicate records in all collected structured asset data to create standardized asset records. Specifically, field standardization maps inconsistent fields from different tools to standard names (e.g., "ms-wbt-server" to "rdp", "mariadb" to "mysql"). Time unification converts timestamps from all asset data to a unified time zone and format. Source identification marks the source of each piece of asset data (e.g., "port scan", "report parsing") for easy traceability and credibility assessment. Sensitive field anonymization removes or summarizes plaintext passwords and personal identification information in the asset data to prevent leakage. Duplicate merging merges duplicate records from different sources.

[0048] S22, Perform feature normalization on each asset record to obtain the normalized feature fields of each asset;

[0049] For example, "ms-wbt-server" returned by different scanning tools is uniformly mapped to "rdp", "mariadb" to "mysql", and "ssl / http" to "https". The normalized feature fields include: IP address, port number, protocol type, service name, banner text, HTTP status code, HTTP header key-value pairs, web title, TLS certificate (extracting information such as organization name, common name, validity period, and issuing authority to determine asset ownership and business type), operating system fingerprint (such as TTL value and TCP window size), and middleware identifiers (such as Tomcat, Nginx, and Redis). This step ensures that data from all sources has consistent field names and value formats, eliminating ambiguity caused by heterogeneous data.

[0050] S23. Perform path brute-force operation on each asset to obtain the access path and response status code of each asset. Then, parse the page content of the successfully brute-forced path to extract the page keywords and authentication entry features of each asset.

[0051] In this embodiment, for HTTP / HTTPS services, an additional round of proactive probing is performed after the basic data collection. The path brute-force operation is implemented as follows: the system has a built-in or dynamically loaded dictionary covering common sensitive paths (such as / admin, / login, / api, / console, / manager, etc.). The root URL of the target web service is sequentially appended with paths from the dictionary, and an HTTP GET or HEAD request is sent. The request headers simulate mainstream browsers (such as Chrome and Firefox) to avoid being intercepted by simple User-Agent requests. A reasonable timeout is set for each request (e.g., 5 seconds), and the concurrency is controlled (e.g., 10-20 requests per second) to prevent stress on the target or triggering a WAF. Record all access paths that return a non-404 status (404 Not Found indicates the path does not exist) and their response status codes (e.g., 200 OK indicates the page is accessible and is marked as an "accessible path"; 301 / 302 Found indicates a redirect exists, recording the target URL, which may point to a login page or other resources; 401 Unauthorized indicates the path exists but requires authentication, suggesting the path is a protected resource (e.g., an administrative backend); 403 Forbidden indicates the path exists but access is prohibited, also indicating the path is meaningful and may be a sensitive directory). Furthermore, for the same asset, path results from different dictionaries or different depths can be merged, duplicates removed, and sorted by status code and path semantics (e.g., 401 takes precedence over 200 because authentication entry points are more important).

[0052] Next, for paths successfully brute-forced (returning status codes such as 200, 401, 403, etc.), download the HTML source code of the page. Use regular expressions or a lightweight HTML parser (such as BeautifulSoup style) to extract page keywords and authentication entry features from the HTML. Page keywords include authentication-related (such as login, sign in, username, password, CAPTCHA, etc.), management-related (such as management, Admin, Dashboard, console, etc.), and business-related (such as system name, welcome, company name, copyright information, etc.). Authentication entry features are obtained by parsing the HTML... <form>The extracted tags include the action attribute (the target URL for form submission, such as / login_check), the method attribute (GET or POST), the input field type, whether a password input field exists (if it exists, the page is considered an authentication entry point), and whether a CAPTCHA component exists (check whether the src attribute of the img tag contains keywords such as captcha or verify, or whether there is a separate CAPTCHA input field).

[0053] Understandably, existing passive data collection technologies (such as port scanning and banner identification) can only obtain service banners and homepage content for known ports. However, many web applications place their management backends, debugging interfaces, or backup files in non-standard paths, which cannot be directly discovered through port scanning or banner identification. This embodiment, through path brute-force and page crawling, can uncover deep structural information of web applications, proactively discover authentication entry points, and fill the blind spots of passive data collection.

[0054] S24, build a historical risk knowledge index based on unstructured security operation data.

[0055] The implementation of the historical risk knowledge index involves: parsing unstructured security operation data, segmenting it into paragraphs, and extracting structured data from a large model to output structured records containing entities such as asset descriptions, password samples, and attack paths. Then, a full-text index is built on the asset identifiers (such as IP addresses, domain names, URL paths, and banner fragments) within these records. Each record in the index contains the following metadata: asset identifier, source document ID, discovery time, weak password content (de-identified), default credentials, attack path description, trust level, and associated asset type.

[0056] S25: Extract query conditions from the characteristic fields, access paths, response status codes, page keywords, and authentication entry features of each asset. Match the query conditions with the historical risk knowledge index using keywords. When the keywords match successfully, extract the historical vulnerabilities and historical risk records corresponding to that asset.

[0057] For the target asset currently being processed, the system extracts features that can be used as query conditions from existing fields of its multidimensional asset vector. For example, key features of the current asset (such as IP address, port number, protocol type, service name, banner text, HTTP status code, HTTP header key-value pairs, web title, TLS certificate, operating system fingerprint, middleware identifier access path, response status code, page keywords, and authentication entry features) are used as query conditions. Keyword matching is performed in the historical risk knowledge index. For instance, if the current asset IP is 10.0.0.5, the system searches the index for all records containing `target_ip:10.0.0.5`. If the asset is found to have appeared in the historical risk knowledge index, the corresponding historical weak passwords, default credentials (known factory default usernames and passwords for this asset type, such as root:toor, admin:admin), attack path descriptions (summaries of how attackers used the asset's weak passwords to enter the internal network and move laterally, as recorded in historical reports, such as "obtained external network access through a VPN weak password, and then entered the internal network via an SSH jump server"), and the hit conditions of successful detection at that time are extracted and used as the "Historical Risk Records" field to fill the vector. Historical weak passwords refer to username and password pairs that were hit in past detections for this asset or similar assets (stored after de-identification, such as admin / ****, but retaining password structure information such as admin+year).

[0058] Understandably, this embodiment utilizes keyword matching retrieval technology to perform similarity matching between the feature fields of the current asset and the asset description in the historical risk knowledge index, thereby reusing past security discoveries. This is equivalent to giving the system "memory," helping to avoid redundant work. The "historical risk record" field can be directly associated with password templates extracted during the subsequent attack knowledge learning stage, providing "targeted" clues for dynamic password evolution steps. This allows the system to prioritize trying previously hit weak passwords in the new round of authentication risk detection, thereby significantly improving the hit rate.

[0059] S26. The set of characteristic fields, access paths, response status codes, page keywords, authentication entry features, historical vulnerabilities, and historical risk records corresponding to each asset constitutes the multidimensional asset vector of each asset.

[0060] For each asset, the system constructs a multidimensional asset vector A, which includes, but is not limited to, the following fields: Multidimensional asset vector A = {Network location, Port set, Service protocol, Banner fragment, HTTP Header, Web title, TLS certificate, Response status code, Page keywords, Operating system characteristics, Middleware characteristics, Historical vulnerabilities, Access path, Authentication entry characteristics, Historical risk records}.

[0061] Understandably, existing asset discovery methods only focus on superficial features such as IP addresses, ports, and service names. Their core idea is "detection begins as soon as an asset is discovered," failing to differentiate between different business roles of the same type of asset (e.g., production database vs. test database), and lacking information on historical risk status and authentication entry details. This leads to uniform weak password detection strategies, insufficient detection of high-value assets, wasted resources on low-value assets, and an inability to leverage historical weak password information to improve hit rates. To address this, this embodiment constructs a multi-dimensional asset vector for each asset before asset recognition and reasoning. This multi-dimensional asset vector not only includes network layer facts (IP, port, protocol, banner) but also creatively extends application layer semantics through proactive probing (Web title, page keywords, response status codes, access paths, authentication entry features), revealing the asset's business functions and access methods. Furthermore, it introduces historical risk experience through historical risk association, elevating the asset from a "network coordinate" to a "business entity," imbuing it with sufficiently rich semantic information to lay the foundation for subsequent asset recognition and reasoning.

[0062] S3 performs multi-source evidence fusion and confidence quantification on multi-dimensional asset vectors to obtain asset cognitive labels for accurate asset identification. Each asset cognitive label includes content, source, basis, and comprehensive confidence level.

[0063] The asset recognition tag in this embodiment includes the following:

[0064] 1. Content: Includes asset types (such as hosts, web applications, databases, middleware, network devices, security devices, video surveillance, etc.), components (such as Redis), business attributes (such as database), detection priority, candidate tags, etc.

[0065] 2. Source: What evidence sources triggered the candidate label (e.g., port, service, HTTP, banner, TLS, rules, large model, etc.)?

[0066] 3. Basis: A list of specific evidence facts that match the match (such as "port=6379", "http.title=RabbitMQManagement", "history_match:2025 report found weak password admin / admin123").

[0067] 4. Overall confidence level: A value between 0 and 1, derived from the fusion of multi-source evidence and confidence quantification, reflecting the credibility of the judgment.

[0068] Understandably, existing asset cognition technologies mainly focus on asset discovery and login point identification, with asset information being relatively flat (only IP, port, and service). In contrast, this embodiment constructs a multi-dimensional asset vector, and through multi-source evidence fusion and confidence quantification, outputs structured and interpretable asset cognition tags with content, source, basis, and comprehensive confidence, thereby achieving deep cognition.

[0069] Please see the appendix Figure 2 Specifically, in this embodiment, multi-source evidence fusion and confidence quantification are performed on the multi-dimensional asset vector to obtain asset cognitive labels, including:

[0070] S31, Construct an asset identification rule base. Each rule in the asset identification rule base includes a hit condition and a candidate label.

[0071] The candidate tags include one or more of the following: asset type, component, subtype, business attribute, etc.

[0072] For example, suppose we generate a multidimensional asset vector E = {Network location = 192.168.1.40, Port = 8080, Service name = http, HTTP Header is empty, Banner fragment is empty, but the favicon hash matches the known Tomcat favicon, and the TLS certificate shows the organization name as "Example Corp". Furthermore, historical risk correlation reveals a formal attack and defense exercise report that precisely matches this network location, and historical risk records show "This asset is a Tomcat management backend, previously logged in using admin / admin123"}. The following demonstrates the complete reasoning process from the original multidimensional asset vector E to the final asset cognitive label.

[0073] For example, the asset identification rule base contains the following relevant rules:

[0074] Rule R1: Hit conditions: port=8080 and service=http, output candidate tags: assetType=Web application, component=generic_web;

[0075] Rule R2: Hit condition: favicon_hash="tomcat_favicon_hash", output candidate label: auxiliary evidence, do not output asset type separately;

[0076] Rule R3: Hits condition: TLS certificate organization name is not empty, output candidate tags: assetType=Web application, component=generic_web.

[0077] Furthermore, the historical risk association mechanism itself constitutes an implicit rule: when a historical risk record precisely matches the current asset's network location, the asset type and component in the historical risk record are output as candidate labels.

[0078] S32, match the multidimensional asset vector of the current asset with the hit conditions of each rule in the asset identification rule base one by one. When all the hit conditions of a rule match the multidimensional asset vector of the current asset, the rule is considered to be hit. For each hit rule, record the source and basis of the corresponding candidate label.

[0079] For example, taking the current asset's multidimensional asset vector E as an example, and matching it one by one with the hit conditions of each rule in the asset identification rule base, the matching result is:

[0080] 1. Rule R1 hit: port=8080 and service=http → Output candidate tag A: assetType=Web application, component=generic_web

[0081] Source: source=["port","service","rule"]

[0082] Basis: evidence=["port=8080","service=http","rule=R1:port+httpclassified as web app"].

[0083] 2. Rule R2 hit: favicon_hash match → output candidate tag B: assetType=middleware, component=tomcat

[0084] Source: source=["favicon","rule"]

[0085] Basis: evidence=["favicon hash matches tomcat_favicon_hash","rule=R2:favicon indicates tomcat"].

[0086] 3. Historical Risk Correlation Hit: A precise network location was matched to a formal attack and defense exercise report. The report indicated that the asset was a Tomcat management backend, and had been logged in using admin / admin123 → Output candidate tag C:assetType=middleware,component=tomcat

[0087] Source: source=["history_report"] Basis: evidence=["history_match:2025 formal report identified this IPas Tomcat management console with weak password admin / admin123"].

[0088] At this point, the three candidate tags point to two different conclusions: candidate tag A (Web application) conflicts with candidate tags B and C (middleware - Tomcat). The system marks this as a candidate tag conflict scenario pointed to by the source.

[0089] Furthermore, this embodiment can also introduce an LLM (Large Model of Least Might) as a supplement to solve the problem of identifying long-tail devices and new types of assets that cannot be covered by the asset identification rule base, and avoid the illusion of the LLM large model through a rule verification mechanism.

[0090] For example, the complete fingerprint of the multidimensional asset vector E (port 8080, service http, favicon hash, TLS certificate organization name, historical evidence digest) is submitted to the pre-configured LLM large model. LLM large model output: {

[0091] "assetType":"Middleware",

[0092] "subType":"Apache Tomcat",

[0093] "confidence":0.88, "evidence":["favicon matches Tomcat signature","TLS certificateorganization suggests enterprise application","historical record confirmsTomcat management interface"],

[0094] "ruleHits":["favicon rule","history match"]}

[0095] The matching result is as follows: The output of the LLM large model is consistent with the association of rule R2 and historical risk, but conflicts with rule R1. According to the rule verification mechanism (high confidence rule takes precedence, and both sides are retained in case of conflict), the LLM large model result is adopted as candidate label D, with the source being ["llm"].

[0096] S33, based on the predefined base confidence scores corresponding to different types of sources, determine the base confidence scores for each source of each candidate label.

[0097] In this embodiment, an evidence source-basic confidence level mapping table is predefined. This mapping table is based on statistical analysis of a large amount of historical data (such as calculating the accuracy of each evidence source in determining asset types individually) and the experience-based calibration of security experts. The mapping table assigns a confidence level range to each evidence source, rather than a fixed value, to accommodate differences in matching quality within the same source. A typical mapping relationship is as follows:

[0098] 1. Port hit only: 0.55–0.65 (The port number may be associated with multiple services, such as 8080, which could be either Tomcat or Jenkins, so the confidence level is low)

[0099] 2. Service name hit: 0.75–0.85 (Service names such as "redis" are more distinctive than ports, but can still be spoofed)

[0100] 3. Product / Version Match: 0.80–0.90 (If the banner contains "nginx / 1.18.0", both the product name and version must be confirmed).

[0101] 4. Banner text hit rate: 0.80–0.92 (Banner text typically contains detailed service identifiers, such as "SSH-2.0-OpenSSH_8.9p1")

[0102] 5. HTTP header hit rate: 0.80–0.95 (headers such as "RabbitMQ Management" have strong semantic relevance)

[0103] 6. Favicon hash hit rate: 0.90–0.98 (Favicon hashes are usually unique identifiers for specific applications, with an extremely low false positive rate)

[0104] 7. TLS certificate hit rate: 0.70–0.88 (The organization name and domain name in the certificate can help determine this, but wildcards or self-signed certificates may exist).

[0105] 8. Comprehensive judgment of large model: 0.60–0.90 (Large model can handle complex semantics, but there is a risk of hallucination, so the range is relatively wide).

[0106] For each source of matching evidence, a specific value can be selected from the corresponding range based on the precision and specificity of the match. The selection rules include exact match (if the evidence field is exactly equal to the rule condition, the higher value of the range is selected) and partial match (if the evidence field contains keywords but is not exactly equal, the lower value of the range is selected).

[0107] 9. When historical risk records are used as an independent source of evidence in fusion, their confidence level is determined by the source's credibility and the matching accuracy. The base confidence level of a historical risk record source = source credibility × matching accuracy. Source credibility is set according to the data type; for example, a formal attack / defense exercise report is 0.95, a penetration test report is 0.90, a vulnerability report is 0.85, and manually entered samples are 0.70. In terms of matching accuracy, exact match (same IP, port) is 1.0, and semantic search match (similar assets) is 0.7-0.9. Because historical risk record sources typically have high credibility, they can significantly improve the overall confidence level of asset tags, especially when current detection evidence is weak or conflicting; in such cases, historical risk record sources can play a decisive role.

[0108] For example, assign values ​​to the sources of the candidate tag AD:

[0109] 1. Candidate Tag A (Web Application):

[0110] Port 8080 hit: 0.61 (interval midpoint, exact match); Service HTTP hit: 0.76 (service name is not a strong match). Source confidence list: [{source:"port",value:0.61},{source:"service",value:0.76}]

[0111] 2. Candidate tag B (middleware - Tomcat, from rule):

[0112] Favicon hash hit: 0.95 (favicon is very specific, take the upper edge of the range); TLS certificate hit: 0.80 (organization name auxiliary, take the median). Source confidence list: [{source:"favicon",value:0.95},{source:"tls_cert",value:0.80}]

[0113] 3. Candidate label C (middleware - Tomcat, based on historical evidence):

[0114] Historical risk record: Source confidence 0.95 (official report) × Match accuracy 1.0 (exact IP) = 0.95. Source confidence list: [{source:"history_report",value:0.95}]

[0115] 4. Candidate tag D (middleware - Tomcat, from LLM):

[0116] LLM large model judgment: 0.88 (sufficient evidence, higher value in the interval). Source confidence list: [{source:"llm",value:0.88}]

[0117] Understandably, assigning a basic confidence level to a single source is a crucial step in transforming the candidate labels generated by rule matching from "qualitative judgment" to "quantitative credibility," ensuring the interpretability and auditability of the asset recognition process. The core idea of ​​step S33 is that different types of evidence sources have different inherent reliability, and it is necessary to quantify the degree of support for the label by using a preset confidence level benchmark.

[0118] S34. Perform a consistency judgment on the sources of all candidate labels for the current asset. If all sources point to the same candidate label, perform a consistency fusion calculation on the basic confidence of each source of the candidate label to obtain the overall confidence of the current asset. If all sources point to conflicting candidate labels, perform a conflict reduction calculation on the basic confidence of each source of the candidate label to obtain the overall confidence of the current asset.

[0119] On the one hand, when all sources point to the same candidate label, the overall confidence score obtained by consistency fusion calculation is 1 - (1 - c1) × (1 - c2) × ... × (1 - cn), and then multiplied by a normalization factor. Here, c1 - cn represents the basic confidence score of each source for all candidate labels. For example, if c1 = 0.60 and c2 = 0.82, then 1 - (1 - 0.6) * (1 - 0.82) = 1 - 0.4 * 0.18 = 1 - 0.072 = 0.928. The consistency fusion calculation method proposed in this embodiment naturally reflects the characteristic that the more sources there are, the higher the confidence score, and the decreasing rate of increase.

[0120] On the other hand, when there is partial consistency or complete conflict among the candidate labels pointed to by all sources, the conflict weighting calculation prioritizes the asset type corresponding to the source with higher basic confidence as the final candidate label output. Consistency fusion calculation is performed on all sources that support the final candidate label, and then multiplied by the conflict discount (such as 0.85-0.95) to obtain the comprehensive confidence, while retaining the basis for conflict.

[0121] For example, in a scenario where candidate tag A (Web application) conflicts with candidate tags B, C, and D (middleware - Tomcat), the basic confidence scores of each source of the candidate tags are weighted according to the conflict. The implementation method is as follows:

[0122] There are three sources supported for middleware: favicon (0.95), historical risk records (0.95), and LLM (0.88). There are two sources supported for web applications: port (0.61) and service (0.76).

[0123] First, the sources were ranked by their basic confidence scores: favicon (0.95) > historical risk records (0.95) > LLM (0.88) > service (0.76) > port (0.61). The sources supporting middleware had significantly higher basic confidence scores than those supporting web applications; therefore, the middleware conclusion was selected as the final candidate label output.

[0124] Next, a consistency fusion calculation is performed on the three sources supporting the middleware (favicon, history, and LLM). Confidence level = 1 - (1 - 0.95) × (1 - 0.95) × (1 - 0.88) = 0.9997. Due to the existence of conflicts, a conflict discount of 0.90 is applied: 0.9697 × 0.90 ≈ 0.87, as the overall confidence level, and the conflict basis "port=8080 and service=httpconflict with typical web app classification, overridden by stronger evidence" is retained.

[0125] S35, perform structured integration of all candidate labels for the current asset to obtain the asset recognition label for the current asset.

[0126] It is understandable that the inventive concept behind this embodiment of obtaining asset cognitive labels by fusing multi-source evidence and quantifying confidence in multi-dimensional asset vectors lies in elevating asset cognition from "single-point judgment" to "credible decision-making based on multi-source evidence fusion." Existing asset identification technologies typically employ hard-coded rules like "if port==6379 then type=redis" or use machine learning classifiers, which cannot handle feature conflicts, noise interference, and semantic ambiguity. This embodiment creatively treats asset identification as a decision-making problem involving multi-source information fusion, rather than simple feature matching. By constructing an evidence source system (port, service, HTTP, banner, TLS, historical reports, etc.), assigning a basic confidence level to each source, and designing a fusion algorithm to handle consistency and conflicts, it ultimately outputs a structured asset cognitive label with comprehensive confidence. This design transforms asset cognition from black-box guessing into a traceable, explainable, and auditable reasoning process. More importantly, the historical risk record fields extracted from historical risk associations are incorporated into the fusion system, enabling practical experience in attack and defense to directly influence the matching of asset cognition, thereby solving to some extent the problem that unstructured data is difficult to identify and utilize by existing certified risk monitoring technologies.

[0127] S4 extracts entities and constructs relationships from unstructured security operation data to form an attack knowledge graph. It then summarizes rules from the attack knowledge graph to obtain a rule knowledge base that includes account rules, password templates, and industry terminology rules.

[0128] Understandably, the improvement in this embodiment lies in transforming "external exploration" into "internal mining." By constructing an attack knowledge graph based on unstructured security operation data and designing an inductive mapping mechanism from graph nodes to a rule knowledge base, internal unstructured attack experience can be transformed into executable rules for the system, rather than simply copied. This forms a rule knowledge base that includes account rules, password templates, and industry-specific root word rules, thereby providing continuously updated cryptographic patterns, organizational characteristics, and attack paths for dynamic cryptographic evolution and driving the continuous evolution of subsequent cryptographic generation strategies.

[0129] Please see the appendix Figure 3 Specifically, in this embodiment, entity extraction and relationship construction are performed on unstructured security operation data to form an attack knowledge graph, including:

[0130] S411 performs document preprocessing on unstructured security operation data to obtain preprocessed text blocks.

[0131] The document preprocessing is implemented as follows: unstructured security operation data is sequentially segmented and denoised, formatted uniformly, sensitive information is anonymized, and context-based chunking is performed. Specifically, segmentation and denoising involves dividing long documents into several text chunks according to chapters, paragraphs, or semantic boundaries, removing noisy content such as headers, footers, tables of contents, and chart descriptions. Formatting uniformly involves converting documents in different formats such as PDF, Word, and Markdown into plain text while preserving paragraph structure. Sensitive information anonymization involves anonymizing sensitive information such as plaintext passwords, personal ID numbers, and mobile phone numbers appearing in the document (e.g., replacing them with placeholders) to prevent the leakage of sensitive data in the knowledge graph. Context-based chunking involves dividing each paragraph into a context window size suitable for the input of a large model (e.g., 512 tokens), while preserving the overlapping areas between adjacent chunks to avoid cutting off key information.

[0132] S412, extract prompt words for each text block according to a predefined structure to obtain the prompt words corresponding to the text block.

[0133] In this embodiment, the prompts corresponding to the text blocks are an optimized design to address the challenges of cybersecurity reporting. The prompts can adopt a structure of "role definition + task description + entity type definition + output format constraints." The role definition sets the large model as a "cybersecurity knowledge extraction expert," specifically responsible for extracting structured information related to weak passwords from attack and defense reports, helping the model focus on domain-specific vocabulary. The task description clearly specifies the entity and relation types to be extracted, emphasizing that "only information explicitly mentioned in the text should be extracted; do not fabricate information; for uncertain content, set it to null or an empty list." It also specifies that the output must be a valid JSON array, with each element representing an extraction result. The entity type definition provides clear definitions and examples for each entity type, helping the model understand the boundaries. For example, by explicitly stating in the prompts, "Password structure: refers to the pattern of password construction described in the text, such as 'company abbreviation + year', 'component name + 123'. Note that this is not a specific password value, but a pattern," the password structure is abstracted. For example, the text "Attack path: refers to the complete link from the attacker's entry point to the target, usually connected by '→' or '->', such as 'VPN entry point → SSH jump host → database server'" encourages the model to recognize '→' or '->' symbols in the text and break them down into an ordered sequence of nodes. If arrows are not explicitly used in the text, the model is required to infer the path order from the context (e.g., "first...then...finally...") to achieve chained extraction of the attack path.

[0134] S413: Input each text block and its corresponding prompt word into the pre-configured large model to perform entity extraction and relation extraction, and output the first candidate knowledge.

[0135] Among them, pre-configured LLM large models (such as the GPT series or equivalent capability models) are already mature language modeling technologies that can understand the technical terms and contextual relationships in cybersecurity reports and extract the entities and relationships required for attack knowledge graphs from natural language descriptions.

[0136] S414, use rule extraction logic to perform deterministic extraction of each text block to obtain the second candidate knowledge;

[0137] To prevent omissions or illusions in the large model, this embodiment also runs a set of deterministic rule extraction logic as a fallback. The implementation method is as follows: First, a predefined keyword list is used to identify asset types and components. Then, regular expressions are used to identify account names (such as "admin", "root"), password patterns (such as "\w+\d{4}"), CVE numbers (such as "CVE-\d{4}-\d+"), and path expressions are used to identify attack path descriptions of symbolic links such as "->" or "→".

[0138] Understandably, large models may be susceptible to illusions, while keyword matching and regular expressions can provide high-precision deterministic extraction, complementing each other.

[0139] S415 maps the first and second candidate knowledge to knowledge nodes and edges of the attack knowledge graph. The knowledge nodes include asset type, authentication entry, account role, password structure, hit condition, attack path, organizational characteristics and component services. The edges include source node and target node, relationship type and attributes.

[0140] Each edge includes relation types such as uses_password_pattern (using password pattern), belongs_to_industry (belonging to a certain industry), has_auth_entry (having an authentication entry point), and leads_to (the next step in the attack path). The attributes included in the edge refer to the conditions or context of the relation, such as condition: "remote access asset", evidence: ["chunk-12", "chunk-18"].

[0141] It is understood that the nodes and edges in the attack knowledge graph formed in this embodiment are candidate knowledge. They cannot be directly used for system operation and must be reviewed by experts before being published as specific rules according to the node type and corresponding edge, thus being integrated into the rule knowledge base. The rule knowledge base is a set of executable rules for the system, directly driving asset recognition, candidate password generation, and authentication risk detection.

[0142] Specifically, in this embodiment, the attack knowledge graph is subjected to rule summarization to obtain a rule knowledge base including account rules, password templates, and industry-specific root word rules, including:

[0143] S421: Extract default account candidates of different asset types from the account role nodes and corresponding edges in the attack knowledge graph, and publish them as account rules.

[0144] The rule induction uses the central node of the attack knowledge graph and its one-hop relation edge as evidence, retaining not only candidate values, but also the source node ID, the associated edge ID, and the associated node ID.

[0145] Specifically, the implementation of S421 in this embodiment is as follows: Query one-hop edge with the account role node as the center, summarize the Credential adjacent nodes as account candidates, and publish ACCOUNT_RULE after deduplication. condition_json.match solidifies the matching conditions such as asset type, industry, component, service and account role; content_json.accounts solidifies the default account candidates; graphEvidence solidifies the graph evidence.

[0146] For example, the account role nodes in the attack knowledge graph include specific account names, with corresponding edges AssetType—[has_account_role]→AccountRole: indicating that a certain type of asset has a certain account role (e.g., "VPN assets have an administrator account"). AccountRole—[uses_credential]→Credential: indicating the specific account names commonly used for this role (e.g., "admin is a commonly used account for administrators"). Default account candidates for different asset types are extracted from these, with the rule: for a specific asset type (e.g., MySQL) and matching a specific role (e.g., administrator), the account name (e.g., "admin") is preferentially tried. These account rules directly affect authentication risk detection, prioritizing the use of these accounts during authentication attempts.

[0147] S422 extracts the asset types, industries, and component services applicable to different cryptographic structures from the cryptographic structure nodes and corresponding edges in the attack knowledge graph, and publishes them as cryptographic templates.

[0148] Specifically, in this embodiment, S422 is implemented as follows: A one-hop edge is queried centered on the Password Pattern node to extract the template, password structure, and applicable scope, and a PASSWORD_TEMPLATE is published. The password template also carries asset type, industry, component, and service constraints; when an asset-directed dictionary request is initiated, the cloud only returns password template candidates that match the asset profile.

[0149] For example, attacking a cryptographic structure node in the knowledge graph, such as "{abbr}@{year}", corresponds to the edge AssetType—[uses_password_pattern]→PasswordPattern: indicating that a certain type of asset tends to use this cryptographic structure, and conditions can be attached to the edge (such as "remote access assets"). PasswordPattern—[applies_to_industry]→Industry: indicating that the pattern is applicable to a certain industry. PasswordPattern—[applies_to_component]→Component: indicating that the pattern is applicable to a certain component (such as "OpenVPN"). The asset types, industries, and component services applicable to different cryptographic structures are extracted from this and published as cryptographic templates. The cryptographic template includes a structural description (such as "organization abbreviation + year"), a character pattern (such as "L4S1D4"), and an applicable scope (asset type, industry, component). When generating candidate cryptographic data, the system will match the applicable cryptographic template based on the asset's asset recognition tag and substitute specific root words (such as the organization abbreviation "ABC") to generate candidate cryptographic data (such as "ABC2024").

[0150] S423 extracts industry-related terms associated with different organizations from the organizational feature nodes and corresponding edges in the attack knowledge graph, and publishes them as industry-related term rules.

[0151] For example, attacking organizational feature nodes in the knowledge graph, such as the company abbreviation "ABC", the domain prefix "abc-tech", the city "Hangzhou", and the industry root "finance", corresponds to the edge OrgFeature—[belongs_to_organization]→Organization: indicating that the feature belongs to a certain organization. OrgFeature—[associated_with_industry]→Industry: indicating that the feature is related to a certain industry. Industry roots associated with different organizations are extracted and published as industry root rules. These roots are added to the "root set" in the cryptographic evolution stage. When generating cryptographic candidates, the system selects corresponding key roots (such as "ABC", "finance") from the root set based on the organization and industry to which the current asset belongs, to construct targeted cryptography (such as "ABC2024", "finance123").

[0152] S424 extracts the component services, authentication entry points, and hit conditions associated with different asset types from the asset type nodes and corresponding edges in the attack knowledge graph, publishes them as new asset identification rules, and stores them in the asset identification rule library.

[0153] For example, attacking asset type nodes in the knowledge graph, such as "VPN," "database," and "network device," corresponds to the edge AssetType—[has_component]→Component: indicating which components this type of asset typically contains (e.g., "VPN assets often contain OpenVPN"). AssetType—[has_auth_entry]→AuthEntry: indicating the typical authentication entry point for this type of asset (e.g., "VPN login page"). AssetType—[has_default_credential]→Credential: indicating the default credentials for this type of asset. Asset type nodes themselves are not directly published as rules; instead, they are published as asset identification rules in combination with their associated component services, authentication entry points, and hit conditions. These asset identification rules are added to the asset identification rule base in the asset recognition stage, improving the ability to identify unknown assets.

[0154] It is understandable that, through this rule induction mechanism, each piece of attack knowledge experience in the attack knowledge graph (such as "the company abbreviation plus the year is commonly used as a password in VPNs in the financial industry") is decomposed into executable rules, which directly drive asset cognition, candidate password generation and authentication risk detection, and realize a complete closed loop from "unstructured experience" to "system capability".

[0155] S5 generates a set of candidate passwords for each asset under the constraints of asset cognitive tags and rule knowledge base.

[0156] Understandably, existing cryptographic knowledge relies primarily on leaked password databases and common organizational characteristics, making password generation relatively generic. The core innovation of this embodiment lies in transforming a deep understanding of asset cognition and practical experience in attack knowledge learning into a highly targeted set of password candidates. This minimizes attempts to cover the highest probability of weak password risks, fundamentally solving the detection problem in existing technologies caused by a lack of asset semantics: "insufficient detection of high-value assets leads to missed critical authentication risks, while low-value assets waste significant detection resources and even cause false positives." This achieves precise governance with a "one asset, one strategy" approach. Furthermore, the password candidate set continuously evolves with asset scenarios and attack knowledge, making it more accurate and efficient.

[0157] Please see the appendix Figure 4 Specifically, in this embodiment, under the constraints of asset cognitive tags and rule knowledge base, a candidate set of passwords for each asset is generated in a targeted manner, including:

[0158] S51, based on asset recognition tags, determine the password generation strategy corresponding to the current asset.

[0159] In this embodiment, the password generation strategy includes default root word sources, password template preferences, and password candidate limits. For example, database assets pay more attention to component names, account roles, and organization abbreviations; remote access assets pay more attention to organization abbreviations, domain name prefixes, and years.

[0160] S52, based on the password generation strategy corresponding to the current asset, selects several keyword roots for the current asset from the account rules and industry terminology rules in the rule knowledge base. These keyword roots, as a small set of terminology, are sourced from:

[0161] 1. Asset recognition tags can be provided directly: organization abbreviation (e.g., "ABC"), domain name prefix (e.g., "abc-tech"), business system name (e.g., "CRM"), equipment brand, and component name (e.g., "Redis").

[0162] 2. The rules knowledge base provides: account role roots (such as "admin", "root"), industry roots (such as "finance", "bank"), and time characteristics (current year "2026", registration year "2020").

[0163] S53, real-time statistics of the historical hit count of each password template in the rule knowledge base (from the hit result feedback loop), and determination of the conditional probability of each password template under different asset types based on the historical hit count.

[0164] For example, if statistics show that the password template "organization abbreviation + year" has a 35% hit rate on VPN assets, then its conditional probability is set to 0.35. Hit rate = historical hit count / total authentication attempts.

[0165] S54, based on the asset recognition tag and the corresponding password generation strategy, determines all password templates that match the current asset from the password templates in the rule knowledge base.

[0166] Specifically, asset recognition tags are used as search criteria to retrieve all password templates in the rule knowledge base whose applicable scope matches the current asset. The matching rule is: the greater the intersection between the applicable scope of the password template and the asset recognition tag, the higher the match degree.

[0167] S55: Sort all the password templates that match the current asset in descending order of conditional probability, and select the top few password templates as the high-probability password structure of the current asset.

[0168] S56, replace the placeholders in the high-probability cryptographic structure of the current asset with key roots to generate several cryptographic candidates, denoted as the cryptographic candidate set of the current asset.

[0169] In this embodiment, the high-probability cryptographic structure selected is not directly used to generate the cipher, but is combined with the keyword roots extracted in step S52. Each high-probability cryptographic structure defines the placement position and type of the word root. For example, the high-probability cryptographic structure "{abbr}{year}" requires the first slot to be filled with a word root of an organization abbreviation and the second slot to be filled with a word root of a year. The system checks whether there is a word root in the current keyword roots that meets the slot requirements: if it does, a cipher candidate is generated; if it does not, the high-probability cryptographic structure is skipped.

[0170] S6 uses a set of password candidates to attempt to authenticate the target asset within the authorized scope, generating a hit result.

[0171] The target asset is the asset corresponding to the password candidate set. Within the authorized scope, the system invokes detection plugins that match the asset authentication protocol (such as Web form login plugins, SSH protocol plugins, and Redis AUTH command plugins), and uses the targeted password candidate set output in the previous step to attempt the authentication entry points of the target asset one by one. The hit result recorded for each authentication attempt includes asset type, IP / port, service, protocol, weak password (the specific account and password hit), password template source, and verification result (hit or miss).

[0172] S7 updates the attack knowledge graph and password templates in the rule knowledge base based on the hit results.

[0173] Understandably, the core of existing technologies lies in "data-driven" approaches, which involve generating richer codebooks by integrating data from different sources (leaked databases, AI-generated codebooks) and only involve a closed-loop business process of "discovery-detection-rectification-verification." In contrast, the core of this embodiment lies in "knowledge and cognition-driven" approaches. It not only focuses on the generation of the code itself but also on a deep understanding of the assets themselves and the systematic learning and reuse of attacker experience. To this end, a deeper data loop is designed: detection hit results (hit / miss) feed back into the attack knowledge graph and rule knowledge base, enabling the next round of asset cognition and code generation strategies to continuously and dynamically evolve.

[0174] On the one hand, this embodiment incrementally updates the cryptographic structure nodes and corresponding edges in the attack knowledge graph based on the hit results. That is, the association between the asset cognitive tags such as cryptographic structure, hit conditions, account roles, organizational characteristics, and component services extracted from the hit results and the cryptographic templates is added to each node and edge in the attack knowledge graph.

[0175] On the other hand, this embodiment updates the historical hit count of the corresponding password template in the rule knowledge base according to the hit result matching password template, so that the hit password template is strengthened (historical hit count is increased) and the unhit password template is weakened.

[0176] Understandably, the probability tables of traditional PCFG models are typically fixed after offline training, leading to a decline in detection capability over time. This embodiment uses a hit feedback loop to update the conditional probability of each cryptographic structure in a specific asset context in real time. This mechanism ensures that the conditional probability of the cryptographic template under different asset types always reflects the most effective cryptographic structure currently available, and invalid authentication attempts will not accumulate due to outdated structures.

[0177] Example 2:

[0178] This embodiment only applies to comparisons with... Figure 1 The differences between the two embodiments will be described in the following descriptions. The technical concepts of the remaining designs are similar to those of the first embodiment, and will not be repeated here.

[0179] To further enhance the targeting of the dynamic authentication risk detection strategy for cyberspace assets, this embodiment employs a candidate set of passwords to attempt authentication of the target asset within the authorized scope, generating a hit result, including:

[0180] Based on asset recognition tags, determine the detection parameters of the target asset;

[0181] Using a set of password candidates, the target asset is authenticated within the authorized scope according to the corresponding detection parameters, and a hit result is generated.

[0182] Understandably, while targeted password candidate sets are accurate, attempting authentication on all assets at a high rate could still lead to business interruptions or account lockouts. To address this, this embodiment proposes differentiated detection parameter orchestration and execution. Based on the authentication entry characteristics and historical risk records of the asset's cognitive tag, the system assesses the detection strength level of each asset and customizes corresponding detection parameters for each level. For example, for assets labeled "Core Transaction System" with a detection strength level of "High," even with only 20 candidate items, the system will employ extremely low concurrency (e.g., 1 request per second), a longer request interval (e.g., 5 seconds), and activate account lockout protection mechanisms (e.g., automatically pausing and awaiting manual confirmation after three consecutive failures). Conversely, for test environment assets with a detection strength level of "Low," even with 50 candidate items, the system can use higher concurrency (e.g., 10 requests per second) to accelerate detection. This "asset-specific" execution approach ensures that the password candidate set can function securely without impacting business operations.

[0183] Example 3:

[0184] Please see the appendix Figure 5 , Figure 5 This is a schematic diagram of the structure of a dynamic authentication risk detection system for cyberspace assets provided in one embodiment of this specification.

[0185] like Figure 5 As shown, the dynamic authentication risk detection system for cyberspace assets may include at least:

[0186] Data acquisition module 1 is used to collect structured asset basic data and unstructured security operation data within the authorized scope;

[0187] Asset cognition module 2 is used to construct a multi-dimensional asset vector for each asset based on asset basic data and security operation data, and to perform multi-source evidence fusion and confidence quantification on the multi-dimensional asset vector to obtain asset cognition labels. Each asset cognition label includes content, source, basis and comprehensive confidence level.

[0188] Attack knowledge learning module 3 is used to extract entities and construct relationships from unstructured security operation data to form an attack knowledge graph. The attack knowledge graph is then used to summarize rules to obtain a rule knowledge base that includes account rules, password templates, and industry root word rules. The attack knowledge graph and the password templates in the rule knowledge base are updated based on the hit results of the authentication risk detection module.

[0189] The targeted password generation module 4 is used to generate a set of candidate passwords for each asset under the constraints of asset cognitive tags and rule knowledge base.

[0190] The authentication risk detection module 5 is used to attempt to authenticate the target asset within the authorized scope using a set of password candidates and generate a hit result.

[0191] It is understood that the technical concept of the dynamic authentication risk detection system for cyberspace assets provided in this embodiment is similar to the technical concept of the aforementioned dynamic authentication risk detection method for cyberspace assets, and will not be repeated here.

[0192] Example 4:

[0193] Another embodiment of this specification provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform one or more steps in the above-described method embodiments. The constituent modules of the above-described electronic device, if implemented as software functional units and used as independent downstream task predictions or applications, can be stored in the computer-readable storage medium.

[0194] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0195] The above description is merely a preferred embodiment disclosed in this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of protection involved in this disclosure should cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-disclosed concept. Furthermore, although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure.< / form>

Claims

1. A method for dynamic authentication risk detection of cyberspace assets, characterized in that, Includes the following steps: Collect structured asset-based data and unstructured security operation data within the authorized scope; Based on asset base data and security operation data, a multi-dimensional asset vector is constructed for each asset. Multi-source evidence fusion and confidence quantification are performed on multi-dimensional asset vectors to obtain asset cognitive labels. Each asset cognitive label includes content, source, basis, and comprehensive confidence level. Entity extraction and relationship construction are performed on unstructured security operation data to form an attack knowledge graph. The attack knowledge graph is then used to summarize rules to obtain a rule knowledge base that includes account rules, password templates, and industry terminology rules. Under the constraints of asset cognitive tags and rule knowledge base, a set of candidate passwords is generated for each asset in a targeted manner; The target asset is authenticated using a set of password candidates within the authorized scope, and a successful authentication result is generated. Update the attack knowledge graph and password templates in the rule knowledge base based on the hit results.

2. The method for dynamic authentication risk detection of cyberspace assets as described in claim 1, characterized in that, Based on asset baseline data and security operation data, a multi-dimensional asset vector is constructed for each asset, including: Standardize the structured asset data to obtain standardized asset records; For each asset record, feature normalization is performed to obtain the normalized feature fields of each asset. Perform path brute-force operations on each asset to obtain the access path and response status code of each asset, and parse the page content of the successfully brute-forced path to extract the page keywords and authentication entry characteristics of each asset. A historical risk knowledge index is built based on unstructured security operation data; Query conditions are extracted from the characteristic fields, access paths, response status codes, page keywords, and authentication entry features of each asset. The query conditions are matched with the historical risk knowledge index. When the keywords match successfully, the historical vulnerabilities and historical risk records corresponding to the asset are extracted. The collection of characteristic fields, access paths, response status codes, page keywords, authentication entry features, historical vulnerabilities, and historical risk records corresponding to each asset constitutes a multidimensional asset vector for each asset.

3. The method for dynamic authentication risk detection of cyberspace assets as described in claim 1, characterized in that, Multi-source evidence fusion and confidence quantification are performed on multi-dimensional asset vectors to obtain asset cognitive labels, including: Construct an asset identification rule base, where each rule includes a hit condition and candidate labels; The multidimensional asset vector of the current asset is matched one by one with the hit conditions of each rule in the asset identification rule base. When all the hit conditions of a rule match the multidimensional asset vector of the current asset, the rule is considered to be hit. For each hit rule, the source and basis of the corresponding candidate label are recorded. Based on the predefined base confidence scores corresponding to different types of sources, determine the base confidence scores of each source for each candidate label; The consistency of the sources of all candidate labels for the current asset is judged. If all sources point to the same candidate label, the basic confidence of each source of the candidate label is fused for consistency to obtain the overall confidence of the current asset. If all sources point to conflicting candidate labels, the basic confidence of each source of the candidate label is weighted for conflict to obtain the overall confidence of the current asset. All candidate tags for the current asset are structurally integrated to obtain the asset recognition tag for the current asset.

4. The dynamic authentication risk detection method for cyberspace assets as described in claim 3, characterized in that, Entity extraction and relationship construction are performed on unstructured security operations data to form an attack knowledge graph, including: Unstructured security operations data is preprocessed to obtain preprocessed text blocks; For each text block, extract the prompt words according to the predefined structure to obtain the prompt words corresponding to the text block; Each text block and its corresponding prompt word are input into a pre-configured large model to perform entity extraction and relation extraction, and the first candidate knowledge is output. The rule-based extraction logic is used to deterministically extract each text block to obtain the second candidate knowledge; The first and second candidate knowledge are mapped to knowledge nodes and edges of the attack knowledge graph. The knowledge nodes include asset type, authentication entry point, account role, password structure, hit condition, attack path, organizational characteristics and component services. The edges include source node and target node, relationship type and attribute.

5. The dynamic authentication risk detection method for cyberspace assets as described in claim 4, characterized in that, By summarizing the attack knowledge graph, a rule knowledge base is obtained, including account rules, password templates, and industry-specific root word rules, including: Default account candidates of different asset types are extracted from account role nodes and corresponding edges in the attack knowledge graph and published as account rules; Extract the asset types, industries, and component services applicable to different cryptographic structures from the cryptographic structure nodes and corresponding edges in the attack knowledge graph, and publish them as cryptographic templates; Industry-related terms associated with different organizations are extracted from the organizational feature nodes and corresponding edges in the attack knowledge graph and published as industry-related term rules. Extract the component services, authentication entry points, and hit conditions associated with different asset types from the asset type nodes and corresponding edges in the attack knowledge graph, publish them as new asset identification rules, and store them in the asset identification rule library.

6. The method for dynamic authentication risk detection of cyberspace assets as described in claim 4, characterized in that, Under the constraints of asset cognitive tags and rule knowledge base, a candidate set of passwords is generated for each asset, including: Based on asset recognition tags, determine the password generation strategy corresponding to the current asset; Based on the password generation strategy corresponding to the current asset, select several keyword roots for the current asset from the account rules and industry word root rules in the rule knowledge base; The historical hit count of each password template in the rule knowledge base is counted in real time, and the conditional probability of each password template under different asset types is determined based on the historical hit count. Based on asset cognitive tags and the corresponding password generation strategy, all password templates that match the current asset are determined from the password templates in the rule knowledge base; Sort all the password templates that match the current asset in descending order of conditional probability, and select the top few password templates as the high-probability password structure for the current asset. Replace the placeholders in the high-probability cryptographic structure of the current asset with key roots to generate several cryptographic candidates, denoted as the cryptographic candidate set of the current asset.

7. The method for dynamic authentication risk detection of cyberspace assets as described in claim 6, characterized in that, Update the attack knowledge graph and password templates in the rule knowledge base based on the hit results, including: Based on the hit results, the cryptographic structure nodes and corresponding edges in the attack knowledge graph are incrementally updated; Based on the matching results, the password template in the rule knowledge base is updated with the historical hit count of the corresponding password template in the rule knowledge base.

8. The method for dynamic authentication risk detection of cyberspace assets as described in claim 1, characterized in that, The system uses a set of password candidates to attempt authentication of the target asset within the authorized scope, generating a hit result, including: Based on asset recognition tags, determine the detection parameters of the target asset; Using a set of password candidates, the target asset is authenticated within the authorized scope according to the corresponding detection parameters, and a hit result is generated.

9. A dynamic authentication risk detection system for cyberspace assets, characterized in that, include: The data acquisition module is used to collect structured asset-based data and unstructured security operation data within the authorized scope. The asset cognition module is used to construct a multi-dimensional asset vector for each asset based on basic asset data and security operation data, and to perform multi-source evidence fusion and confidence quantification on the multi-dimensional asset vector to obtain asset cognition labels. Each asset cognition label includes content, source, basis and comprehensive confidence level. The attack knowledge learning module is used to extract entities and construct relationships from unstructured security operation data to form an attack knowledge graph. The attack knowledge graph is then used to summarize rules to obtain a rule knowledge base that includes account rules, password templates, and industry root word rules. The attack knowledge graph and the password templates in the rule knowledge base are updated based on the hit results of the authentication risk detection module. The targeted password generation module is used to generate a set of candidate passwords for each asset under the constraints of asset cognitive tags and rule knowledge base; The authentication risk detection module is used to attempt to authenticate the target asset within the authorized scope using a set of password candidates and generate a hit result.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the dynamic authentication risk detection method for cyberspace assets as described in any one of claims 1 to 8.

Images