Patent Description:
Rather, this background is only provided to illustrate one exemplary technology area where some embodiments describe herein may be practiced.

<CIT> relates to determining an entity's cybersecurity risk and benchmarking that risk includes non-intrusively collecting one or more types of data associated with an entity. A security score is calculated for at least one of the types of data based on processing of security information extracted from the at least one type of data, wherein the security information is indicative of a level of cybersecurity. A weight is assigned to the calculated security score based on a correlation between the extracted security information and an overall cybersecurity risk determined from analysis of one or more previously-breached entities in the same industry as the entity.

<CIT> relates to an apparatus for credit based management of a telecommunication system. The apparatus includes an interface for communicating credit information on a particular subscriber and for receiving call records for the particular subscriber that are derived from a switch, which establishes connections between telecommunication devices. A credit limit device then utilizes the credit information to establish a credit limit for the subscriber. The apparatus also includes a device for comparing the particular subscriber's call usage to a credit limit established for the subscriber based on information obtained from the credit bureau. An output device is used to provide an indication that the subscriber has exceeded their credit limit.

<CIT> relates to systems, methods and computer program products for determining a risk score for an agent associated with an entity. First information is received associated with an agent's action related to an account and/or an agent's actions over a predetermined period of time related to one or more applications. A first risk score is determined based on the first information.

It is the object of the present invention to provide an enhanced security system and method for more efficient user related risk evaluation.

The principles described herein permit for conditionally initiating a security measure in response to an estimated increase in risk imposed related to a particular user of a computing network. The risk is determined using a rolling time window. Accordingly, sudden increases in risk are quickly detected, allowing security measures to be taken quickly within that computing network. Thus, improper infiltration into a computing network is less likely to escalate or move laterally to other users or resources within the computing network.

An agent of the entity may have pre-configured a security measure to take upon detection of a sudden increase in risk. Risk scores are determined for multiple related users of the entity over a rolling window to generate a rolling set of risk scores. Each user may then be evaluated for potential risk with respect to the rolling set of risk scores (i.e., relative to the multiple related users). In particular, for a particular user, the system generates a time series of relative risk scores relative to the rolling set of scores. Then, anomalous detection is performed on that generated time series. If an anomalous increase in risk scores is detected, the pre-configured security measure is automatically taken. As an example, security credentials of the particular user may be revoked or suspended, with new credentials being issued to the user upon appropriate secure authentication. Thus, because a rolling window is used to quickly determine increases in risk in real time, and because security remedies can be issued right away, the damage caused by security breaches can be remediated. Furthermore, the entity owning the computing network retains control over what security measures are taken. Thus, the interests of the entity are protected, minimizing risk of overreaching with the security measure.

<FIG> illustrates an environment <NUM> that includes multiple networks <NUM> that are served by a risk mitigation service <NUM>. Each of the networks <NUM> are used by a respective entity, such as a tenant of the risk mitigation service <NUM>. Thus, the networks <NUM> may each be regarded as instead a tenant of the risk mitigation service <NUM>. Thus, a network in this sense may be any system that contains resources and that implements procedures for controlling access to those resources. The risk mitigation service <NUM> may be implemented as one or more executable components, such as the executable component <NUM> described below with respect to <FIG>.

In the illustrated example, the networks <NUM> include network <NUM>, network <NUM> and network <NUM>. However, the risk mitigation service <NUM> may serve any number of networks as represented by the ellipsis <NUM>. As an example, if the risk mitigation service <NUM> operates in a private cloud or for a single entity, there may be but a single tenant and thus a single network <NUM>. At the other extreme, the networks <NUM> may include countless networks. In that case, the risk mitigation service <NUM> may be offered in a public cloud.

Each of the networks <NUM> contains multiple users. For purposes of illustrative example, the network <NUM> is illustrated as including users 112A through <NUM>, with the ellipsis 112I representing that the network <NUM> may include any number of users. The other networks <NUM> may also include any number of users, though those users are not illustrated in <FIG> to avoid unnecessarily complicating <FIG> and this description.

