Adaptive Profiling of Cloud Services Using Machine Learning for Malware Detection

A cloud-service malware detection application detects, in real time or in near real time, malware infecting cloud services. The cloud-service malware detection application monitors incoming communications, outgoing communications, API calls, and other inter-service activities conducted between different cloud services in a cloud-computing environment. Because the cloud-computing environment may have many different cloud services, the cloud-service malware detection application detects a malware attack that spans multiple hosts and cloud services. The cloud-service malware detection application adaptively profiles each individual cloud service using machine learning, thus providing quicker, more accurate, and more scalable malware detection.

BACKGROUND

The subject matter described herein generally relates to computers, to computer security, and to computer network security and, more particularly, the subject matter relates to cyber-security adaptive profiling of distributed cloud-native services.

Cloud services are vulnerable to malicious threats. In the past, cloud environments were generally believed more resilient to cyber threats. Recently, though, cloud environments have been found to be equally prone to malware infections. Even though cloud services providers may quickly identify and remove malicious content, attackers exploit any short window of opportunity. Techniques are thus needed that detect evidence of malware in cloud services.

SUMMARY

A cloud-service malware detection application infers, in real time or in near real time, evidence of cloud malware infecting cloud services. The cloud-service malware detection application provides security by monitoring incoming communications, outgoing communications, API calls, and other inter-service activities conducted between cloud services in a cloud-computing environment. Because the cloud-computing environment may have many different cloud services implemented as bare metal machines, virtual machines, containers, and/or functions, the cloud-service malware detection application detects service anomalies as evidence of malicious events that span multiple hosts and cloud services. The cloud-service malware detection application automatically and individually profiles each cloud service, thus providing quicker, more accurate, and more scalable malware detection.

DETAILED DESCRIPTION

Some examples relate to adaptive profiling of cloud services using machine learning. As cloud computing has grown, threat actors now target cyberattacks to cloud services. Cloud malware exploits a vulnerability associated with a cloud service. Examples of a cloud-service malware detection application thus monitor any cloud service and detect service anomalies as evidence of malware. A service behavioral profile is generated by a machine learning model. The service behavioral profile describes or represents normal operations of the cloud service. In some examples, the cloud-service malware detection application monitors any contemporaneous incoming communications, outgoing communications, API calls, and other inter-service activities conducted between computers, virtual machines, containers, and/or functions providing cloud services. Any inter-service activity may then be compared to the service behavioral profile. If the inter-service activity matches or conforms to the service behavioral profile, then the inter-service activity may be considered or inferred to be one normal operations of the cloud service. If, however, the inter-service activity deviates from, or fails to conform to, the service behavioral profile, then some examples may classify or infer the inter-service activity to be abnormal or unexpected service activity. The cloud-service malware detection application may flag the inter-service activity as potential evidence of cloud malware. Alerts, escalations, and other threat procedures may be implemented that protect the cloud service.

Example techniques may be implemented as a third party cloud service in any cloud-computing environment. Today's cloud-computing networks may have hundreds, or even thousands, of different and distributed, cloud services. Some examples thus also describe a third party cloud malware detection service that profiles/characterizes each different cloud service. The cloud malware detection service may be called or invoked by other cloud services in the cloud-computing environment. The cloud malware detection service identifies and trains a service-specific machine learning model using inter-service activities representing normal or expected service activities of each corresponding cloud service. Once trained, then, the cloud malware detection service specifically detects service anomalies as evidence of any malware targeted to the corresponding cloud service. So, even though examples of the cloud malware detection service may be deployed as a network cloud malware detection resource, the cloud malware detection service provides individualized, service-specific malware detection. The cloud malware detection service may thus be deployed throughout any cloud-computing environment with little or no custom coding or implementation. The cloud malware detection service is thus agnostic to the cloud service, thus quickly adapting and implementing cloud service-specific malware detection.

Examples of malware detection are easily implemented. Whatever the cloud service, any machine learning model may be used. Sample data points, or features, of normal or expected inter-service activities may be fed as inputs to the desired machine learning model. In some examples, the machine learning model may generate statistical ranges or values of these normal or expected inter-service activities. Should any contemporaneous incoming communications, outgoing communications, API calls, and other inter-service activities lie outside statistical models, then potential evidence of cloud malware has been detected and threat procedures may be implemented.

Cloud services malware detection will now be described more fully hereinafter with reference to the accompanying drawings. Cloud services malware detection, however, may be embodied in many different forms and should not be construed as limited to the examples set forth herein. These examples are provided so that this disclosure will be thorough and complete and fully convey cloud services malware detection to those of ordinary skill in the art. Moreover, all the examples of cloud services malware detection are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

FIGS.1-5illustrate some examples of inferring cloud malware20in a cloud-computing environment22. A computer24operates in the cloud-computing environment22.FIG.1illustrates the computer24as a server26. The computer24, though, may be any processor-controlled device, as later paragraphs will explain. In this example, the server26communicates via a communications network28(e.g., public Internet, private network, and/or hybrid network) with other servers, devices, computers, or other network members30operating within, or affiliated with, the cloud-computing environment22. The server26is programmed to provide one or more cloud services32to the network members30of the cloud-computing environment22. The server26thus has a hardware processor34(illustrated as “CPU”) that executes a cloud-native service application36stored in a memory device38. The cloud-native service application36may be a computer program, instruction(s), or code that instructs or causes the server26to provide the cloud service32, perhaps on demand, on behalf of a service provider40. The cloud-native service application36may be executed by, or associated with, a virtual machine42. The cloud-native service application36, in particular, may be packaged as an isolated container44that contains all of the necessary elements to provide the cloud service32. The cloud-native service application36, for simplicity, is thus known as a containerized service32and44. The cloud-computing environment22delivers hosted cloud-native services, like storage, servers, and application services, via the communications network28(such as the Internet). Various implementations of a cloud-computing environment22are possible and could be used in the examples herein described.

