Vulnerability scanning method and system based on asset fingerprint identification and storage medium
Patent Information
- Application Number
- CN202610879402.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-17
- Publication Date
- 2026-09-15
Smart Images
Figure CN122764592A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a vulnerability scanning method, system and storage medium based on asset fingerprint recognition. Background Technology
[0002] Network asset vulnerability scanning is an integral part of network security operations. The general process of existing vulnerability scanning methods based on asset fingerprinting is as follows: The scanning engine sends TCP SYN probe packets, ICMP echo request packets, and banner collection requests to each asset in the target network, extracts the service version field, operating system protocol stack characteristics, and open port information from the response messages, maps the above information to the CPE standard format in a standardized manner, generates asset fingerprint records, matches the asset fingerprint records with the CVE vulnerability database according to rules, generates alarm tickets for assets that match vulnerability entries, and further verifies candidate vulnerabilities through PoC scripts or vulnerability verification tools, ultimately forming an asset security posture report.
[0003] However, existing vulnerability scanning methods based on asset fingerprinting have the following shortcomings: First, once an asset fingerprint is collected, it is considered a permanently valid static truth value. When matching it with the CVE vulnerability database, the timeliness of the fingerprint information is not considered. When the target asset undergoes software version upgrades, service restarts, or operating system configuration changes after fingerprint collection, the discrepancy between the asset state described by the old fingerprint and the actual state continues to accumulate. CVE matching results based on the old fingerprint cannot reflect the current true state of the asset, resulting in a large number of patched vulnerabilities being continuously marked as valid vulnerabilities, generating large-scale false alarms. Second, existing methods lack a real-time perception mechanism for asset network behavior and cannot proactively trigger fingerprint updates when the asset state changes. They rely solely on manually configured periodic full scan cycles, resulting in a long time window between asset state changes and fingerprint updates. During this window, the reliability of vulnerability alerts cannot be guaranteed. Third, existing methods lack a hierarchical mechanism for alert handling. All CVE matching results are pushed to alert tickets with the same priority. Security operations personnel cannot differentiate the handling of alert results based on the reliability of the fingerprint information, further increasing the manual burden of false alarm handling.
[0004] If a fingerprint timeliness perception mechanism is introduced and dynamic lifetime weights are assigned to asset fingerprints, new technical problems arise: the initial reliability of fingerprints obtained by different acquisition methods varies, and the rate of state change of different types of assets is different. Fixed lifetime decay parameters cannot adapt to the actual change patterns of various assets in heterogeneous network environments, causing the fingerprint lifetime of slowly changing assets to decay prematurely below the rescan threshold and frequently triggering unnecessary rescan tasks. On the other hand, the fingerprint lifetime decay rate of rapidly changing assets is insufficient to reduce the lifetime to the range that triggers rescan in time after the asset actually changes. Furthermore, even if a mechanism is introduced to accelerate the decay of fingerprint lifetimes by triggering abnormal network behavior, the problem of how to adaptively correct the decay rate parameter based on the historical rescan comparison results of various assets still exists. If there is no feedback correction mechanism for the decay rate parameter based on the rescan results, the system cannot accumulate prior knowledge of the change patterns of various assets from historical correction experience during long-term operation. Newly connected assets of the same type will still start running with the default decay rate parameter, which fundamentally restricts the adaptive capability of the lifetime mechanism. Summary of the Invention
[0005] This application provides a vulnerability scanning method, system, and storage medium based on asset fingerprint recognition. It solves the problems of high false alarm rate and rigid scanning strategy in existing vulnerability scanning methods based on asset fingerprint recognition, which are caused by treating asset fingerprints as static truth values and lacking timeliness perception and abnormal behavior triggering mechanisms. It also solves the problem that the decay rate parameter cannot be adaptively corrected for different types of assets based on the rescan comparison results, which leads to the inability to accumulate prior knowledge of asset change patterns during long-term system operation.
[0006] In a first aspect, this application provides a vulnerability scanning method based on asset fingerprint recognition, the vulnerability scanning method based on asset fingerprint recognition comprising: Step S1: Perform fingerprint detection on each asset in the target network, and map the detected service version field and protocol stack feature vector with the CPE standard format to obtain a standardized asset fingerprint record. Step S2: Based on the acquisition method of the standardized asset fingerprint record, bind the standardized asset fingerprint record with the initial lifetime weight and the initial decay rate parameter to obtain asset fingerprint entries with lifetime values. Step S3: Continuously monitor the port response mode, Banner version field and protocol stack feature vector in the asset fingerprint entry with life value. When any field is found to be inconsistent with the corresponding field in the standardized asset fingerprint record, the current life value in the asset fingerprint entry with life value is reduced according to the corresponding penalty coefficient to obtain a dynamic life value update record. Step S4: Combine the current life value in the dynamic update record of life value with the matching result of the CVE vulnerability database, and divide it into three levels of handling according to the interval of the current life value: direct alarm, suspected pending verification, and triggered rescan. For assets that have triggered rescan, re-execute S1 to S2 to generate new standardized asset fingerprint records. Compare the similarity between the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record. Adjust or lower the initial decay rate parameter according to the comparison result to obtain the corrected decay rate parameter.
[0007] Secondly, this application provides a vulnerability scanning system based on asset fingerprint recognition, the vulnerability scanning system based on asset fingerprint recognition comprising: The detection module is used to perform fingerprint detection on each asset in the target network. It maps the detected service version field and protocol stack feature vector with the CPE standard format to obtain a standardized asset fingerprint record. The binding module is used to bind the standardized asset fingerprint record with the initial life value weight and the initial decay rate parameter according to the collection method of the standardized asset fingerprint record, so as to obtain the asset fingerprint entry with life value. The attenuation module is used to continuously monitor the port response mode, banner version field and protocol stack feature vector in the asset fingerprint entry with life value. When any field is detected to be inconsistent with the corresponding field in the standardized asset fingerprint record, the current life value in the asset fingerprint entry with life value is attenuated according to the corresponding penalty coefficient to obtain a dynamic life value update record. The correction module is used to combine the current life value in the dynamic update record of the life value with the matching result of the CVE vulnerability database, and divide it into three levels of handling according to the interval of the current life value: direct alarm, suspected pending verification, and triggered rescan. For assets that have triggered rescan, S1 to S2 are re-executed to generate new standardized asset fingerprint records. The similarity of the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record is compared. The initial decay rate parameter is adjusted upward or downward according to the comparison result to obtain the corrected decay rate parameter.
[0008] Thirdly, a vulnerability scanning device based on asset fingerprinting is provided, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the vulnerability scanning device based on asset fingerprinting to execute the aforementioned vulnerability scanning method based on asset fingerprinting.
[0009] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the aforementioned vulnerability scanning method based on asset fingerprinting.
[0010] The technical solution provided in this application introduces a binding mechanism between initial lifetime weight and initial decay rate parameter after the standardized asset fingerprint record is generated. This ensures that the asset fingerprint carries an initial trust metric corresponding to the trust level of the collection method from the moment of collection. Different initial lifetime weights are assigned to the three collection methods: authenticated scanning, unauthenticated active scanning, and passive traffic sniffing. This incorporates the differences in the trust level of fingerprint information into the input conditions for subsequent vulnerability alert decisions from the source, overcoming the defect in existing technologies where fingerprints obtained from all collection methods are indiscriminately treated as static truth values. Based on this, a continuous monitoring and penalty coefficient accumulation mechanism is implemented for three network behavior fields in the asset fingerprint entries with lifetime values: port response mode, banner version field, and protocol stack feature vector. This enables the system to perform differentiated accelerated decay of the current lifetime value based on the fingerprint failure risk level reflected by the anomaly type when a substantial change occurs in the asset state. This establishes a fingerprint failure perception channel driven by actual asset behavior changes, in addition to fixed-period full scans, solving the problem in existing technologies where there is a long time window between asset state changes and fingerprint updates, during which the trust level of alerts cannot be guaranteed. By combining the current vulnerability value with the CVE vulnerability database matching results to form a vulnerability association record, and dividing the handling results into three levels based on the current vulnerability value range: direct alert, suspected pending verification, and triggered rescan, the granularity of vulnerability alert handling is expanded from the single hit-and-alert in the existing technology to a hierarchical decision-making corresponding to the fingerprint trust level. This avoids the large-scale false alarms caused by directly pushing high-priority alert tickets based on CVE matching results of low-trust fingerprints.
[0011] By re-performing fingerprint detection on assets that trigger rescanning, the CPE string set of the new standardized asset fingerprint record is compared with that of the historical standardized asset fingerprint record using Jaccard similarity. Based on the similarity interval, the initial decay rate parameter is adjusted upwards or downwards to achieve differential correction. This allows the decay rate parameter to gradually converge to a value that matches the actual rate of change of the asset as the rescanning correction rounds accumulate. The decay rate parameter of fast-changing assets converges to a higher value through the continuous effect of increasing the step size coefficient, enabling its lifetime value to trigger a rescanning decision more quickly. The decay rate parameter of slow-changing assets converges to a lower value through the continuous effect of decreasing the step size coefficient, avoiding frequent unnecessary rescanning tasks due to excessively rapid fingerprint lifetime value decay. Furthermore, the corrected attenuation rate parameters of each asset are categorized and summarized by the operating system type field, and the arithmetic mean is written into the attenuation rate parameter library. This allows newly connected assets of the same type to reference the historical prior attenuation rate of the operating system type when they are first bound, instead of starting with a fixed default value. This realizes the cross-asset migration of attenuation experience between assets of the same type, and fundamentally solves the problem that the attenuation parameters are fixed and cannot adapt to the actual change patterns of various assets in heterogeneous network environments in the existing technology. Attached Figure Description
[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0013] Figure 1 This is a schematic diagram of one embodiment of the vulnerability scanning method based on asset fingerprinting in this application. Figure 2 This is a schematic diagram illustrating the distribution of vulnerability alert handling results based on fingerprint lifetime values in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the adaptive convergence process of the attenuation rate parameter with the number of rescan corrections in the embodiments of this application. Detailed Implementation
[0014] This application provides a vulnerability scanning method, system, and storage medium based on asset fingerprinting. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.
[0015] For ease of understanding, the specific process of the embodiments of this application is described below. Please refer to [link / reference]. Figure 1 One embodiment of the vulnerability scanning method based on asset fingerprinting in this application includes: Step S1: Perform fingerprint detection on each asset in the target network, and map the detected service version field and protocol stack feature vector with the CPE standard format to obtain a standardized asset fingerprint record. Specifically, a standardized asset fingerprint record is a complete technical status description of a single asset in a target network at a specific probe time. Its fields include the asset's IP address, operating system type, CPE string set, open port set, protocol type set, and fingerprint collection timestamp. The protocol stack feature vector is generated by extracting sequence number increment features, window size field, TTL value, and flag combinations from the response packets after sending TCP probe packets, ICMP echo request packets, and UDP probe packets to the target host. These are then weighted and concatenated according to preset weights. The preset weights of each sub-feature are determined based on its historical statistical contribution to distinguishing operating system types, with TCP sequence number-related sub-features having the highest weight, followed by ICMP sub-features, and then UDP sub-features having the lowest. This weight allocation method is determined with reference to known technical practices in the field of existing network asset probes. The CPE normalization mapping converts the service name field and version number field into a CPE standard string according to the hierarchical structure of vendor, product name, and version number, giving the asset software information a format foundation for direct matching with the CVE vulnerability database.
[0016] Step S2: Based on the collection method of standardized asset fingerprint records, bind the standardized asset fingerprint records with the initial life value weight and the initial decay rate parameter to obtain asset fingerprint entries with life values. Specifically, asset fingerprint entries with lifetime values add two fields to the standardized asset fingerprint record: initial lifetime weight and initial decay rate parameter. The initial lifetime weight is assigned to three levels based on the reliability of the data collection method: Authentication scans, because the scanning engine holds legitimate login credentials for the target host and collects the most complete information, are assigned the highest initial lifetime weight of 1.0; non-authentication active scans rely on banner responses and protocol stack analysis, and have the possibility of service spoofing, so they are assigned the middle level initial lifetime weight of 0.85; passive traffic sniffing only extracts features from network traffic, resulting in the lowest information completeness, so it is assigned the lowest level initial lifetime weight of 0.65. The interval between the three levels is based on the fact that the reliability difference between adjacent levels is considered substantial in engineering practice, and the interval is set to 0.15, so that the three levels produce perceptible differences in alarm decisions during subsequent lifetime decay. The default value of the initial decay rate parameter is set to 0.005 per hour, which means that under the baseline state without any abnormal behavior triggers, the fingerprint lifetime value decays naturally by 0.5% per hour. This default value is determined based on statistical experience of the frequency of asset configuration changes in typical enterprise network environments. For cases where there are existing historical correction records for the same type of assets, the initial decay rate parameter is directly taken as the arithmetic mean of all historically corrected decay rate parameters under the same operating system type, so that newly connected assets inherit the prior information of the change rate of similar assets from the first binding.
[0017] Step S3: Continuously monitor the port response mode, Banner version field and protocol stack feature vector in the asset fingerprint entry with life value. When any field is found to be inconsistent with the corresponding field in the standardized asset fingerprint record, the current life value in the asset fingerprint entry with life value is reduced according to the corresponding penalty coefficient to obtain a dynamic life value update record. Specifically, the dynamic update record for life points adds an anomaly trigger record list field to the asset fingerprint entries with life points. This field records the type, trigger time, and corresponding penalty coefficient for each anomaly trigger. The penalty coefficients for the three types of anomalies are set as follows: 0.80 for port response mode changes, 0.70 for inconsistent Banner version fields, and 0.60 for protocol stack feature vector drift. The three values are set based on the following criteria: port response mode changes are a minor anomaly at the network layer, with the lowest risk of fingerprint failure and the smallest penalty; inconsistent Banner version fields directly reflect software version changes, with a larger deviation between the fingerprint and the current actual state, resulting in a moderate penalty; and protocol stack feature vector drift indicates a possible change at the operating system level, with the highest risk of fingerprint failure and the largest penalty. When multiple anomalies trigger simultaneously, the penalty coefficients are multiplied sequentially and applied to the current life point. The order of multiplication does not affect the final result, ensuring the determinism of the penalty calculation. The drift of the protocol stack feature vector is determined based on the drift threshold, which is set to a Hamming distance of 3. This means that no more than 3 feature bits in the protocol stack feature vector are allowed to change. If more than 3 change, it is considered an abnormal drift. The threshold is set based on the fact that the protocol stack response fluctuation caused by slight adjustments to the operating system kernel parameters under normal network device operation usually does not exceed 2 feature bits. A threshold of 3 can effectively capture substantial changes while tolerating normal fluctuations.
[0018] Step S4: Combine the current life value in the dynamic update record with the CVE vulnerability database matching results, and classify it into three levels of handling according to the interval of the current life value: direct alarm, suspected pending verification, and triggered rescan. For assets that have triggered rescan, re-execute S1 to S2 to generate new standardized asset fingerprint records. Compare the similarity between the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record. Adjust or lower the initial decay rate parameter according to the comparison result to obtain the corrected decay rate parameter.
[0019] Specifically, in the three-level range division of the current vulnerability value, the first vulnerability value threshold is set to 0.70, and the second vulnerability value threshold is set to 0.40. When the current vulnerability value is not lower than 0.70, it is judged as a direct alarm, based on the fact that the credibility of the fingerprints in this range is sufficient to support the direct acceptance of the CVE vulnerability database matching results; when the current vulnerability value is between 0.40 and 0.70, it is judged as a suspected pending verification, because the fingerprints in this range have undergone a certain degree of behavioral anomaly trigger attenuation, and the matching results are uncertain, requiring manual intervention for review; when the current vulnerability value is lower than 0.40, it is judged as a trigger for rescanning, because the deviation between the asset status reflected by the fingerprint and the actual status has exceeded the acceptable range, and directly performing CVE matching will generate a large number of invalid alarms. The similarity of CPE strings is calculated by the ratio of the number of elements in the intersection to the number of elements in the union of two sets. The first similarity threshold is set to 0.90, and the second similarity threshold is set to 0.70. When the similarity is not lower than 0.90, the old and new fingerprints are considered to be highly consistent, and the initial decay rate parameter is adjusted downward by a step size of 0.10, indicating that the asset changes slowly and the subsequent decay rate should be reduced. When the similarity is lower than 0.70, the fingerprint is considered to have undergone substantial changes, and the initial decay rate parameter is adjusted upward by a step size of 0.20, indicating that the asset changes rapidly and the subsequent decay rate should be increased. The upward step size is greater than the downward step size, based on the fact that the security risk of unreported vulnerabilities is higher than the operational cost of false positives. In uncertain situations, the decay rate is accelerated to trigger more rescan operations. The corrected decay rate parameter has a lower limit of 0.001 / hour and an upper limit of 0.050 / hour to prevent the decay rate from tending to extreme values due to multiple consecutive corrections.
[0020] In one specific embodiment, step S1 includes: Send SYN packets to the target ports of each asset in the target network, and extract the port open status based on the returned SYN / ACK response to obtain the set of open ports; Based on the Banner response text of each open port in the open port set, the service name field, version number field, and vendor identifier field are extracted to obtain the service fingerprint triplet. TCP probe packets, ICMP echo request packets, and UDP probe packets are sent sequentially to each asset. The sequence number increment feature, window size field, TTL value, and flag combination in each response message are weighted and concatenated according to a preset weight to obtain the protocol stack feature vector. The service name field and version number field in the service fingerprint triplet are mapped to the CPE in a CPE-standardized manner according to the hierarchical structure of vendor, product name and version number. Combined with the protocol stack feature vector and open port set, a standardized asset fingerprint record is obtained.
[0021] Specifically, after sending SYN packets to the target ports of each asset in the target network, the system receives a SYN / ACK response from the target host and immediately sends an RST packet to terminate the connection, thus confirming that the port is open. All confirmed open port numbers are then aggregated into an open port set. For each port in the open port set, the system waits for the target service to actively send a banner response text within a fixed duration of 6 seconds. The service name, version number, and vendor identifier fields are extracted from the banner response text. These three fields together constitute a service fingerprint triplet. The service name field identifies the application type running on that port, the version number field identifies the specific release version of the application, and the vendor identifier field identifies the development source of the application. These three fields together uniquely identify the identity information of the software running on that port. The waiting time is set to 6 seconds because the banner sending delay of common network services under normal operating conditions is usually no more than 3 seconds. A 6-second delay ensures that most services can complete the banner response while avoiding excessively low detection efficiency due to timeouts.
[0022] TCP probe packets, ICMP echo request packets, and UDP probe packets are sent sequentially to each asset. Each type of probe packet has a specific function: TCP probe packets extract sequence number increment features, window size fields, and TCP flag combinations to reflect the implementation characteristics of the target host's TCP protocol stack; ICMP echo request packets extract TTL values and ICMP code fields to reflect differences in the target host's network layer protocol implementation; UDP probe packets are sent to confirmed closed ports to extract the message length and IP header copying status from the ICMP port unreachable response, reflecting differences in the target host's UDP processing mechanism. The sequence number increment features, window size fields, TTL values, and flag combinations extracted from the above response packets are weighted and concatenated according to preset weights to obtain a protocol stack feature vector. The preset weights are allocated from high to low based on the ability of each sub-feature to distinguish operating system types. The TCP sequence number-related sub-features have the strongest distinguishing ability and the highest weight, followed by ICMP sub-features, and then UDP sub-features. This weight allocation method is determined based on the known statistical laws governing the distinguishing ability of various protocol features in the existing network asset detection field. The service name and version number fields in the service fingerprint triplet are converted into CPE standard format strings according to the hierarchical structure of vendor, product name and version number, so that the service software information has a unified identification format that can be directly searched and matched with the CVE vulnerability database. The CPE string set, protocol stack feature vector, open port set and fingerprint collection timestamp are assembled together into a standardized asset fingerprint record.
[0023] In one specific embodiment, step S2 includes: The collection methods for standardized asset fingerprint records are classified into three categories: authentication scanning, non-authentication active scanning, and passive traffic sniffing, resulting in collection method type labels. Based on the type of collection method, the standardized asset fingerprint records are assigned corresponding initial lifetime weights. The initial lifetime weight corresponding to the authentication scan is higher than that corresponding to the non-authentication active scan, and the initial lifetime weight corresponding to the non-authentication active scan is higher than that corresponding to the passive traffic sniffing. Based on the operating system type field in the standardized asset fingerprint record, retrieve the historical decay rate parameter records of the same type of asset, and take the arithmetic mean of the retrieved historical decay rate parameter records to obtain the initial decay rate parameter. Standardized asset fingerprint records, initial life value weights, and initial decay rate parameters are bound and stored according to asset identifiers to obtain asset fingerprint entries with life values.
[0024] Specifically, the criteria for determining the collection method type are whether the scanning engine possesses valid login credentials for the target host during the probe and whether the data source is an active packet transmission: If the scanning engine successfully logs into the target host via authentication protocols such as SSH, WMI, or SNMP and then collects fingerprints, it is determined to be an authentication scan, assigned an initial lifetime weight of 1.0, which is the highest lifetime value, based on the fact that the fingerprint information collected by authentication scans comes directly from within the target host, resulting in the highest field completeness and accuracy; if the scanning engine does not possess login credentials and only collects fingerprints by sending probe packets to the target host and analyzing the response, it is determined to be an unauthenticated active scan. The initial lifetime weight is assigned to 0.85, which is 0.15 units lower than that of authentication scans. This is based on the fact that non-authentication active scans may return a fake banner from the target service, and while the accuracy of the fields is lower than that of authentication scans, it still has a high degree of reliability. If the fingerprint information comes from the side-channel capture and analysis of data packets that naturally flow through the network, and the scanning engine does not actively send any probe packets to the target host, it is judged as passive traffic sniffing, and an initial lifetime weight of 0.65 is assigned to it. This is the lowest value among the three levels, based on the fact that the fields that can be extracted by passive traffic sniffing are limited by the actual protocol interactions that occur in the traffic, and the probability of incomplete field coverage is the highest. The interval design between the three levels allows for distinguishable differences in alarm decisions during the subsequent lifetime decay process for different collection methods.
[0025] The initial attenuation rate parameter is determined in two scenarios: If a historical correction record exists in the attenuation rate parameter library that matches the operating system type field in the standardized asset fingerprint record, the arithmetic mean of the historically corrected attenuation rate parameters of all assets under that operating system type is taken as the initial attenuation rate parameter for the current asset, allowing the historical change patterns of assets of the same type to be directly transmitted to newly accessed assets; if no historical correction record for the corresponding operating system type exists in the attenuation rate parameter library, the initial attenuation rate parameter is set to a default value of 0.005 per hour. This default value is set based on the statistical frequency of asset configuration changes in a typical enterprise network environment. Under this change frequency, the time required for the fingerprint lifetime value to decay from the initial value to the first lifetime value threshold of 0.70 is approximately 72 hours, which matches the regular asset inspection cycle in an enterprise network. The standardized asset fingerprint record, initial lifetime value weight, and initial attenuation rate parameter are bound to the asset IP address as a unique asset identifier, and a fingerprint collection timestamp is written as the time reference for lifetime value attenuation calculation. Together, they constitute an asset fingerprint entry with a lifetime value. This entry is the unified data carrier for subsequent dynamic attenuation monitoring and hierarchical alarm decision-making.
[0026] In one specific embodiment, step S3 includes: With a preset time step as the period, probe packets are sent to each open port in the asset fingerprint entry with life value. The returned TCP flag response combination is compared bit by bit with the port response pattern in the standardized asset fingerprint record. Ports with differences in the comparison results are marked as port response abnormalities, thus obtaining port response abnormality markers. Using a preset time step as the period, re-collect the Banner response text for each open service in the asset fingerprint entries with life value, match the re-collected version number field with the Banner version field in the standardized asset fingerprint record, and mark services with inconsistent matching results as Banner version abnormal, thus obtaining the Banner version abnormal marker. With a preset time step as the period, TCP probe packets and ICMP echo request packet response messages are re-collected for each asset in the asset fingerprint entries with life value. The incremental features of the sequence number, window size field and TTL value obtained by re-collection are weighted and concatenated with the protocol stack feature vector according to the preset weight, and the Hamming distance is calculated. Assets whose Hamming distance exceeds the preset drift threshold are marked as protocol stack drift anomalies, and the protocol stack drift anomaly mark is obtained. Based on the port response anomaly flag, banner version anomaly flag, and protocol stack drift anomaly flag, the penalty coefficient corresponding to each anomaly type is multiplied sequentially by the current life value in the asset fingerprint entry with life value. The multiplication result, along with each anomaly flag and the trigger time, is written back to the asset fingerprint entry with life value to obtain a dynamic life value update record.
[0027] Specifically, the preset time steps for the three types of anomaly monitoring are set to different periods: the preset time step for port response pattern monitoring is set to once every 2 hours, based on the fact that changes in port open status are usually triggered by service restarts or firewall policy adjustments. Such changes are low-frequency events in enterprise networks, and the 2-hour period can capture changes while avoiding frequent probes that would cause additional network load to the target host; the preset time step for Banner version field monitoring is set to once every 4 hours, based on the fact that software version changes are usually accompanied by service restarts, and the Banner content is updated immediately after the restart, and the 4-hour period is sufficient to complete the detection within a reasonable time window after the version change; the preset time step for protocol stack feature vector monitoring is set to once every 6 hours, based on the fact that changes in protocol stack features at the operating system level only occur after system updates or restarts, and the change frequency is the lowest, and the 6-hour period matches the response time of operating system-level changes. The preset drift threshold is set to a Hamming distance of 3. The Hamming distance is calculated by concatenating the incremental sequence number feature, window size field, and TTL value obtained from the re-acquisition with the protocol stack feature vector according to preset weights. Then, a bitwise XOR operation is performed on the corresponding binary bits of the two feature vectors, and the total number of bits with a value of 1 in the XOR result is counted; this total number is the Hamming distance. The reason for setting the preset drift threshold to 3 is that, under normal operating conditions, protocol stack response fluctuations caused by slight adjustments to operating system kernel parameters typically do not exceed two feature bits. Setting the threshold to 3 allows for tolerance of normal operating fluctuations while effectively identifying substantial changes at the operating system level.
[0028] The penalty coefficients for the three types of anomalies are set as follows: 0.80 for port response anomalies, 0.70 for banner version anomalies, and 0.60 for protocol stack drift anomalies. These three values are based on the degree of fingerprint failure risk reflected by the anomaly type: port response mode changes are minor anomalies at the network connection level, not directly reflecting changes in software version or operating system, resulting in the lowest fingerprint failure risk and the smallest penalty; inconsistent banner version fields directly indicate a change in the target service's software version, showing a substantial deviation from the version information described by the CPE string in the standardized asset fingerprint record, resulting in a moderate fingerprint failure risk and a moderate penalty; protocol stack feature vector drift indicates a possible version update or configuration change at the target host's operating system level, resulting in the highest fingerprint failure risk and the largest penalty. When multiple anomalies are detected simultaneously within the same time step, the penalty coefficients corresponding to each anomaly type are multiplied sequentially by the current lifetime value in ascending order of penalty magnitude. The multiplication order does not affect the final numerical result; the explicit order is only to ensure the determinism of the calculation process. The accumulated current life value, each anomaly marker type, and each anomaly trigger time field are written back to the asset fingerprint entry with life value to form a dynamic life value update record. This record adds the current life value field and the anomaly trigger record list field to the standardized asset fingerprint record fields. The two newly added fields together constitute the input data for subsequent hierarchical alarm decisions.
[0029] In one specific embodiment, step S4, which combines the current health value in the dynamic health value update record with the CVE vulnerability database matching result, includes: The CPE string set of the standardized asset fingerprint record in the dynamic update record of life value is searched and matched with the list of affected CPE strings of each entry in the CVE vulnerability database, and the CVE entries with intersection in the CPE string set are extracted as a candidate vulnerability set. Based on the repair confirmation timestamp of each CVE entry in the candidate vulnerability set, CVE entries whose repair confirmation timestamp is earlier than the fingerprint collection timestamp in the standardized asset fingerprint record are removed from the candidate vulnerability set to obtain the effective candidate vulnerability set. The set of valid candidate vulnerabilities is associated with the current life value in the dynamic life value update record by asset identifier to obtain the life value vulnerability association record.
[0030] Specifically, each CPE string in the CPE string set of the standardized asset fingerprint record in the dynamic update record of life values is matched against the affected CPE string list of each CVE entry in the CVE vulnerability database, using string prefix matching. The matching rule is: if a CPE string in the CPE string set is completely identical to an entry in the affected CPE string list of the CVE entry in the vendor and product name fields, and the version number field meets the affected version range declared by the CVE entry, then it is determined that there is an intersection between the two, and the CVE entry is included in the candidate vulnerability set. The fields retained for each CVE entry in the candidate vulnerability set include CVE number, affected CPE string list, CVSS score, vulnerability disclosure timestamp, and remediation confirmation timestamp. The remediation confirmation timestamp is the time record of the release of the official remediation plan for the CVE entry and confirmation by the authoritative vulnerability database. For some CVE entries that do not yet have an official remediation plan, this field is empty. For CVE entries with an empty fix confirmation timestamp field, it is determined that there is no official fix confirmation for the vulnerability, and they are retained in the candidate vulnerability set without removal. For CVE entries with a valid time record in the fix confirmation timestamp field, their fix confirmation timestamp is compared with the fingerprint collection timestamp in the standardized asset fingerprint record. If the fix confirmation timestamp is earlier than the fingerprint collection timestamp on the timeline, it indicates that the official fix for the vulnerability has been officially released before this fingerprint collection, and the target asset has the conditions to obtain the fix when the fingerprint is collected. The CVE entry is then removed from the candidate vulnerability set, resulting in a valid candidate vulnerability set.
[0031] The removal operation where the repair confirmation timestamp is earlier than the fingerprint collection timestamp is based on the following technical basis: Existing vulnerability scanning methods only match version strings with the CVE database, neglecting the release time of repair solutions. This results in vulnerabilities that have already received official patches being continuously marked as valid vulnerabilities, generating numerous invalid alerts. The introduction of a comparison and filtering between the repair confirmation timestamp and the fingerprint collection timestamp ensures that the valid candidate vulnerability set retains only CVE entries for which the asset objectively requires repair at the time of fingerprint collection. The CVE number, CVSS score field, and current life value field of each CVE entry in the valid candidate vulnerability set are associated with the asset's IP address as a unique asset identifier. Simultaneously, the abnormal trigger record list field in the life value dynamic update record is retained, collectively forming a life value vulnerability association record. This record integrates the asset's current fingerprint trust information and the valid vulnerability information faced by the asset into the same data structure, serving as a unified input for subsequent three-level handling decisions.
[0032] Figure 2 This is a schematic diagram of the distribution of vulnerability alert three-level handling results based on fingerprint lifetime values in the embodiments of this application. Figure 2The paper compares the number of various alarm handling entries after vulnerability scanning by the prior art and the method described in this application under the same target network environment. The prior art, due to the lack of a fingerprint life value mechanism, classifies all matching results into direct alarms and generates 148 false alarm entries due to the failure to perform remediation timeliness filtering. The method described in this application, after introducing life value vulnerability association records, divides the alarm results into three levels of handling according to the current life value interval: 187 direct alarms, 95 suspected alarms pending verification, and 38 alarms triggering rescanning. The number of false alarm entries is reduced to 12.
[0033] In one specific embodiment, step S4 is divided into three levels of handling based on the current health value range: direct alarm, suspected pending verification, and triggered rescan, including: The current life value in the life value vulnerability association record is ranged. The set of valid candidate vulnerabilities corresponding to assets whose current life value is not lower than the first life value threshold is sorted from high to low according to the CVSS score of the CVE entry. A direct alarm work order containing asset identifier, CVE number, CVSS score and suggested remediation solution is generated to obtain the direct alarm list. The set of valid candidate vulnerabilities corresponding to assets whose current health value is lower than the first health value threshold but not lower than the second health value threshold is used to generate a list of suspected vulnerabilities pending verification with fingerprints indicating insufficient health value. Assets with current health below the second health threshold are extracted from the health vulnerability association record. CVE entry matching is not performed. The asset identifier is written to the rescan task queue to obtain the list of assets that trigger rescan.
[0034] Specifically, the first life value threshold is set to 0.70, and the second life value threshold is set to 0.40. These two thresholds divide the current life value range into three intervals. The first life value threshold is set to 0.70 because when the current life value is not lower than 0.70, the deviation between the asset status reflected by the fingerprint and the actual status is within an acceptable range under the combined effect of natural decay and behavior anomaly penalty, and the CVE matching result has a degree of credibility that can be directly accepted. The second life value threshold is set to 0.40 because when the current life value is lower than 0.40, the fingerprint has accumulated multiple behavior anomaly penalty decays, and the cumulative penalty coefficient results show that there are at least two types of substantial deviations between the asset status reflected by the fingerprint and the actual status, such as protocol stack feature drift, banner version change, or port response mode change. At this time, the credibility of the CVE matching result obtained based on this fingerprint is insufficient to support alarm decision. For assets with a current health value of at least 0.70, each CVE entry in the set of valid candidate vulnerabilities is sorted from highest to lowest according to its CVSS score, and a direct alert ticket is generated for each entry. The fields of the direct alert ticket include asset identifier, CVE number, CVSS score, vulnerability disclosure timestamp, and suggested remediation solution. The content of the suggested remediation solution field comes from the official remediation guidance text associated with the CVE entry in the CVE vulnerability database. All direct alert tickets are summarized into a direct alert list.
[0035] For assets with a current lifespan below 0.70 but not below 0.40, generate suspected vulnerability verification entries for each CVE entry in their valid candidate vulnerability set. These suspected vulnerability verification entries are annotated with a fingerprint indicating insufficient lifespan, based on the direct alert ticket field. This annotation includes the specific value of the current lifespan, the anomaly type that triggered the lifespan decrease, and the time of the most recent anomaly trigger. The annotation content is directly derived from the anomaly trigger record list field in the lifespan vulnerability association record, enabling manual reviewers to determine the specific reason for fingerprint failure and decide whether to initiate manual verification. All suspected vulnerability verification entries are then compiled into a suspected verification list. For assets with a current lifespan below 0.40, no CVE entry sorting or alert ticket generation operations are performed on their valid candidate vulnerability set. Instead, the asset identifier is directly written to the rescan task queue. Each record in the rescan task queue contains only two fields: asset identifier and write time. The write time is used to schedule rescan tasks sequentially according to the write order. All asset identifiers in the rescan task queue are compiled into a rescan-triggered asset list, serving as input data for subsequent rescan execution and decay rate parameter self-calibration steps.
[0036] In one specific embodiment, in step S4, S1 to S2 are re-executed for the asset that triggered the rescan to generate a new standardized asset fingerprint record. The new standardized asset fingerprint record is compared with the CPE string set of the standardized asset fingerprint record for similarity. Based on the comparison result, the initial decay rate parameter is adjusted upward or downward to obtain the corrected decay rate parameter, including: For each asset in the triggered rescan asset list, re-execute steps S1 to S2 to obtain a new standardized asset fingerprint record and the corresponding new initial life value weight. The CPE string set of the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record are treated as two sets respectively. The ratio of the number of elements in the intersection of the two sets to the number of elements in the union of the two sets is calculated to obtain the CPE string similarity. Based on the range of CPE string similarity, differential correction is performed on the initial decay rate parameter: the initial decay rate parameter corresponding to the asset with CPE string similarity not lower than the first similarity threshold is down-corrected by the first down-correction step size coefficient, the initial decay rate parameter corresponding to the asset with CPE string similarity lower than the first similarity threshold but not lower than the second similarity threshold remains unchanged, and the initial decay rate parameter corresponding to the asset with CPE string similarity lower than the second similarity threshold is up-corrected by the first up-correction step size coefficient to obtain the corrected decay rate parameter; The corrected attenuation rate parameters are categorized and summarized according to the asset's operating system type field. The arithmetic mean of the corrected attenuation rate parameters of all assets under the same operating system type is taken, and the arithmetic mean is written into the attenuation rate parameter library as the initial attenuation rate parameter of newly connected assets under the corresponding operating system type, thus obtaining the updated attenuation rate parameter library.
[0037] Specifically, the CPE string similarity is calculated using CPE string entries as the counting unit. The number of CPE string entries appearing simultaneously in the CPE string set of the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record is taken as the number of intersection elements. The total number of CPE string entries after merging the two sets and removing duplicate entries is taken as the number of union elements. The ratio of the two is the CPE string similarity, which ranges from 0 to 1. A higher value indicates a higher degree of consistency between the new and old fingerprints in terms of software component composition. The first similarity threshold is set to 0.90, and the second similarity threshold is set to 0.70. These two thresholds divide the CPE string similarity into three intervals. The first similarity threshold is set at 0.90 because: when the CPE string similarity is not lower than 0.90, more than 90% of the entries in the software component sets of the old and new fingerprints are consistent, the asset status has not changed substantially, the original initial decay rate parameter is set too fast, and should be adjusted downwards; the second similarity threshold is set at 0.70 because: when the CPE string similarity is lower than 0.70, more than 30% of the entries in the software component sets of the old and new fingerprints have changed, the asset status has changed substantially, the original initial decay rate parameter is set too slow, and should be adjusted upwards; when the CPE string similarity is between 0.70 and 0.90, the asset status has been partially adjusted but has not reached the level of substantial change, and the initial decay rate parameter remains unchanged. The first downward adjustment step size factor is set to 0.10, meaning that the current initial attenuation rate parameter is multiplied by 0.90 to obtain the corrected attenuation rate parameter, i.e., the attenuation rate will be reduced by 10% for each highly consistent rescan result. The first upward adjustment step size factor is set to 0.20, meaning that the current initial attenuation rate parameter is multiplied by 1.20 to obtain the corrected attenuation rate parameter, i.e., the attenuation rate will be increased by 20% for each substantially changed rescan result. The reason for setting the upward adjustment step size factor to be greater than the downward adjustment step size factor is that the security risk caused by missed vulnerabilities is higher than the operational cost caused by false positives. In uncertain situations, a strategy that tends to accelerate the attenuation rate to trigger more rescan operations has higher security value.
[0038] The corrected decay rate parameter has a lower and upper limit. The lower limit is set at 0.001 per hour, and the upper limit is set at 0.050 per hour. The lower limit of 0.001 per hour is based on the following: if the decay rate continues to decrease and approaches zero, the fingerprint lifetime value will remain high for a long time without triggering a rescan, resulting in the inability to update the fingerprints of assets that have actually changed in a timely manner. The upper limit of 0.050 per hour is based on the following: if the decay rate continues to increase and exceeds 0.050 per hour, the fingerprint lifetime value will decay from the initial value of 1.0 to below the second lifetime value threshold of 0.40 within approximately 20 hours. The frequency of triggering a rescan will exceed the normal network inspection cycle, causing a surge in network probe traffic and placing additional load on the target host. When performing a downward correction, if the correction result is lower than the lower limit of 0.001 per hour, the corrected decay rate parameter will be forcibly set to 0.001 per hour; when performing an upward correction, if the correction result is higher than the upper limit of 0.050 per hour, the corrected decay rate parameter will be forcibly set to 0.050 per hour. The corrected attenuation rate parameters of each asset are classified according to the operating system type field in its standardized asset fingerprint record. The arithmetic mean of the corrected attenuation rate parameters of all assets under the same operating system type is taken and written into the entry of the corresponding operating system type in the attenuation rate parameter library, overwriting the original record of the operating system type, to obtain the updated attenuation rate parameter library. When a newly connected asset retrieves the historical attenuation rate parameter record of the same type in step S2, the value of the corresponding operating system type entry in the updated attenuation rate parameter library is directly read as the initial attenuation rate parameter.
[0039] Figure 3 The diagram illustrates how the initial decay rate parameters of fast-changing and slow-changing assets converge towards their respective convergence ranges after multiple rounds of rescanning correction. For fast-changing assets, the rescanning results continuously trigger upward correction by adjusting the step size coefficient by 0.20, causing the decay rate parameter to gradually increase from its initial value of 0.005 and stabilize around 0.018 after approximately the fifth correction round. For slow-changing assets, the rescanning results continuously trigger downward correction by adjusting the step size coefficient by 0.10, causing the decay rate parameter to gradually decrease from its initial value of 0.020 and stabilize around 0.003 after approximately the fourteenth correction round. The decay rate parameter in the prior art remains fixed at 0.005, failing to adaptively adjust according to the actual rate of change of the asset.
[0040] The above describes the vulnerability scanning method based on asset fingerprint recognition in the embodiments of this application. The following describes the vulnerability scanning system based on asset fingerprint recognition in the embodiments of this application. One embodiment of the vulnerability scanning system based on asset fingerprint recognition in the embodiments of this application includes: The detection module is used to perform fingerprint detection on each asset in the target network. It maps the detected service version field and protocol stack feature vector with the CPE standard format to obtain a standardized asset fingerprint record. The binding module is used to bind the standardized asset fingerprint record with the initial life value weight and the initial decay rate parameter according to the collection method of the standardized asset fingerprint record, so as to obtain the asset fingerprint entry with life value. The attenuation module is used to continuously monitor the port response mode, banner version field and protocol stack feature vector in the asset fingerprint entry with life value. When any field is detected to be inconsistent with the corresponding field in the standardized asset fingerprint record, the current life value in the asset fingerprint entry with life value is attenuated according to the corresponding penalty coefficient to obtain a dynamic life value update record. The correction module is used to combine the current life value in the dynamic update record of the life value with the matching result of the CVE vulnerability database, and divide it into three levels of handling according to the interval of the current life value: direct alarm, suspected pending verification, and triggered rescan. For assets that have triggered rescan, S1 to S2 are re-executed to generate new standardized asset fingerprint records. The similarity of the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record is compared. The initial decay rate parameter is adjusted upward or downward according to the comparison result to obtain the corrected decay rate parameter.
[0041] This invention also provides a vulnerability scanning device based on asset fingerprinting, which can be a server. The asset fingerprinting-based vulnerability scanning device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor, designed as a computer, provides computing and control capabilities. The memory of the asset fingerprinting-based vulnerability scanning device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the asset fingerprinting-based vulnerability scanning device stores the data corresponding to this embodiment. The network interface of the asset fingerprinting-based vulnerability scanning device is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.
[0042] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the vulnerability scanning method based on asset fingerprinting.
[0043] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0044] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a vulnerability scanning device based on asset fingerprinting (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0045] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. An asset fingerprinting based vulnerability scanning method, characterized in that, The method includes: Step S1: Perform fingerprint detection on each asset in the target network, and map the detected service version field and protocol stack feature vector with the CPE standard format to obtain a standardized asset fingerprint record. Step S2: Based on the acquisition method of the standardized asset fingerprint record, bind the standardized asset fingerprint record with the initial lifetime weight and the initial decay rate parameter to obtain asset fingerprint entries with lifetime values. Step S3: Continuously monitor the port response mode, Banner version field and protocol stack feature vector in the asset fingerprint entry with life value. When any field is found to be inconsistent with the corresponding field in the standardized asset fingerprint record, the current life value in the asset fingerprint entry with life value is reduced according to the corresponding penalty coefficient to obtain a dynamic life value update record. Step S4: Combine the current life value in the dynamic update record of life value with the matching result of the CVE vulnerability database, and divide it into three levels of handling according to the interval of the current life value: direct alarm, suspected pending verification, and triggered rescan. For assets that have triggered rescan, re-execute S1 to S2 to generate new standardized asset fingerprint records. Compare the similarity between the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record. Adjust or lower the initial decay rate parameter according to the comparison result to obtain the corrected decay rate parameter.
2. The method for vulnerability scanning based on asset fingerprinting as claimed in claim 1, wherein, Step S1 includes: Send SYN packets to the target ports of each asset in the target network, and extract the port open status based on the returned SYN / ACK response to obtain the set of open ports; Based on the Banner response text of each open port in the open port set, the service name field, version number field, and vendor identifier field are extracted to obtain the service fingerprint triplet. TCP probe packets, ICMP echo request packets, and UDP probe packets are sent sequentially to each asset. The sequence number increment feature, window size field, TTL value, and flag combination in each response message are weighted and concatenated according to a preset weight to obtain the protocol stack feature vector. The service name field and version number field in the service fingerprint triplet are mapped in a CPE-normalized manner according to the hierarchical structure of vendor, product name and version number. Combined with the protocol stack feature vector and the set of open ports, the standardized asset fingerprint record is obtained.
3. The method for vulnerability scanning based on asset fingerprinting as claimed in claim 1, wherein, Step S2 includes: The collection method of the standardized asset fingerprint record is determined by type, and the collection method is divided into three categories: authentication scanning, non-authentication active scanning and passive traffic sniffing, and the collection method type label is obtained; According to the type of collection method, the standardized asset fingerprint record is assigned a corresponding initial lifetime weight, wherein the initial lifetime weight corresponding to the authentication scan is higher than the initial lifetime weight corresponding to the non-authentication active scan, and the initial lifetime weight corresponding to the non-authentication active scan is higher than the initial lifetime weight corresponding to the passive traffic sniffing, thus obtaining the initial lifetime weight. Based on the operating system type field in the standardized asset fingerprint record, retrieve the historical decay rate parameter records of the same type of asset, and take the arithmetic mean of the retrieved historical decay rate parameter records to obtain the initial decay rate parameter. The standardized asset fingerprint record, the initial life value weight, and the initial decay rate parameter are bound and stored according to the asset identifier to obtain the asset fingerprint entry with life value.
4. The method for vulnerability scanning based on asset fingerprinting as claimed in claim 1, wherein, Step S3 includes: With a preset time step as the period, probe packets are sent to each open port in the asset fingerprint entry with life value. The returned TCP flag response combination is compared bit by bit with the port response pattern in the standardized asset fingerprint record. Ports with differences in the comparison results are marked as port response abnormalities, thus obtaining port response abnormality markers. With a preset time step as the period, the Banner response text of each open service in the asset fingerprint entry with life value is re-collected. The version number field obtained by re-collection is matched with the Banner version field in the standardized asset fingerprint record. Services with inconsistent matching results are marked as Banner version abnormal, and Banner version abnormal markers are obtained. With a preset time step as the period, TCP probe packets and ICMP echo request packet response messages are re-collected for each asset in the asset fingerprint entry with life value. The sequence number incremental feature, window size field and TTL value obtained by re-collection are weighted and concatenated with the protocol stack feature vector according to the preset weight, and the Hamming distance is calculated. Assets whose Hamming distance exceeds the preset drift threshold are marked as protocol stack drift anomalies, and the protocol stack drift anomaly mark is obtained. Based on the port response anomaly flag, the banner version anomaly flag, and the protocol stack drift anomaly flag, the penalty coefficient corresponding to each anomaly type is multiplied sequentially by the current life value in the asset fingerprint entry with life value. The multiplication result, along with each anomaly flag and the trigger time, is written back to the asset fingerprint entry with life value to obtain the dynamic life value update record.
5. The method for vulnerability scanning based on asset fingerprinting as claimed in claim 1, wherein, Step S4 involves combining the current health value in the dynamically updated health value record with the CVE vulnerability database matching results, including: The CPE string set of the standardized asset fingerprint record in the dynamic update record of the life value is searched and matched with the list of affected CPE strings of each entry in the CVE vulnerability database, and the CVE entries with intersection in the CPE string set are extracted as a candidate vulnerability set. Based on the repair confirmation timestamp of each CVE entry in the candidate vulnerability set, CVE entries whose repair confirmation timestamp is earlier than the fingerprint collection timestamp in the standardized asset fingerprint record are removed from the candidate vulnerability set to obtain a valid candidate vulnerability set. The set of valid candidate vulnerabilities is associated and bound with the current life value in the dynamic life value update record according to the asset identifier to obtain the life value vulnerability association record.
6. The method of vulnerability scanning based on asset fingerprinting as claimed in claim 5, wherein, Step S4 is divided into three levels of handling based on the current health value range: direct alarm, suspected pending verification, and triggered rescan, including: The current life value in the life value vulnerability association record is ranged. The set of valid candidate vulnerabilities corresponding to assets whose current life value is not lower than the first life value threshold is sorted from high to low according to the CVSS score of the CVE entry. A direct alarm work order containing asset identifier, CVE number, CVSS score and suggested remediation solution is generated to obtain a direct alarm list. The set of valid candidate vulnerabilities corresponding to assets whose current health value is lower than the first health value threshold but not lower than the second health value threshold is used to generate a list of suspected vulnerabilities pending verification with fingerprints indicating insufficient health value. Assets with current health values below the second health value threshold are extracted from the health value vulnerability association record. CVE entry matching is not performed. The asset identifier is written into the rescan task queue to obtain the asset list that triggers rescan.
7. The method of vulnerability scanning based on asset fingerprinting as claimed in claim 6, wherein, In step S4, S1 to S2 are re-executed for the assets that triggered the rescan to generate new standardized asset fingerprint records. The new standardized asset fingerprint records are then compared with the CPE string set of the original standardized asset fingerprint records for similarity. Based on the comparison results, the initial decay rate parameter is adjusted upwards or downwards to obtain the corrected decay rate parameter, including: Steps S1 to S2 are re-executed for each asset in the triggered rescan asset list to obtain new standardized asset fingerprint records and corresponding new initial life value weights. The CPE string set of the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record are respectively regarded as two sets. The ratio of the number of elements in the intersection of the two sets to the number of elements in the union of the two sets is calculated to obtain the CPE string similarity. Based on the range of CPE string similarity, differential correction is performed on the initial decay rate parameter: the initial decay rate parameter corresponding to the asset with CPE string similarity not lower than the first similarity threshold is down-corrected by the first down-correction step size coefficient; the initial decay rate parameter corresponding to the asset with CPE string similarity lower than the first similarity threshold but not lower than the second similarity threshold remains unchanged; and the initial decay rate parameter corresponding to the asset with CPE string similarity lower than the second similarity threshold is up-corrected by the first up-correction step size coefficient, thus obtaining the corrected decay rate parameter. The corrected attenuation rate parameters are categorized and summarized according to the asset's operating system type field. The arithmetic mean of the corrected attenuation rate parameters of all assets under the same operating system type is taken, and the arithmetic mean is written into the attenuation rate parameter library as the initial attenuation rate parameter of newly connected assets under the corresponding operating system type, thus obtaining the updated attenuation rate parameter library.
8. A vulnerability scanning system based on asset fingerprinting, characterized in that, For implementing the vulnerability scanning method based on asset fingerprinting as described in any one of claims 1-7, the vulnerability scanning system based on asset fingerprinting comprises: The detection module is used to perform fingerprint detection on each asset in the target network. It maps the detected service version field and protocol stack feature vector with the CPE standard format to obtain a standardized asset fingerprint record. The binding module is used to bind the standardized asset fingerprint record with the initial life value weight and the initial decay rate parameter according to the collection method of the standardized asset fingerprint record, so as to obtain the asset fingerprint entry with life value. The attenuation module is used to continuously monitor the port response mode, banner version field and protocol stack feature vector in the asset fingerprint entry with life value. When any field is detected to be inconsistent with the corresponding field in the standardized asset fingerprint record, the current life value in the asset fingerprint entry with life value is attenuated according to the corresponding penalty coefficient to obtain a dynamic life value update record. The correction module is used to combine the current life value in the dynamic update record of the life value with the matching result of the CVE vulnerability database, and divide it into three levels of handling according to the interval of the current life value: direct alarm, suspected pending verification, and triggered rescan. For assets that have triggered rescan, S1 to S2 are re-executed to generate new standardized asset fingerprint records. The similarity of the new standardized asset fingerprint record and the CPE string set of the standardized asset fingerprint record is compared. The initial decay rate parameter is adjusted upward or downward according to the comparison result to obtain the corrected decay rate parameter.
9. A vulnerability scanning device based on asset fingerprint recognition, characterized in that, The device includes a memory and a processor, the memory storing a computer program that can run on the processor, the processor executing the computer program to implement the vulnerability scanning method based on asset fingerprinting as described in any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it causes the processor to perform the vulnerability scanning method based on asset fingerprinting as described in any one of claims 1 to 7.