A risk control method, device, medium, product and equipment

Abstract

The present disclosure relates to a risk control method, apparatus, medium, product and equipment. Based on the current login log of the authorized user under the SDP framework, the login behavior attribute information is discretized, and the login risk label is determined through the decision tree model, so that the legitimacy of the authorized user's login behavior can be identified based on the login log through the decision tree model to achieve risk control. In addition, based on the legal historical access log corresponding to the application or authorization group, the user access behavior can be abstracted into an API call sequence and a corresponding call time series, and then the API call rules corresponding to the application or authorization group can be determined. Access risk control is performed by comparing the user access behavior in the current access log with the determined API call rules. In addition, based on the API legal call conditions set according to experience, the user access behavior in the current access log can be judged to perform access risk control.

Description

Technical Field

[0001] The present disclosure relates to the field of network security technology, and in particular to a risk control method, apparatus, medium, product, and equipment. Background Art

[0002] This section is intended to provide a background or context to the embodiments of the present disclosure that are recited in the claims. No statement herein is admitted to be prior art by virtue of its inclusion in this section.

[0003] Zero Trust (ZT) provides a set of concepts and ideas that reduce the uncertainty of decision-making accuracy when executing each access request to information systems and services, assuming the network environment has been compromised. Zero Trust Architecture (ZTA) is an enterprise network security planning approach based on the Zero Trust concept and structured around component relationships, workflow planning, and access policies.

[0004] The Software-Defined Perimeter (SDP) technology architecture standard, proposed by the Cloud Security Alliance (CSA), has become a widely adopted zero-trust security technology solution globally. SDP uses software-defined methods to build a secure and trusted virtual perimeter on the internet for businesses or organizations, controlling access to resources based on identity. Typically, each terminal must be authenticated before connecting to the server to ensure that each device is authorized to access.

[0005] The core concept of SDP is to hide core network assets and facilities through the SDP architecture, preventing them from being directly exposed to the internet and protecting them from external security threats. Based on the SDP framework, distributed denial of service (DDoS) attacks, man-in-the-middle attacks, vulnerability scanning, and advanced persistent threat (ATP) attacks can be prevented. However, while fine-grained authorization policies can be used to prevent unauthorized user access, the legitimacy of authorized user behavior cannot be verified.

[0006] Currently, there is no solution that can accurately identify the legitimacy of authorized user behavior under the SDP framework, making it impossible to effectively control user behavior risks. Summary of the Invention

[0007] The embodiments of the present disclosure provide a risk control method, apparatus, medium, product, and device for solving the problem of being unable to accurately identify the risks of authorized user behavior under the SDP framework.

[0008] In a first aspect, the present disclosure provides a risk control method, the method comprising:

[0009] Obtaining a current login log of an authorized user, wherein the current login log includes specified login behavior attribute information;

[0010] Discretizing the login behavior attribute information to obtain discrete login behavior attribute information;

[0011] The discrete attribute information of the login behavior is used as the input of a pre-established decision tree model, and a login risk label corresponding to the current login log of the authorized user is determined by the decision tree model.

[0012] Optionally, the specified login behavior attribute information includes login address information, login time period information, login device identification information and authorization group information.

[0013] Optionally, the decision tree model is established in the following manner:

[0014] Obtain historical login log samples, each of which corresponds to a legitimate login behavior;

[0015] Discretize the login behavior attribute information included in each historical login log sample to obtain discrete login behavior attribute information;

[0016] According to the data distribution of the discrete attribute information of the login behavior, the login risk label corresponding to each branch of the decision tree model is determined, and the decision tree model is established.

[0017] Optionally, the method further includes:

[0018] Obtaining the current access log of the authorized user and determining the application corresponding to the current access log;

[0019] Determining whether the call to the application program interface corresponding to the current access log complies with the application program interface call rule corresponding to the application;

[0020] generating an access risk tag for the current access log of the authorized user according to the determined result;

[0021] The application program interface calling rules corresponding to the application are obtained in the following manner:

[0022] Obtain historical access log samples corresponding to the application, each historical access log sample corresponding to a legitimate access behavior to the application; determine the application program interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application program interface call sequence; determine the application program interface call rules corresponding to the application based on the determined application program interface call sequence and call time sequence.

[0023] Optionally, the method further includes:

[0024] Obtaining the current access log of the authorized user, and determining the authorization group corresponding to the current access log;

[0025] Determining whether the call to the application program interface corresponding to the current access log complies with the application program interface call rule corresponding to the authorization group;

[0026] generating an access risk tag for the current access log of the authorized user according to the determined result;

[0027] The application program interface call rules corresponding to the authorization group are obtained in the following manner:

[0028] Obtain historical access log samples corresponding to the authorization group, each historical access log sample corresponding to the legal access behavior of the authorized user under the authorization group; determine the application interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application interface call sequence; determine the application interface call rules corresponding to the authorization group based on the determined application interface call sequence and call time sequence.

[0029] Optionally, the method further includes:

[0030] Obtaining the current access log of the authorized user;

[0031] Determining whether the call to the application program interface corresponding to the current access log meets a pre-set application program interface legal call condition;

[0032] According to the determined result, an access risk tag is generated for the current access log of the authorized user.

[0033] In a second aspect, the present disclosure further provides a risk control device, comprising:

[0034] A login log acquisition module is used to obtain the current login log of the authorized user, wherein the current login log includes the specified login behavior attribute information;

[0035] a discrete processing module, configured to discretize the login behavior attribute information to obtain discrete login behavior attribute information;

[0036] The login risk control module is configured to use the discrete attribute information of the login behavior as input to a pre-established decision tree model, and determine a login risk label corresponding to the current login log of the authorized user through the decision tree model.

[0037] Optionally, the specified login behavior attribute information includes login address information, login time period information, login device identification information and authorization group information.

[0038] Optionally, the decision tree model is established in the following manner:

[0039] Obtain historical login log samples, each of which corresponds to a legitimate login behavior;

[0040] Discretize the login behavior attribute information included in each historical login log sample to obtain discrete login behavior attribute information;

[0041] According to the data distribution of the discrete attribute information of the login behavior, the login risk label corresponding to each branch of the decision tree model is determined, and the decision tree model is established.

[0042] Optionally, the device further includes an access log acquisition module and a first access risk control module:

[0043] The access log acquisition module is used to obtain the current access log of the authorized user;

[0044] The first access risk control module is configured to determine the application corresponding to the current access log; determine whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the application; and generate an access risk tag for the current access log of the authorized user based on the determination result;

[0045] The application program interface calling rules corresponding to the application are obtained in the following manner:

[0046] Obtain historical access log samples corresponding to the application, each historical access log sample corresponding to a legitimate access behavior to the application; determine the application program interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application program interface call sequence; determine the application program interface call rules corresponding to the application based on the determined application program interface call sequence and call time sequence.

[0047] Optionally, the device further includes an access log acquisition module and a second access risk control module:

[0048] The access log acquisition module is used to obtain the current access log of the authorized user;

[0049] The second access risk control module is configured to determine the authorization group corresponding to the current access log; determine whether the call to the application program interface corresponding to the current access log complies with the application program interface call rule corresponding to the authorization group; and generate an access risk tag for the current access log of the authorized user based on the determination result;

[0050] The application program interface call rules corresponding to the authorization group are obtained in the following manner:

[0051] Obtain historical access log samples corresponding to the authorization group, each historical access log sample corresponding to the legal access behavior of the authorized user under the authorization group; determine the application interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application interface call sequence; determine the application interface call rules corresponding to the authorization group based on the determined application interface call sequence and call time sequence.

[0052] Optionally, the device further includes an access log acquisition module and a third access risk control module:

[0053] The access log acquisition module is used to obtain the current access log of the authorized user;

[0054] The third access risk control module is used to determine whether the call to the application program interface corresponding to the current access log meets the pre-set application program interface legal call conditions; based on the determined result, generate an access risk label for the current access log of the authorized user.

[0055] In a third aspect, the present disclosure further provides a computer program product, which includes an executable program, and the executable program is executed by a processor to implement the method described above.

[0056] In a fourth aspect, the present disclosure further provides a non-volatile computer storage medium, wherein the computer storage medium stores an executable program, and the executable program is executed by a processor to implement the method described above.

[0057] In a fifth aspect, the present disclosure further provides a risk control device, comprising a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0058] The memory is used to store computer programs;

[0059] The processor is configured to implement the above-described method steps when executing the program stored in the memory.

[0060] According to the solution provided by the embodiment of the present disclosure, the login behavior attribute information can be discretized based on the current login log of the authorized user under the SDP framework, and the corresponding login risk label can be determined through the decision tree model. Therefore, based on the login log, the legitimacy of the authorized user's login behavior can be accurately identified through the decision tree model, thereby realizing user behavior risk control and reducing system risk.

[0061] Other features and advantages of the present disclosure will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present disclosure. The purposes and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0063] Figure 1 A flow chart of the risk control method provided in an embodiment of the present disclosure;

[0064] Figure 2 A schematic diagram of the process of establishing a decision tree model provided in an embodiment of the present disclosure;

