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 internet protocol threat prevention. High-risk IP connections are blocked in real-time while users are allowed to tailor their acceptable risk profiles to match the security requirements of their network resources. IP threat information is acquired from one or more providers via a feed (e.g., based on extensible Markup Language (XML) or JavaScript Object Notation (JSON)). The information includes, for example, an IP address, a named risk category, and a confidence level that the listed IP address is actually a threat within the named category. The category names from each provider are mapped into a set of common category names to resolve potential naming conflicts. An aggregate risk score based on the individual risk scores takes into account confidence levels assigned by IRIPs, the number of times an IP address has been listed as high-risk over a predefined time interval, and the time interval since the last time the IP address was listed. In addition, weighting the scores from the IRIP data improves threat assessment.

It is the object of the present invention to improve identification misconfigured interface services.

The principles described herein relate to automatically performing threat assessment in a multi-cluster system, such as a public cloud. The threat assessment automatically detects interface services that are externally exposed with insufficient protection to outside of the cluster or even to the Internet. The multi-cluster system includes a plurality of clusters of machine nodes, each cluster running one or more applications, and each application having an interface service that exposes the corresponding application as a network service.

A threat assessment component first identifies one or more characteristics of interface services that are indicative of a sensitive interface service. Such might include identifying a group of interface services that have one or more common characteristics, and then identifying the group of interface services as sensitive based on an amount (e.g. a percentage) of clusters that permit the interface services to be connected from outside the respective cluster. If there is a lower percentage of clusters that permit such external access, this would be more indicative of the interface services being more highly sensitive, since the behavior of the clusters in restricting access implies greater sensitivity.

For each of at least some of the plurality of interface services within the multi-cluster system, the threat assessment component estimates that a corresponding interface service within a corresponding cluster is misconfigured so as to be improperly connectable external to the corresponding cluster. It does so in response to the following determinations: <NUM>) determining that the corresponding interface service also has the one or more common characteristics (thereby implying that the interface service is likely sensitive like the other interface services that fewer clusters grant external access to); <NUM>) that the corresponding interface service is connectable outside the corresponding cluster; and <NUM>) that a corresponding application that the corresponding interface service exposes as a network service does not require authentication. If the determinations are made, this means that the interface service is sensitive, and is accessible external to the cluster without using authentication. In this case, the threat assessment component might send a notification to a cluster management component allowing a network administrator for the cluster to take corrective action.

Accordingly, the principles described herein permit for the automated estimation that an interface service has been misconfigured. Sensitive interface services are first identified based on common characteristics, and those characteristics are associated with sensitivity based on behavior across multiple clusters. Thereafter, the threat assessment estimates that a particular interface service is misconfigured if the particular interface service has these same common characteristics, is accessible from outside the cluster, and does not require authentication. Cluster administrators can therefore be more fully and timely advised when a misconfiguration of an interface service subjects their cluster to undue security risks.

<FIG> illustrates a multiple cluster environment <NUM> in which the principles described herein may be practiced. A "cluster" is a group of connected computing systems that operate together to perform tasks. In a cluster, each computing system is referred to as a "node". A node may be a physical computing system or a virtual machine. An example of a multiple cluster environment <NUM> is a cloud computing environment. In a private cloud environment, all clusters may perhaps be in a common sphere of trust. In a public cloud environment, clusters may belong to different customers of the public cloud provider. Each customer may operate one or more clusters within the multiple cluster environment.

In this illustrated cluster environment <NUM>, there are only five clusters shown including clusters <NUM> through <NUM>. However, the ellipsis <NUM> represents that there may be any number of clusters within the multiple cluster environment <NUM>. The ellipsis <NUM> also represents that the number of clusters may change over time as clusters are removed from the multiple cluster environment <NUM>, and as clusters are added to the multiple cluster environment <NUM>. The principles described herein are not limited to the number of clusters operating in the multiple cluster environment <NUM>. As an example, a cloud computing environment might run on the order of thousands or millions of clusters or even more.

