Identifying credential attacks against encrypted network traffic

Abstract

Techniques are described that include a computer-implemented method of summing a number of authentication failures from multiple connection attempts of an application or service that serves multiple clients, where each authentication failure is detected by evaluating encrypted packets of the multiple connection attempts. The method further includes determining that the number of authentication failures is greater than an upper bound number of authentication failures, where the upper bound number of authentication failures is determined by an anomaly function that uses the multiple connection attempts as input, where the anomaly function is defined, at least in part, by the Chebyshev limit and the Chernoff limit. The method further includes generating an alert indicative of a potential credential attack on the application or service.

Description

[Technical Field]

[0001] The present disclosure relates to computer network security, and more particularly to identifying credential attacks without decrypting network traffic. [Background technology]

[0002] Credential attacks are a serious and growing security threat. One type of credential attack is credential stuffing, in which a malicious actor uses compromised usernames, email addresses, and / or passwords (e.g., from a data breach) to gain unauthorized access to user accounts through large-scale, automated login requests. Another type of credential attack is a brute-force credential attack (e.g., credential cracking), in which a malicious actor submits numerous combinations of guessed usernames, email addresses, and / or passwords in the hopes of eventually guessing correctly. Summary of the Invention

[0003] Aspects of the present disclosure are directed to a computer-implemented method for summing a number of authentication failures from multiple connection attempts of an application or service that serves multiple clients, where each authentication failure is detected by evaluating encrypted packets of the multiple connection attempts. The method further includes determining that the number of authentication failures is greater than an upper bound number of authentication failures, where the upper bound number of authentication failures is determined by an anomaly function that uses the multiple connection attempts as input, where the anomaly function is defined, at least in part, by the Chebyshev limit and the Chernoff limit. The method further includes generating an alert indicating a potential credential attack on the application or service.

[0004] Additional aspects of the present disclosure are directed to systems and computer program products configured to implement the aforementioned methods. This Summary is not intended to represent every aspect, every implementation, or every embodiment, or combination, of the present disclosure.

[0005] The drawings included in this application are incorporated into and form a part of this specification. These drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are merely illustrative of certain embodiments and do not limit the disclosure. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 illustrates a block diagram of an exemplary computing environment having a security system for detecting credential attacks on encrypted network traffic, in accordance with some embodiments of the present disclosure. [Figure 2A] 10 illustrates an exemplary decoded standard server response according to some embodiments of the present disclosure. [Figure 2B] 10 illustrates an exemplary encrypted standard server response according to some embodiments of the present disclosure. [Figure 3] 1 illustrates a flow diagram of an exemplary method for detecting credential attacks using encrypted network traffic, according to some embodiments of the present disclosure. [Figure 4] 10A-10C show graphs of anomalous functions including Chebyshev and Chernoff limits, in accordance with some embodiments of the present disclosure. [Figure 5] 10 shows a graph of an irregular function in step format, according to some embodiments of the present disclosure. [Figure 6] 1 illustrates a block diagram of an exemplary computer according to some embodiments of the present disclosure. [Figure 7] 1 illustrates a cloud computing environment according to some embodiments of the present disclosure. [Figure 8] 1 illustrates abstraction model layers according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0007] While the present disclosure is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the intention is not to limit the disclosure to the particular embodiments described. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure.

[0008] Aspects of the present disclosure are directed to computer network security, and more particularly to identifying credential attacks without decrypting network traffic. While not limited to such application, embodiments of the present disclosure may be better understood in light of the foregoing context.

[0009] Aspects of the present disclosure are directed to the on-the-fly detection of suspicious authentication behavior with a high degree of confidence. Aspects of the present disclosure can analyze encrypted network traffic, for example, between a client and a server or between a client and a cloud service. More specifically, aspects of the present disclosure can analyze the encrypted portion of authentication at the application protocol layer. Advantageously, aspects of the present disclosure can distinguish between failed and successful authentication attempts without decrypting any of the encrypted network traffic. As a result, sensitive information is never made available to the security system, thereby preserving the security of network traffic while enabling the detection of credential attacks.

[0010] Aspects of the present disclosure can utilize the Chernoff and Chebyshev limits to define an anomalous area that ties authentication failures (AFs) to the total number of authentication attempts. When the number of authentication failures relative to the total number of authentication attempts falls into the anomalous area as defined by the Chernoff and Chebyshev limits (e.g., when the observed number of authentication failures is greater than an upper bound number of authentication failures, indicating normal authentication failure behavior determined using the Chernoff and / or Chebyshev limits), the security system can signal a potential credential attack.