[0065] Figure 3 A schematic diagram of a decision tree model provided in an embodiment of the present disclosure;

[0066] Figure 4 A flowchart of a frequent subsequence mining algorithm provided by an embodiment of the present disclosure;

[0067] Figure 5 A schematic diagram of the structure of a risk control device provided in an embodiment of the present disclosure;

[0068] Figure 6 A schematic diagram of the structure of the risk control device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0069] To make the objectives, technical solutions, and advantages of the present disclosure more clear, the present disclosure will be further described in detail below with reference to the accompanying drawings. It is apparent that the embodiments described are only a portion of the embodiments of the present disclosure, rather than all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without creative effort are intended to fall within the scope of protection of the present disclosure.

[0070] It should be noted that the term "multiple or several" in this document refers to two or more. "And / or" describes the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0071] The terms "first," "second," and the like in the specification and claims of the present disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, such that the embodiments of the present disclosure described herein can be practiced in orders other than those illustrated or described herein.

[0072] In addition, the terms "comprises" and "having" and any variations thereof are intended to cover a non-exclusive inclusion. For example, a process, method, system, product or apparatus that includes a series of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, product or apparatus.

[0073] The acquisition, storage, use, and processing of data in this application's technical solution comply with relevant national laws and regulations.

[0074] In order to achieve access risk control under the SDP framework, an embodiment of the present invention proposes that a login risk label can be determined based on the current login log of the authorized user through a decision tree model to achieve login risk control. In addition, based on the legal historical access log corresponding to the application or authorization group, the user behavior can be abstracted into an application program interface (API) call sequence and a corresponding call time sequence, and then the application program interface call rules corresponding to the application or authorization group can be determined. The access risk label is generated by comparing the user behavior in the current access log with the determined application program interface call rules. In addition, based on the legal application program interface call conditions set according to experience, the user behavior in the current access log can be judged to generate an access risk label to achieve access risk control.

[0075] Several concepts involved in this embodiment are briefly described below.

[0076] Authorization group: Under the SDP framework, authorized users are grouped, and each group can be recorded as an authorization group. Authorized users in each authorization group can access different application permissions;

[0077] Frequent subsequence: For a sequence group (including at least two sequences), if the number of times a subsequence of any sequence appears in other sequences (frequency) is not less than the frequent threshold, then this subsequence is a frequent subsequence of this sequence group;

[0078] Frequent long subsequence: Among the frequent subsequences corresponding to a sequence group, a frequent subsequence whose length is greater than the length threshold is a frequent long subsequence of this sequence group;

[0079] Longest frequent subsequence: Among the frequent subsequences corresponding to a sequence group, the frequent subsequence with the longest length is the longest frequent subsequence of this sequence group.

[0080] For example, for a sequence group including three sequences (abcd, ac, abc), the frequency of subsequence ab is 2, the frequency of subsequence ac is 3, the frequency of ad is 1, the frequency of abc is 2, the frequency of acd is 1, and the frequency of abcd is 1.

[0081] Assuming the frequent threshold is 2, the frequent subsequences corresponding to this sequence group include ab, ac, and abc.

[0082] Assuming the length threshold is 2, the frequent long subsequence corresponding to this sequence group is abc.

[0083] In addition, among the frequent subsequences corresponding to this sequence group, the longest subsequence is abc, and abc is the longest frequent subsequence corresponding to this sequence group.

[0084] Based on the above inventive concept, the present disclosure provides a risk control method, the steps of which can be as follows: Figure 1 As shown, including:

[0085] Step 101: Obtain the current login log of the authorized user.

[0086] In this step, the current login log of an authorized user under the SDP framework can be obtained.

[0087] A login log may include specified login behavior attribute information. In a possible implementation, the specified login behavior attribute information may include, but is not limited to, login address information, login time period information, login device identification information, and authorization group information.

[0088] Step 102: Discretize the login behavior attribute information to obtain discrete login behavior attribute information.

[0089] In this step, each login behavior attribute information may be discretized to obtain corresponding login behavior discrete attribute information.

[0090] For example, the specified login behavior attribute information includes login address information, login time information, login device identification information, and authorization group information:

[0091] The login address information can be discretized to obtain the corresponding discrete attribute information of three login behaviors: local province (which can be understood as the login address and registration address are in the same city in the same province), out-of-province province (which can be understood as the login address and registration address are in different cities in the same province), and out-of-province (not in the province, which can be understood as the login address and registration address are in different provinces).

[0092] Discretize the login time period information to obtain discrete attribute information of twelve login behaviors, each of which is identified by 0 to 11 and corresponds to a time period of two hours in a day.

