Banking message sensitive data detection method and device based on message classification, equipment and medium

Abstract

The application provides a bank business message sensitive data detection method, device and equipment based on message classification and a medium. The method comprises the following steps: judging whether the type of an obtained network request belongs to a non-specific request type or a specific request type that fails to pass a whitelist check; if any of the judgments is yes, identifying the category of a business message in the network request; when the category of the business message belongs to a message type supported by a system, analyzing the business message to extract a field name and a field value; double-checking the field name and the field value of the business message; and if the field name is matched successfully and the field value also meets the data characteristics of sensitive information, or the field name is not matched successfully but the field value meets the data characteristics of specific sensitive information, it is determined that the business message contains sensitive information. The technical scheme solves the problems of poor model generalization ability, repeated detection, high artificial maintenance cost, high risk of misjudgment or missed judgment and the like of the existing method.

Description

Technical Field

[0001] This application belongs to the field of information security technology and relates to a method, apparatus, equipment and medium for detecting sensitive data in banking business messages based on message classification. Background Technology

[0002] With the deepening of digital transformation in the financial sector, data interaction between banking systems and external systems is becoming increasingly frequent. Business messages, as the fundamental carriers of core data such as transaction information, customer information, and account information, continuously circulate in the network environment, making them a critical link in data security protection. Messages may be maliciously intercepted during network transmission, leading to the leakage of sensitive data. Once sensitive data in messages is leaked, it not only poses risks such as the leakage of customer privacy information, triggering telecommunications fraud, and causing financial losses for customers, but also leads to a series of problems for banks, including reputational damage, regulatory penalties, and the failure of financial risk control. Therefore, pre-emptive detection of sensitive information in banking business messages, and timely detection and handling of sensitive data leakage risks before messages are sent, has become an urgent technical problem for the banking industry.

[0003] Current methods for detecting sensitive information in messages mainly include the following three technical approaches:

[0004] 1) Regular expressions + keyword matching

[0005] Regular expression + keyword matching is a traditional method for detecting sensitive information in messages. Its core is to identify sensitive information in messages through predefined rule patterns. For example, personally identifiable information (PII) such as ID card numbers and bank card numbers have fixed formats and can be matched using regular expressions. The key to this method lies in rule design, i.e., building regular expression and keyword libraries for different types of sensitive information. The limitations of this method are: it lacks generalization ability, cannot identify sensitive keywords not added to the dictionary, and has a high risk of false positives / false negatives; it also has high maintenance costs, requiring manual addition of various possible keywords, making comprehensive coverage difficult.

[0006] 2) Traditional machine learning methods

[0007] First, financial security and business experts manually extract multidimensional features from sensitive data in the messages, including character statistics, format features, field position features, message business attribute features, and contextual features. Then, based on labeled banking business message samples, traditional machine learning classification models (such as Support Vector Machine (SVM), Naive Bayes, Random Forest, Logistic Regression, etc.) are trained. The model achieves binary classification of message content / fields as sensitive / non-sensitive, or multi-class detection of sensitive data types. The limitations of this method are that feature engineering relies on expert experience and is difficult to adapt to new types of sensitive information; the model's generalization ability is limited, and its performance in recognizing modified sensitive words is poor; and its ability to process high-dimensional unstructured data is weak, making it prone to the curse of dimensionality.

[0008] 3) Deep learning methods

[0009] The deep learning-based method for detecting sensitive information in banking messages utilizes deep learning architectures such as RNN / LSTM, pre-trained large models in the financial field, and Transformer. It automatically learns deep features at the character, word, sentence, contextual semantic, and business scenario levels from banking business messages end-to-end, eliminating the need for manual feature engineering. It can simultaneously perform multiple tasks including message classification, sensitive entity identification, sensitive data location, sensitivity level classification, and risk assessment. However, this method has limitations: poor model interpretability and significant compliance risks; extremely high computational and annotation costs, and poor real-time adaptability; poor adaptability to small sample scenarios and significant cold-start difficulties; general pre-trained models are prone to domain shift and performance degradation in banking-specific message scenarios; and when applied across business scenarios, continuous sample annotation, model fine-tuning, and iterative optimization are required, resulting in high long-term maintenance costs. Summary of the Invention

[0010] This application provides a method, apparatus, equipment, and medium for detecting sensitive data in banking business messages based on message classification, which solves the problems of poor model generalization ability, repeated detection, high manual maintenance cost, and high risk of misjudgment or omission in existing message sensitive information detection methods.