The cloud malware20may infect the cloud-computing environment22. The cloud malware20exploits a vulnerability associated with the cloud service32. As a simple example, suppose that the cloud service32runs as the container44in the distributed AMAZON® Web Services platform. If any electronic data stored in an AMAZON SIMPLE STORAGE SERVICE® (or “AMAZON S3®”) storage container bucket gets compromised, the cloud service32could be commanded to setup a malicious AWS LAMBDA® service. This malicious service may copy and steal the electronic data from the AMAZON S3 ® storage container bucket and exfiltrate the electronic data to an unauthorized network destination. The cloud malware20may thus cause a security breach that threatens the accuracy/confidentiality/integrity of the cloud service32. The cloud malware20may further jeopardize the performance and functioning of the hardware processor34and the memory device38. Simply put, the cloud service32must be monitored against attacks by the malicious cloud malware20.

FIG.1thus illustrates an example of a cloud-service malware detection application50. The cloud-service malware detection application50detects, in real time or in near real time, anomalies as evidence of the cloud malware20. In this simple example,FIG.1illustrates the cloud-service malware detection application50installed to, and locally stored by, the server26. The cloud-service malware detection application50may be integrated into the container44that packages the cloud service32. However, the cloud-service malware detection application50may be implemented as its own containerized cloud malware detection service. Regardless, in this example, the cloud-service malware detection application50interfaces with, and perhaps supervises, the cloud-native service application36. The cloud-service malware detection application50monitors any events, communications, and activities associated with the cloud service32. The cloud-service malware detection application50, in particular, monitors and approves/denies inter-service activities52conducted by the container44(e.g., the cloud-native service application36providing the cloud service32). If the inter-service activities52indicate evidence of the cloud malware20, the cloud-service malware detection application50may automatically implement notification/quarantine/isolation/halt or other threat procedures54that protect the server26and the cloud-computing environment22.

FIGS.2-4further illustrate examples of cloud services malware detection. An example of the cloud-service malware detection application50uses a service behavioral profile56to detect the cloud malware20. AsFIG.2illustrates, the service behavioral profile56is automatically and autonomously generated by a machine learning model58that interfaces with, or is integrated with, the cloud-service malware detection application50. The cloud-service malware detection application50may monitor the contemporaneous inter-service activities52conducted by the cloud-native service application36providing the cloud service32. InFIG.3, for example, the cloud-service malware detection application50monitors the inter-service activities52conducted between different containers (illustrated as reference numerals44aand44b) that are co-hosted by the server26. InFIG.4, though, the cloud-service malware detection application50monitors the inter-service activities52conducted (via the communications network28illustrated inFIG.1) between different containers44aand44chosted by different network nodal members (illustrated as servers26and60). The cloud-service malware detection application50may thus monitor and supervise the inter-container activities53conducted between different containerized services32and44. Whatever the containerized architecture, the cloud-service malware detection application50compares any inter-service activity52to the service behavioral profile56. If the inter-service activity52matches or conforms to the service behavioral profile56, then the cloud-service malware detection application50may permit or allow the inter-service activity52to continue or to execute. The inter-service activity52, in other words, may be classified as normal or expected service activity62conducted while providing the cloud service32. If, however, the cloud-service malware detection application50determines that the inter-service activity52deviates from, or fails to match, the service behavioral profile56, then the cloud-service malware detection application50may classify the inter-service activity52as an anomaly or unexpected service activity64. The cloud-service malware detection application50, in other words, may flag the inter-service activity52as potential evidence of the cloud malware20. The cloud-service malware detection application50may thus generate and send a malware alert notification66to any notification addresses that initiate further investigation. The cloud-service malware detection application50may also implement the predefined threat procedures54that protect the cloud-computing environment22.

Any threat notification scheme may be used. When the cloud-service malware detection application50detects the cloud malware20, the cloud-service malware detection application50may implement the threat procedures54. The cloud-service malware detection application50, for example, may instruct its host machine (such as the server26) to generate and to send the malware alert notification66to predefined notification addresses. The malware alert notification66may be any message, webpage/website/social posting, and/or SMS text. Whatever the notification method, the malware alert notification66may have any electronic content describing the inter-service activity52(such as the inter-container activity53) that is the suspected cloud malware20. The cloud-service malware detection application50may be programmed or coded to include far more detailed escalation actions. For simplicity, though,FIG.4illustrates a procedural hand-off to a threat resolution system that is more specifically programmed to inspect or resolve the cloud malware20.

Other actions may be implemented. When the cloud-service malware detection application50detects evidence of any malicious event (e.g., the cloud malware20), operations may be implemented or executed that quarantine the cloud service36. Operations may additionally or alternatively include quarantining the host machine (such as the server26). Operations may additionally or alternatively include terminating the container44(e.g., the cloud-native service application36providing the cloud service32). Service orchestration software may additionally or alternatively be instructed or commanded to remove the container44from the cloud computing environment22. Because evidence of the cloud malware20has been detected, any actions may be implemented that isolate the offending cloud service36to protect the cloud computing environment22.

FIG.5further illustrates examples of quickly detecting the cloud malware20. The cloud-service malware detection application50may initially train the machine learning model58to recognize, or to predict, many different features or indicators of the normal or expected service activities62. In these examples, the machine learning model58may be trained with cloud service training data70representing the normal or expected service activities62. The cloud service training data70describes actual, known, and/or normal activities that should be, or have been, conducted by the cloud-native service application36providing the cloud service32. The cloud service training data70may be extracted from actual samples, attributes, calls, events, parameters, and/or ranges of values that have been historically observed/logged as uncorrupted or unaffected by the cloud malware20. The cloud service training data70is input to the machine learning model58, and the machine learning model58learns and builds one or more statistical models that describe, expand, and/or predict the normal or expected service activities62conducted by the cloud-native service application36. The cloud-service malware detection application50, in other words, may autonomously and automatically generate the cloud-service behavioral profile56that describes, or characterizes, the inter-service activities52conducted by the cloud-native service application36. The cloud-service malware detection application50may monitor the contemporaneous inter-service activities52conducted by the cloud-native service application36. The cloud-service malware detection application50may then compare the contemporaneous inter-service activities52to the cloud-service behavioral profile56. Any contemporaneous inter-service activity52that conforms to the cloud-service behavioral profile56may be quickly permitted/allowed to execute or proceed.