Each cluster runs one or more applications. Each application has a corresponding interface service that exposes the application as a network service. In <FIG>, each application is represented as a horizontally extending rectangle, and the corresponding interface service is represented as an elongated semi-circle attached at its flat side to the right side of the rectangle. Of course, the clusters can run any arbitrary number of applications, and the number of applications shown as running by each cluster <NUM> through <NUM> in <FIG> is just for illustrative purposes only.

As an example only, the cluster <NUM> is illustrated as running three applications 112A, 112B and 112C. Interface service 111A exposes the application 112A as a network service, interface service 111B exposes application 112B as a network service, and interface service 111C exposes application 112C as a network service. Likewise, cluster <NUM> is illustrated as running four applications 122A through 122D which are each exposed as network services using respective interface services 121A through 121D. Similarly, cluster <NUM> is illustrated as running two applications 132A and 132B which are each exposed as network services using respective interface services 131A and 131B. Continuing, cluster <NUM> is illustrated as running five applications 142A through 142E which are each exposed as network services using respective interface services 141A through 141E. Finally in this example, cluster <NUM> is illustrated as running three applications 152A through 152C which are each exposed as network services using respective interface services 151A through 151C.

The multiple cluster environment <NUM> also includes a threat assessment component <NUM> that performs the threat assessments described herein. The threat assessment component <NUM> may be structured as described below for the executable component <NUM> of <FIG>. The threat assessment component <NUM> also has access to a log <NUM> which records some events that occur within the multiple cluster environment <NUM>, such as interface service creation and reconfiguration events that will be described further below. The log <NUM> may record events from any of the clusters <NUM> through <NUM>.

<FIG> illustrates a flowchart of a method <NUM> for automatically estimating whether interface services having one or more characteristics are sensitive, in accordance with the principles described herein. The method <NUM> is performed in a multi-cluster system that includes a plurality of clusters of machine nodes, each cluster running one or more applications, and each application having an interface service that exposes the corresponding application as a network service. As an example, the method <NUM> may be performed by the multi-cluster thread assessment component <NUM> within the multiple cluster environment <NUM> of <FIG>, and this example will commonly be referred to hereinafter.

The method <NUM> may be performed for each of multiple groups of interface services to determine whether or not each group is sensitive. Sensitive interface services are those services that are allowed to perform sensitive actions in the cluster and\or on the underlying nodes. As examples, such actions can be the ability to run code on the container and/or underlying node, deploy new containers in the cluster, list secrets from the cluster, gather information about the running workload, and so forth. These are just examples. Sensitive actions could include any function that one external to the cluster should not be able to perform without proper authentication.

The method <NUM> includes identifying a group of interface services that have one or more common characteristics (act <NUM>). As examples, the one or more common characteristics could include an interface service type. For instance, if the multi-cluster system <NUM> was a Kubernetes system, the interface service type might be the LoadBalancer service type. The one or more common characteristics could also include similar names of the interface service. A name similarity algorithm could be used to combine similar interface service names.

<FIG> illustrates an example flow <NUM> in which the method <NUM> is performed three times. The act <NUM> is performed one time in one instance of the method <NUM> to identify a first group <NUM> having common characteristic(s) (as represented by the constituent interface services being illustrated as triangles). The act <NUM> is performed one time in another instance of the method <NUM> to identify a second group <NUM> having common characteristic(s) (as represented by the constituent interface services being illustrated as trapezoids). As an example, the interface services 111A, 121C, 131A, 141A and 151B of <FIG> could have the characteristic(s) associated with this second group <NUM> is symbolized by each being illustrated as also including a trapezoid. The act <NUM> is performed one time in yet another instance of the method <NUM> to identify a third group <NUM> having common characteristic(s) (as represented by the constituent interface services being illustrated as circles).

The threat assessment component <NUM> receives the characteristic(s) for each of these groups <NUM>, <NUM> and <NUM> as represented by respective arrows <NUM>, <NUM> and <NUM>. The threat assessment component <NUM> then determines whether or not the amount of clusters that permit external access to the interface services of that group are low (e.g., below a predetermined percentage of the clusters). As an example, if only a smaller number of clusters (e.g., <NUM> percent) permit entities outside of the cluster to use the cluster, then interface services of that group (or in other words having the associated characteristic(s)) are considered sensitive.