[0011] Firstly, this application provides a method for detecting sensitive data in banking business messages based on message classification, comprising the following steps: obtaining a network request; determining whether the request type of the network request belongs to a non-specific request type or a specific request type that fails whitelist verification; if either the request type of the network request is a non-specific request type or a specific request type that fails whitelist verification, then identifying the category of the business message in the network request; when the category of the business message belongs to a message type supported by the system, using a message parsing method adapted to that category to parse the business message to extract the field names and field values ​​contained therein; performing dual verification on the field names and field values ​​of the business message based on a sensitive field library and a sensitive data rule library; if the field name of the business message matches successfully in the sensitive field library and the rule field value in the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message does not match successfully in the sensitive field library, but the field value conforms to the data characteristics of specific sensitive information, then determining that the business message contains sensitive information.

[0012] In this application, a self-learning whitelist verification mechanism is established. After obtaining network requests, for common specific request types (HTTP / HTTPS requests), if the URL is in the whitelist, the verification passes and the request is allowed directly. For non-specific request types (such as TCP requests) or specific request types that fail the whitelist verification, the process proceeds to the next step. Then, the category of the business message in the network request is identified. For message types supported by the system, a message parsing method appropriate to that category is used to parse the business message to extract the field names and field values ​​contained therein. Unlike existing detection methods that use single keyword matching or regular expression matching, this application uses a dual verification judgment logic of field name semantics (sensitive field library) and field value data characteristics (sensitive data rule library) in the sensitive information detection process. It quickly locates suspected sensitive field names through keywords and performs secondary verification of field values ​​through the verification rules in the sensitive data rule library corresponding to the field names, fundamentally solving the inherent defects of single detection methods.

[0013] Furthermore, during the dual verification process, multiple matching mechanisms are employed in combination to reduce missed detections of sensitive fields. When matching keywords by field name, three different matching methods are used sequentially: precise matching, fuzzy matching, and dynamic distance generalization matching. This reduces the chance of missed detections of sensitive data caused by incomplete sensitive field databases or misspelled field names. Simultaneously, the dynamic distance generalization matching method proposed in this application allows for adjustment of the generalization matching precision through configuration parameter values, making the system's detection accuracy highly flexible.

[0014] In one implementation of the first aspect, the method further includes: generating early warning information and recording logs based on the results of sensitive information identification.

[0015] In one implementation of the first aspect, identifying the category of the service message in the network request includes: determining whether the service message belongs to a message type supported by the system according to the priority order of different categories; wherein the priority order of the categories is related to the breadth of their usage scenarios; if the service message does not belong to a message type supported by the system, then determining whether the request type of the network request is a specific request type; if so, then adding the URL corresponding to the network request to the whitelist.

[0016] In one implementation of the first aspect, the dual verification of the field names and field values ​​of the business message based on the sensitive field library and the sensitive data rule library includes: using exact matching to search for the field names of the business message in the sensitive field library; if the exact matching search is successful, then searching for the verification rule in the sensitive data rule library through the verification rule number corresponding to the record corresponding to the successfully matched field name in the sensitive field library, so as to determine whether the field values ​​of the business message conform to the data characteristics of sensitive information.

[0017] In one implementation of the first aspect, the dual verification of the field names and field values ​​of the business message based on the sensitive field library and the sensitive data rule library further includes: if the field value of the business message does not conform to the data characteristics of sensitive information, then performing a fuzzy matching search on the field name of the business message in the sensitive field library; if the fuzzy matching search is successful and the field value of the business message also conforms to the data characteristics of sensitive information, then adding the field name to the sensitive field library.

[0018] In one implementation of the first aspect, the dual verification of the field names and field values ​​of the business message based on the sensitive field library and the sensitive data rule library further includes: if the fuzzy matching search fails or the fuzzy matching search succeeds but the field values ​​of the business message do not conform to the data characteristics of sensitive information, then the field names of the business message are searched and matched in the sensitive field library using a dynamic distance generalization matching method.

[0019] In one implementation of the first aspect, if the field name of the business message matches successfully in the sensitive field library and the rule field value in the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message does not match successfully in the sensitive field library, but the field value conforms to the data characteristics of specific sensitive information, then it is determined that the business message contains sensitive information including:

[0020] After performing a maximum of three searches and matches on the field names of the business message using the above method, if one of the matches is successful and the field value of the business message also conforms to the data characteristics of sensitive information, then the business message is determined to contain sensitive information.

[0021] If three searches for the field names in the business message fail, it is determined that the field names in the business message do not match in the sensitive field database. The values ​​of each field in the message are then verified based on the data characteristics of the specific sensitive information. If the field values ​​in the message match the data characteristics of the specific sensitive information, it is also determined that the business message contains sensitive information.