Predictions may be made. Because the machine learning model58may build a statistical model, the machine learning model58may statistically predict a range of the normal or expected service activities62. As a simple example, the machine learning model58may generate the cloud-service behavioral profile56using Gaussian probability distributions based on the cloud service training data70. One or more standard deviations and confidence intervals may then be calculated to predict ranges of the normal or expected service activities62. As the cloud-service malware detection application50inspects the inter-service activities52, the statistical models may be used to predict that any inter-service activity52lies within, or deviates or differs from, the cloud-service behavioral profile56. The cloud-service malware detection application50may thus classify the inter-service activity52as the abnormal or unexpected service activity64and, thus, the suspected cloud malware20. The cloud-service malware detection application50may then cause the cloud-native service application36, and/or the server26, to nearly instantaneously stop/halt/terminate the offending inter-service activity52. Indeed, the cloud-service malware detection application50may even disable the entire cloud service32. The cloud-service malware detection application50may further generate the malware alert notification66that is sent (via the communications network28) to any destination/recipient network address. The cloud-service malware detection application50thus autonomously and quickly protects the cloud-computing environment22from the cloud malware20.

The cloud-service malware detection application50provides many improvements to computer functioning. The cloud-service behavioral profile56, for example, is autonomously and automatically generated by the cloud-service malware detection application50invoking the machine learning model58. Conventional malware detection solutions use manually-generated profiles that are exceptionally laborious to create and slow to implement. Manually-generated profiles, in plain words, are simply too complicated to humanly complete, as hundreds or even thousands of rules must be coded. In practice, then, manually-generated profiles are too simple and incomplete, thus causing conventional malware detection products to under catch, or over catch, the cloud malware20. Moreover, conventional malware detection schemes train machine learning models with threat data. That is, conventional schemes train machine learning models to identity or predict malware using known, previously discovered vulnerability traits. These conventional schemes, in other words, fail to detect new or unknown vulnerabilities that can wreak havoc on the cloud service32. The conventional schemes must also repeatedly retrain the machine learning models to recognize the latest-discovered threat. The cloud-service malware detection application50, in contradistinction, trains the machine learning model58with the normal or expected service activities62conducted by the cloud-native service application36. If any inter-service activity52deviates from the cloud-service behavioral profile56, the inter-service activity52may be immediately classified as suspicious and flagged as the cloud malware20. The cloud-service malware detection application50thus need not have a priori knowledge of any event or activity caused by any threat. The cloud-service malware detection application50maintains the accuracy/integrity of the cloud service32, and the cloud-service malware detection application50prevents malware-degraded hardware and memory performance of the computer24.

FIGS.6-8illustrate more examples of containerized architectures.FIG.6, for example, illustrates a container-integration approach to malware detection. The cloud-service malware detection application50, in other words, may be integrated with the container44that packages the cloud-native service application36providing the cloud service32. The cloud-service malware detection application50, in particular, may be installed into, inserted into, added to, or imported into the container44that packages or contains the cloud-native service application36providing the cloud service32. The service provider40(of the cloud service32) codes the cloud-service malware detection application50into the cloud-native service application36. The cloud-service malware detection application50receives or intercepts the inter-service activities52and processes according to the service behavioral profile56. The service provider40may thus manage the lifecycle of the cloud service32, including the cloud-service malware detection application50.

FIGS.7-8, though, illustrate examples of hosted service solutions. The cloud-service malware detection application50may be packaged as its own malware detection container80providing a cloud malware detection service82. The cloud-service malware detection application50may be packaged to contain all of its necessary elements to provide the cloud malware detection service82. The malware detection container80, for example, packages the service behavioral profile56generated by the machine learning model58based on the normal service activities62. When evidence of the cloud malware20is determined/predicted, the malware detection container80may also package the code generating the malware alert notification66and other threat procedures54. InFIG.7, the malware detection container80(providing the cloud malware detection service82) may be co-hosted by the server26that also hosts the different cloud service32. InFIG.8. though, the malware detection container80is hosted by the different network member30(illustrated as the server60) operating within, or affiliated with, the cloud-computing environment22. The cloud-service malware detection application50, packaged as the malware detection container80, may be separate/remote network resource/service that may be invoked by any network member30of the cloud-computing environment22.

A detection agent84may inform the malware detection container80. The detection agent84cooperates with the cloud-native service application36providing the cloud service32. The detection agent84may have code or instructions that cause the server26, and/or the cloud-native service application36(providing the cloud service32), to read or intercept the inter-service activities52(such as the inter-container activities53) conducted by the container44. The service provider40may install or add the detection agent84to an operating system executed by the server26. The service provider40may additionally or alternatively install or add the detection agent84to the cloud-native service application36providing the cloud service32. The malware detection container80may expose its application programming interfaces (“APIs”)86for calling/requesting the cloud malware detection service82. The detection agent84invokes the APIs86and may instruct or cause its host server26to send or transfer the inter-service activities52(via the communications network28illustrated inFIG.1) to the network IP address representing the malware detection container80, the cloud malware detection service82, and/or the cloud-service malware detection application50. The detection agent84, in plain words, may send a request specifying the cloud malware detection service82based on the inter-service activities52. The malware detection container80may provide the cloud malware detection service82. If evidence of the cloud malware20is detected, the cloud-service malware detection application50may send the malware alert notification66and may implement the threat procedures54.

FIGS.9A-9Billustrate more examples of containerized services architectures. The cloud-computing environment22may have many, perhaps even hundreds, of different and distributed, containerized cloud services32. Such a complicated architecture is too difficult to illustrate.FIG.9A, then, simply illustrates four (4) network members30a-dproviding their corresponding containerized cloud services32a-dand44a-d. InFIG.9A, network member30a, in particular, hosts the malware detection container80providing the cloud malware detection service82.