<FIG> illustrates a flowchart of a method <NUM> for conditionally initiating a security measure. The method <NUM> may be performed within the environment <NUM> of <FIG>. As an example, the method <NUM> may be performed by the risk mitigation service <NUM> for any of the networks <NUM>. Accordingly, the method <NUM> of <FIG> will now be described with respect to the environment <NUM> of <FIG>. In particular, though the method <NUM> of <FIG> may be performed for any of the networks <NUM> of <FIG>, the method <NUM> will be described as being performed for the network <NUM> of <FIG>. The method <NUM> is performed with respect to a rolling time window. Accordingly, the method <NUM> is frequently performed to account for the rolling of the time window.

The method <NUM> includes determining risk scores for related users of an entity of a rolling window to generate a rolling set of risk scores (act <NUM>). The entity could be a tenant of a cloud service. Referring to <FIG>, the entity could be the owner of the network <NUM> such that all of the users 112A through 112I are the related users. There are a variety of mechanisms for calculating risk scores. The principles described herein are not limited to any particular mechanism. However, risk scores are typically calculated based on a variety of factors involving behavior and actions of a user.

Let us take an arbitrary example in which there are <NUM> users A through J, and risks scores can vary from <NUM> to <NUM>. Furthermore, let us measure time as beginning at <NUM> and increasing monotonically. Finally, let us take the example in which the set of user scores measure since time <NUM> until time <NUM> is as follows in Table <NUM>.

Now assume a time window of <NUM>. At time <NUM>, the rolling risk set would include all of the risk scores for all of the <NUM> users for time <NUM>, <NUM>, <NUM> and <NUM>. Thus, this would include <NUM> risk scores in total, corresponding to all risk scores in the right <NUM> columns of Table <NUM>. Let the rolling set of risk scores be represented by the variable S, and each risk score being defined by sxy where x represents the letter of the user A through J, and y represents the time. Thus, the risk score of user C at time <NUM> would be represented as sC4.

Referring back to <FIG>, for each of the users, the content of dashed-lined box <NUM> is performed. A time series is generated for a relative risk score of each user. The relative risk score is relative to the rolling set of risk scores. As an example, suppose that the relative risk score is a function of the percentage of raw scores in the rolling window that are less than the raw score. Now suppose that each relative risk score is to be represented by Rxy where x represents the letter of the user A through J, and y represents the time.

Consider a case where a time series of relative risk scores is to be generated for user A. The first risk score of user A in the time window is sA2 which is <NUM>. The number of scores that are less than <NUM> in the rolling set of risk scores is <NUM>. And since there are <NUM> total risk scores in the rolling set of risk scores, the relative risk score RA2 is <NUM>/<NUM> or <NUM>. The second risk score of user A in the time window is sA3 which is <NUM>. The number of scores that are less than <NUM> in the rolling set of risk scores is <NUM>. So, the relative risk score RA3 is <NUM>/<NUM> or <NUM>. The third risk score of user A in the time window is sA4 which is <NUM>. The number of scores that are less than <NUM> in the rolling set of risk scores is <NUM>. So, the relative risk score RA4 is <NUM>/<NUM> or <NUM>. The final risk score sA5 of user A in the time window is <NUM>. The number of scores that are less than <NUM> in the rolling set of risk scores is <NUM>. So, the relative risk score RA4 is <NUM>/<NUM> or <NUM>. So in this example, the time series of relative risk scores for user A is <NUM>, <NUM>, <NUM> and <NUM>.

Referring back to <FIG>, the service performs anomalous detection on the time series (act <NUM>). In this example, anomalous detection is performed on the series <NUM>, <NUM>, <NUM> and <NUM>. There are a variety of conventional algorithms used to perform anomaly detection of a time series. The principles described herein are not limited to any particular time series anomaly detection function. However, in one embodiment, the ARIMA unsupervised time series anomaly detection algorithm is used.