[0011] Referring now to FIG. 1, FIG. 1 illustrates a computer environment 100 having a security system 108 for detecting credential attacks on encrypted network traffic in accordance with some embodiments of the present disclosure. The computer environment 100 includes multiple client applications 102, such as client application 1 102-1, client application 2 102-2, and client application N 102-N, where N may be any integer and refer to any number of total client applications (e.g., several, tens, hundreds, thousands, etc.). The client applications 102 may interface with services 104 over an encrypted network 106. The services 104 may refer to virtual or physical servers that provide functionality (e.g., application functionality, cloud-based service functionality, etc.) to the client applications 102. However, the services 104 may require authentication with the client applications 102 to allow the client applications 102 to access the functionality provided by the services 104. As previously mentioned, a service 104 can be maliciously accessed using a credential attack, whereby a malicious actor accesses the service 104 using compromised credentials.

[0012] In some embodiments, the client application 102, the service 104, and / or the encrypted network 106 may represent computer interactions at the end-user protocol level or the application protocol level, such as Oracle® Net Message (TNS), Server Presentation Data Stream (TDS), Sybase® Command Sequence (CMDSEQ), Informix SQL Sequence (SQLSEQ), DB2® Distributed Relational Database Architecture (DRDA), MongoDB® wire protocol, MYSQL®, NEO4J®, etc.

[0013] Aspects of the present disclosure relate to a security system 108. The security system 108 intercepts encrypted network traffic on an encrypted network 106. The security system 108 can identify authentication failures 110 from the total number of connection attempts 112 in a predefined lookback window (e.g., duration, number of connection attempts, etc.). The authentication failures 110 can be distinguished from authentication successes based on characteristics of the encrypted packets intercepted from the encrypted network 106 (e.g., encrypted packet size, encrypted packet pattern, etc.). Furthermore, the security system 108 can identify the total number of connection attempts 112 (successful and unsuccessful) based on characteristics of the encrypted packets intercepted from the encrypted network 106 (e.g., encrypted packet size, encrypted packet pattern, socket open / close events, etc.). In some embodiments, the security system 108 can monitor connection socket open and close events to identify authentication failures. For example, a new connection opens a connection socket at the client and server. Thus, an open socket event can indicate a new connection, and closing a socket during the connection authentication handshake can indicate an authentication failure.

[0014] The security system 108 can use an anomaly function 114 to determine whether the authentication failures 110 and all connection attempts 112 indicate a potential credential attack. For example, the anomaly function 114 can receive the total connection attempts 112 as input and generate an upper bound number of authentication failures 116. The upper bound number of authentication failures 116 can represent a number of authentication failures above which a credential attack is indicated and below which normal authentication failure behavior is indicated. The upper bound number of authentication failures 116 can be compared to the authentication failures 110. If the number of authentication failures 110 is less than the upper bound number of authentication failures 116, then the security system 108 treats the authentication failures 110 and all connection attempts 112 as within normal operating conditions. On the other hand, if the number of authentication failures 110 is greater than the upper bound number of authentication failures 116, then the security system 108 can generate a warning indicating a potential credential attack involving the client application 102, the service 104, or both.

[0015] In some embodiments, the anomaly function 114 may be represented as a bounded area of ​​a graph relating the number of authentication failures 110 (e.g., on the y-axis) to the number of total connection attempts 112 (e.g., on the x-axis). In such embodiments, the security system 108 may compare the two-dimensional coordinates of the authentication failures 110 and total connection attempts 112 to a two-dimensional graph having an anomaly area defined, at least in part, by the anomaly function 114. If the two-dimensional coordinates of the authentication failures 110 and total connection attempts 112 fall within the anomaly area, then the security system 108 may issue a warning indicating a possible credential attack.

[0016] Those skilled in the art will appreciate that the configuration depicted in FIG. 1 is for illustrative purposes only and should not be construed as limiting. While, as one example, security system 108 is shown as separate from client application 102 and service 104, in some embodiments, security system 108 is a component of client application 102, service 104, or both. In other embodiments, security system 108 may be a standalone entity, although security system 108 may provide one or more agents, modules, or functionality, or a combination thereof, to service 104, client application 102, or both. In some embodiments, security system 108 is part of an Intrusion Detection System (IDS), an Intrusion Prevention System (IPS), a Security Information and Event Management (SIEM) system, or another security system, data protection platform, or monitoring system. In some embodiments, security system 108 is a component of Guardium®, a product of International Business Machines (IBM) Corporation.