Consider the interface services of <FIG> that belong to the second group <NUM> (illustrated as containing a trapezoid). One cluster <NUM> exposes (as represented by line <NUM>) the interface service 151B of the second group <NUM> outside of the cluster <NUM>. However, clusters <NUM> through <NUM> each do not expose their respective interface service of that second group <NUM> outside of their respective cluster. Accordingly, here, but a single cluster exposes interface services of the second group <NUM> outside of the respective cluster. In the example, this causes the threat assessment component <NUM> to estimate that interface services having the common characteristic(s) of the second group <NUM> are to be consider sensitive, since the clusters themselves are behaving that way. On the other hand, if most clusters exposed interface services having particular common characteristic(s) external to the cluster (e.g., to other clusters or to the Internet), then the threat assessment component <NUM> would determine that the particular characteristic(s) is not indicative of a sensitive interface service, since clusters are behaving like they are not sensitive.

Referring again to <FIG>, suppose that the threat assessment component <NUM> determines that interface services having the characteristic(s) associated with the first group <NUM> are not sensitive (act <NUM>) based on the amount of clusters permitting external access to such interface services being higher ("No" in decision block <NUM>). Referring to <FIG>, the threat assessment component <NUM> may determine which clusters permit external access to such interface services by examining the log <NUM>. The threat assessment component would then determine (as represented by arrow <NUM> and decision <NUM>) that interface services having those characteristic(s) are not sensitive.

Continuing the example of <FIG>, suppose also that the threat assessment component <NUM> determines that interface services having the characteristic(s) associated with the second group <NUM> are sensitive (act <NUM> of <FIG>) based on the relatively smaller amount of clusters permitting external access to such interface services ("Yes" in decision block <NUM> of <FIG>). The threat assessment component <NUM> would then determine (as represented by arrow <NUM> and decision <NUM>) that interface services having those characteristic(s) are sensitive.

Lastly, suppose that the threat assessment component <NUM> determines that interface services having the characteristic(s) associated with the third group <NUM> are not sensitive (act <NUM>) based on the amount of clusters permitting external access to such interface services being higher ("No" in decision block <NUM>). The threat assessment component would then determine (as represented by arrow <NUM> and decision <NUM>) that interface services having those characteristic(s) are not sensitive.

Thus, the method <NUM> may be used to categorize characteristic(s) of interface services with estimated sensitivity. This categorization may be done well in advance of making an estimation of whether any particular interface service has been misconfigured. At one extreme, perhaps the categorization of interface characteristic(s) with sensitivity of the corresponding service is done only once. Or perhaps, the categorization is done periodically in case there has been a change in cluster behavior towards interface services having particular characteristic(s). Or perhaps, the categorization is repeated over time in order to obtain better estimations of mappings between interface services and sensitivity. Customers behavior may also be considered. As an example, if customer feedback shows that characteristic(s) are less likely associated with sensitivity, that feedback can be considered in the sensitivity estimation.

<FIG> illustrates a flowchart of a method <NUM> for automatically detecting or estimating interface services that are externally exposed with insufficient protection. This method <NUM> may be performed perhaps with higher frequency, even as often as every time an interface service is created or reconfigured. Specifically, the method <NUM> estimates whether an interface service of a cluster is misconfigured so as to be improperly connectable external to the corresponding cluster. The method <NUM> may be performed for any number of interface services, and may be performed for interface services of any number of clusters.

The method <NUM> includes having the threat assessment component determine that the corresponding interface service also has the one or more common characteristics that the threat assessment component previously categorized as being associated with a group of sensitive interface services (act <NUM>). As an example, the threat assessment component might determine that a particular interface service has the characteristic(s) associated with the second group <NUM>, and thus also determines that the particular interface service is sensitive. If the threat assessment component is not sensitive, then the method <NUM> can stop without reaching an estimation that the interface service has been improperly configured.