Referring to <FIG>, if no anomaly is found in the time series (decision block <NUM>), then no action is taken at this time (act <NUM>). However, if an anomalous increase is found in the generated time series of the relative risk score of the particular user ("Yes" in decision block <NUM>), then the service automatically performs a security measure configured by the entity (act <NUM>).

Several examples of the detection of an increase in the time series of relative risk scores will now be described. In one example, the anomalous increase is detected by determining that a most recent risk score of the generated time series is above a pre-determined percentage of the rolling set of risk scores. For instance, suppose that the pre-determined percentage is <NUM> percent. In that case, the generated time series <NUM>, <NUM>, <NUM> and <NUM> would result in the detection of an anomaly since the final relative risk score <NUM> is above <NUM> percent.

The percentage thresholds may be changed adaptively. Thus, the threshold may be varied from <NUM> percent in order to avoid unnecessary triggering of security measures, or to avoid missing security problems. The threshold may be adjusted by an administrator of the entity should the entity desired to throttle back the detection of anomalous increases in risk scores.

In another example, an anomalous increase is detected by determining that a last risk score of the generated time series is above a first pre-determined percentage of the rolling set of risk scores, and that a penultimate risk score of the generated time series is below a second pre-determined percentage of the rolling set of risk scores, the second pre-determined percentage being less than the first pre-determined percentage. As an example, suppose that the first threshold is <NUM> percent, and the second threshold is <NUM> percent. The generated time series <NUM>, <NUM>, <NUM> and <NUM> would result in the detection of an anomaly since the final relative risk score <NUM> is above <NUM> percent, and since the second-to-last risk score <NUM> is below <NUM> percent.

This technique has the advantage of refraining from too frequently finding a sudden increase where the particular user ordinarily has a higher risk score, and thus might otherwise be inconvenienced by having security measures frequently taken. As an example, user G of Table <NUM> characteristically has high risk scores. The raw risk scores sG2 through sG5 are <NUM>, <NUM>, <NUM> and <NUM>, resulting in relative risk scores RG2 through RG5 of <NUM>, <NUM>, <NUM> and <NUM>. The second-to-last relative risk score is <NUM>, which is above the lower threshold, so an anomalous increase is not detected even though the last relative risk score is <NUM>, above the higher <NUM> percent threshold. Thus, the technique of having two thresholds prevents the user G from having security measures taken every time a new raw risk score is gathered.

In one embodiment, the anomalous increase is an increase relative to the rolling set of risk scores of a later relative risk score in the generated time series as compared to an earlier relative risk score in the generated time series. Let S be the set of scores received during the scoring period in any context in which the risk scores are comparable, such as the risk score of users from the same organization or the same geographical region. Note that the risk score set can include risk scores with no requirement that risk scores be calculated at the same time for all users, as was the case for Table <NUM>. Let x<NUM>, x<NUM> ∈ S be the risk scores of the tested user which were received in this order. Let h ∈ (<NUM>,<NUM>) be the lower bound of the top ranked risk scores. Let l ∈ (<NUM>,<NUM>) be the upper bound of the bottom ranked risk scores such that h > l.

The lower and upper bounds of the ranked risks h and l above can be constant values. For example, l can be equal to <NUM> to mark the bottom percentage and h can be equal to <NUM> to mark the top percentage. The bounds can also be adaptive based on the context and can be transferred or shared between different contexts. A sudden increase in risk score of the tested user from x<NUM> to x<NUM> exists if the following is true: <MAT>.