[0093] Discretize the login device identification information to obtain discrete attribute information for three types of login behaviors: a brand-new device (which can be understood as a number of logins not exceeding a first login threshold), a relatively new device (which can be understood as a number of logins exceeding a first login threshold but not exceeding a second login threshold), and an old device (which can be understood as a number of logins exceeding a second login threshold).

[0094] The authorization group information is discretized, and the obtained login behavior discrete attribute information can still be represented by the authorization group identifier. For example, the corresponding four login behavior discrete attribute information of the president's office, finance department, logistics department and business department are obtained.

[0095] Step 103: Use the discrete attribute information of the login behavior as the input of the pre-established decision tree model, and determine the login risk label through the decision tree model.

[0096] In this step, the discrete attribute information of the login behavior may be used as the input of a pre-established decision tree model, and the decision tree model may be used to determine a login risk label corresponding to the current login log of the authorized user.

[0097] In one possible implementation, the decision tree model can be established in, but is not limited to, the following ways:

[0098] Obtain historical login log samples, each of which corresponds to a legitimate login behavior;

[0099] Discretize the login behavior attribute information included in each historical login log sample to obtain discrete login behavior attribute information;

[0100] According to the data distribution of the discrete attribute information of the login behavior, the login risk label corresponding to each branch of the decision tree model is determined, and the decision tree model is established.

[0101] Taking the specified login behavior attribute information including login address information, login time period information, login device identification information and authorization group information as an example, the flow chart of establishing the decision tree model can be as follows: Figure 2 shown.

[0102] First, a large number of legitimate historical login logs can be obtained. Then, valid historical login logs can be filtered out from these logs in real-world environments. Subsequently, the historical login logs can be grouped according to the corresponding authorization groups. Furthermore, data classification (i.e., determining the branches of the decision tree model) can be performed based on the discrete attributes of login behavior corresponding to the login address information, login time period information, and login device identification information. Then, based on the data distribution (which can be understood as data duplication), the login risk label corresponding to each branch can be determined, thereby generating a decision tree model.

[0103] For example, after dividing the historical login logs into 4 groups according to the authorization grouping, for each group, we can obtain the discrete attribute information of login behavior corresponding to the login address information (3 types) * the discrete attribute information of login behavior corresponding to the login time period information (12 types) * the discrete attribute information of login behavior corresponding to the login device identification information (3 types), a total of 108 data classifications.

[0104] For each data classification, the corresponding login risk label can be determined based on the data distribution. For example, if the data distribution is very dense and the corresponding number of historical login logs is very large, for example, a branch that is greater than the first set value, the corresponding login risk label is determined to be no risk. If the data distribution is relatively dense and the corresponding number of historical login logs is relatively large, for example, a branch that is greater than the second set value but not greater than the first set value, the corresponding login risk label is determined to be low risk. If the data distribution is relatively sparse and the corresponding number of historical login logs is relatively small, for example, a branch that is greater than the third set value but not greater than the second set value, the corresponding login risk label is determined to be high risk. If the data distribution is very sparse and the corresponding number of historical login logs is very small, for example, a branch that is not greater than the third set value, the corresponding login risk label is determined to be high risk.

[0105] Taking the specified login behavior attribute information including login address information, login time period information, login device identification information and authorization group information as an example, the decision tree model diagram can be as follows: Figure 3 As shown. Figure 3Due to limited space, only the following information is illustrated: Under the authorization grouping of the President's Office, the discretized information corresponding to the login address information is non-local province, the discretized information corresponding to the login device identification information is the classification of second-hand equipment, the branch whose discretized information corresponding to the login time period information is 0 corresponds to a login risk label of low risk, the branch whose discretized information corresponding to the login time period information is 1 corresponds to a login risk label of high risk, the branch whose discretized information corresponding to the login time period information is 2 corresponds to a login risk label of high risk, the branch whose discretized information corresponding to the login time period information is 3 corresponds to a login risk label of high risk, the branch whose discretized information corresponding to the login time period information is 4 corresponds to a login risk label of no risk, the branch whose discretized information corresponding to the login time period information is 5 corresponds to a login risk label of no risk, and the branch whose discretized information corresponding to the login time period information is 6 corresponds to a login risk label of high risk.

[0106] In this embodiment, in addition to performing login risk control based on the login log using a decision tree model, access risk control can also be performed based on the access log using application program interface call rules corresponding to the application obtained by analyzing historical access logs.

[0107] In a possible implementation, this embodiment may further include:

[0108] Obtain the current access log of the authorized user and determine the application corresponding to the current access log;

[0109] Determine whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the application;

[0110] Based on the determined results, an access risk tag is generated for the current access log of the authorized user;