[0022] Secondly, this application also provides a sensitive data detection device for banking business messages based on message classification, comprising: a request acquisition module for acquiring network requests; a whitelist verification module for determining whether the request type of the network request belongs to a non-specific request type or a specific request type that fails the whitelist verification; a message category identification module for identifying the category of the business message in the network request if either the request type of the network request is a non-specific request type or a specific request type that fails the whitelist verification; and a message parsing module for, when the category of the business message belongs to a message type supported by the system, using a method similar to that of the network request. A category-appropriate message parsing method parses the business message to extract the field names and field values ​​contained therein; a dual verification module is used to perform dual verification on the field names and field values ​​of the business message based on a sensitive field library and a sensitive data rule library; a sensitive information identification module is used to determine that the business message contains sensitive information if, after verification by the dual verification module, the field name of the business message matches successfully in the sensitive field library and the rule field value based on the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message does not match successfully in the sensitive field library, but the field value conforms to the data characteristics of specific sensitive information.

[0023] Thirdly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the above-mentioned method for detecting sensitive data in banking business messages based on message classification.

[0024] Fourthly, this application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by an electronic device, implements the above-described method for detecting sensitive data in banking business messages based on message classification.

[0025] As described above, the method, apparatus, equipment, and medium for detecting sensitive data in banking business messages based on message classification described in this application have the following beneficial effects:

[0026] 1) A URL-based whitelist fast verification channel was introduced to directly allow requests to risk-free business interfaces that have passed the test. This effectively avoids redundant computational overhead when submitting the same interface repeatedly, significantly improving system throughput while ensuring detection accuracy, and meeting the stringent requirements of core financial businesses for low latency and high concurrency.

[0027] 2) Traditional static whitelists rely on manual configuration and maintenance, which cannot adapt to frequent additions, deletions, and modifications to business interfaces, and there is a risk of false blocking or missed detection due to configuration lag. This invention uses subsequent detection results to automatically capture legitimate requests that do not contain sensitive information and add them to the whitelist in real time, significantly reducing operation and maintenance costs.

[0028] 3) During the dual verification process, multiple matching mechanisms are used in combination to reduce the false negatives of sensitive fields. When matching keywords by field name, three different matching methods are used sequentially: exact matching, fuzzy matching, and dynamic distance generalization matching. This reduces the false negatives of sensitive data caused by incomplete sensitive field databases or misspelled field names. Furthermore, the dynamic distance generalization matching method proposed in this application allows for adjustment of the generalization matching precision through configuration parameter values, making the system's detection accuracy highly flexible.

[0029] 4) Existing technologies often employ single keyword matching or regular expression matching, which can easily lead to false positives (e.g., a field name containing "ID card" but the field value being descriptive text) or false negatives (e.g., a field name containing sensitive data but without sensitive keywords). This invention utilizes a dual-verification logic based on both the semantics of field names (sensitive field library) and the data characteristics of field values ​​(sensitive data rule library). It quickly identifies potentially sensitive field names through keywords and performs secondary verification using the verification rule field values ​​in the corresponding sensitive data rule library, fundamentally solving the inherent defects of single detection methods.

[0030] 5) Supports banks in dynamically updating their sensitive keyword database and data feature rules based on their own business characteristics without modifying the core system code. When new sensitive data types (such as digital RMB wallet numbers) are added or regulatory requirements change, the detection capabilities can be rapidly iterated and upgraded, ensuring the timeliness of the detection system. Attached Figure Description

[0031] Figure 1 The diagram shows a detailed flowchart of the sensitive data detection method for banking business messages based on message classification as described in the embodiments of this application.

[0032] Figure 2The diagram shows a flowchart illustrating the method for identifying UnionPay 8583 messages in the sensitive data detection method for banking business messages based on message classification described in this application embodiment.

[0033] Figure 3 The diagram shows the module structure of the banking business message sensitive data detection device based on message classification as described in this application embodiment. Detailed Implementation

[0034] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0035] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0036] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0037] like Figure 1 The diagram shown is a schematic representation of a specific process for a sensitive data detection method for banking business messages based on message classification, provided in this embodiment.

[0038] refer to Figure 1 The sensitive data detection method includes the following steps:

[0039] S101: Obtain network request.

[0040] S102: Determine whether the request type of the network request belongs to a non-specific request type or a specific request type that failed the whitelist verification.

[0041] S103: If the network request type is either a non-specific request type or a specific request type that fails the whitelist verification, then the category of the service message in the network request is identified.

[0042] S104: When the type of the service message belongs to the message type supported by the system, the service message is parsed using a message parsing method appropriate to that type to extract the field names and field values ​​contained therein.

[0043] S105: Perform dual verification on the field names and field values ​​of the business message based on the sensitive field library and the sensitive data rule library.

[0044] S106: If the field name of the business message is successfully matched in the sensitive field library and the rule field value in the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message is not successfully matched in the sensitive field library but the field value conforms to the data characteristics of specific sensitive information, then it is determined that the business message contains sensitive information.