<FIG> illustrates a flowchart of a method <NUM> for performing anomalous detection on the time series, and represents and example of act <NUM> of the method <NUM> of <FIG>. The method <NUM> includes using an anomalous detection algorithm to generate an initial positive detection of an anomaly in the time series (act <NUM>). Then false positive detection logic may be applied (act <NUM>) to estimate whether or not initial positive detection is a false positive (decision block <NUM>). If the positive detection is estimated to be a false positive ("Yes" in decision block <NUM>), then the initial positive detection is ignored (act <NUM>). On the other hand, if the initial positive detection is estimated to not be a false positive ("No" in decision block <NUM>), the positive detection is output (act <NUM>). Referring to <FIG>, this would result in an anomaly being detected ("Yes" in decision block <NUM>).

An example of a false positive may be if the number of risk score samples is too small (e.g., below <NUM> risk scores) so as not to be a reliable standard against which user risk scores can be compared to detect true risk behavior. Another example of a false positive may be that the risk score itself (although being relatively high with respect to the rolling set of risk scores) is still well in the safe range compared to the behavior of all entities (e.g., across all of the networks <NUM>).

As previously mentioned, the security measure performed by the service may be configured by the entity itself. <FIG> illustrates a flowchart of a method <NUM> for pre-configuring the security measure. The method <NUM> may be performed by the risk mitigation service <NUM> of <FIG>. The service causes a user interface to be displayed to an administrator of the entity (act <NUM>). Thereafter, the service detects user interaction of the entity administrator (act <NUM>). The service then sets the security measure in response to administrator interaction with the user interface (act <NUM>). This configuration is performed in advance of the performance of the method <NUM> against the users of that entity.

The configuration may specify a fixed security measure that is applied whenever an increase is detected across all users. Alternatively, the security measure may depend on the user or the role of the user. Alternatively, or in addition, the security measure may depend on the severity of the increase. Example security measures that the entity administrator might set include electronically notifying an administrator of the entity, suspending a credential of the particular user, revoking or suspending authorization of the particular user to access at least a subset of computing resources of the entity. Another option is to automatically establish a secure session with the particular user, and establishing new credentials with the particular user via the secure session.

Accordingly, the principles described herein quickly determine whether there is a sudden increase in risk posed by a particular user within an entity, allowing for more quick resolution of a potential security breach before further damage is done by the breach. In addition, the entity has say into what the security measure is to be, allowing for security measures to be taken potentially immediately and automatically without taking away the control the entity has over their own security. Because the principles described herein are performed in the context of a computing system, some introductory discussion of a computing system will be described with respect to <FIG>.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> includes a general-purpose processor. Although not required, the processing unit <NUM> may also include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, the memory <NUM> includes a physical system memory. That physical system memory may be volatile, non-volatile, or some combination of the two. In a second embodiment, the memory is non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, the memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. The term "executable component" is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods (and so forth) that may be executed on the computing system. Such an executable component exists in the heap of a computing system, in computer-readable storage media, or a combination.

One of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term "executable component".

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 512A as well as input mechanisms 512B. The principles described herein are not limited to the precise output mechanisms 512A or input mechanisms 512B as such will depend on the nature of the device. However, output mechanisms 512A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms 512B might include, for instance, microphones, touchscreens, virtual or augmented reality, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, datacenters, wearables (such as glasses) and the like.

For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, an some of the operations may be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

The present invention may be embodied in other specific forms without departing from the scope defined by the appended claims.

Claim 1:
A computing system (<NUM>) comprising:
one or more processors (<NUM>); and
one or more computer-readable media (<NUM>) having thereon computer-executable instructions (<NUM>) that are structured such that, if executed by the one or more processors, causes the computing system to conditionally initiate a security measure by:
determining (<NUM>) risk scores for a plurality of related users (112A, ..., 112I) of an entity over a rolling time window to generate a rolling set of risk scores;
generating (<NUM>) a time series of a relative risk score of a particular user, the relative risk score being relative to the rolling set of risk scores, the particular user being one of the plurality of related users;
performing (<NUM>) anomalous detection on the time series; and
if the anomalous detection detects an anomalous increase in the generated time series of the relative risk score of the particular user, automatically performing (<NUM>) a security measure configured by the entity.