[0017] 2A and 2B, an exemplary decrypted standard server response 200 and an exemplary encrypted standard server response 202 are shown as part of an authentication failure exchange between a client and a server. The decrypted standard server response 200 includes 118 bytes, while the encrypted standard server response includes 128 bytes (e.g., a 5-byte Transport Layer Security (TLS) header, a 118-byte body, and 5 bytes of padding). Aspects of the present disclosure recognize that authentication failures at the application protocol layer have several distinct characteristics that make them suitable for detection without decrypting the encrypted packets. First, authentication failures are limited to the first few packets exchanged between a client / server or client / cloud service. Second, the number of authentication failure network packets is the same for each connection type. Third, encrypted packets associated with authentication failures have a standard length with little variability. Fourth, the server / service authentication error response has a standard size. Fifth, the server / service closes the connection after sending the server / service authentication error response. Collectively, these properties make it possible to recognize authentication failures by observing the sequence and / or size of the first few packets during an authentication attempt.

[0018] This is readily observable by comparing Figures 2A and 2B. For example, as shown in Figure 2A, the decrypted standard server response 200 has a consistent presentation of information related to authentication failure. When comparing the encrypted standard server response 202 of Figure 2B with the decrypted standard server response 200 of Figure 2A, it becomes apparent that the standardized characteristics of the standard server response for authentication failures can enable aspects of the present disclosure to identify authentication failures even in encrypted network traffic. In some embodiments, for example, the security system 108 can determine that an authentication failure occurs if fewer than a predefined number of packets are exchanged between the client and server, the last recorded packet is sent from the server to the client, and the last recorded packet has a relatively short size. In other embodiments, the security system 108 can determine that an authentication failure occurs if no packets are exchanged between the client and server for a predefined period of time, and the last exchanged packet is from the server to the client and has a relatively short size. In some embodiments, a successful authentication attempt is determined when the number of packets exchanged between the client and server exceeds a threshold number.

[0019] These are merely examples of rules that may be used to distinguish successful authentication from unsuccessful authentication, but one skilled in the art will appreciate that similar or different rules or combinations of rules based on packet size, patterns in packet sequences, delays between packet exchanges, socket open / close events, etc. may be used to distinguish successful authentication from unsuccessful authentication depending on the authentication layer protocol.

[0020] 3, a flow diagram of an exemplary method 300 for detecting credential attacks using encrypted network traffic is shown, in accordance with some embodiments of the present disclosure. Method 300 may be implemented by security system 108 of FIG. 1, a computer, a server, a processor, or another configuration of hardware, software, or both.

[0021] Operation 302 includes intercepting a new network connection. The network connection may be, for example, between a client application 102 and a service 104 over an encrypted network 106. In some embodiments, the new network connection begins with, for example, an authentication or login attempt.

[0022] Operation 304 includes analyzing encrypted packets of the new network connection. In some embodiments, operation 304 includes analyzing encrypted packets of an application layer protocol connection handshake. In some embodiments, operation 304 analyzes the size of the encrypted packets, the sequence of the encrypted packets, the sender and receiver of the encrypted packets, socket open / close events, and / or the time between sent and received encrypted packets. Advantageously, operation 304 does not include any decryption of encrypted data, thereby protecting the security of sensitive information that may be transmitted during the application layer protocol connection handshake.

[0023] Operation 306 includes determining whether the new network connection is an authentication failure. As discussed in Figures 2A and 2B, aspects of the present disclosure can use standardized characteristics (e.g., size and / or pattern) of encrypted packets sent as part of an application layer protocol connection handshake to determine whether authentication was successful or failed.

[0024] If the new network connection does not result in an authentication failure (306: NO), then the new network connection is successful and the method 300 ends. If the new network connection results in an authentication failure (306: YES), then the method 300 proceeds to operation 308.

[0025] Operation 308 includes summing a total number (e.g., m) of authentication failures 110 and a total number (e.g., n) of network connection attempts 112. In some embodiments, operation 308 sums the number of authentication failures 110 and the total number of network connection attempts 112 from a lookback window, where the lookback window may include a predetermined number (e.g., 10, 50, 100, 1000, etc.) of total connection attempts 112.

[0026] Regardless of how operation 308 totals the number of authentication failures 110 and the total number of network connection attempts 112, a threshold number of previous network connections is selected to identify credential stuffing attacks with sufficient accuracy.

[0027] Operation 310 includes determining whether coordinate (m,n) (which references the total number (m) of authentication failures 110 and the total number (n) of connection attempts 112) is anomalous. In some embodiments, operation 310 includes comparing the number of authentication failures 110 to an upper bound number of authentication failures 116 generated by an anomaly function 114 (where the anomaly function 114 uses the total number (n) of connection attempts 112 as input). In graphical form, operation 310 may include determining whether coordinate (m,n) is within an anomaly area defined by the anomaly function 114.