InFIG.9B, though, the cloud malware detection service82may utilize multiple malware detection containers (illustrated as reference numerals80a-c). Because the cloud-computing environment22may implement many hundreds or more of distributed, containerized cloud services32, such a large service architecture may overwhelm the performance capabilities of a single malware detection container80. Indeed, packet congestion, network delays, and timing/performance objectives may require the installation of multiple and distributed malware detection containers80a-cto adequately serve the needs of the cloud-computing environment22.

The cloud malware detection service82monitors the cloud services32. The network members30b-dmay each store and execute an instance of the detection agent84. Each instance of the detection agent84may instruct the corresponding network member30b-dto invoke the APIs86and to report its corresponding inter-service/inter-container activities52b-dand53b-d(via the communications network28illustrated inFIG.1) to the network IP address associated with the malware detection container80providing the cloud malware detection service82. The malware detection container80provides the cloud malware detection service82, based on the corresponding service behavioral profile56b-dthat is associated with the containerized cloud service32b-d. Each containerized cloud service32b-d, in other words, may have its unique service behavioral profile56b-d, generated based on historical observations of the corresponding normal service activity62b-d. Indeed, the cloud malware detection service82may be configured to utilize different machine learning models58b-dthat are predetermined or pre-selected according to the containerized cloud service32b-d. The cloud malware detection service82may thus be trained to detect different cloud malware20b-d, again depending on the corresponding containerized cloud service32b-d. The cloud malware detection service82may be additionally configured with different malware alert notifications66b-dand different threat procedures54b-d, again depending on the corresponding containerized cloud service32b-d. The cloud malware detection service82may thus be customized according to the containerized cloud service32b-d.

FIGS.10-11illustrate examples of the inter-service activities52that may be monitored by the cloud-service malware detection application50and/or the cloud malware detection service82. The cloud-computing environment22may provide thousands or even millions of distributed containers44, with each different container44specializing in a corresponding cloud service32. Each container44may package a single function that performs a specific task (sometimes referred to as a “microservice”). Large, complicated software applications may thus be broken up into much smaller, and more specialized, cloud services32. As this disclosure above explained, though, such a complicated architecture is too difficult to illustrate.FIGS.10-11thus simply illustrate two (2) containerized services32/44and80/82. Whatever cloud service32is provided by the container44, the detection agent84may report the corresponding inter-service activities52and/or the inter-container activities53(via the communications network28illustrated inFIG.1) to the network IP address representing the malware detection container80packaging the cloud malware detection service82. The detection agent84may request the cloud malware detection service82using the APIs86, as above explained.

AsFIG.10illustrates, the inter-service activities52may include network connections90. As the containerized cloud service32operates, the cloud-service malware detection application50may monitor and inspect the incoming/outgoing inter-service/inter-container activities52and/or53conducted to/from the container44. For example, each container44is assigned to, and associated with, a unique cloud service identifier92and an Internet Protocol address94. As the containerized cloud service32and44operates, communications are established with other containers and services. The hosting network member30, the cloud service32, and/or the detection agent84may report the network connections90, the service identifiers92, and/or the Internet Protocol addresses94to the malware detection container80packaging the cloud malware detection service82. The cloud-service malware detection application50may inspect one, some, or all of these inter-service activities52and identify or classify the corresponding cloud service32. The cloud-service malware detection application50may read, or generate, logs describing input data sent to other containers44, output data received from other containers44, their corresponding Internet Protocol addresses94, and/or cloud service identifiers92. The cloud-service malware detection application50may read or log inter-container and/or inter-host requests, responses, replies, events, activities, their corresponding Internet Protocol addresses94, and/or cloud service identifiers92. The cloud-service malware detection application50may query and retrieve these inter-container Internet Protocol addresses94and cloud service identifiers92from cloud configuration data96provided by AWS®, GOOGLE®, MICROSOFT®, or any other cloud-service provider hosting the cloud-computing environment22. Because the container44is configured to talk to incoming and to outgoing external container services, the cloud-service malware detection application50may identify the external container44by reading the cloud configuration data96describing inter-container communications.

The network connections90allow identity inferences. The network connections90, for example, allow the cloud-service malware detection application50to distinguish between an IP address for an object store API, an IP address of a local host, and an IP address of a computer on a network. Furthermore, the cloud-service malware detection application50may distinguish between an internal application or a public IP address. The Internet Protocol address94and cloud service identifier92may even quickly and easily identify other categories of services (such as a SALESFORCE® API or a SLACK® messaging service). The cloud-service malware detection application50may identify and/or classify the cloud service identifier92by monitoring the inter-service network connections90between the different containers44and the cloud services32. Any method or network data may be used to infer service identities.

The cloud-service malware detection application50may also identify a service topology98. The cloud-service malware detection application50may consult public/private domain name service (DNS) records to further identify and classify the cloud service identifier92. For example, once any IP address is determined (such as the IP address94assigned to the container44), the cloud-service malware detection application50may query a DNS database lookup and identify, retrieve, or infer the corresponding URL domain, cloud service32, and/or service provider40. The DNS records may thus quickly and easily further reveal the service topology98attempted by any container44. As another example, cloud service providers publish ranges of IP addresses that correspond to cloud services32. These ranges of IP addresses may be retrieved and compared to the IP address94assigned to the container44, thus identifying the cloud service32and/or service provider40. As yet another example, Internet Protocol reputations99may be retrieved and used to identify IP addresses associated with bulk spam, malware, dangerous domains, or suspicious locations (e.g., poor IP reputations). Again, though, any method or network data may be used to infer service identities.

FIG.11illustrates more examples of the inter-service activities52. The cloud-service malware detection application50may generate and monitor an API resource identification100. Again, the cloud-computing environment22may deploy thousands or even millions of different containers44, with each container44providing a corresponding cloud micro-service32. Each container44may thus be associated with application programming interfaces (or “APIs”) that defines protocols for using the native cloud service32provided by the container44. The hosting network member30, the cloud service32, and/or the detection agent84may report incoming and outgoing API calls102to the malware detection container80packaging the cloud malware detection service82. By analyzing the incoming and outgoing API calls102made by the cloud service32, the API resource identification100reveals the web resource104called by the cloud service32and the service provider40.

