FIG. 3.

At S230, computing interface call data is obtained. As a non-limiting example, the computing interface call data may include calls to any or all of the computing interfaces 155, FIG. 1. Each computing interface calls may include, but are not limited to, a verb or method (e.g., a HTTP verb) as well as an instance of a computing interface name. Each instance of a computing interface name, in turn, may indicate a path to an endpoint and one or more parameters, any of which may be divided into segments by bookend characters such as slash marks.

At S240, computing interface calls among the computing interface call data are clustered according to the cluster definitions created at S220. To this end, S230 may include, but is not limited to, matching each computing interface call or portion thereof (e.g., a portion excluding the verb) to the cluster definitions created at S220 in order to determine whether each computing interface call matches one of the clusters. Moreover, the parameter type strings in the cluster definitions may be compared to the computing interface calls using parameter type comparison rules that determine whether a given portion of a computing interface call matches a type of parameter indicated by the parameter type string including, but not limited to, analyzing the data type, format, and the like, of each segment.

To this end, in an embodiment, S240 includes matching computing interface call instances in order to determine computing interface call instances matching respective computing interface cluster definitions, and grouping the computing interface call instances into clusters of computing interface calls having the same computing interface cluster definition. Further, S240 includes identifying portions of the computing interface call instances which match types of parameters represented by respective string type parameters of the computing interface cluster definitions. In this manner, parameters in those identified portions may be generalized for purposes of comparing to the computing interface cluster definitions such that clustering of calls may be achieved despite potential differences in instance-specific parameters. Moreover, the resulting clusters may include fewer clusters than the number of original computing interface call instances, which in turn reduces subsequent processing as described herein.

At S250, baseline behavior is established with respect to the clustered calls. The baseline behavior may include, but is not limited to, the computing interfaces being called, sequences of computing interfaces being called, timing of computing interface calls, sources of computing interface calls (e.g., particular systems or computing environments), combinations thereof, and the like. Moreover, any or all of those baseline behaviors may further be defined with respect to user activity which, in turn, may be defined with respect to specific users, types of users, users from the same source (e.g., based on calls made from the same computing environment or network), combinations thereof, portions thereof, and the like. Even further, the baseline behavior may be established differently for different entities, e.g., for entities owning or operating different computing environments based on analysis of data collected from their respective computing environments.

In some embodiments, computing interface call flows may be analyzed, where the call flows are defined with respect to computing interfaces according to the cluster definitions such that computing interface calls matching the same cluster are determined to represent a call to the same computing interface, and flows between computing interfaces may be defined based on calls to and from the same computing interface.

At S260, abnormal behavior is detected based on the determined baseline behaviors. The abnormal behavior may be, but is not limited to, behavior that deviates from one or more of the determined baseline behaviors above a threshold. In an embodiment, the abnormal behavior is based on subsequently observed computing interface calls (i.e., calls observed after the establishment of the baseline behavior). In this manner, the baseline behavior may effectively be extrapolated to future behavior and utilized to determine whether the future behavior is abnormal.

At S270, one or more mitigation actions are performed with respect to the detected abnormal behavior. The mitigation actions may include, but are not limited to, blocking traffic, reconfiguring computing interfaces, reconfiguring computing interface gateways (e.g., API gateways), generating alerts, generating and sending notifications, combinations thereof, and the like.

FIG. 3 is a flowchart S220 illustrating a method for defining computing interface clusters according to an embodiment.

At S310, computing interface name examples are read, for example, from a database (e.g., one or more of the databases 120, FIG. 1). In some implementations, the set of computing interface name examples are examples for a particular entity (e.g., an entity who owns or operates a computing environment hosting services to which computing interface calls are made). In this regard, cluster definitions may be created which are entity-specific in order to improve cluster determination when analyzing computing interface calls to or from computing interfaces for that entity.

At S320, a character matrix is created based on the computing interface name examples. The character matrix includes entries representing potential combinations of characters. In a non-limiting example implementation, a two-dimensional matrix is created including entries representing every combination of two English letters. Moreover, the character matrix may include each potential ordered combination of characters. As a non-limiting example, the ordered combinations “a-k” and “k-a” may be two entries in a two-dimensional character matrix.

It should be noted that S310 and S320 are depicted as part of a single flow with the rest of FIG. 3 merely for illustrative purposes, and that the disclosed embodiments are not necessarily limited to performing these steps as part of the same flow. As a non-limiting example according to at least some embodiments, character matrices may be created as discussed with respect to S310 and S320 in advance, and subsequently computing interface names may be analyzed with respect to these predefined character matrices. Further, the subsequently analyzed computing interface names may be names among the name examples, or may be a different set of names (e.g., a set of computing interface names belonging to a specific entity or organization). In this regard, the character matrix may be defined more generally (i.e., non-entity or organization specific), and the cluster definitions may be defined per entity or organization (i.e., based on the examples of general kinds of computing interface names observed within data related to that entity or organization).