[0111] The application program interface calling rules corresponding to the application are obtained in the following ways:

[0112] Obtain historical access log samples corresponding to the application, each historical access log sample corresponding to a legitimate access behavior to the application; determine the application interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application interface call sequence; determine the application interface call rules corresponding to the application based on the determined application interface call sequence and call time sequence.

[0113] In one possible implementation, the determined application program interface calling rule corresponding to the application may be, but is not limited to, at least one of the following two calling rules:

[0114] The first one is the calling order of the application program interface.

[0115] By setting the calling rules of the calling order of the application program interface, illegal calls to the application program interface can be prevented and access risk control can be achieved.

[0116] The second type is the percentage of application program interface calls.

[0117] By setting the call rule for the proportion of application program interface calls, access risks such as Challenge Collapsar (CC) attacks and database drag attacks can be controlled.

[0118] At this point, determining whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the application may include:

[0119] Determine whether the order of calls to the application program interface in the current access log conforms to the order of calls to the application program interface corresponding to the application; and / or determine whether the proportion of calls to the specified application program interface in the current access log conforms to the proportion of calls to the specified application program interface corresponding to the application.

[0120] Furthermore, in a possible implementation, the above-mentioned calling rules may be determined based on big data learning and frequent subsequence mining algorithms.

[0121] The first calling rule may be determined by, but is not limited to, the following methods:

[0122] Determine a frequent long subsequence based on the application program interface call sequence corresponding to each historical access log sample; and determine the call order of the application program interface corresponding to the application based on the determined frequent long subsequence;

[0123] The second calling rule can be determined by, but is not limited to, the following methods:

[0124] According to the application program interface call sequence corresponding to each historical access log sample, a frequent long subsequence is determined; and according to the determined frequent long subsequence, a proportion of the number of calls of each application program interface corresponding to the application is determined.

[0125] In this embodiment, access risk control may also be performed based on the access logs by utilizing the application program interface calling rules corresponding to the authorization groups obtained by analyzing the historical access logs.

[0126] In a possible implementation, this embodiment may further include:

[0127] Obtain the current access log of the authorized user and determine the authorization group corresponding to the current access log;

[0128] Determine whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the authorization group;

[0129] Based on the determined results, an access risk tag is generated for the current access log of the authorized user;

[0130] The API call rules corresponding to the authorization group are obtained in the following way:

[0131] Obtain historical access log samples corresponding to the authorization group, each historical access log sample corresponds to the legal access behavior of the authorized user under the authorization group; determine the application interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application interface call sequence; determine the application interface call rules corresponding to the authorization group based on the determined application interface call sequence and call time sequence.

[0132] In one possible implementation, the determined application program interface calling rule corresponding to the authorization group may be, but is not limited to, at least one of the following two calling rules:

[0133] The first one is to specify the calling order of the application program interface.

[0134] By setting the calling rules of specifying the calling order of the application program interface, it is possible to prevent abnormal access behavior of authorized users and implement access risk control.

[0135] The second method is to specify the calling time of the application program interface.

[0136] The specified API call time may include, but is not limited to, at least one of the API call start time, call end time, and call time span. By setting a call rule for specifying the API call time, abnormal API access times can be prevented, thereby achieving access risk control.

[0137] At this time, determining whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the authorization group may include:

[0138] Determine whether the order of calls to the specified application interface in the current access log conforms to the order of calls to the specified application interface corresponding to the authorization group; and / or determine whether the time of calls to the specified application interface in the current access log conforms to the time of calls to the application interface corresponding to the authorization group.

[0139] Furthermore, in a possible implementation, the above-mentioned calling rules corresponding to the authorization group may be determined based on big data learning and frequent subsequence mining algorithms.

[0140] The first calling rule may be determined by, but is not limited to, the following methods:

[0141] Based on the application interface call sequence corresponding to each historical access log sample, a frequent subsequence is determined; based on the determined frequent subsequence, a core application interface is determined. The core application interface can be understood, but is not limited to, as an application interface that is called more than a threshold value in the determined frequent subsequence; based on the determined frequent subsequence, a calling order of the core application interface corresponding to the authorization group is determined.

[0142] The second calling rule can be determined by, but is not limited to, the following methods:

[0143] Based on the application interface call sequence corresponding to each historical access log sample, a frequent subsequence is determined; based on the determined frequent subsequence, a core application interface is determined; based on the call time sequence corresponding to the determined application interface call sequence, a call time of the core application interface corresponding to the authorization group is determined.

[0144] In this embodiment, access risk control can also be performed based on the access log and using the legitimate calling conditions of the program interface set based on experience.

[0145] In a possible implementation, this embodiment may further include:

[0146] Get the current access log of the authorized user;

[0147] Determine whether the call to the application program interface corresponding to the current access log meets the pre-set application program interface legal call conditions;

[0148] Based on the determined result, an access risk tag is generated for the current access log of the authorized user.

[0149] In a possible implementation, the calling condition may be set for big data learning and frequent subsequence mining algorithms.

[0150] The pre-set application interface legal call conditions may include, but are not limited to: the variance of the call time span corresponding to the longest frequent subsequence corresponding to the current access log is not less than a variance threshold, and the proportion of the longest frequent subsequence in the application interface call sequence is not greater than a proportion threshold, wherein the longest frequent subsequence is determined based on the application interface call sequence corresponding to the current access log.

[0151] The above-mentioned legal calling conditions of the application program interface can prevent automated attacks and control access risks such as data crawling.

[0152] Of course, this embodiment is not limited to solely utilizing the API call rules corresponding to the application obtained from analyzing historical access logs, the API call rules corresponding to the authorization group obtained from analyzing historical access logs, and the empirically established conditions for legitimate API calls to perform access risk control. At least two of the aforementioned three methods can also be used simultaneously for access risk control to better implement access risk control and reduce access risk. This embodiment will not be further elaborated on this. By determining whether the API call corresponding to the current access log complies with each call rule corresponding to the application or authorization group obtained from analyzing historical access logs, as well as the empirically established call conditions, it is possible to determine whether the current access log contains access anomalies and what type of access anomalies exist, thereby generating an access risk tag.

[0153] The flowchart of the frequent subsequence mining algorithm involved in this embodiment can be shown as follows: Figure 4 shown.

[0154] When determining the API call rules for an application, we can obtain a sample of historical access logs for each application. This allows us to obtain the complete path sequence (API call sequence) and corresponding call time sequence for each user access to the service. This allows us to identify frequent long subsequences, and based on this analysis, we can determine the normal API call sequence and the reasonable call frequency range for each API.

[0155] Similarly, when determining the API call rules corresponding to an authorization group, a sample of historical access logs can be obtained for each authorization group. This allows the complete path sequence (API call sequence) and corresponding call time sequence of each user accessing the service to be obtained. Frequent subsequences can then be determined, and the core APIs can be identified based on frequent subsequence analysis. The normal call sequence of the core APIs can then be analyzed and determined, as well as the common call times for each core API, including the call start time, call end time, and call time span.

[0156] In addition, in the process of determining whether the call to the application program interface corresponding to the current access log meets the pre-set application program interface legal call conditions, the current access log of an authorized user (which can be understood as a semi-real-time log) can be used to obtain the complete path sequence (API call sequence) and the corresponding call time sequence for each user access to the service. The longest frequent subsequence can then be determined, and the proportion of the longest frequent subsequence in the application program interface call sequence and the variance of the call time span corresponding to the longest frequent subsequence can be analyzed to obtain the proportion of the longest frequent subsequence in the application program interface call sequence and the set proportion threshold. The variance of the call time span corresponding to the longest frequent subsequence can then be compared with the set variance threshold to monitor access anomalies and implement access risk control.

[0157] The solution provided by the embodiment of the present invention includes two specific solutions for user behavior risk control. Among them, the login operations can be grouped according to authorization, abstracted into three dimensions of time, address and device, and the abnormal identification of user login behavior can be realized through the decision tree model. In addition, the access operation can also be abstracted as an API call sequence, and the abnormal identification of user access behavior can be realized through the analysis of the API call sequence, so that user behavior can be fully covered, and risk control can be realized based on login behavior and access behavior respectively. It should be noted that the solution provided by the embodiment of the present invention has the ability to identify automated attacks, and can effectively identify various automated attacks, such as ticket swiping, data crawling, replay attacks and wool pulling, etc.

[0158] Corresponding to the provided method, the following device is further provided.

[0159] The embodiment of the present disclosure provides a risk control device, the structure of which can be as follows: Figure 5 Shown, including:

[0160] The login log acquisition module 11 is used to obtain the current login log of the authorized user, and the current login log includes the specified login behavior attribute information;

[0161] The discrete processing module 12 is used to discretize the login behavior attribute information to obtain discrete login behavior attribute information;

[0162] The login risk control module 13 is configured to use the discrete attribute information of the login behavior as input to a pre-established decision tree model, and determine a login risk label corresponding to the current login log of the authorized user through the decision tree model.

[0163] Optionally, the specified login behavior attribute information includes login address information, login time period information, login device identification information and authorization group information.

[0164] Optionally, the decision tree model is established in the following manner:

[0165] Obtain historical login log samples, each of which corresponds to a legitimate login behavior;