[0045] The sensitive data detection method for banking business messages based on message classification described in this embodiment is applicable to banking business systems.

[0046] In S102, after receiving a network request (as described in S101), it is determined whether the request type of the network request belongs to a non-specific request type or a specific request type that failed the whitelist verification. The specific request type includes HTTP (Hypertext Transfer Protocol) / HTTPS (Hypertext Transfer Secure Protocol) requests, which are the most commonly used request types for interaction between banking systems and external systems, i.e., network requests based on the HTTP / HTTPS protocol. For some high-frequency transactions (such as internet lending), the daily transaction volume can reach hundreds of thousands.

[0047] Unlike existing technologies, this embodiment designs a self-learning whitelist mechanism. For commonly used request types (as specific request types), it quickly determines whether an HTTP / HTTPS request needs sensitive information detection based on whether the URL of the HTTP / HTTPS request is included in the whitelist. Here, a URL (Uniform Resource Locator) is a technical form used in Hypertext Markup Language to connect content between different web pages or systems; its address includes protocol, hostname, and path.

[0048] Specifically, depending on the request type, if it is a specific request type (such as an HTTP / HTTPS request), the URL of the network request will be whitelisted. If the whitelisting passes, the request will be allowed directly without further processing. Conversely, if the request type is not a specific request type (such as a TCP request), or if it is a specific request type but fails the whitelisting, the request will proceed to the next step.

[0049] This embodiment uses a whitelist to directly allow already detected interfaces, avoiding duplicate detection and thus greatly improving detection efficiency and system performance. Simultaneously, subsequent detection processes automatically add HTTP / HTTPS requests found not to contain sensitive information to the whitelist, enabling automatic whitelist learning. Furthermore, to prevent missed detection of sensitive information due to interface updates, this embodiment sets an expiration date for URLs in the whitelist. For URLs exceeding their expiration date, the whitelist will no longer be effective. When an expired URL request in the whitelist is triggered again and passes detection, the URL's expiration date will be updated.

[0050] As described in S103, when determining the request type of the network request (as described in S102), if either the request type of the network request is a non-specific request type or a specific request type that fails the whitelist verification, the category of the service message in the network request is identified.

[0051] Specifically, this step includes:

[0052] S1031: Determine whether the service message belongs to a message type supported by the system according to the priority order of different categories; wherein, the priority order of the categories is related to the breadth of their use cases.

[0053] S1032: If the service message does not belong to the message type supported by the system, then determine whether the request type of the network request is a specific request type; if so, then add the URL corresponding to the network request to the whitelist.

[0054] In the banking and payment sectors, commonly used business message types include, but are not limited to, JSON messages, XML messages, and UnionPay 8583 messages. UnionPay 8583 messages are a widely used international standard message format, employing binary or ASCII format, and are commonly used for communication between ATMs, POS terminals, and banks. This message format conforms to the ISO 8583 standard and is used by China UnionPay and major Chinese banks to process bank card transactions. JSON and XML messages are more often used for data exchange between web services and internal systems.

[0055] In this embodiment, the priority order is determined based on the breadth of usage scenarios for different types of business messages. For example, the determination order is JSON messages, XML messages, and UnionPay 8583 messages. In practical applications, the priority order for determining the type of business message is not limited to that of this embodiment.

[0056] Since JSON and XML messages are commonly used data formats for network data transmission, many programming languages ​​provide methods for identifying and parsing these two data formats, which can be directly identified by calling the methods in the corresponding utility classes.

[0057] For the identification of UnionPay 8583 messages, the following methods can be used: Figure 2 The discrimination method shown is used to implement this, refer to Figure 2 Specifically, it includes:

[0058] S201: Receive the message to be analyzed (usually a hexadecimal string).

[0059] S202: Check the total length of the message (based on the first 2 bytes of the message). If the length does not match or cannot be parsed, proceed to S203; otherwise, if the length matches, proceed to S204.

[0060] S203: This message is not a UnionPay 8583 message.

[0061] S204: Parse the fixed structure parts in sequence (including TPDU, message header, message type MTI and bitmap).

[0062] S205: Verify key fields (such as MTI and message header identifier). If the UnionPay specifications are not met, proceed to S203; otherwise, if the specifications are met, proceed to S206.

[0063] S206: Parse data fields (including parsing bitmaps, reading data from each field by bitmap, and checking critical fields).

[0064] S207: Comprehensive judgment. If there is a mismatch or error, proceed to S203; otherwise, if all verifications pass, proceed to S208.

[0065] S208: This is identified as a UnionPay 8583 message.