The cloud-service malware detection application50may thus generate and monitor a runtime network instrumentation106. The cloud-service malware detection application50may generate the runtime network instrumentation106by identifying the API call102and by accessing and using publicly-available details about the API call102. For example, suppose that the container44(e.g., the cloud-native service application36) issues an HTTP REST API call102. Because the packet headers in the HTTP portion are visibly available, the cloud-service malware detection application50may read the HTTP portion and identify the URL hosting the API resource. The IP reputation99associated with the URL host may identify malicious threat actors. Furthermore, using deep packet inspection of the inter-container HTTP traffic with the URL host, the cloud-service malware detection application50may identify that the container44is communicating with the particular web resource104(such as SALESFORCE®) and making a modification to the web resource104. As another example, encrypted network traffic may also be inspected and identified. The detection agent84may inspect packet headers in HTTPS traffic (such as by using the extended Berkeley Packet Filter or eBPF) to extract and identify security observability data. In other words, the cloud-service malware detection application50may obtain fine-grained details of the API call102and determine the API resource identification100, even from encrypted traffic. The API resource identification100may thus reveal the cloud malware20attempting a rogue resource modification.

The cloud-service malware detection application50may encode other information. The cloud-service malware detection application50may be programmed to include details regarding all, some, or commonly used API calls102. These API details allow the cloud-service malware detection application50to distinguish between different API calls102(such as REST API call from a Graph QL call). Amazon's AWS®, for example, offers hundreds of different API calls102. The cloud-service malware detection application50may be coded to include fine details regarding all, or a popular or common subset, of these AWS® API calls102. These fine details may be retrieved from the cloud configuration data96(such as Amazon's AWS® specification) and provide a deep knowledge of the resource exposed by the API call102. These fine details, for example, may reveal a name108, an object110, and an action112associated with the API call102. These fine details may be incorporated into the API resource identification100, thus providing a rich-data description of the inter-container API calls102associated with the container44providing the cloud service32.