[0166] Discretize the login behavior attribute information included in each historical login log sample to obtain discrete login behavior attribute information;

[0167] According to the data distribution of the discrete attribute information of the login behavior, the login risk label corresponding to each branch of the decision tree model is determined, and the decision tree model is established.

[0168] Optionally, the device further includes an access log acquisition module 14 and a first access risk control module 15:

[0169] The access log acquisition module 14 is used to obtain the current access log of the authorized user;

[0170] The first access risk control module 15 is used to determine the application corresponding to the current access log; determine whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the application; and generate an access risk tag for the current access log of the authorized user based on the determination result;

[0171] The application program interface calling rules corresponding to the application are obtained in the following manner:

[0172] Obtain historical access log samples corresponding to the application, each historical access log sample corresponding to a legitimate access behavior to the application; determine the application program interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application program interface call sequence; determine the application program interface call rules corresponding to the application based on the determined application program interface call sequence and call time sequence.

[0173] Optionally, the device further includes an access log acquisition module 14 and a second access risk control module 16:

[0174] The access log acquisition module 14 is used to obtain the current access log of the authorized user;

[0175] The second access risk control module 16 is configured to determine the authorization group corresponding to the current access log; determine whether the call to the application program interface corresponding to the current access log complies with the application program interface call rules corresponding to the authorization group; and generate an access risk tag for the current access log of the authorized user based on the determination result.

[0176] The application program interface call rules corresponding to the authorization group are obtained in the following manner:

[0177] Obtain historical access log samples corresponding to the authorization group, each historical access log sample corresponding to the legal access behavior of the authorized user under the authorization group; determine the application interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application interface call sequence; determine the application interface call rules corresponding to the authorization group based on the determined application interface call sequence and call time sequence.

[0178] Optionally, the device further includes an access log acquisition module 14 and a third access risk control module 17:

[0179] The access log acquisition module 14 is used to obtain the current access log of the authorized user;

[0180] The third access risk control module 17 is used to determine whether the call to the application program interface corresponding to the current access log meets the preset application program interface legal call conditions; based on the determined result, generate an access risk tag for the current access log of the authorized user.

[0181] The functions of each functional unit of each device provided in the above embodiments of the present disclosure can be implemented through the steps of the above corresponding methods. Therefore, the possible working processes and beneficial effects of each functional unit in each device provided in the embodiments of the present disclosure are not repeated here.

[0182] Based on the same inventive concept, the embodiments of the present disclosure provide the following devices and media.

[0183] The embodiment of the present disclosure provides a risk control device, the structure of which can be as follows: Figure 6 As shown, it includes a processor 21, a communication interface 22, a memory 23 and a communication bus 24, wherein the processor 21, the communication interface 22, and the memory 23 communicate with each other through the communication bus 24;

[0184] The memory 23 is used to store computer programs;

[0185] The processor 21 is configured to implement the steps described in the above method embodiment of the present disclosure when executing the program stored in the memory.

[0186] Optionally, the processor 21 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), may be one or more integrated circuits for controlling program execution, may be a hardware circuit developed using a field programmable gate array (FPGA), or may be a baseband processor.

[0187] Optionally, the processor 21 may include at least one processing core.

[0188] Optionally, the memory 23 may include a read-only memory (ROM), a random access memory (RAM), and a disk storage. The memory 23 is used to store data required by at least one processor 21 during operation. The number of memories 23 may be one or more.

[0189] An embodiment of the present disclosure further provides a non-volatile computer storage medium, wherein the computer storage medium stores an executable program. When the executable program is executed by a processor, the method provided in the above method embodiment of the present disclosure is implemented.

[0190] In a possible implementation process, computer storage media may include: Universal Serial Bus Flash Drive (USB), mobile hard disk, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disk or optical disk, and other storage media that can store program code.

[0191] An embodiment of the present disclosure further provides a computer program product, which includes an executable program. The executable program is executed by a processor to implement the method provided by the above method embodiment of the present disclosure.

[0192] In the embodiments of the present disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical or other forms.

[0193] Each functional unit in the embodiment of the present disclosure may be integrated into one processing unit, or each unit may be an independent physical module.

[0194] If the integrated unit is implemented in the form of 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, all or part of the technical solution of the embodiment of the present disclosure can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device, such as a personal computer, a server, or a network device, or a processor to execute all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: a Universal Serial Bus Flash Drive, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, and other media that can store program codes.

[0195] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0196] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0197] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1The function specified in one or more boxes.

[0198] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0199] Although the preferred embodiments of the present disclosure have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present disclosure.