[0066] In this embodiment, the message types supported by the system mainly include the aforementioned JSON messages, XML messages, and UnionPay 8583 messages. If the business message does not belong to any of the above three message types (for example, a business message using base64 or hexadecimal encoding), it is determined whether the request type of the network request is a specific request type. If so, the URL corresponding to the network request is added to the whitelist. This is because messages after base64 or hexadecimal encoding cannot be parsed if the character encoding method is unknown. For unparsable message types, if the request is a specific request type, adding the URL corresponding to the request to the whitelist can avoid invalid duplicate detection.

[0067] As described in S104, when the type of the service message belongs to the message type supported by the system, the service message is parsed using a message parsing method adapted to that type to extract the field names and field values ​​contained therein.

[0068] Specifically, the message parsing module in the system can be divided into several sub-modules, such as JSON message parsing, XML message parsing, and UnionPay 8583 message parsing, with one sub-module corresponding to each supported message format. After being classified, business messages are sent to the corresponding message parsing sub-modules, which automatically extract field names and values ​​at any level using a hierarchical parsing approach.

[0069] Those skilled in the art will understand that many programming languages ​​support automatic parsing of JSON and XML messages, which will not be elaborated upon here. In this embodiment, the parsing method for UnionPay 8583 messages is described in detail. First, the UnionPay 8583 message adopts a layered structure of transport layer header + application layer data, and its complete format is shown below:

[0070] The core components include: 1) Message length, which is 2 bytes long and indicates the total length of all subsequent data (excluding itself); 2) TPDU (Transmission Protocol Data Unit), which is 5 bytes long and used for routing addressing; 3) Application header, which is 6 bytes long and is defined by UnionPay, containing application version, terminal status, etc.; 4) Application data, which is of variable length and includes MTI, bitmap, and data field in its core components.

[0071] Step 1.1: Strip the transport layer header, including:

[0072] 1) Read the first 2 bytes and convert them to decimal to get the total message length L.

[0073] 2) Skip the next 5 bytes of TPDU and 6 bytes of application header.

[0074] 3) The remaining bytes are the application data that needs to be parsed.

[0075] Step 1.2: Parse the Message Type Identifier (MTI). The first 4 characters (2-byte BCD encoding) of the application data are the MTI, which defines the message type and direction.

[0076] Step 1.3: Parse the bitmap. The bitmap is a "switch matrix", where each bit corresponds to a data field, with 1 indicating that the field exists and 0 indicating that it does not exist.

[0077] 1) Main bitmap: Fixed 8 bytes (64 bits), corresponding to data fields 1~64.

[0078] 2) Sub-bitmap: If the first bit of the main bitmap is 1, then there is a sub-bitmap (another 8 bytes), corresponding to data fields 65~128.

[0079] 3) Positional order rule: from left to right, the most significant bit comes first. For example, in the main bitmap, the 1st bit corresponds to field 1, the 2nd bit corresponds to field 2, ..., and the 64th bit corresponds to field 64.

[0080] Step 1.4: Parse the data fields in sequence. Based on the existing fields indicated by the bitmap, parse them strictly in ascending order of field number to obtain the field name and field value of each field.

[0081] As described in S105, the field names and field values ​​of the business message are double-checked based on the sensitive field library and the sensitive data rule library.

[0082] Specifically, this step includes:

[0083] S1051: Use exact matching to search for the field names of the business message in the sensitive field library.

[0084] S1052: If the exact match search is successful, the verification rule in the sensitive data rule library is searched through the verification rule number corresponding to the record in the sensitive field library to determine whether the field value of the business message conforms to the data characteristics of sensitive information.

[0085] S1053: If the field value of the service message does not conform to the data characteristics of sensitive information, then a fuzzy matching search is performed on the field name of the service message in the sensitive field library.

[0086] S1054: If the fuzzy matching search is successful and the field value of the business message also meets the data characteristics of sensitive information, then the field name is added to the sensitive field library.

[0087] S1055: If the fuzzy matching search fails or the fuzzy matching search succeeds but the field value of the business message does not meet the data characteristics of sensitive information, then the field name of the business message is searched and matched in the sensitive field library using the dynamic distance generalization matching method.

[0088] In this embodiment, to facilitate the identification of fields containing sensitive information based on field names, a sensitive field library suitable for incremental learning is established. This sensitive field library includes fields such as ID, field name, field name length, sensitive information type, and verification rule ID (e.g., <111, ID_NO, 5, ID card number, 345>), records common sensitive information types and their corresponding field names (each sensitive information type may correspond to multiple field names), and can automatically perform incremental learning during sensitive information detection. Simultaneously, to avoid missed sensitive data detection due to developers' non-standard field naming or an incomplete sensitive field library, a sensitive data rule library is also established. This sensitive data rule library records common sensitive data types and their corresponding verification rules.