The cloud-service malware detection application50may generate a resource action identification114. The cloud-service malware detection application50may generate the resource action identification114by semantically translating the action112(revealed by the API resource identification100) using a context116. As a very simple example, suppose the action112associated with the API call102is defined by the word “create.” Using the fine details describing the API call102(perhaps obtained from Amazon's, Google's, or Microsoft's cloud-computing service specification), the cloud-service malware detection application50may identify the API call102as a creation of a resource from its context116. If the context116is an AMAZON S3 ® bucket, the resource action identification114identifies the corresponding semantics and a single action112. If, however, the context116is a SALESFORCE® service, then the context116may have different semantics. The resource action identification114, as constructed perhaps over time and usage, is a rich glossary of semantics associated with API calls102and their corresponding name108, object110, and action112.

The cloud-service malware detection application50greatly improves cloud services malware detection. The cloud-service malware detection application50may define the machine learning model58to identify anomalies from inter-container and inter-host network traffic logs that provide service level details. The cloud-service malware detection application50thus need not have a priori knowledge of any threat event or activity. The cloud-service malware detection application50may use statistical approaches to identify anomalies for any cloud service32. The normal service activities62may be defined based on the historical service logs, and the features or indicators of the normal service activities62may be defined in terms of the service identifiers92and their inter-service/inter-container/inter-host interactions without looking into the operations performed. The cloud-service malware detection application50may thus train the machine learning model58to identify anomalies using the features or indicators of the normal service activities62. The cloud-service malware detection application50may then be deployed per-container44, and/or per-service32, for monitored cloud services32. Each container/service instance of the cloud-service malware detection application50gets differently trained to identify container-specific/service-specific anomalies (or threats). The cloud-service malware detection application50may thus generate the unique service behavioral profile56for each distributed cloud service32. Because the cloud-service malware detection application50may use statistical approaches, the cloud-service malware detection application50may statistically predict if a cloud service operation (in terms of the service identity92) is considered anomalous. Once any anomaly is detected, the cloud-service malware detection application50may flag the potential cloud malware20, generate the malware alert notification66, and/or alert downstream services for further investigation and/or response actions. The cloud-service malware detection application50may thus be a very workload-focused solution to detect threats. The cloud-service malware detection application50resolves the conventional problem of scale, as customers need not manually create and validate profiles. The cloud-service malware detection application50detects threats in terms of the high level entities (such as the above example of the malicious AWS LAMBDA® function). The cloud-service malware detection application50may apply machine learning and statistical modeling to individual cloud-native services based on service identities in the context of containerized applications. The cloud-service malware detection application50, however, may also apply machine learning and statistical modeling to non-containerized cloud services/applications.

The cloud-service malware detection application50provides more improvements to computer functioning. The cloud-service malware detection application50provides malware protection to distributed cloud-native computing services. The cloud-service malware detection application50predicts the cloud malware20by detecting anomalous inter-service activities52conducted between different containerized services32and even by different inter-host network members30. The cloud-service malware detection application50may generate the cloud-service behavioral profile56based on inter-service/inter-container incoming and outgoing network communications90, the API calls102, and other inter-service activities52conducted between the different containers44providing the different cloud services32distributed in the cloud-computing environment22. The cloud-service malware detection application50detects anomalies in the context of the cloud services32utilizing each other. The cloud-service malware detection application50operates in a domain of the inter-service/inter-container communications90, API calls102, and other inter-service activities52that are deployed on multiple computer hosts30distributed in the cloud-computing environment22. Conventional malware detection schemes focus on signals within a single host, which misses an attack that spans over multiple hosts30. The cloud-service malware detection application50detects anomalies in a much bigger picture with context—i.e., an attack that spans over multiple hosts and the context being the cloud services32involved in the attack. Indeed, by analyzing the API calls102, the cloud-service malware detection application50provides insights into the behavior of the cloud-native service application36(providing the cloud service32), again at a big picture level. Conventional malware detection schemes, for example, only monitor and analyze local system calls at the host level. Because the cloud-service malware detection application50profiles based on inter-service/inter-container communications, API calls102, and other inter-service activities52, the examples of the cloud-service malware detection application50provide greater and more useful malware detection in a distributed services system.

FIGS.12-13illustrate examples of feature extraction. The cloud-service malware detection application50has access to a rich data description of the inter-service/inter-container activities52and53conducted by any containerized service (illustrated as reference numerals32and44inFIGS.1-11). The cloud-service malware detection application50, for example, may query databases storing the inter-service and/or inter-host network connections90, the cloud configuration data96, and the service topology98. The cloud-service malware detection application50may also access databases storing the API resource identification100, runtime network instrumentation106, the resource action identification114, and/or the context116. The inter-service/inter-container activities52and53identify what inter-container cloud services32and network connections90are being invoked. The cloud-service malware detection application50may thus store or log any or all of this data in an electronic database120of features.FIG.12illustrates the database120of features as being stored in the memory device38of the computer24(such as the server26) hosting the cloud malware detection service82. The database120of features may optionally be remotely stored and accessed/queried by any other network member of the cloud computing environment22. Even though the database120of features may have any logical structure, a relational database is perhaps easiest to understand.FIG.13thus illustrates the database120of features as table122having row and columnar entries that map, relate, or associate different operational observations of the inter-service/inter-container activities52and53to their corresponding features124. The features124, in other words, have been extracted from the data describing the inter-service/inter-container activities52and53. These extracted features124may then be used to train the machine learning model58(as previously explained with reference toFIG.5).

The extracted features124may vary based on circumstances, experience, results, time, cost, and other factors. Actual prototype testing extracted the features124over several thousand observations. In actual practice, though, millions of observations may be recorded.FIG.13thus illustrates the truncated table122having many entries removed for clarity and simplification. Each row represents an observed inter-service/inter-container activity52and53, and each columnar entry represents a corresponding feature124. The extracted features124, for example, may describe a remote address ID, a remote port ID, and the network connection protocol (such as TCP or UDP) associated with the corresponding inter-container cloud service32. Other columnar entries may further describe a timing parameter, whether the cloud service32is a remote KUBERNETES® service and its service ID, an external indication, a domain name, a cloud indication, and the cloud service identifier92. Again, in actual practice, the table122may have millions of observations depending on a desired accuracy, budget, and other objectives.

The extracted features124reveal many details. The extracted features124, for example, may identify whether the external cloud service32is local (e.g., stored/co-hosted and executed by the server26) or remotely accessed via the communications network28. If the external cloud service32is local, the extracted features124may reveal whether the external cloud service32is deployed on the same compute cluster or deployed in a different compute cluster. The extracted features124may reveal whether the external cloud service32is a KUBERNETES® service and, if so, the identification for that particular KUBERNETES® service. The extracted features124may reveal a domain name for a particular IP address and, from that domain, distinguish between an API endpoint and another cloud network.

The extracted features124may include temporal components. The inter-service activities52may change with the passage of time. Any of the inter-service activities52, then, may have an initial value at an initial time to, a current value at a current time t, and perhaps a final value at a final or end time tf. The cloud service32, then, may startup and initially conduct many connections/communications90and other inter-service activities52with external containers44. As time passes, though, later phases of execution may cease some or most inter-service activities52. The extracted features124capture these details.

FIG.14illustrates a prototype example of cloud services malware detection. Now that the features124have been extracted, the machine learning model58may be trained to identify or predict the cloud malware20. The features124(extracted from the inter-service activities52) represent the historical observations of the normal or expected service activities (illustrated as reference numeral62inFIGS.2-5&7-9) reported by the legitimate cloud service32. The cloud-service malware detection application50may thus train the machine learning model58to recognize statistical ranges or values of these features124and even unknown values. The machine learning model58thus automatically, autonomously, and internally embeds the service behavioral profile56profiling the normal or expected service activity62. The cloud-service malware detection application50, of course, may implement a custom machine learning model that is specifically tailored and coded for cloud-computing services.

The prototype example was constructed. The prototype example was coded using a LINUX® Virtual Machine on an APPLE® MACBOOK® having an INTEL® hardware processor34. The setup consisted of a distributed application running as containers in a KUBERNETES® cluster deployed on a single virtual machine. Alongside the targeted distributed application, the prototype example was also running the malware detection container80as the cloud malware detection service82on the same cluster. Of course, the cloud-service malware detection application50may utilize any other KUBERNETES® cluster implementation (e.g., AWS®, GOOGLE®, MICROSOFT®). Each host in the cluster executed products from https://cilium.io/as the detection agent that provides network visibility into the network traffic on the host that originates from the containerized service32and44. The prototype malware detection container received the inter-service activities52from the cilium products, extracted the features124, and trained the machine learning model58with the extracted features124for the sending containerized service32and44. There are many other vendors and technologies that provide network visibility, and the cloud-service malware detection application50may interface with any vendor's product acting as the detection agent84.

The prototype example, though, was conceptually proven using publicly-available resources. While any machine learning model58or scheme may be used, the prototype example was implemented using the Local Outlier Factor programs available from the https://www.scikit-learn.org project. These programs allowed the inventor to quickly and inexpensively implement the machine learning model58and to conceptually prove the cloud-service malware detection application50. Again, though, any machine learning and statistical models may be used to detect normal and anomalous activities. Any classification models may also be used to classify/categorize normal and abnormal activities. Whatever models are used, the model(s)58are trained with the features124extracted from the observed inter-service activities52. Once trained, the machine learning model58analyzes unseen or unknown service interactions. If the statistical models predict the inter-service/inter-container activities52/53as anomalous, the cloud-service malware detection application50detects the cloud malware20.

FIG.15illustrates an example of a method for detecting the cloud malware20. The cloud-service malware detection application50receives the inter-service/inter-container activities52/53(as reported by the detection agent84) performed by the monitored cloud workload (Block130). The cloud workload represents the monitored cloud service32whose service behavioral profile56has been generated. The cloud service identifier92is determined (Block132), perhaps by accessing the cloud configuration data96and the runtime network instrumentation106(Block134). The service topology identification98is performed (Block136), perhaps using the cloud configuration data96, the runtime network instrumentation106, public DNS records, and the cloud service provider's IP service mapping data (Block138). The features124are extracted (Block140), perhaps using the cloud service identifiers92, the service topology identification98, and/or temporal features of the inter-service/inter-container activities52/53(Block142). The machine learning model58is trained with the features (Block144) and the service behavioral profile56is generated (Block146). The cloud-service malware detection application50may thus examine the contemporaneous inter-service activities52and distinguish between unseen, but normal, service activity (Block148) and the abnormal cloud malware20(Block150). Any abnormal cloud malware20triggers the threat procedures54(Block152).

FIGS.16-17illustrate examples of container-specific profiling. As this disclosure above explains, the cloud malware detection service82may be a client resource available to all containerized services32and44affiliated with the cloud computing environment22. The cloud malware detection service82may thus provide network-wide containerized cloud service malware detection. Moreover, the cloud malware detection service82may dynamically adapt to each different containerized service32and44. That is, the cloud malware detection service82may generate a unique service behavioral profile56for each different containerized service32and44. So, as the cloud malware detection service82receives the contemporaneous inter-service/inter-container activities52/53reported by a particular one of the cloud services32, the cloud malware detection service82may query for and identify the corresponding service behavioral profile56. Indeed, the cloud malware detection service82may even maintain electronic records indicating which machine learning model58is specified for the particular cloud malware detection service82.

FIG.16, for example, illustrates a database160of profiles. The database160of profiles has entries that define which service behavioral profile56is specified for each different containerized service32and44. Again, the cloud-computing environment22may have hundreds or even thousands of different and distributed, containerized cloud services32and44. For simplicity, then,FIG.16only illustrates the cloud malware detection service82communicating with three (3) network members30b-dproviding their corresponding containerized cloud services32b-dand44b-d. The network member30a, in particular, hosts the malware detection container80providing the cloud malware detection service82. As each containerized cloud service32b-dand44b-dsends its corresponding intra-service activities52b-d, the cloud malware detection service82must apply the correct, corresponding service behavioral profile56b-d.

FIG.17further illustrates the database160of profiles. The database160of profiles is illustrated as being integrated within the malware detection container80packaging the cloud-service malware detection application50. The database160of profiles may thus be stored by the network member30athat hosts the malware detection container80providing the cloud malware detection service82. The database160of profiles, however, may optionally be remotely stored and accessed/queried for its database entries. Even though the database160of profiles may have any logical structure, a relational database is perhaps easiest to understand.FIG.17thus illustrates the database160of profiles as table162having row and columnar entries that map, relate, or associate each cloud service identifier92to its corresponding machine learning model58, service behavioral profile56, malware alert notification66, and threat procedures54. Again, for simplicity, the table162is illustrated as only having several rows and columns. In actual practice, though, the database160of profiles may have thousands of entries, as the cloud computing environment22may have thousands of different containerized services32and44. Regardless, when the cloud malware detection service82determines the cloud service identifier92associated with the contemporaneous inter-service/inter-container activities52/53, the cloud-service malware detection application50need only perform a database lookup for the corresponding entries. The cloud-service malware detection application50may thus quickly identify which machine learning model58is specified for the requesting cloud service32. If the contemporaneous inter-service/inter-container activities52/53fail to statistically lie within the service behavioral profile56, the database160of profiles further specifies the malware alert notification66to be generated and the threat procedures54to be executed. The database160of profiles thus allows the cloud malware detection service82to quickly switch between different service behavioral profiles56as different cloud service clients stream their inter-service/inter-container activities52/53for malware detection. This example of a database-oriented approach allows for efficient implementation of the cloud malware detection service82.

The cloud malware detection service82is client and service agnostic. The cloud-service malware detection application50automatically and autonomously builds the service-specific behavioral profile56for each containerized cloud service32and44. The cloud malware detection service82profiles/characterizes each different container44providing its corresponding cloud service32. The cloud-service malware detection application50identifies and trains the service-specific machine learning model58with specific, inter-service activities52representing the normal or expected service activity62of the corresponding cloud service32. Once trained, then, the cloud malware detection service82specifically detects the cloud malware20targeted to the corresponding cloud service32. So, even though the cloud malware detection service82may be deployed as a network cloud malware detection resource, the cloud-service malware detection application50trains itself for individualized cloud malware detection service82. The cloud-service malware detection application50need only be fed or trained with the specific samples or features124of the inter-service activities52conducted by the corresponding customer/client cloud service32. The cloud-service malware detection application50may thus be deployed throughout the cloud-computing environment22with little or no custom coding or implementation. The cloud-service malware detection application50autonomously and automatically profiles each containerized cloud service32and44. The cloud-service malware detection application50is thus agnostic to the cloud service32and to the container44, thus quickly adapting and implementing cloud service-specific, container-specific, and application-specific malware detection.

The cloud-service malware detection application50provides still more improvements to computer functioning. Because the service behavioral profile56is automatically and autonomously created, the service behavioral profile56is much more accurate than manually-created profiles. Conventional, manually-created profiles must be written to include long branches of code implementing decisional rules. These manually-created profiles are simply too cumbersome and time-consuming to code for pattern recognition. The cloud-service malware detection application50, in contradistinction, trains the machine learning model58using the features124extracted from the historical inter-service activities. The machine learning model58thus inspects the contemporaneous inter-service activities and identifies statistical patterns, thus greatly improving malware detection.

Scalability is another improvement to computer functioning. Conventional, manually-created profiles are simply too difficult to code, implement, and manage. Consider, for example, the cloud-service provider40that runs a cluster of computer machines, with the cluster having one hundred (100) computing nodes. Suppose, further, that each computing node runs one hundred (100) different containers44, with each container providing its corresponding, unique cloud service32. In other words, the cluster runs10,000containers44. A team of human network administrator must then code10,000different profiles, and each profile must be managed, checked for accuracy, and implemented for production. This conventional, manual effort is simply not feasible for accurate and reliable malware detection. The cloud-service malware detection application50, in contradistinction, is a single service that is merely invoked via its APIs86. The cloud-service malware detection application50need only be trained using the service-specific features124(explained with reference toFIGS.10-14). The cloud-service malware detection application50detects the service-specific cloud malware20by automatically profiling its customer cloud service32. The cloud-service malware detection application50provides a scale of operation that is quick and simple to implement.

Profile management is another improvement to computer functioning. The cloud-native service application36can provide a better, faster, and/or cheaper cloud service32. Conventional schemes must profile each version, check for accuracy, and approve for production. The cloud-service malware detection application50, however, automatically profiles each version, thus greatly reducing manual efforts, hardware processing, and electricity consumption.

FIG.18illustrates another example of a method or operations for detecting the cloud malware20in the containerized service32and44. The inter-service/inter-container activities52/53are monitored (Block170). Any inter-service/inter-container activity52/53may be compared to the service behavioral profile56generated by the machine learning model58(Block172). If the activity52/53conforms to the service behavioral profile56(Block174), then either or both of the inter-service/inter-container activity52/53and/or the containerized service32and44may be executed (Block176). However, if the inter-service/inter-container activity52/53fails to conform to the service behavioral profile56(Block174), then, in response, the malware alert notification66may be generated to indicate that evidence of the cloud malware20is detected in the cloud service32(Block178).

FIG.19illustrates a more detailed example of the operating environment.FIG.19is a more detailed block diagram illustrating the computer24(and thus the server26and the network member30). The cloud-service malware detection application50is stored in the memory subsystem or device38. One or more of the processors34communicate with the memory subsystem or device38and execute the cloud-service malware detection application50. Examples of the memory subsystem or device38may include Dual In-Line Memory Modules (DIMMs), Dynamic Random Access Memory (DRAM) DIMMs, Static Random Access Memory (SRAM) DIMMs, non-volatile DIMMs (NV-DIMMs), storage class memory devices, Read-Only Memory (ROM) devices, compact disks, solid-state, and any other read/write memory technology. Because the computer24is known to those of ordinary skill in the art, no detailed explanation is needed.

The computer24may have any embodiment. This disclosure mostly discusses the computer24as the server26. The cloud malware detection service82, however, may be easily adapted to mobile computing, wherein the computer24may be a smartphone, a laptop computer, a tablet computer, or a smartwatch. The cloud malware detection service82may also be easily adapted to other embodiments of smart devices, such as a television, an audio device, a remote control, and a recorder. The cloud malware detection service82may also be easily adapted to still more smart appliances, such as washers, dryers, and refrigerators. Indeed, as cars, trucks, and other vehicles grow in electronic usage and in processing power, the cloud malware detection service82may be easily incorporated into any vehicular controller.

The above examples of the cloud malware detection service82may be applied regardless of the networking environment. The cloud malware detection service82may be easily adapted to stationary or mobile devices having wide-area networking (e.g., 4G/LTE/5G cellular), wireless local area networking (WI-FI®), near field, and/or BLUETOOTH® capability. The cloud malware detection service82may be applied to stationary or mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). The cloud malware detection service82, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain. The cloud malware detection service82may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN). The cloud malware detection service82may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, the many examples may be applied regardless of physical componentry, physical configuration, or communications standard(s).