[0028] If not (310: NO), then method 300 ends. If so (310: YES), then method 300 proceeds to operation 312. Operation 312 includes generating an alert indicating a credential attack. In some embodiments, operation 312 includes mitigating the detected credential attack. For example, in some embodiments, operation 312 may isolate service 104 or client application 102 from encrypted network 106 by terminating the connection, such as by implementing a customized firewall.

[0029] 4 illustrates a graph 400 of an anomaly area 404 in accordance with some embodiments of the present disclosure. In some embodiments, the graph 400 of the anomaly area 404 corresponds to the anomaly function 114 of FIG. 1. As shown in FIG. 4, the graph 400 of the anomaly area 404 illustrates the total number of connection attempts 112 (e.g., n) on the x-axis and the total number of authentication failures 110 (e.g., m) on the y-axis. The graph 400 of the anomaly area 404 is divided into a normal area 402 (indicating normal authentication attempt behavior) and an anomaly area 404 (indicating a possible credential attack). The anomaly area 404 has a functional limit 406 of m=n (e.g., every connection attempt is an authentication failure). Meanwhile, the upper bound 116 of authentication failures separating the anomalous area 404 (e.g., the anomalous function 114 that distinguishes the normal area 402 from the anomalous area 404) of each total number of connection attempts 112 from the normal area 402 is composed of two lines—the Chebyshev bound 408 and the Chernoff bound 410. Those skilled in the art will appreciate that the Chebyshev inequality (also known as the Bienaime-Chebyshev inequality) states that for various probability distributions, no more than a certain fraction of values ​​can be more than a predefined distance from the mean. Meanwhile, the Chernoff bound provides an exponentially decreasing bound on the tail distribution of a sum of independent random variables. Advantageously, the Chebyshev bound 408 and the Chernoff bound 410 provide improved accuracy in accurately identifying credential attacks from the total number of authentication failures 110 and the total number of connection attempts 112.

[0030] Any one or any combination of Chebyshev limit 408 and Chernoff limit 410 may be used to define an upper bound 116 of authentication failures for each count of connection attempts 112 that separates normal behavior (e.g., as represented by normal area 402) from anomalous behavior (e.g., as represented by anomalous area 404). For example, in some embodiments, the smaller of either limit may define the upper bound. In such embodiments, Chebyshev limit 408 may be an upper bound on the ratio of m / n below a threshold (e.g., of the n value before the intersection of Chebyshev limit 408 and Chernoff limit 410), and Chernoff limit 410 may be an upper bound on the ratio of m / n above a threshold (e.g., after the intersection of Chebyshev limit 408 and Chernoff limit 410). In other embodiments, the opposite is true, and a larger limit on either limit may define the upper bound. In yet other embodiments, Chebyshev limits 408 may be used for predefined n values ​​and Chernoff limits 410 may be used for other predefined n values. In such embodiments, Chebyshev limits 408 and Chernoff limits 410 may be used regardless of which limit is larger or smaller.

[0031] For clarity, aspects of the present disclosure will now be discussed mathematically: P is the probability of authentication failure, and P max Assume that is the maximum acceptable authentication failure probability. Accordingly, inequality (1) shows that there are no anomalous authentication failures: (1) P≦P max

[0032] We further assume that authentication attempts from client applications 102 to services 104 are random and independent. The Chernoff bound 410 can be expressed as inequality (2):

number

[0033] Regarding inequality (2), Pr may represent the probability of deviation, and m is the number of authentication failures 110 out of a total of n connections 112.

number

number

[0034] P r To define the confidence 1-δ in the estimation of , then the right-hand side of inequalities (2) and (2') is shown below as (3) and (3'):

number

number

[0035] The term δ can be a relatively small value approaching 0. Inequality (4) can be used to test inequality (1) as a statistical hypothesis:

number

[0036] To test the hypothesis of inequality (1), we use the precision

number

number