[0089] In the dual verification process of this embodiment, when matching keywords by field name, three different matching methods are used in sequence: exact matching, fuzzy matching, and dynamic distance generalization matching, which reduces the false negatives of sensitive data caused by incomplete sensitive field databases, misspellings of field names, etc.

[0090] Specifically, identifying sensitive information in a message by field name involves a maximum of three rounds of searching and matching:

[0091] The first round of matching (i.e., exact matching): The system searches for the field to be matched (i.e., the field name in the business message) in the sensitive field database. If a match is found, the system uses the verification rule number corresponding to the record in the sensitive field database (i.e., the record corresponding to the successfully matched field name) to find the verification rule in the sensitive data rule database. Based on the corresponding verification rule, it determines whether the field value conforms to the data characteristics of the sensitive information (including length, format, numerical range, regular expressions, etc.). If the data characteristics of the field value conform, it is determined that the field contains sensitive information; otherwise, the field proceeds to the second round of matching.

[0092] For example, if the field name "acctNo" for bank card number is a field in the sensitive field database, then a perfect match is achieved. Further, based on the validation rules in the sensitive data rule base, it is determined whether the field value corresponding to "acctNo" conforms to the data characteristics of sensitive information (i.e., whether the field value is a bank card number). If it conforms to the data characteristics of a bank card number, then the field is determined to contain sensitive information. Conversely, although the field name "acctNo" is a field in the sensitive field database, if the field value corresponding to "acctNo" does not conform to the data characteristics of sensitive information (e.g., the field value is empty or is not a bank card number), then the field is determined not to contain sensitive information.

[0093] The second round of matching (i.e., fuzzy matching): Fuzzy matching search is performed in the sensitive field database based on the field name to be matched. If the match is successful and the data feature verification of the field value passes, it is determined that the field contains sensitive information; and the field name is added to the sensitive field database to realize incremental learning of the sensitive field database; otherwise, the field enters the third round of matching.

[0094] Unlike the first round of exact matching, the fuzzy matching described here is the same as the fuzzy query mechanism in relational databases. The string "ABC" can be successfully matched with the string "*ABC*", where * represents any string. For example, the field name "account" can be successfully matched with "accountNo".

[0095] The third round of matching (i.e., dynamic distance generalization matching): If the field name length is greater than or equal to N, then the field name is matched against the field names in the sensitive field database according to the dynamic distance generalization matching method. arrive The field names are matched one by one. If a match is successful and the data feature verification of the field value passes, it is determined that the field name contains sensitive information and the field name is added to the sensitive field library to achieve incremental learning of the sensitive field library.

[0096] The dynamic distance generalization matching method provided in this embodiment is as follows: For fields whose field name length exceeds a set threshold N (N is a configurable parameter), the field name is compared with the field name length in the sensitive field library. arrive The field names are matched one by one, and after converting all letters in the field names to lowercase, the Levenshtein edit distance (a metric for measuring the difference between two strings, defined as the minimum number of single-character edits required to convert string A to string B) is calculated. A Levenshtein edit distance less than or equal to... If the match is successful, then the match is successful; otherwise, the match fails. These are configurable parameters. The dynamic distance generalization matching method used in this embodiment allows for adjustment of the generalization matching accuracy through configuration parameter values, resulting in greater flexibility in the system's detection accuracy.

[0097] As described in S106, if the field name of the business message is successfully matched in the sensitive field library and the rule field value in the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message is not successfully matched in the sensitive field library but the field value conforms to the data characteristics of specific sensitive information, then it is determined that the business message contains sensitive information.

[0098] Specifically, this step includes:

[0099] S1061: After performing up to three searches and matches on the field names of the business message according to the above method, if one of them is a successful match and the field value of the business message also meets the data characteristics of sensitive information, then it is determined that the business message contains sensitive information.

[0100] S1062: If the field name of the service message is not successfully matched in three searches, it is determined that the field name of the service message is not matched in the sensitive field database. The values ​​of each field in the message are verified according to the data characteristics of the specific sensitive information. If the field value of the message matches the data characteristics of the specific sensitive information, it is also determined that the service message contains sensitive information.

[0101] This embodiment employs a dual judgment logic of field semantics (using a sensitive field library) and data features (using a sensitive data rule library). It quickly locates suspected sensitive fields through keywords and performs secondary verification through data feature format validation (such as 18-digit ID card number validation rules, Luhn algorithm for bank card numbers, and transaction amount range features), fundamentally solving the inherent defects of a single detection method.