The computer24and the network members30may utilize any processing component, configuration, or system. For example, the cloud malware detection service82may be easily adapted to any desktop, mobile, or server central processing unit or chipset offered by INTEL®, ADVANCED MICRO DEVICES®, ARM®, APPLE®, TAIWAN SEMICONDUCTOR MANUFACTURING®, QUALCOMM °, or any other manufacturer. The computer24may even use multiple central processing units or chipsets, which could include distributed processors or parallel processors in a single machine or multiple machines. The central processing unit or chipset can be used in supporting a virtual processing environment. The central processing unit or chipset could include a state machine or logic controller. When any of the central processing units or chipsets execute instructions to perform “operations,” this could include the central processing unit or chipset performing the operations directly and/or facilitating, directing, or cooperating with another device or component to perform the operations.

The cloud malware detection service82may use packetized communications. When the computer24, the server36, or any network member30communicates via the communications network28, information may be collected, sent, and retrieved. The information may be formatted or generated as packets of data according to a packet protocol (such as the Internet Protocol). The packets of data contain bits or bytes of data describing the contents, or payload, of a message. A header of each packet of data may be read or inspected and contain routing information identifying an origination address and/or a destination address.

The communications network28may utilize any signaling standard. The cloud computing environment22may mostly use wired networks to interconnect the network members30. However, the cloud malware detection service82may utilize any communications device using the Global System for Mobile (GSM) communications signaling standard, the Time Division Multiple Access (TDMA) signaling standard, the Code Division Multiple Access (CDMA) signaling standard, the “dual-mode” GSM-ANSI Interoperability Team (GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signaling standard. The cloud malware detection service82may also utilize other standards, such as the I.E.E.E. 802 family of standards, the Industrial, Scientific, and Medical band of the electromagnetic spectrum, BLUETOOTH®, low-power or near-field, and any other standard or value.

The cloud malware detection service82may be physically embodied on or in a computer-readable storage medium. This computer-readable medium, for example, may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks. This computer-readable medium, or media, could be distributed to end-subscribers, licensees, and assignees. A computer program product comprises processor-executable instructions for providing the cloud malware detection service82, as the above paragraphs explain.

The diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating examples of cloud services malware detection. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing instructions. The hardware, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer or service provider.

It will also be understood that, although the terms first, second, and so on, may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first computer or container could be termed a second computer or container and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.