At S330, N-gram statistics are determined for the computing interface name examples based on the character matrix. Each N-gram is a continuous sequence of N items, where N is an integer greater than or equal to 1. In an embodiment, each of the N-grams is a continuous sequence of 2 characters, where each sequence of 2 characters includes the characters of one of the potential combinations of characters represented in the character matrix.

In an embodiment, S330 includes calculating a number of occurrences (i.e., a count) of each N-gram. In a further embodiment, a value representing the relative frequency of each N-gram among the population of N-grams in the computing interface name examples is determined. In an example implementation, such a value may be calculated as log (count).

At S340, N-grams represented in the character matrix are extracted from the computing interface name examples. Each N-gram is a contiguous sequence of N items (e.g., characters) from a given sample of the computing interface name examples (e.g., of strings among those examples), where N is an integer having a value of 1 or greater. In an embodiment, the N-grams are 2-grams including 2 characters. As a non-limiting example, when a string among the computing interface name examples is “Father”, the 2-grams “fa”, “at”, “th”, “he”, and “er” may be extracted from that string.

At S350, a score is determined for the N-grams in each string among the computing interface examples. As a non-limiting example for the “Father” example above, the score may be calculated as an average value as follows:

score
⁢

(
average
)

=

[

value
⁢

(

‘
fa
’

)

+

value
⁢

(

‘
at
’

)

+

value
⁢

(

‘
th
’

)

+

value
⁢

(

‘
he

)

+
 

value
⁢

(

‘
er
’

)

]

/
5

Where the value of each N-gram may be the value indicating relative frequency as discussed above with respect to S330.

At S360, it is determined whether each score is above a threshold. The threshold may be a predetermined threshold set based on the use case. As a non-limiting example, the threshold may be a predetermined value set for the English language (i.e., a known value used for determining meaningful English language words). In other words, such a comparison may allow for recognizing whether words are gibberish or otherwise lack meaning according to one or more languages. It has been identified that parameters tend to be gibberish (i.e., unrecognizable as a word) such that the threshold may be utilized to identify portions of segments which are likely to represent parameters.

In some implementations, the threshold is determined based on one or more datasets including labeled strings, where the labels indicate whether a given string in the datasets has a positive association as a “real” word or a negative association as a “gibberish” word. The positively labeled strings may be a dictionary of many example strings of known words, and the positively labeled strings may include random strings that collectively have the same or a similar distribution of lengths of those strings as compared to the dictionary of the positively labeled strings. The threshold may be selected so as to minimize mistakes, i.e., when the threshold is applied as discussed above, the threshold results in the lowest number of negatively labeled strings being above the threshold, the highest number of positively labeled strings being below the threshold, or both, as compared to other potential threshold values.

At S370, clusterizers are identified within segments of the computing interface examples. Each clusterizer is at least a portion of a string (e.g., a string or substring) which demonstrates a recurring pattern within the computing interface examples, for example, as determined using regular expressions. Each clusterizer is identified as one of the strings having an average value below the threshold or a portion thereof (e.g., a substring that is part of a string having an average value below the threshold).

In an embodiment, each segment among the computing interface name examples may be divided into clusterizers and leftovers, where the leftovers are portions of segments (e.g., strings) which do not belong to any clusterizer.

In a further embodiment, S370 may also include verifying one or more minimum count conditions for each potential clusterizer identified within segments. Such minimum count conditions may define minimum counts for each clusterizer with respect to counts of the clusterizers within segments, for example a number of instances of each clusterizer demonstrating the same ancestor (e.g., the same clusterizer preceding that clusterizer), a number of instances of each clusterizer appearing within the same segment pattern, both, and the like. Such minimum count conditions may serve as an additional check to ensure that clusterizers yield accurate clusters when utilized as part of cluster definitions.

Each segment pattern represents a pattern of the segment and may be defined with respect to clusterizers (or potential clusterizers) and leftovers within each segment such that each segment pattern represents the contents of the entire segment. Moreover, each segment pattern may be an ordered sequence of clusterizers and leftovers arranged according to the order in which each clusterizer or leftover appears within the segment. These segment patterns may be utilized to identify commonalities between segments, and moreover may be utilized as further evidence that a potential clusterizer is actually a clusterizer. That is, if a potential clusterizer appears in the same segment pattern above a threshold number of times, the potential clusterizer is much more likely to be an actual clusterizer. Each leftover may be generalized into a general format leftover based on the type of data, how the characters of the leftover are arranged, both, and the like.

At S380, clusterized string lists are matched between the segments of the computing interface examples. In an embodiment, S380 includes generating a clusterized string list for each segment, where the clusterized string list is an ordered list of clusterizers in each segment which can be compared in order to match between segments (i.e., two segments may match if the clusterized string lists of the segments match). The clusterized string lists may be utilized to determine cluster definitions, more specifically, by performing a multiple clusterizer test for segments including multiple clusterizers in addition to the per-clusterizer count tests discussed above.