[0200] Obviously, those skilled in the art may make various changes and modifications to the present disclosure without departing from the spirit and scope of the present disclosure. Thus, if these modifications and variations of the present disclosure fall within the scope of the claims of the present disclosure and their equivalents, the present disclosure is intended to include these modifications and variations.

Claims

1. A risk control method, characterized in that: Applied to a software-defined perimeter (SDP) framework, the method includes: Obtaining a current login log of an authorized user, wherein the current login log includes specified login behavior attribute information, and the specified login behavior attribute information includes login address information, login time period information, login device identification information, and authorization group information; Discretizing the login behavior attribute information to obtain discrete login behavior attribute information, specifically including: discretizing the login address information into local province, remote province, and remote region; discretizing the login time period information into identifiers from 0 to 11 corresponding to every two-hour interval in a day; and discretizing the login device identifier information into brand new device, second-hand device, and old device. Using the discrete attribute information of the login behavior as input to a pre-established decision tree model, and determining a login risk label corresponding to the current login log of the authorized user through the decision tree model; The decision tree model is established in the following way: Obtain historical login log samples, each of which corresponds to a legitimate login behavior; Discretize the login behavior attribute information included in each historical login log sample to obtain discrete login behavior attribute information; According to the data distribution of the discrete attribute information of the login behavior, the login risk label corresponding to each branch of the decision tree model is determined, and the decision tree model is established.

2. The method according to claim 1, wherein The method further comprises: Obtaining the current access log of the authorized user and determining the application corresponding to the current access log; Determining whether the call to the application program interface corresponding to the current access log complies with the application program interface call rule corresponding to the application; generating an access risk tag for the current access log of the authorized user according to the determined result; The application program interface calling rules corresponding to the application are obtained in the following manner: Obtain historical access log samples corresponding to the application, each historical access log sample corresponding to a legitimate access behavior to the application; determine the application program interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application program interface call sequence; determine the application program interface call rules corresponding to the application based on the determined application program interface call sequence and call time sequence.

3. The method according to claim 1, wherein The method further comprises: Obtaining the current access log of the authorized user, and determining the authorization group corresponding to the current access log; Determining whether the call to the application program interface corresponding to the current access log complies with the application program interface call rule corresponding to the authorization group; generating an access risk tag for the current access log of the authorized user according to the determined result; The application program interface call rules corresponding to the authorization group are obtained in the following manner: Obtain historical access log samples corresponding to the authorization group, each historical access log sample corresponding to the legal access behavior of the authorized user under the authorization group; determine the application interface call sequence corresponding to each historical access log sample, and the call time sequence corresponding to the application interface call sequence; determine the application interface call rules corresponding to the authorization group based on the determined application interface call sequence and call time sequence.

4. The method according to claim 1, wherein The method further comprises: Obtaining the current access log of the authorized user; Determining whether the call to the application program interface corresponding to the current access log meets a pre-set application program interface legal call condition; According to the determined result, an access risk tag is generated for the current access log of the authorized user.

5. A risk control device, characterized in that: Applied to the software-defined perimeter (SDP) framework, the device includes: A login log acquisition module is used to obtain the current login log of the authorized user, wherein the current login log includes specified login behavior attribute information, and the specified login behavior attribute information includes login address information, login time period information, login device identification information and authorization group information; a discrete processing module, configured to discretize the login behavior attribute information to obtain discrete login behavior attribute information; The discrete processing module is specifically used to discretize the login address information into local province, remote province, and remote region; discretize the login time period information into identifiers from 0 to 11 corresponding to a time period of two hours per day; and discretize the login device identification information into new device, second-hand device, and old device. A login risk control module is used to use the discrete attribute information of the login behavior as the input of a pre-established decision tree model, and to determine the login risk label corresponding to the current login log of the authorized user through the decision tree model; wherein, the decision tree model is established in the following manner: obtaining historical login log samples, each historical login log sample corresponding to a legal login behavior; discretizing the login behavior attribute information included in each historical login log sample to obtain the discrete attribute information of the login behavior; determining the login risk label corresponding to each branch of the decision tree model based on the data distribution of the discrete attribute information of the login behavior, and establishing a decision tree model.

6. A non-volatile computer storage medium, characterized in that The computer storage medium stores an executable program, and the executable program is executed by a processor to implement the method according to any one of claims 1 to 4.

7. A computer program product, characterized in that The computer program product includes an executable program, and the executable program is executed by a processor to implement the method according to any one of claims 1 to 4.

8. A risk control device, characterized in that: The device includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; The memory is used to store computer programs; The processor is configured to implement the method steps described in any one of claims 1 to 4 when executing the program stored in the memory.

Images