The threat assessment component also determines whether or not the particular interface service is connectable outside of the corresponding cluster. In one example, this determination is made by examining a log (e.g., log <NUM>) that contains a creation event or reconfiguration event for the particular interface service. <FIG> illustrates an example of such an event <NUM>, which includes an Internet Protocol (IP) address <NUM> and a network port <NUM>. The threat assessment component determines from the recorded IP address <NUM> and the recorded network port <NUM> within the creation event <NUM> whether the particular interface service is accessible outside of the corresponding cluster. If the interface service is not connectable outside of the cluster, then again, the method <NUM> can stop without reaching an estimation that the interface service has been improperly configured. However, if the threat assessment component determines that the particular interface service is connectable outside of the corresponding cluster (act <NUM>), the analysis continues.

The threat assessment component also determines whether or not the application that the corresponding interface service exposes as a network service requires authentication (act <NUM>). In one example, this determination is made by checking configuration of the particular application. For instance, in <FIG>, if the threat assessment component <NUM> was estimating whether or not the interface service 151B is misconfigured, the threat assessment component <NUM> would look at the application configuration of the corresponding application 152B. <FIG> illustrates an example of the application configuration <NUM> which includes an entry point <NUM>, environmental variables <NUM> and a configuration map <NUM>. If authentication is applied, an indication should appear in at least one of the application's entry-point, the application's environment variables, and a configuration map in the application's namespace and response code.

If the application requires authentication, then again, the method <NUM> can stop without reaching an estimation that the interface service has been improperly configured. However, if the threat assessment component determines that the application does not require authentication (act <NUM>), the threat assessment component estimates that the particular interface service is misconfigured, and sends a notification of the estimation to a cluster management component of a particular cluster within which the particular interface service operates (act <NUM>). For instance, suppose that the application 152C is a cluster management component run by a cluster administrator of the cluster <NUM>. If the threat assessment component <NUM> estimates that the interface service 151B is misconfigured, the threat assessment component <NUM> sends an electronic notification of the estimation to the application 152C.

Accordingly, the principles described herein permit for the automated estimation that an interface service has been misconfigured. Sensitive interface services are first identified based on common characteristics, and those characteristics are associated sensitivity based on behavior across multiple clusters. Thereafter, the threat assessment estimates that a particular interface service is misconfigured if the particular interface service has these same common characteristics, is accessible from outside the cluster, and does not require authentication. Cluster administrators can therefore be more fully and timely advised when a misconfiguration of an interface service subjects their cluster to undue security risks.

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 712A as well as input mechanisms 712B. The principles described herein are not limited to the precise output mechanisms 712A or input mechanisms 712B as such will depend on the nature of the device. However, output mechanisms 712A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms 712B 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.

The invention may also be practiced in distributed system environments where local and remote computing system, which are linked (either by hardwired data links, wireless the behavior of the clusters in restricting access implies greater sensitivity. data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.

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, and 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.

Claim 1:
A computing system for performing threat assessment by detecting interface services that are externally exposed with insufficient protection in a multi-cluster system that includes a plurality of clusters (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of machine nodes, each cluster running one or more applications, and each application having an interface service that exposes the corresponding application as a network service, the computing system comprising:
one or more processors (<NUM>); and
one or more computer-readable media (<NUM>) having thereon computer-executable instructions that are structured such that, if executed by the one or more processors, the computing system is configured to:
identifying (<NUM>) a group of interface services that have one or more common characteristics;
identifying (<NUM>) the group of interface services as sensitive based on an amount of plurality the clusters that permit the interface services to be connected from outside the respective cluster;
for each of at least some of the plurality of interface services within the multi-cluster system, estimating (<NUM>) that a corresponding interface service within a corresponding cluster is misconfigured so as to be improperly connectable external to the corresponding cluster in response to the following determinations:
determining that the corresponding interface service also has the one or more common characteristics;
determining that the corresponding interface service is connectable outside the corresponding cluster; and
determining that a corresponding application that the corresponding interface service exposes as a network service does not require authentication.