[0037] If at least one of (3) or (3') is true, then the probability of hypothesis (1) is as low as δ. Thus, with confidence 1-δ, the security system can identify the authentication failure as an anomaly (e.g., a possible credential attack). Inequalities (3) and (3') can be transformed into a format more suitable for defining the anomaly area 404 shown in (6) and (6'):

number

number

[0038] Using (5), (6), and (6′), m can be defined as a function of n (e.g., m=f(n)) for both the Chernoff limit 410 and the Chebyshev limit 408 as shown in (7) and (7′):

number

number

[0039] In some embodiments, the Chebyshev limits 408 may be defined according to (7') and the Chernoff limits 410 may be defined according to (7).

[0040] Equations (7) and (7′) can be combined to define a single upper bound that distinguishes between an abnormal amount of authentication failures (e.g., as represented by anomalous area 404) and a normal amount of authentication failures (e.g., as represented by normal area 402), as shown in (8):

number

[0041] In some embodiments, (8) is the irregular function 114. As shown in (8), if the observed m value is greater than the smaller of the Chebyshev bound 408 upper bound m value and the Chernoff bound 410 upper bound m value, then the observed m value may be identified as indicative of a possible credential attack. In other words, when (8) is true, the security system 108 may be configured to generate a warning indicative of a possible credential attack.

[0042] 5 illustrates an example graph 500 of a step-wise variation function, in accordance with some embodiments of the present disclosure. Similar to graph 400, graph 500 illustrates n (e.g., total connection attempts 112) on the x-axis and m (e.g., authentication failures 110) on the y-axis. In the example illustrated in graph 500, security system 108 is configured with a maximum allowable authentication failure probability of 0.05 (e.g., 5%). Furthermore, security system 108 may be configured to detect credential attacks with 90% confidence. In this example, the term P max = 0.05 and δ = 0.1. Graph 500 includes a normal area 502 (e.g., P ≦ 0.05) and an anomalous area 504 (e.g., P > 0.05). The anomalous area is defined by a functional constraint 506 (e.g., m = n) and an upper bound 508. In some embodiments, upper bound 508 may be defined according to the right-hand side of (8). As shown in graph 500, upper bound 508 may be stepped at predetermined intervals (e.g., to maintain an integer number) rather than a continuous (e.g., unbroken) line as shown in graph 400. However, in other embodiments, a continuous upper bound 508 may be used, and security system 108 may be configured to round up, down, or to the nearest integer as part of its evaluation of whether a given coordinate (m, n) falls within anomalous area 504 or normal area 502.

[0043] FIG. 6 illustrates a block diagram of an exemplary computer 600 according to some embodiments of the present disclosure. In various embodiments, computer 600 may perform any or all portions of the method described in FIG. 3 and / or implement functionality discussed in FIGS. 1-2 and / or 4-5. In some embodiments, computer 600 receives instructions related to the aforementioned methods and functionality by downloading processor-executable instructions from a remote data processing system via network 650. In other embodiments, computer 600 provides instructions for the aforementioned methods and / or functionality to a client machine, such that the client machine performs the method, or portions of the method, based on the instructions provided by computer 600. In some embodiments, computer 600 is incorporated into one or more entities illustrated in FIG. 1 and / or other aspects of the present disclosure (or functionality similar to computer 600 is virtually provided).

[0044] The computer 600 includes memory 625, storage 630, an interconnect 620 (e.g., a bus), one or more CPUs 605 (also referred to herein as processors), an I / O device interface 610, I / O devices 612, and a network interface 615.

[0045] Each CPU 605 retrieves and executes programming instructions stored in memory 625 or storage 630. Interconnect 620 is used to move data, e.g., programming instructions, between CPU 605, I / O device interface 610, storage 630, network interface 615, and memory 625. Interconnect 620 may be implemented using one or more buses. CPU 605, in various embodiments, may be a single CPU, multiple CPUs, or a single CPU with multiple processing cores. In some embodiments, CPU 605 may be a digital signal processor (DSP). In some embodiments, CPU 605 includes one or more 3D integrated circuits (3DICs) (e.g., 3D wafer-level packaging (3DWLP), 3D interposer-based integration, 3D stacked IC (3D-SIC), monolithic 3DIC, 3D heterogeneous integration, 3D system-in-package (3DSiP), or package-on-package (PoP) CPU configurations, or combinations thereof). Memory 625 is included generally to represent random access memory (e.g., static random access memory (SRAM), dynamic random access memory (DRAM), or flash). Storage 630 is included generally to represent non-volatile memory, such as a hard disk drive, solid state drive (SSD), removable memory card, optical storage, or flash memory device. In an alternative embodiment, storage 630 may be replaced by a storage area network (SAN) device, cloud, or other device connected to computer 600 via I / O device interface 610 or to network 650 via network interface 615.

[0046] In some embodiments, memory 625 stores instructions 660. However, in various embodiments, instructions 660 are stored partially in memory 625 and partially in storage 630, or instructions 660 are stored entirely in memory 625 or entirely in storage 630, or instructions 660 are accessed over network 650 via network interface 615.

[0047] The instructions 660 may be computer-readable and computer-executable instructions for performing any portion, or all, of the method of Figure 3, or may implement functionality discussed in Figures 1-2 or 4-5, or a combination thereof. Although the instructions 660 are shown in memory 625, the instructions 660 may include program instructions collectively stored across multiple computer-readable storage media and executable by one or more CPUs 605.

[0048] In various embodiments, I / O device 612 includes an interface capable of presenting information and receiving input. For example, I / O device 612 can present information to and receive input from a user interacting with computer 600.

[0049] Computer 600 is connected to network 650 via network interface 615. Network 650 may include physical, wireless, cellular, or different networks.

[0050] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings provided herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0051] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0052] Its features include:

[0053] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity (e.g., server time and network storage) automatically as needed without the need for human interaction with the service provider.

[0054] Broad Network Access: The capability is available over the network and is accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0055] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated according to demand. There is a sense of location independence in that consumers generally have no control or knowledge of the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0056] Rapid Elasticity: Capacity can be rapidly elastically provisioned, sometimes automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0057] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both providers and consumers of utilized services.

[0058] The service model is as follows:

[0059] Software as a Service (SaaS): The consumer is offered the ability to use the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0060] Platform as a Service (PaaS): The ability offered to the consumer is to deploy consumer-created or acquired applications written using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and sometimes the application hosting environment configuration.

[0061] Infrastructure as a Service (IaaS): The capability offered to consumers is the provision of processing, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating system, storage, deployed applications, and possibly limited control over select networking components (e.g., host firewalls).

[0062] The deployment models are as follows:

[0063] Private Cloud: The cloud infrastructure is operated solely for one organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0064] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0065] Public cloud: Cloud infrastructure is made available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0066] Hybrid Cloud: A cloud infrastructure is a composition of multiple clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0067] A cloud computing environment is a service oriented environment with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0068] Referring now to FIG. 7, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automotive computer system 54N, may communicate. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped in one or more networks, such as private, community, public, or hybrid clouds (not shown), as previously described, or a combination thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service without requiring cloud consumers to maintain resources on their local computing devices. It is understood that the types of computing devices 54A-N shown in FIG. 7 are intended to be illustrative only, and that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0069] Referring now to Figure 8, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 7) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 8 are intended to be merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0070] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0071] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71, virtual storage 72, underlying networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0072] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing of the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 83 provides consumer and system administrator access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides advance provisioning and procurement of cloud computing resources when future requirements are anticipated according to SLAs.

[0073] The workload layer 90 provides examples of functionality for which a cloud computing environment can be utilized. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analysis results processing 94, transaction processing 95, and credential attack detection using encrypted network data 96.

[0074] Embodiments of the present invention may be systems, methods, and / or computer program products, at any possible level of technical detail integration, including one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to implement aspects of the present invention.

[0075] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded on them, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as being a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0076] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical fiber transmission cables, wireless transmission cables, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0077] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages, e.g., the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to implement aspects of the present invention.

[0078] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0079] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute through the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular way, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0080] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process, such that the instructions, executing on the computer, other programmable apparatus, or other device, implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0081] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or subset of instructions, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a special-purpose hardware-based system that performs the specified functions or acts or a combination of special-purpose hardware and computer instructions.

[0082] It is understood that the process software (e.g., any software configured to perform any of the instructions stored in instructions 660 of FIG. 6 or any portion of the method described with respect to FIG. 3 or implement functionality discussed in FIGS. 1-2 and / or 4-5) can be deployed by manually loading it directly at the client, server, and proxy computers via loading a storage medium such as a CD or DVD, but the process software can also be automatically or semi-automatically deployed to computer systems by sending the process software to a central server or group of central servers. The process software is then downloaded to the client computers that will execute the process software. Alternatively, the process software is sent directly to the client systems via email. The process software is then isolated in a directory or loaded into the directory by executing a set of program instructions that isolates the process software in the directory. Another alternative is to send the process software directly to a directory on the client computer hard drive. If a proxy server is present, the process will select the proxy server code, determine on which computer to place the proxy server code, transmit the proxy server code, and then install the proxy server code on the proxy computer. The process software will be transmitted to the proxy server, and then it will be stored on the proxy server.

[0083] Embodiments of the invention may also be delivered as part of a services agreement with a client company, non-profit organization, government agency, internal organizational structure, etc. These embodiments may include configuring an implementing computer system and deploying software, hardware, and web services that implement some or all of the methods described herein. These embodiments may also include analyzing client behavior, making recommendations in response to the analysis, building a system that implements a subset of the recommendations, integrating the system into existing processes and infrastructure, metering usage of the system, allocating costs to users of the system, and billing, invoicing (e.g., generating invoices), or otherwise receiving payment for use of the system.