[0102] If a field name in a business message fails to match more than three times, it is determined that the field name in that business message does not match in the sensitive field database. However, if the field value of the business message matches the data characteristics of specific sensitive information, it is also determined that the business message contains sensitive information. For example, field value validation for mismatched field names can typically only validate some common important sensitive data (i.e., specific sensitive information). This specific sensitive information includes easily identifiable and highly sensitive data such as ID card numbers, bank card numbers, and mobile phone numbers. If a field name in a business message fails to match due to non-standard naming or spelling errors, but the corresponding field value matches the data characteristics of specific sensitive information, it is also determined that the business message contains sensitive information.

[0103] If no sensitive information is found in the network request messages after the above methods are used for detection, and the corresponding request type is HTTP / HTTPS, then the corresponding URL is added to the whitelist.

[0104] Furthermore, the banking business message sensitive data detection method based on message classification described in this embodiment also includes the following steps: generating early warning information and recording logs based on the results of sensitive information identification.

[0105] Specifically, the system can generate detailed warning information and record it in a log based on the results of sensitive information identification. The warning information mainly includes the warning level, message source, destination address, transmission time, sensitive field name, and the specific location of the field in the message. In this embodiment, based on the sensitivity level of the sensitive information, the warning log can be divided into three warning levels: NOTICE, WARNING, and ERROR. The correspondence between the warning levels and sensitive data is as follows:

[0106] 1) The sensitive information corresponding to the warning level ERROR includes: complete bank card number, magnetic stripe data (8583 field 35), PIN password (8583 field 52), account transaction password, complete ID card number, biometric feature data and other high-risk sensitive data that have undergone double verification of field name and field value.

[0107] 2) The sensitive information corresponding to the WARNING warning level includes: (1) highly sensitive data such as customer name, mobile phone number, home address, and transaction amount that have been double-verified by field name and field value; and (2) high-risk sensitive data that have only been verified by field value.

[0108] 3) The sensitive information corresponding to the NOTICE warning level includes: highly sensitive data such as customer name, mobile phone number, home address, and transaction amount, which are only validated by field values.

[0109] This embodiment provides real-time early warning and precise location. Once an unencrypted sensitive field is detected, the system immediately generates detailed early warning information including the message source, destination address, transmission time, sensitive field name, and the specific location of the field in the message, and simultaneously records a complete early warning log. The precise location capability of this invention can help maintenance personnel locate potential data risks within minutes and decide whether to repair them based on the review results, which can significantly shorten the risk exposure time.

[0110] The scope of protection of the banking business message sensitive data detection method based on message classification described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, deleting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0111] This application also provides a device for detecting sensitive data in banking business messages based on message classification. The device can implement the method for detecting sensitive data in banking business messages based on message classification described in this application. However, the implementation device for the method for detecting sensitive data in banking business messages based on message classification described in this application includes, but is not limited to, the structure of the device for detecting sensitive data in banking business messages based on message classification listed in this embodiment. All structural modifications and substitutions of the prior art made in accordance with the principles of this application are included within the protection scope of this application.

[0112] like Figure 3 The diagram shown is a schematic diagram of the module structure of the banking business message sensitive data detection device based on message classification according to an embodiment of this application.

[0113] refer to Figure 3 The banking business message sensitive data detection device 3 includes: a request acquisition module 31, used to acquire network requests; a whitelist verification module 32, used to determine whether the request type of the network request belongs to a non-specific request type or a specific request type that failed the whitelist verification; a message category identification module 33, used to identify the category of the business message in the network request if the verification result of the whitelist verification module 32 satisfies either the request type of the network request being a non-specific request type or a specific request type that failed the whitelist verification; a message parsing module 34, used to parse the business message using a message parsing method appropriate to the category when the category of the business message belongs to a system-supported message type, in order to extract the field names and field values ​​contained therein; and a dual verification module 35, used to perform dual verification of the field names and field values ​​of the business message based on a sensitive field library and a sensitive data rule library. The sensitive information identification module 36 is used to determine that the business message contains sensitive information if, after verification by the dual verification module 35, the field name of the business message is successfully matched in the sensitive field library and the rule field value in the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message is not successfully matched in the sensitive field library, but the field value conforms to the data characteristics of specific sensitive information.

[0114] In this embodiment, the specific implementation of each module in the banking business message sensitive data detection device 3 can be referred to the corresponding steps in the above method embodiment, and will not be repeated here.

[0115] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0116] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0117] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0118] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor, when executing the program, is adapted to implement the above-described method for detecting sensitive data in banking business messages based on message classification.

