Detailed Description
Embodiments of the present invention will be described below with reference to the accompanying drawings.
The risk control method and the risk control device are suitable for a scene of carrying out risk control on the account or the network behavior of the user, wherein the network behavior can comprise login behavior, payment behavior, transaction behavior and the like.
For example, in the application scenario shown in fig. 1, the client may refer to a terminal device that logs in a registered account of a user, or may refer to an application that logs in a registered account of a user, where the application is located in the terminal device; the client can upload the event information of the risk event perceived by the user of the client to the server in real time, that is, the user in the application refers to a user capable of perceiving the risk event, and the event information may include an event name and/or event content.
After receiving event information of a risk event uploaded by a client, a server in fig. 1 may determine a category of the risk event in combination with preset historical behavior information; and under the condition that the category of the risk event is determined to be the risk event, classifying the event information into the following categories: personalized event information and general event information; specifically, if the event information belongs to personalized event information, the event information is directly recorded, and a personalized security policy is generated according to the event information, so that a server can perform risk control on accounts or network behaviors of the user and/or similar users of the client according to the personalized security policy and a preset security policy, thereby being closer to the personal requirements of the user, wherein the preset security policy is compiled by developers according to historical behavior information of the user; if the event information belongs to the general event information, further determining the risk level of the risk event, and generating a general security strategy according to the event information under the condition that the risk level meets a preset condition; and according to the general security policy and the preset security policy, performing risk control on the accounts and network behaviors of the user of the client and other users, thereby achieving the purpose of sharing event information by a plurality of users.
It should be further noted that, under the condition that the event information is valid, the server may store the event information, so that a subsequent server may perform risk control on an account or a network behavior of the user in combination with the preset historical behavior information and the event information, thereby better ensuring the security of the user.
Fig. 2 is a flowchart of a risk control method according to an embodiment of the present application. The execution subject of the method may be a device with processing capabilities: a server or a system or an apparatus, such as a server in fig. 1, as shown in fig. 2, the method may specifically include:
step 210, receiving event information corresponding to the risk event sent by the client.
The client may be a terminal device that has logged in a registered account of the user, or may be an application that has logged in a registered account of the user and is located in the terminal device. Further, the risk events described above may include, but are not limited to, the following: account stolen events, money lost events, infrequent device login events, billing exception events, network underpinning events, login failure events, and drop events, among others.
It should be further noted that, in the present application, the user of the client has the ability to perceive the risk event. Specifically, when the user of the client senses the risk event, the user can fill in the event information of the risk event through an application interface provided by the client, and then trigger the client to upload the event information of the risk event to the server. The event information here may include event names and/or event contents, etc., wherein categories and risk levels may be set according to actual needs, and in one example, the categories may include: both at-risk and no-risk events, the risk levels may include: high, medium and low.
Of course, the above description only shows two categories of risk events and three risk levels by way of example, and is not intended to limit the present application, and in practical applications, the categories of risk events may also be expressed as: risk events and potential risk events occur, or other categories and the like can also be included; in addition, the risk level may also be expressed as a numerical value, or may include other risk levels, etc.
In addition, after receiving the event information sent by the client, the server may also perform preprocessing on the event information, for example, convert the event information into information conforming to a preset format, and the like, where the information in the preset format may be recognized by the server.
For example, it is assumed that the name of the wifi network to which the terminal device of the user is currently connected is "daoyong", and the user logs in the payer client using the registered payer account, and after a period of time, in the case that the user does not perform any payment operation, the payer account of the user has a fund loss, so that the user perceives a risk event, at this time, the user may trigger the payer client to send event information of the risk event to the payer server, and assuming that the event information includes an event name and event content, the event name may be an "account stolen event", and the event content may be a fund loss when the wifi network with the "daoyong" is connected.
And step 220, determining the category of the risk event according to the event information and preset historical behavior information.
Here, the preset historical behavior information may be collected by the server from the background database in advance. Specifically, the event information may be analyzed according to the preset historical behavior information to determine the category of the risk event, where a process of analyzing the event information according to the preset historical behavior information is also referred to as a process of data cleansing. In one implementation, risk model modeling may be performed according to the preset historical behavior information; and analyzing the event information through the risk model to determine the category of the risk event, wherein the event information is analyzed through the risk model to determine that the category of the risk event belongs to the conventional technology, which is not repeated herein.
The categories of the risk events determined in step 220 may include risk events and risk-free events, or may also include risks and risks of potential hazards, etc., and in this specification, the categories of the risk events including risk events and risk-free events are taken as an example.
And step 230, if the type of the risk event is the risk event, generating a security policy according to the event information.
If the server determines that the category of the risk event is a risk event, it indicates that event information corresponding to the risk event is valid information or available data, so that a security policy can be further generated based on the event information, where the security policy refers to a risk control method or rule adopted by the server for an account or a network behavior when the server identifies that the account or the network behavior of a user is at risk, and may include two types, namely a personalized security policy and a general security policy, and the personalized security policy is used for performing risk control on the account or the network behavior of a certain user and/or a similar user; the generic security policy is used for risk control of all users' accounts or network behavior.
It should be noted that, the generating the security policy according to the event information in step 230 further includes:
determining the classification of the event information according to the event information;
if the classification of the event information belongs to the general event information, acquiring the risk level of the risk event according to the event information;
and when the risk level meets a preset condition, generating a safety strategy according to the event information.
In order to perform personalized security protection on the user, when the risk event is determined to be a risk event, the event information can be further classified. In one implementation, the event information may further include classification information, the classification information including: personalized event information and general event information; after receiving the event information, the server determines the classification of the event information according to the classification information in the event information. Specifically, if the classification of the event information belongs to the personalized event information, a personalized security policy is generated directly according to the event information; if the classification of the event information belongs to the general event information, acquiring the risk level of the risk event according to the event information; and generating a general security policy according to the event information under the condition that the risk level meets a preset condition.
In one implementation, before acquiring the risk level of the risk event according to the event information, a storage unit may be preset, where the storage unit is configured to record a corresponding relationship between event information and level information of at least one preset risk event, where the preset risk event may be collected manually in advance.
In one example, the predetermined memory location may be as shown in table 1.
TABLE 1
It should be noted that the content in table 1 is only an exemplary illustration, and in practical applications, table 1 may further include other risk events, and the event information of the risk event may also not be limited to the event name, and may also include event content, event identifier, and the like, which is not limited in this application.
After presetting the storage unit, the obtaining the risk level of the risk event according to the event information may specifically include: and matching the event information with the event information of the preset risk event in the storage unit, and when the event information is matched with the event information of any preset risk event, taking the grade information corresponding to the event information of any preset risk event as the risk grade of the risk event. Here, matching may include coincidence or a similarity value being the largest (or exceeding a preset threshold), and the like. In the case that the event information includes only the event name, the event name of the risk event sent by the paypal client in the foregoing example is "account stolen event", and the event name is consistent with the second name in table 1, so that the name is matched with the second name in table 1, and thus the obtained risk level of the risk event is "medium"; and when the event name of the risk event sent by the client is the "account stolen event", the similarity value between the event name and the second name in table 1 is the largest, so that the name is matched with the second name in table 1, and the acquired risk level of the risk event is also "medium".
The above description has been made by taking an example that the event information only includes an event name, and only the event name is recorded in the storage unit, it can be understood that, when the event information also includes event content and the event content is also recorded in the storage unit, the event name and the event content in the event information sent by the client may be respectively matched with the event name and the event content in the storage unit, and in a case that the event name and the event content are all matched, the level information corresponding to the event name and the event content in the storage unit is acquired.
It should be further noted that when the event information of the risk event sent by the client does not match the event information of each preset risk event in the storage unit, the risk level of the risk event may be manually assigned, and when the risk level meets the preset condition, the event information and the corresponding risk may be equivalently added to the storage unit so as to match the event information subsequently sent by the client.
After determining the risk level of the risk event, and when the risk level satisfies a preset condition, a generic security policy may be generated.
As in the previous example, the risk level of the acquired risk event is "medium", and the preset conditions are assumed to be: and if the risk level is greater than or equal to the middle level, the risk level of the risk event meets the preset condition.
It is understood that the event information is discarded if the risk level does not satisfy the preset condition. Here, since a user of the client may experience a sensing error (for example, a remote login event, the user may forget that the user uses a certain device, and thus the event logged in the device is perceived as a risk event by mistake), when the server receives event information of the risk event, the obtained risk level of the risk event is relatively low (that is, the preset condition is not met), and thus the event information is not used as a basis for generating a security policy.
In one implementation, the generated generic security policy may include:
sending a reminding message to a client of a user; alternatively, the first and second electrodes may be,
prohibiting use of the account or prohibiting execution of the network action.
As in the foregoing example, when the event name is "account stolen event", and the event content is "fund loss occurs when connecting to wifi network with name" daoyong ", the general security policy generated by the paymate server may be: "send a warning message when detecting that the user performs login, payment operation through wifi network named" daoyong "or" prohibit login, payment operation through wifi network named "daoyong" and so on.
And 240, performing risk control on the account or the network behavior of the user according to the generated security policy and a preset security policy, wherein the preset security policy is written according to historical behavior information.
After the server generates the personalized security policy, the server can detect the account or network behavior of the user of the client and/or the similar user according to the personalized security policy and the preset security policy, wherein the similar user refers to a user having similar behavior with the current user obtained by the server through analyzing historical behavior data of the current user and other users; or after the general security policy is generated, the account or network behavior of the user of the client and/or other users may be detected according to the general security policy and the preset security policy. As in the previous example, the pay bank server sends a reminder message when detecting that a pay bank user (including a user using the current client and users of other clients) logs in a pay bank account or performs a payment operation through a wifi network named "daoyong"; or the payment service terminal forbids the login behavior or forbids the payment operation once detecting that the payment user (including the user using the current client and the users of other clients) logs in the payment account or executes the payment operation through the wifi network named as "daoyong".
That is, the risk control can be performed on the accounts or the network behaviors of all the users through the general security policy generated by the application, so that the sharing of data among the users is realized.
Of course, the above steps 210 to 240 are operations executed by the server side when the server side determines that the category of the risk event is a risk event; and when the server judges that the type of the risk event is a risk-free event, discarding the event information uploaded by the client. Here, the risk event is perceived by the user and an error occurs, so that when the server receives the event information sent by the client, the server needs to filter the risk event first to ensure that the risk event is a real risk event and is not a risk event sent by mistake due to a user perception error; and when event information of a risk event of a user perception error is received, a security policy is not generated according to the event information.
It can be understood that the general security policy and the personalized security policy generated by the present application are only supplements to the existing security policy, and are not replacements for the existing security policy, that is, after the general security policy or the personalized security policy of the present application is generated, the existing security policy and the general security policy or the personalized security policy may be combined to perform risk control on an account or a network behavior of a user, so that the effectiveness of risk control may be improved.
Fig. 3 is a flowchart of a risk control method according to another embodiment of the present application. The execution subject of the method may be a device with processing capabilities: a server or a system or an apparatus, such as a server in fig. 1, as shown in fig. 3, the method may specifically include:
and step 310, receiving event information corresponding to the risk event sent by the client.
And step 320, determining the category of the risk event according to the event information and preset historical behavior information.
Step 330, if the category of the risk event is a risk event, executing step 350, otherwise executing step 340;
at step 340, the event information is discarded.
Step 350, determining the classification of the event information according to the event information.
In step 360, if the classification of the event information belongs to the personalized event information, step 370 is executed, otherwise step 390 is executed.
And step 370, generating a personalized security policy according to the event information.
And 380, performing risk control on accounts or network behaviors of the user and/or similar users of the client according to the personalized security policy and the preset security policy.
Step 390, obtaining the risk level of the risk event according to the event information.
In step 3100, if the risk level satisfies the predetermined condition, execute step 3120, otherwise execute step 3110.
At step 3110, the event information is discarded.
And 3120, generating a general security policy according to the event information.
3130, performing risk control on accounts or network behavior of the user of the client and/or other users according to the general security policy and the preset security policy.
Therefore, the personalized requirements of the users can be met, and the purpose of sharing data among a plurality of users can be achieved.
In conclusion, the core idea of the application is to change the traditional method that developers write a security policy according to historical behavior data of users and perform risk control on accounts or network behaviors of the users according to the security policy; and the user is allowed to participate in the process, namely, the subject of participatory perception is applied, so that the server can receive the event information of the risk event uploaded by the client in real time, generate a security policy according to the event information, and finally realize risk control on the account or network behavior of the user by combining the generated security policy and a preset security policy, thereby improving the effectiveness of risk control.
Corresponding to the risk control method, an embodiment of the present application further provides a risk control device, as shown in fig. 4, the device includes:
a receiving unit 401, configured to receive event information corresponding to a risk event sent by a client.
A determining unit 402, configured to determine a category of the risk event according to the event information received by the receiving unit 401 and preset historical behavior information.
A generating unit 403, configured to generate a security policy according to the event information if the category of the risk event determined by the determining unit 402 is a risk event.
Optionally, the generating unit 403 is specifically configured to:
determining the classification of the event information according to the event information;
if the classification of the event information belongs to the general event information, acquiring the risk level of the risk event according to the event information;
and when the risk level meets a preset condition, generating a safety strategy according to the event information.
Optionally, the generating unit 403 is further specifically configured to:
matching the event information with event information of preset risk events in a storage unit, wherein the storage unit is used for recording the corresponding relation between the event information of at least one preset risk event and the grade information;
and when the risk level information is matched with the event information of any preset risk event, taking the level information corresponding to the event information of any preset risk event as the risk level of the risk event.
A control unit 404, configured to perform risk control on an account or a network behavior of the user according to the security policy generated by the generating unit 403 and a preset security policy, where the preset security policy is written according to historical behavior information.
Here, the generated general security policy may include:
sending a reminding message to a client of a user; alternatively, the first and second electrodes may be,
prohibiting use of the account or prohibiting execution of the network action.
Optionally, the apparatus may further include: a discarding unit 405, configured to discard the event information if the category of the risk event is a risk-free event.
The functions of the functional modules of the device in the embodiment of the present application may be implemented through the steps in the method embodiment described above, and therefore, the specific working process of the device provided in the present application is not repeated herein.
In the risk control device provided by the application, a receiving unit 401 receives event information corresponding to a risk event sent by a client; the determining unit 402 determines the category of the risk event according to the event information and preset historical behavior information; if the type of the risk event is a risk event, the generating unit 403 generates a security policy according to the event information; the control unit 404 performs risk control on the account or the network behavior of the user according to the generated security policy and the preset security policy. Therefore, effective risk control on the account or the network behavior of the user can be realized.
Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.