[0084] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit various embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "comprise" and / or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, or components or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups or combinations thereof. In the preceding detailed description of exemplary embodiments of various embodiments, reference has been made to the accompanying drawings (in which like numerals represent like elements), which form a part hereof, and in which like numerals represent like elements, shown by way of illustration specific exemplary embodiments in which various embodiments may be practiced. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the embodiments, but other embodiments may be used, and logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. In the foregoing description, numerous specific details have been set forth in order to provide a thorough understanding of the various embodiments. However, various embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the embodiments.

[0085] Different instances of the word "embodiment" as used herein do not necessarily refer to the same embodiment, but may. Any data and data structures shown and described herein are merely examples; in other embodiments, different amounts of data, types of data, fields, numbers and types of fields, field names, numbers and types of rows, records, entries, or data organization may be used. Furthermore, any data may be combined with logic such that separate data structures may not be required. Therefore, the foregoing detailed description should not be taken in a limiting sense.

[0086] The description of various embodiments of the present disclosure has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Numerous modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best explain the principles of the embodiments, practical applications, or technical improvements over technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0087] While the present disclosure has been described with respect to particular embodiments, it is anticipated that variations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted as including all such variations and modifications that are within the scope of the present disclosure.

[0088] Any advantages discussed in this disclosure are exemplary advantages, and there may be embodiments of the disclosure that achieve all, some, or none of the advantages discussed while remaining within the scope of the disclosure.

[0089] A non-limiting list of examples is provided below to describe some aspects of the present disclosure. Example 1 is a computer-implemented method. The method includes summing a number of authentication failures from multiple connection attempts of an application or service that provides services to multiple clients, where each authentication failure is detected by evaluating encrypted packets of the multiple connection attempts; determining that the number of authentication failures is greater than an upper bound number of authentication failures, where the upper bound number of authentication failures is determined by an anomaly function that uses the multiple connection attempts as input, where the anomaly function is defined, at least in part, by Chebyshev bound and Chernoff bound; and generating an alert indicating a potential credential attack on the application or service.

[0090] Example 2 includes the method of example 1, including or excluding optional features. In this example, each authentication failure is detected, at least in part, by evaluating encrypted packet sizes of the multiple connection attempts, sequence patterns of encrypted packets during the multiple connection attempts, or open / close socket events of the multiple connection attempts, or a combination thereof.

[0091] Example 3 includes any of the methods of examples 1-2, including or excluding optional features. In this example, the upper bound number of authentication failures is less than the Chebyshev limit and the Chernoff limit for multiple connection attempts.

[0092] Example 4 includes any of the methods of examples 1 to 3, including or excluding optional features. In this example, the step function is a step function that rounds each upper bound number of authentication failures for each number of connection attempts to an integer.

[0093] Example 5 includes any of the methods of examples 1 to 4, including or excluding optional features. In this example, the anomaly function uses Chebyshev limits for connection attempt values ​​below the intersection of the Chebyshev limits and the Chernoff limits, and wherein the anomaly function uses Chernoff limits for connection attempt values ​​above the intersection of the Chebyshev limits and the Chernoff limits.

[0094] Example 6 includes any of the methods of examples 1 through 5, including or excluding optional features. In this example, the summing of the number of authentication failures from multiple connection attempts occurs in real time.

[0095] Example 7 includes the method of example 6, with or without optional features. In this example, summing the number of authentication failures from multiple connection attempts uses a lookback window. Optionally, the lookback window is a number of connection attempts.

[0096] Example 8 includes any of the methods of Examples 1 to 7, including or excluding optional features. In this example, the method is performed by one or more computers in accordance with software downloaded to the one or more computers from a remote data processing system. Optionally, the method further includes: metering usage of the software; and generating invoices based on the usage measurements.

[0097] Example 9 is a system comprising one or more computer-readable storage media storing program instructions and one or more processors configured to perform a method according to any one of Examples 1 to 8 in response to executing the program instructions.

[0098] Example 10 is a computer program product that includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions including instructions configured to cause one or more processors to perform a method according to any one of Examples 1 to 8.

Claims

1. A method for information processing on a computer having one or more processors, said method comprising: summing a number of authentication failures from multiple connection attempts of an application or service that serves multiple clients, wherein each authentication failure is detected by evaluating encrypted packets of the multiple connection attempts; determining that the number of authentication failures is greater than an upper bound number of authentication failures, the upper bound number of authentication failures being determined by an anomaly function that uses the plurality of connection attempts as an input, the anomaly function being defined at least in part by Chebyshev bounds and Chernoff bounds; generating an alert indicating a potential credential attack on said application or said service; A method comprising:

2. 2. The method of claim 1, wherein the respective authentication failures are detected, at least in part, by evaluating sizes of the encrypted packets of the plurality of connection attempts, sequence patterns of the encrypted packets during the plurality of connection attempts, and open / close socket events of the plurality of connection attempts.

3. 2. The method of claim 1, wherein the upper bound number of authentication failures is the lesser of the Chebyshev limit and the Chernoff limit of the number of connection attempts.

4. 2. The method of claim 1, wherein the irregular function is a step function that rounds each upper bound number of authentication failures for each number of connection attempts to an integer.

5. 2. The method of claim 1, wherein the anomaly function uses the Chebyshev limits for connection attempt values ​​below the intersection of the Chebyshev limits and the Chernoff limits, and the anomaly function uses the Chernoff limits for connection attempt values ​​above the intersection of the Chebyshev limits and the Chernoff limits.

6. The method of claim 1 , wherein the summing of the number of authentication failures from the multiple connection attempts occurs in real time.

7. The method of claim 6 , wherein the summing of the number of authentication failures from the plurality of connection attempts uses a look-back window.

8. The method of claim 7 , wherein the lookback window is a number of connection attempts.

9. 10. The method of claim 1, wherein the method is performed by one or more computers in accordance with software downloaded to the one or more computers from a remote data processing system.

10. Measuring usage of the software; generating an invoice based on the usage measurements; 10. The method of claim 9, further comprising:

11. one or more computer-readable storage media storing program instructions; summing a number of authentication failures from multiple connection attempts of an application or service that serves multiple clients, wherein each authentication failure is detected by evaluating encrypted packets of the multiple connection attempts; determining that the number of authentication failures is greater than an upper bound number of authentication failures, the upper bound number of authentication failures being determined by an anomaly function that uses the plurality of connection attempts as an input, the anomaly function being defined at least in part by Chebyshev bounds and Chernoff bounds; generating an alert indicating a potential credential attack on said application or said service; one or more processors configured to perform, in response to executing the program instructions, a method comprising: A system comprising:

12. 12. The system of claim 11, wherein the respective authentication failures are detected, at least in part, by evaluating sizes of the encrypted packets of the plurality of connection attempts, sequence patterns of the encrypted packets during the plurality of connection attempts, and open / close socket events of the plurality of connection attempts.

13. 12. The system of claim 11, wherein the upper bound number of authentication failures is the lesser of the Chebyshev limit and the Chernoff limit of the number of connection attempts.

14. 12. The system of claim 11, wherein the irregular function is a step function that rounds each upper bound number of authentication failures for each number of connection attempts to an integer.

15. 12. The system of claim 11, wherein the irregularity function uses the Chebyshev limits for connection attempt values ​​below the intersection of the Chebyshev limits and the Chernoff limits, and the irregularity function uses the Chernoff limits for connection attempt values ​​above the intersection of the Chebyshev limits and the Chernoff limits.

16. 1. A computer program product comprising one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the computer program product comprising: summing a number of authentication failures from multiple connection attempts of an application or service that serves multiple clients, wherein each authentication failure is detected by evaluating encrypted packets of the multiple connection attempts; determining that the number of authentication failures is greater than an upper bound number of authentication failures, the upper bound number of authentication failures being determined by an anomaly function that uses the plurality of connection attempts as an input, the anomaly function being defined at least in part by Chebyshev bounds and Chernoff bounds; generating an alert indicating a potential credential attack on said application or said service; A computer program product that causes one or more processors to perform a method comprising:

17. 17. The computer program product of claim 16, wherein the respective authentication failures are detected, at least in part, by evaluating sizes of the encrypted packets of the plurality of connection attempts, sequence patterns of the encrypted packets during the plurality of connection attempts, and open / close socket events of the plurality of connection attempts.

18. 17. The computer program product of claim 16, wherein the upper bound number of authentication failures is the lesser of the Chebyshev limit and the Chernoff limit of the number of connection attempts.

19. 17. The computer program product of claim 16, wherein the irregular function is a step function that rounds each upper bound number of authentication failures for each number of connection attempts to an integer.

20. 17. The computer program product of claim 16, wherein the irregularity function uses the Chebyshev limits for connection attempt values ​​below an intersection of the Chebyshev limits and the Chernoff limits, and the irregularity function uses the Chernoff limits for connection attempt values ​​above the intersection of the Chebyshev limits and the Chernoff limits.

Images