[0119] This application also provides a computer-readable storage medium storing a computer program that, when executed by an electronic device, implements the aforementioned method for detecting sensitive data in banking business messages based on message classification. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The aforementioned 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 medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0120] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0121] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for detecting sensitive data in banking business messages based on message classification, characterized in that, include: Obtain network requests; Determine whether the network request type belongs to a non-specific request type or a specific request type that failed the whitelist verification; If the network request is either a non-specific request type or a specific request type that fails the whitelist verification, then the category of the service message in the network request is identified. When the type of the service message belongs to the message type supported by the system, the service message is parsed using a message parsing method appropriate to that type in order to extract the field names and field values ​​contained therein. The field names and field values ​​of the business messages are double-checked based on the sensitive field library and the sensitive data rule library; If the field name of the business message matches successfully in the sensitive field library and the rule field value in the sensitive data rule library also conforms to the data characteristics of sensitive information, or if the field name of the business message does not match successfully in the sensitive field library, but the field value conforms to the data characteristics of specific sensitive information, then it is determined that the business message contains sensitive information.

2. The method for detecting sensitive data in banking business messages based on message classification according to claim 1, characterized in that, The method also includes generating early warning information and logging it based on the results of sensitive information identification.

3. The method for detecting sensitive data in banking business messages based on message classification according to claim 1, characterized in that, The identification of the type of service message in the network request includes: The system determines whether a service message belongs to a message type supported by the system according to the priority order of different categories; wherein the priority order of the categories is related to the breadth of their use cases. If the service message does not belong to the message type supported by the system, then determine whether the request type of the network request is a specific request type; if so, then add the URL corresponding to the network request to the whitelist.

4. The method for detecting sensitive data in banking business messages based on message classification according to claim 1, characterized in that, The dual validation of field names and field values ​​in the business message based on the sensitive field library and the sensitive data rule library includes: The field names in the business message are searched using exact matching in the sensitive field library; If a precise match is found, the verification rule in the sensitive data rule library is searched using the verification rule number corresponding to the record with the successfully matched field name in the sensitive field library to determine whether the field value of the business message conforms to the data characteristics of sensitive information.

5. The method for detecting sensitive data in banking business messages based on message classification according to claim 4, characterized in that, The dual validation of field names and field values ​​in the business message based on the sensitive field library and the sensitive data rule library also includes: If the field value of the business message does not conform to the data characteristics of sensitive information, then a fuzzy matching search is performed on the field name of the business message in the sensitive field library; If the fuzzy matching search is successful and the field value of the business message also matches the data characteristics of sensitive information, then the field name is added to the sensitive field library.

6. The method for detecting sensitive data in banking business messages based on message classification according to claim 5, characterized in that, The dual validation of field names and field values ​​in the business message based on the sensitive field library and the sensitive data rule library also includes: If the fuzzy matching search fails or succeeds but the field value of the business message does not meet the data characteristics of sensitive information, then the field name of the business message is searched and matched in the sensitive field library using a dynamic distance generalization matching method.

7. The method for detecting sensitive data in banking business messages based on message classification according to claim 1, characterized in that, If the field name of the business message matches successfully in the sensitive field database and the rule field value in the sensitive data rule database also conforms to the data characteristics of sensitive information, or if the field name of the business message does not match successfully in the sensitive field database, but the field value conforms to the data characteristics of specific sensitive information, then it is determined that the business message contains sensitive information including: After performing a maximum of three searches and matches on the field names of the business message using the above method, if one of the matches is successful and the field value of the business message also conforms to the data characteristics of sensitive information, then the business message is determined to contain sensitive information. If three searches for the field names in the business message fail, it is determined that the field names in the business message do not match in the sensitive field database. The values ​​of each field in the message are then verified based on the data characteristics of the specific sensitive information. If the field values ​​in the message match the data characteristics of the specific sensitive information, it is also determined that the business message contains sensitive information.

8. A sensitive data detection device for banking business messages based on message classification, characterized in that, include: The request retrieval module is used to retrieve network requests; The whitelist verification module is used to determine whether the network request type belongs to a non-specific request type or a specific request type that fails the whitelist verification. The message category identification module is used to identify the category of the service message in the network request if either the request type of the network request is a non-specific request type or a specific request type that fails the whitelist verification. The message parsing module is used to parse the service message using a message parsing method appropriate to the type of message supported by the system, when the type of the service message belongs to the type of message supported by the system, so as to extract the field names and field values ​​contained therein; The dual verification module is used to perform dual verification on the field names and field values ​​of the business message based on the sensitive field library and the sensitive data rule library; The sensitive information identification module is used to determine that the business message contains sensitive information if, after verification by the dual verification module, the field name of the business message matches successfully in the sensitive field database and the rule field value in the sensitive data rule database also conforms to the data characteristics of sensitive information, or if the field name of the business message does not match successfully in the sensitive field database, but the field value conforms to the data characteristics of specific sensitive information.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the sensitive data detection method for banking business messages based on message classification 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 executed by an electronic device, the program implements the sensitive data detection method for banking business messages based on message classification as described in any one of claims 1 to 7.

Images