Patent Description:
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. <CIT> discloses the use of machine learning to analyze and interpret statistical profiles. It also discloses the use of neural network to interpret the network traffic. <CIT> relates to a cyber threat defense system which incorporates data from multiple Software-as-a-Service or SaaS applications hosted by multiple third-party platforms to identify cyber threats across platforms.

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. Accordingly, there is provided a method, a computer, and a computer program as detailed in the claims that follow.

The features, aspects, and advantages of cloud services malware detection are understood when the following Detailed Description is read with reference to the accompanying drawings, wherein:.

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).

<FIG> illustrate some examples of inferring cloud malware <NUM> in a cloud-computing environment <NUM>. A computer <NUM> operates in the cloud-computing environment <NUM>. <FIG> illustrates the computer <NUM> as a server <NUM>. The computer <NUM>, though, may be any processor-controlled device, as later paragraphs will explain. In this example, the server <NUM> communicates via a communications network <NUM> (e.g., public Internet, private network, and/or hybrid network) with other servers, devices, computers, or other network members <NUM> operating within, or affiliated with, the cloud-computing environment <NUM>. The server <NUM> is programmed to provide one or more cloud services <NUM> to the network members <NUM> of the cloud-computing environment <NUM>. The server <NUM> thus has a hardware processor <NUM> (illustrated as "CPU") that executes a cloud-native service application <NUM> stored in a memory device <NUM>. The cloud-native service application <NUM> may be a computer program, instruction(s), or code that instructs or causes the server <NUM> to provide the cloud service <NUM>, perhaps on demand, on behalf of a service provider <NUM>. The cloud-native service application <NUM> may be executed by, or associated with, a virtual machine <NUM>. The cloud-native service application <NUM>, in particular, may be packaged as an isolated container <NUM> that contains all of the necessary elements to provide the cloud service <NUM>. The cloud-native service application <NUM>, for simplicity, is thus known as a containerized service <NUM> and <NUM>. The cloud-computing environment <NUM> delivers hosted cloud-native services, like storage, servers, and application services, via the communications network <NUM> (such as the Internet). Various implementations of a cloud-computing environment <NUM> are possible and could be used in the examples herein described.

The cloud malware <NUM> may infect the cloud-computing environment <NUM>. The cloud malware <NUM> exploits a vulnerability associated with the cloud service <NUM>. As a simple example, suppose that the cloud service <NUM> runs as the container <NUM> in 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 service <NUM> could 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 malware <NUM> may thus cause a security breach that threatens the accuracy/confidentiality/integrity of the cloud service <NUM>. The cloud malware <NUM> may further jeopardize the performance and functioning of the hardware processor <NUM> and the memory device <NUM>. Simply put, the cloud service <NUM> must be monitored against attacks by the malicious cloud malware <NUM>.

<FIG> thus illustrates an example of a cloud-service malware detection application <NUM>. The cloud-service malware detection application <NUM> detects, in real time or in near real time, anomalies as evidence of the cloud malware <NUM>. In this simple example, <FIG> illustrates the cloud-service malware detection application <NUM> installed to, and locally stored by, the server <NUM>. The cloud-service malware detection application <NUM> may be integrated into the container <NUM> that packages the cloud service <NUM>. However, the cloud-service malware detection application <NUM> may be implemented as its own containerized cloud malware detection service. Regardless, in this example, the cloud-service malware detection application <NUM> interfaces with, and perhaps supervises, the cloud-native service application <NUM>. The cloud-service malware detection application <NUM> monitors any events, communications, and activities associated with the cloud service <NUM>. The cloud-service malware detection application <NUM>, in particular, monitors and approves/denies inter-service activities <NUM> conducted by the container <NUM> (e.g., the cloud-native service application <NUM> providing the cloud service <NUM>). If the inter-service activities <NUM> indicate evidence of the cloud malware <NUM>, the cloud-service malware detection application <NUM> may automatically implement notification/quarantine/isolation/halt or other threat procedures <NUM> that protect the server <NUM> and the cloud-computing environment <NUM>.

<FIG> further illustrate examples of cloud services malware detection. An example of the cloud-service malware detection application <NUM> uses a service behavioral profile <NUM> to detect the cloud malware <NUM>. As <FIG> illustrates, the service behavioral profile <NUM> is automatically and autonomously generated by a machine learning model <NUM> that interfaces with, or is integrated with, the cloud-service malware detection application <NUM>. The cloud-service malware detection application <NUM> may monitor the contemporaneous inter-service activities <NUM> conducted by the cloud-native service application <NUM> providing the cloud service <NUM>. In <FIG>, for example, the cloud-service malware detection application <NUM> monitors the inter-service activities <NUM> conducted between different containers (illustrated as reference numerals 44a and 44b) that are co-hosted by the server <NUM>. In <FIG>, though, the cloud-service malware detection application <NUM> monitors the inter-service activities <NUM> conducted (via the communications network <NUM> illustrated in <FIG>) between different containers 44a and 44c hosted by different network nodal members (illustrated as servers <NUM> and <NUM>). The cloud-service malware detection application <NUM> may thus monitor and supervise the inter-container activities <NUM> conducted between different containerized services <NUM> and <NUM>. Whatever the containerized architecture, the cloud-service malware detection application <NUM> compares any inter-service activity <NUM> to the service behavioral profile <NUM>. If the inter-service activity <NUM> matches or conforms to the service behavioral profile <NUM>, then the cloud-service malware detection application <NUM> may permit or allow the inter-service activity <NUM> to continue or to execute. The inter-service activity <NUM>, in other words, may be classified as normal or expected service activity <NUM> conducted while providing the cloud service <NUM>. If, however, the cloud-service malware detection application <NUM> determines that the inter-service activity <NUM> deviates from, or fails to match, the service behavioral profile <NUM>, then the cloud-service malware detection application <NUM> may classify the inter-service activity <NUM> as an anomaly or unexpected service activity <NUM>. The cloud-service malware detection application <NUM>, in other words, may flag the inter-service activity <NUM> as potential evidence of the cloud malware <NUM>. The cloud-service malware detection application <NUM> may thus generate and send a malware alert notification <NUM> to any notification addresses that initiate further investigation. The cloud-service malware detection application <NUM> may also implement the predefined threat procedures <NUM> that protect the cloud-computing environment <NUM>.

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

Other actions may be implemented. When the cloud-service malware detection application <NUM> detects evidence of any malicious event (e.g., the cloud malware <NUM>), operations may be implemented or executed that quarantine the cloud service <NUM>. Operations may additionally or alternatively include quarantining the host machine (such as the server <NUM>). Operations may additionally or alternatively include terminating the container <NUM> (e.g., the cloud-native service application <NUM> providing the cloud service <NUM>). Service orchestration software may additionally or alternatively be instructed or commanded to remove the container <NUM> from the cloud computing environment <NUM>. Because evidence of the cloud malware <NUM> has been detected, any actions may be implemented that isolate the offending cloud service <NUM> to protect the cloud computing environment <NUM>.

<FIG> further illustrates examples of quickly detecting the cloud malware <NUM>. The cloud-service malware detection application <NUM> may initially train the machine learning model <NUM> to recognize, or to predict, many different features or indicators of the normal or expected service activities <NUM>. In these examples, the machine learning model <NUM> may be trained with cloud service training data <NUM> representing the normal or expected service activities <NUM>. The cloud service training data <NUM> describes actual, known, and/or normal activities that should be, or have been, conducted by the cloud-native service application <NUM> providing the cloud service <NUM>. The cloud service training data <NUM> may 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 malware <NUM>. The cloud service training data <NUM> is input to the machine learning model <NUM>, and the machine learning model <NUM> learns and builds one or more statistical models that describe, expand, and/or predict the normal or expected service activities <NUM> conducted by the cloud-native service application <NUM>. The cloud-service malware detection application <NUM>, in other words, may autonomously and automatically generate the cloud-service behavioral profile <NUM> that describes, or characterizes, the inter-service activities <NUM> conducted by the cloud-native service application <NUM>. The cloud-service malware detection application <NUM> may monitor the contemporaneous inter-service activities <NUM> conducted by the cloud-native service application <NUM>. The cloud-service malware detection application <NUM> may then compare the contemporaneous inter-service activities <NUM> to the cloud-service behavioral profile <NUM>. Any contemporaneous inter-service activity <NUM> that conforms to the cloud-service behavioral profile <NUM> may be quickly permitted/allowed to execute or proceed.

Predictions may be made. Because the machine learning model <NUM> may build a statistical model, the machine learning model <NUM> may statistically predict a range of the normal or expected service activities <NUM>. As a simple example, the machine learning model <NUM> may generate the cloud-service behavioral profile <NUM> using Gaussian probability distributions based on the cloud service training data <NUM>. One or more standard deviations and confidence intervals may then be calculated to predict ranges of the normal or expected service activities <NUM>. As the cloud-service malware detection application <NUM> inspects the inter-service activities <NUM>, the statistical models may be used to predict that any inter-service activity <NUM> lies within, or deviates or differs from, the cloud-service behavioral profile <NUM>. The cloud-service malware detection application <NUM> may thus classify the inter-service activity <NUM> as the abnormal or unexpected service activity <NUM> and, thus, the suspected cloud malware <NUM>. The cloud-service malware detection application <NUM> may then cause the cloud-native service application <NUM>, and/or the server <NUM>, to nearly instantaneously stop/halt/terminate the offending inter-service activity <NUM>. Indeed, the cloud-service malware detection application <NUM> may even disable the entire cloud service <NUM>. The cloud-service malware detection application <NUM> may further generate the malware alert notification <NUM> that is sent (via the communications network <NUM>) to any destination/recipient network address. The cloud-service malware detection application <NUM> thus autonomously and quickly protects the cloud-computing environment <NUM> from the cloud malware <NUM>.

The cloud-service malware detection application <NUM> provides many improvements to computer functioning. The cloud-service behavioral profile <NUM>, for example, is autonomously and automatically generated by the cloud-service malware detection application <NUM> invoking the machine learning model <NUM>. 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 malware <NUM>. 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 service <NUM>. The conventional schemes must also repeatedly retrain the machine learning models to recognize the latest-discovered threat. The cloud-service malware detection application <NUM>, in contradistinction, trains the machine learning model <NUM> with the normal or expected service activities <NUM> conducted by the cloud-native service application <NUM>. If any inter-service activity <NUM> deviates from the cloud-service behavioral profile <NUM>, the inter-service activity <NUM> may be immediately classified as suspicious and flagged as the cloud malware <NUM>. The cloud-service malware detection application <NUM> thus need not have a priori knowledge of any event or activity caused by any threat. The cloud-service malware detection application <NUM> maintains the accuracy/integrity of the cloud service <NUM>, and the cloud-service malware detection application <NUM> prevents malware-degraded hardware and memory performance of the computer <NUM>.

<FIG> illustrate more examples of containerized architectures. <FIG>, for example, illustrates a container-integration approach to malware detection. The cloud-service malware detection application <NUM>, in other words, may be integrated with the container <NUM> that packages the cloud-native service application <NUM> providing the cloud service <NUM>. The cloud-service malware detection application <NUM>, in particular, may be installed into, inserted into, added to, or imported into the container <NUM> that packages or contains the cloud-native service application <NUM> providing the cloud service <NUM>. The service provider <NUM> (of the cloud service <NUM>) codes the cloud-service malware detection application <NUM> into the cloud-native service application <NUM>. The cloud-service malware detection application <NUM> receives or intercepts the inter-service activities <NUM> and processes according to the service behavioral profile <NUM>. The service provider <NUM> may thus manage the lifecycle of the cloud service <NUM>, including the cloud-service malware detection application <NUM>.

<FIG>, though, illustrate examples of hosted service solutions. The cloud-service malware detection application <NUM> may be packaged as its own malware detection container <NUM> providing a cloud malware detection service <NUM>. The cloud-service malware detection application <NUM> may be packaged to contain all of its necessary elements to provide the cloud malware detection service <NUM>. The malware detection container <NUM>, for example, packages the service behavioral profile <NUM> generated by the machine learning model <NUM> based on the normal service activities <NUM>. When evidence of the cloud malware <NUM> is determined/predicted, the malware detection container <NUM> may also package the code generating the malware alert notification <NUM> and other threat procedures <NUM>. In <FIG>, the malware detection container <NUM> (providing the cloud malware detection service <NUM>) may be co-hosted by the server <NUM> that also hosts the different cloud service <NUM>. though, the malware detection container <NUM> is hosted by the different network member <NUM> (illustrated as the server <NUM>) operating within, or affiliated with, the cloud-computing environment <NUM>. The cloud-service malware detection application <NUM>, packaged as the malware detection container <NUM>, may be separate/remote network resource/service that may be invoked by any network member <NUM> of the cloud-computing environment <NUM>.

A detection agent <NUM> may inform the malware detection container <NUM>. The detection agent <NUM> cooperates with the cloud-native service application <NUM> providing the cloud service <NUM>. The detection agent <NUM> may have code or instructions that cause the server <NUM>, and/or the cloud-native service application <NUM> (providing the cloud service <NUM>), to read or intercept the inter-service activities <NUM> (such as the inter-container activities <NUM>) conducted by the container <NUM>. The service provider <NUM> may install or add the detection agent <NUM> to an operating system executed by the server <NUM>. The service provider <NUM> may additionally or alternatively install or add the detection agent <NUM> to the cloud-native service application <NUM> providing the cloud service <NUM>. The malware detection container <NUM> may expose its application programming interfaces ("APIs") <NUM> for calling/requesting the cloud malware detection service <NUM>. The detection agent <NUM> invokes the APIs <NUM> and may instruct or cause its host server <NUM> to send or transfer the inter-service activities <NUM> (via the communications network <NUM> illustrated in <FIG>) to the network IP address representing the malware detection container <NUM>, the cloud malware detection service <NUM>, and/or the cloud-service malware detection application <NUM>. The detection agent <NUM>, in plain words, may send a request specifying the cloud malware detection service <NUM> based on the inter-service activities <NUM>. The malware detection container <NUM> may provide the cloud malware detection service <NUM>. If evidence of the cloud malware <NUM> is detected, the cloud-service malware detection application <NUM> may send the malware alert notification <NUM> and may implement the threat procedures <NUM>.

<FIG> illustrate more examples of containerized services architectures. The cloud-computing environment <NUM> may have many, perhaps even hundreds, of different and distributed, containerized cloud services <NUM>. Such a complicated architecture is too difficult to illustrate. <FIG>, then, simply illustrates four (<NUM>) network members 30a-d providing their corresponding containerized cloud services 32a-d and 44a-d. In <FIG>, network member 30a, in particular, hosts the malware detection container <NUM> providing the cloud malware detection service <NUM>.

In <FIG>, though, the cloud malware detection service <NUM> may utilize multiple malware detection containers (illustrated as reference numerals 80a-c). Because the cloud-computing environment <NUM> may implement many hundreds or more of distributed, containerized cloud services <NUM>, such a large service architecture may overwhelm the performance capabilities of a single malware detection container <NUM>. Indeed, packet congestion, network delays, and timing/performance objectives may require the installation of multiple and distributed malware detection containers 80a-c to adequately serve the needs of the cloud-computing environment <NUM>.

The cloud malware detection service <NUM> monitors the cloud services <NUM>. The network members 30b-d may each store and execute an instance of the detection agent <NUM>. Each instance of the detection agent <NUM> may instruct the corresponding network member 30b-d to invoke the APIs <NUM> and to report its corresponding inter-service/inter-container activities 52b-d and 53b-d (via the communications network <NUM> illustrated in <FIG>) to the network IP address associated with the malware detection container <NUM> providing the cloud malware detection service <NUM>. The malware detection container <NUM> provides the cloud malware detection service <NUM>, based on the corresponding service behavioral profile 56b-d that is associated with the containerized cloud service 32b-d. Each containerized cloud service 32b-d, in other words, may have its unique service behavioral profile 56b-d, generated based on historical observations of the corresponding normal service activity 62b-d. Indeed, the cloud malware detection service <NUM> may be configured to utilize different machine learning models 58b-d that are predetermined or pre-selected according to the containerized cloud service 32b-d. The cloud malware detection service <NUM> may thus be trained to detect different cloud malware 20b-d, again depending on the corresponding containerized cloud service 32b-d. The cloud malware detection service <NUM> may be additionally configured with different malware alert notifications 66b-d and different threat procedures 54b-d, again depending on the corresponding containerized cloud service 32b-d. The cloud malware detection service <NUM> may thus be customized according to the containerized cloud service 32b-d.

<FIG> illustrate examples of the inter-service activities <NUM> that may be monitored by the cloud-service malware detection application <NUM> and/or the cloud malware detection service <NUM>. The cloud-computing environment <NUM> may provide thousands or even millions of distributed containers <NUM>, with each different container <NUM> specializing in a corresponding cloud service <NUM>. Each container <NUM> may 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 services <NUM>. As this disclosure above explained, though, such a complicated architecture is too difficult to illustrate. <FIG> thus simply illustrate two (<NUM>) containerized services <NUM>/<NUM> and <NUM>/<NUM>. Whatever cloud service <NUM> is provided by the container <NUM>, the detection agent <NUM> may report the corresponding inter-service activities <NUM> and/or the inter-container activities <NUM> (via the communications network <NUM> illustrated in <FIG>) to the network IP address representing the malware detection container <NUM> packaging the cloud malware detection service <NUM>. The detection agent <NUM> may request the cloud malware detection service <NUM> using the APIs <NUM>, as above explained.

As <FIG> illustrates, the inter-service activities <NUM> may include network connections <NUM>. As the containerized cloud service <NUM> operates, the cloud-service malware detection application <NUM> may monitor and inspect the incoming/outgoing inter-service/inter-container activities <NUM> and/or <NUM> conducted to/from the container <NUM>. For example, each container <NUM> is assigned to, and associated with, a unique cloud service identifier <NUM> and an Internet Protocol address <NUM>. As the containerized cloud service <NUM> and <NUM> operates, communications are established with other containers and services. The hosting network member <NUM>, the cloud service <NUM>, and/or the detection agent <NUM> may report the network connections <NUM>, the service identifiers <NUM>, and/or the Internet Protocol addresses <NUM> to the malware detection container <NUM> packaging the cloud malware detection service <NUM>. The cloud-service malware detection application <NUM> may inspect one, some, or all of these inter-service activities <NUM> and identify or classify the corresponding cloud service <NUM>. The cloud-service malware detection application <NUM> may read, or generate, logs describing input data sent to other containers <NUM>, output data received from other containers <NUM>, their corresponding Internet Protocol addresses <NUM>, and/or cloud service identifiers <NUM>. The cloud-service malware detection application <NUM> may read or log inter-container and/or inter-host requests, responses, replies, events, activities, their corresponding Internet Protocol addresses <NUM>, and/or cloud service identifiers <NUM>. The cloud-service malware detection application <NUM> may query and retrieve these inter-container Internet Protocol addresses <NUM> and cloud service identifiers <NUM> from cloud configuration data <NUM> provided by AWS®, GOOGLE®, MICROSOFT®, or any other cloud-service provider hosting the cloud-computing environment <NUM>. Because the container <NUM> is configured to talk to incoming and to outgoing external container services, the cloud-service malware detection application <NUM> may identify the external container <NUM> by reading the cloud configuration data <NUM> describing inter-container communications.

The network connections <NUM> allow identity inferences. The network connections <NUM>, for example, allow the cloud-service malware detection application <NUM> to 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 application <NUM> may distinguish between an internal application or a public IP address. The Internet Protocol address <NUM> and cloud service identifier <NUM> may even quickly and easily identify other categories of services (such as a SALESFORCE® API or a SLACK® messaging service). The cloud-service malware detection application <NUM> may identify and/or classify the cloud service identifier <NUM> by monitoring the inter-service network connections <NUM> between the different containers <NUM> and the cloud services <NUM>. Any method or network data may be used to infer service identities.

The cloud-service malware detection application <NUM> may also identify a service topology <NUM>. The cloud-service malware detection application <NUM> may consult public/private domain name service (DNS) records to further identify and classify the cloud service identifier <NUM>. For example, once any IP address is determined (such as the IP address <NUM> assigned to the container <NUM>), the cloud-service malware detection application <NUM> may query a DNS database lookup and identify, retrieve, or infer the corresponding URL domain, cloud service <NUM>, and/or service provider <NUM>. The DNS records may thus quickly and easily further reveal the service topology <NUM> attempted by any container <NUM>. As another example, cloud service providers publish ranges of IP addresses that correspond to cloud services <NUM>. These ranges of IP addresses may be retrieved and compared to the IP address <NUM> assigned to the container <NUM>, thus identifying the cloud service <NUM> and/or service provider <NUM>. As yet another example, Internet Protocol reputations <NUM> may 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> illustrates more examples of the inter-service activities <NUM>. The cloud-service malware detection application <NUM> may generate and monitor an API resource identification <NUM>. Again, the cloud-computing environment <NUM> may deploy thousands or even millions of different containers <NUM>, with each container <NUM> providing a corresponding cloud micro-service <NUM>. Each container <NUM> may thus be associated with application programming interfaces (or "APIs") that defines protocols for using the native cloud service <NUM> provided by the container <NUM>. The hosting network member <NUM>, the cloud service <NUM>, and/or the detection agent <NUM> may report incoming and outgoing API calls <NUM> to the malware detection container <NUM> packaging the cloud malware detection service <NUM>. By analyzing the incoming and outgoing API calls <NUM> made by the cloud service <NUM>, the API resource identification <NUM> reveals the web resource <NUM> called by the cloud service <NUM> and the service provider <NUM>.

The cloud-service malware detection application <NUM> may thus generate and monitor a runtime network instrumentation <NUM>. The cloud-service malware detection application <NUM> may generate the runtime network instrumentation <NUM> by identifying the API call <NUM> and by accessing and using publicly-available details about the API call <NUM>. For example, suppose that the container <NUM> (e.g., the cloud-native service application <NUM>) issues an HTTP REST API call <NUM>. Because the packet headers in the HTTP portion are visibly available, the cloud-service malware detection application <NUM> may read the HTTP portion and identify the URL hosting the API resource. The IP reputation <NUM> associated 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 application <NUM> may identify that the container <NUM> is communicating with the particular web resource <NUM> (such as SALESFORCE®) and making a modification to the web resource <NUM>. As another example, encrypted network traffic may also be inspected and identified. The detection agent <NUM> may 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 application <NUM> may obtain fine-grained details of the API call <NUM> and determine the API resource identification <NUM>, even from encrypted traffic. The API resource identification <NUM> may thus reveal the cloud malware <NUM> attempting a rogue resource modification.

The cloud-service malware detection application <NUM> may encode other information. The cloud-service malware detection application <NUM> may be programmed to include details regarding all, some, or commonly used API calls <NUM>. These API details allow the cloud-service malware detection application <NUM> to distinguish between different API calls <NUM> (such as REST API call from a Graph QL call). Amazon's AWS®, for example, offers hundreds of different API calls <NUM>. The cloud-service malware detection application <NUM> may be coded to include fine details regarding all, or a popular or common subset, of these AWS® API calls <NUM>. These fine details may be retrieved from the cloud configuration data <NUM> (such as Amazon's AWS® specification) and provide a deep knowledge of the resource exposed by the API call <NUM>. These fine details, for example, may reveal a name <NUM>, an object <NUM>, and an action <NUM> associated with the API call <NUM>. These fine details may be incorporated into the API resource identification <NUM>, thus providing a rich-data description of the inter-container API calls <NUM> associated with the container <NUM> providing the cloud service <NUM>.

The cloud-service malware detection application <NUM> may generate a resource action identification <NUM>. The cloud-service malware detection application <NUM> may generate the resource action identification <NUM> by semantically translating the action <NUM> (revealed by the API resource identification <NUM>) using a context <NUM>. As a very simple example, suppose the action <NUM> associated with the API call <NUM> is defined by the word "create. " Using the fine details describing the API call <NUM> (perhaps obtained from Amazon's, Google's, or Microsoft's cloud-computing service specification), the cloud-service malware detection application <NUM> may identify the API call <NUM> as a creation of a resource from its context <NUM>. If the context <NUM> is an AMAZON S3® bucket, the resource action identification <NUM> identifies the corresponding semantics and a single action <NUM>. If, however, the context <NUM> is a SALESFORCE® service, then the context <NUM> may have different semantics. The resource action identification <NUM>, as constructed perhaps over time and usage, is a rich glossary of semantics associated with API calls <NUM> and their corresponding name <NUM>, object <NUM>, and action <NUM>.

The cloud-service malware detection application <NUM> greatly improves cloud services malware detection. The cloud-service malware detection application <NUM> may define the machine learning model <NUM> to identify anomalies from inter-container and inter-host network traffic logs that provide service level details. The cloud-service malware detection application <NUM> thus need not have a priori knowledge of any threat event or activity. The cloud-service malware detection application <NUM> may use statistical approaches to identify anomalies for any cloud service <NUM>. The normal service activities <NUM> may be defined based on the historical service logs, and the features or indicators of the normal service activities <NUM> may be defined in terms of the service identifiers <NUM> and their inter-service/inter-container/inter-host interactions without looking into the operations performed. The cloud-service malware detection application <NUM> may thus train the machine learning model <NUM> to identify anomalies using the features or indicators of the normal service activities <NUM>. The cloud-service malware detection application <NUM> may then be deployed per-container <NUM>, and/or per-service <NUM>, for monitored cloud services <NUM>. Each container/service instance of the cloud-service malware detection application <NUM> gets differently trained to identify container-specific/service-specific anomalies (or threats). The cloud-service malware detection application <NUM> may thus generate the unique service behavioral profile <NUM> for each distributed cloud service <NUM>. Because the cloud-service malware detection application <NUM> may use statistical approaches, the cloud-service malware detection application <NUM> may statistically predict if a cloud service operation (in terms of the service identity <NUM>) is considered anomalous. Once any anomaly is detected, the cloud-service malware detection application <NUM> may flag the potential cloud malware <NUM>, generate the malware alert notification <NUM>, and/or alert downstream services for further investigation and/or response actions. The cloud-service malware detection application <NUM> may thus be a very workload-focused solution to detect threats. The cloud-service malware detection application <NUM> resolves the conventional problem of scale, as customers need not manually create and validate profiles. The cloud-service malware detection application <NUM> detects threats in terms of the high level entities (such as the above example of the malicious AWS LAMBDA® function). The cloud-service malware detection application <NUM> may 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 application <NUM>, however, may also apply machine learning and statistical modeling to non-containerized cloud services/applications.

The cloud-service malware detection application <NUM> provides more improvements to computer functioning. The cloud-service malware detection application <NUM> provides malware protection to distributed cloud-native computing services. The cloud-service malware detection application <NUM> predicts the cloud malware <NUM> by detecting anomalous inter-service activities <NUM> conducted between different containerized services <NUM> and even by different inter-host network members <NUM>. The cloud-service malware detection application <NUM> may generate the cloud-service behavioral profile <NUM> based on inter-service/inter-container incoming and outgoing network communications <NUM>, the API calls <NUM>, and other inter-service activities <NUM> conducted between the different containers <NUM> providing the different cloud services <NUM> distributed in the cloud-computing environment <NUM>. The cloud-service malware detection application <NUM> detects anomalies in the context of the cloud services <NUM> utilizing each other. The cloud-service malware detection application <NUM> operates in a domain of the inter-service/inter-container communications <NUM>, API calls <NUM>, and other inter-service activities <NUM> that are deployed on multiple computer hosts <NUM> distributed in the cloud-computing environment <NUM>. Conventional malware detection schemes focus on signals within a single host, which misses an attack that spans over multiple hosts <NUM>. The cloud-service malware detection application <NUM> detects anomalies in a much bigger picture with context - i.e., an attack that spans over multiple hosts and the context being the cloud services <NUM> involved in the attack. Indeed, by analyzing the API calls <NUM>, the cloud-service malware detection application <NUM> provides insights into the behavior of the cloud-native service application <NUM> (providing the cloud service <NUM>), 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 application <NUM> profiles based on inter-service/inter-container communications, API calls <NUM>, and other inter-service activities <NUM>, the examples of the cloud-service malware detection application <NUM> provide greater and more useful malware detection in a distributed services system.

<FIG> illustrate examples of feature extraction. The cloud-service malware detection application <NUM> has access to a rich data description of the inter-service/inter-container activities <NUM> and <NUM> conducted by any containerized service (illustrated as reference numerals <NUM> and <NUM> in <FIG>). The cloud-service malware detection application <NUM>, for example, may query databases storing the inter-service and/or inter-host network connections <NUM>, the cloud configuration data <NUM>, and the service topology <NUM>. The cloud-service malware detection application <NUM> may also access databases storing the API resource identification <NUM>, runtime network instrumentation <NUM>, the resource action identification <NUM>, and/or the context <NUM>. The inter-service/inter-container activities <NUM> and <NUM> identify what inter-container cloud services <NUM> and network connections <NUM> are being invoked. The cloud-service malware detection application <NUM> may thus store or log any or all of this data in an electronic database <NUM> of features. <FIG> illustrates the database <NUM> of features as being stored in the memory device <NUM> of the computer <NUM> (such as the server <NUM>) hosting the cloud malware detection service <NUM>. The database <NUM> of features may optionally be remotely stored and accessed/queried by any other network member of the cloud computing environment <NUM>. Even though the database <NUM> of features may have any logical structure, a relational database is perhaps easiest to understand. <FIG> thus illustrates the database <NUM> of features as table <NUM> having row and columnar entries that map, relate, or associate different operational observations of the inter-service/inter-container activities <NUM> and <NUM> to their corresponding features <NUM>. The features <NUM>, in other words, have been extracted from the data describing the inter-service/inter-container activities <NUM> and <NUM>. These extracted features <NUM> may then be used to train the machine learning model <NUM> (as previously explained with reference to <FIG>).

The extracted features <NUM> may vary based on circumstances, experience, results, time, cost, and other factors. Actual prototype testing extracted the features <NUM> over several thousand observations. In actual practice, though, millions of observations may be recorded. <FIG> thus illustrates the truncated table <NUM> having many entries removed for clarity and simplification. Each row represents an observed inter-service/inter-container activity <NUM> and <NUM>, and each columnar entry represents a corresponding feature <NUM>. The extracted features <NUM>, 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 service <NUM>. Other columnar entries may further describe a timing parameter, whether the cloud service <NUM> is a remote KUBERNETES® service and its service ID, an external indication, a domain name, a cloud indication, and the cloud service identifier <NUM>. Again, in actual practice, the table <NUM> may have millions of observations depending on a desired accuracy, budget, and other objectives.

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

The extracted features <NUM> may include temporal components. The inter-service activities <NUM> may change with the passage of time. Any of the inter-service activities <NUM>, then, may have an initial value at an initial time t<NUM>, a current value at a current time t, and perhaps a final value at a final or end time tf. The cloud service <NUM>, then, may startup and initially conduct many connections/communications <NUM> and other inter-service activities <NUM> with external containers <NUM>. As time passes, though, later phases of execution may cease some or most inter-service activities <NUM>. The extracted features <NUM> capture these details.

<FIG> illustrates a prototype example of cloud services malware detection. Now that the features <NUM> have been extracted, the machine learning model <NUM> may be trained to identify or predict the cloud malware <NUM>. The features <NUM> (extracted from the inter-service activities <NUM>) represent the historical observations of the normal or expected service activities (illustrated as reference numeral <NUM> in <FIG> & <FIG>) reported by the legitimate cloud service <NUM>. The cloud-service malware detection application <NUM> may thus train the machine learning model <NUM> to recognize statistical ranges or values of these features <NUM> and even unknown values. The machine learning model <NUM> thus automatically, autonomously, and internally embeds the service behavioral profile <NUM> profiling the normal or expected service activity <NUM>. The cloud-service malware detection application <NUM>, 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 processor <NUM>. 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 container <NUM> as the cloud malware detection service <NUM> on the same cluster. Of course, the cloud-service malware detection application <NUM> may 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 service <NUM> and <NUM>. The prototype malware detection container received the inter-service activities <NUM> from the cilium products, extracted the features <NUM>, and trained the machine learning model <NUM> with the extracted features <NUM> for the sending containerized service <NUM> and <NUM>. There are many other vendors and technologies that provide network visibility, and the cloud-service malware detection application <NUM> may interface with any vendor's product acting as the detection agent <NUM>.

The prototype example, though, was conceptually proven using publicly-available resources. While any machine learning model <NUM> or 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 model <NUM> and to conceptually prove the cloud-service malware detection application <NUM>. 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) <NUM> are trained with the features <NUM> extracted from the observed inter-service activities <NUM>. Once trained, the machine learning model <NUM> analyzes unseen or unknown service interactions. If the statistical models predict the inter-service/inter-container activities <NUM>/<NUM> as anomalous, the cloud-service malware detection application <NUM> detects the cloud malware <NUM>.

<FIG> illustrates an example of a method for detecting the cloud malware <NUM>. The cloud-service malware detection application <NUM> receives the inter-service/inter-container activities <NUM>/<NUM> (as reported by the detection agent <NUM>) performed by the monitored cloud workload (Block <NUM>). The cloud workload represents the monitored cloud service <NUM> whose service behavioral profile <NUM> has been generated. The cloud service identifier <NUM> is determined (Block <NUM>), perhaps by accessing the cloud configuration data <NUM> and the runtime network instrumentation <NUM> (Block <NUM>). The service topology identification <NUM> is performed (Block <NUM>), perhaps using the cloud configuration data <NUM>, the runtime network instrumentation <NUM>, public DNS records, and the cloud service provider's IP service mapping data (Block <NUM>). The features <NUM> are extracted (Block <NUM>), perhaps using the cloud service identifiers <NUM>, the service topology identification <NUM>, and/or temporal features of the inter-service/inter-container activities <NUM>/<NUM> (Block <NUM>). The machine learning model <NUM> is trained with the features (Block <NUM>) and the service behavioral profile <NUM> is generated (Block <NUM>). The cloud-service malware detection application <NUM> may thus examine the contemporaneous inter-service activities <NUM> and distinguish between unseen, but normal, service activity (Block <NUM>) and the abnormal cloud malware <NUM> (Block <NUM>). Any abnormal cloud malware <NUM> triggers the threat procedures <NUM> (Block <NUM>).

<FIG> illustrate examples of container-specific profiling. As this disclosure above explains, the cloud malware detection service <NUM> may be a client resource available to all containerized services <NUM> and <NUM> affiliated with the cloud computing environment <NUM>. The cloud malware detection service <NUM> may thus provide network-wide containerized cloud service malware detection. Moreover, the cloud malware detection service <NUM> may dynamically adapt to each different containerized service <NUM> and <NUM>. That is, the cloud malware detection service <NUM> may generate a unique service behavioral profile <NUM> for each different containerized service <NUM> and <NUM>. So, as the cloud malware detection service <NUM> receives the contemporaneous inter-service/inter-container activities <NUM>/<NUM> reported by a particular one of the cloud services32, the cloud malware detection service <NUM> may query for and identify the corresponding service behavioral profile <NUM>. Indeed, the cloud malware detection service <NUM> may even maintain electronic records indicating which machine learning model <NUM> is specified for the particular cloud malware detection service <NUM>.

<FIG>, for example, illustrates a database <NUM> of profiles. The database <NUM> of profiles has entries that define which service behavioral profile <NUM> is specified for each different containerized service <NUM> and <NUM>. Again, the cloud-computing environment <NUM> may have hundreds or even thousands of different and distributed, containerized cloud services <NUM> and <NUM>. For simplicity, then, <FIG> only illustrates the cloud malware detection service <NUM> communicating with three (<NUM>) network members 30b-d providing their corresponding containerized cloud services 32b-d and 44b-d. The network member 30a, in particular, hosts the malware detection container <NUM> providing the cloud malware detection service <NUM>. As each containerized cloud service 32b-d and 44b-d sends its corresponding intra-service activities 52b-d, the cloud malware detection service <NUM> must apply the correct, corresponding service behavioral profile 56b-d.

<FIG> further illustrates the database <NUM> of profiles. The database <NUM> of profiles is illustrated as being integrated within the malware detection container <NUM> packaging the cloud-service malware detection application <NUM>. The database <NUM> of profiles may thus be stored by the network member 30a that hosts the malware detection container <NUM> providing the cloud malware detection service <NUM>. The database <NUM> of profiles, however, may optionally be remotely stored and accessed/queried for its database entries. Even though the database <NUM> of profiles may have any logical structure, a relational database is perhaps easiest to understand. <FIG> thus illustrates the database <NUM> of profiles as table <NUM> having row and columnar entries that map, relate, or associate each cloud service identifier <NUM> to its corresponding machine learning model <NUM>, service behavioral profile <NUM>, malware alert notification <NUM>, and threat procedures <NUM>. Again, for simplicity, the table <NUM> is illustrated as only having several rows and columns. In actual practice, though, the database <NUM> of profiles may have thousands of entries, as the cloud computing environment <NUM> may have thousands of different containerized services <NUM> and <NUM>. Regardless, when the cloud malware detection service <NUM> determines the cloud service identifier <NUM> associated with the contemporaneous inter-service/inter-container activities <NUM>/<NUM>, the cloud-service malware detection application <NUM> need only perform a database lookup for the corresponding entries. The cloud-service malware detection application <NUM> may thus quickly identify which machine learning model <NUM> is specified for the requesting cloud service <NUM>. If the contemporaneous inter-service/inter-container activities <NUM>/<NUM> fail to statistically lie within the service behavioral profile <NUM>, the database <NUM> of profiles further specifies the malware alert notification <NUM> to be generated and the threat procedures <NUM> to be executed. The database <NUM> of profiles thus allows the cloud malware detection service <NUM> to quickly switch between different service behavioral profiles <NUM> as different cloud service clients stream their inter-service/inter-container activities <NUM>/<NUM> for malware detection. This example of a database-oriented approach allows for efficient implementation of the cloud malware detection service <NUM>.

The cloud malware detection service <NUM> is client and service agnostic. The cloud-service malware detection application <NUM> automatically and autonomously builds the service-specific behavioral profile <NUM> for each containerized cloud service <NUM> and <NUM>. The cloud malware detection service <NUM> profiles/characterizes each different container <NUM> providing its corresponding cloud service <NUM>. The cloud-service malware detection application <NUM> identifies and trains the service-specific machine learning model <NUM> with specific, inter-service activities <NUM> representing the normal or expected service activity <NUM> of the corresponding cloud service <NUM>. Once trained, then, the cloud malware detection service <NUM> specifically detects the cloud malware <NUM> targeted to the corresponding cloud service <NUM>. So, even though the cloud malware detection service <NUM> may be deployed as a network cloud malware detection resource, the cloud-service malware detection application <NUM> trains itself for individualized cloud malware detection service <NUM>. The cloud-service malware detection application <NUM> need only be fed or trained with the specific samples or features <NUM> of the inter-service activities <NUM> conducted by the corresponding customer/client cloud service <NUM>. The cloud-service malware detection application <NUM> may thus be deployed throughout the cloud-computing environment <NUM> with little or no custom coding or implementation. The cloud-service malware detection application <NUM> autonomously and automatically profiles each containerized cloud service <NUM> and <NUM>. The cloud-service malware detection application <NUM> is thus agnostic to the cloud service <NUM> and to the container <NUM>, thus quickly adapting and implementing cloud service-specific, container-specific, and application-specific malware detection.

The cloud-service malware detection application <NUM> provides still more improvements to computer functioning. Because the service behavioral profile <NUM> is automatically and autonomously created, the service behavioral profile <NUM> is 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 application <NUM>, in contradistinction, trains the machine learning model <NUM> using the features <NUM> extracted from the historical inter-service activities. The machine learning model <NUM> thus 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 provider <NUM> that runs a cluster of computer machines, with the cluster having one hundred (<NUM>) computing nodes. Suppose, further, that each computing node runs one hundred (<NUM>) different containers <NUM>, with each container providing its corresponding, unique cloud service <NUM>. In other words, the cluster runs <NUM>,<NUM> containers <NUM>. A team of human network administrator must then code <NUM>,<NUM> different 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 application <NUM>, in contradistinction, is a single service that is merely invoked via its APIs <NUM>. The cloud-service malware detection application <NUM> need only be trained using the service-specific features <NUM> (explained with reference to <FIG>). The cloud-service malware detection application <NUM> detects the service-specific cloud malware <NUM> by automatically profiling its customer cloud service <NUM>. The cloud-service malware detection application <NUM> provides a scale of operation that is quick and simple to implement.

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

<FIG> illustrates another example of a method or operations for detecting the cloud malware <NUM> in the containerized service <NUM> and <NUM>. The inter-service/inter-container activities <NUM>/<NUM> are monitored (Block <NUM>). Any inter-service/inter-container activity <NUM>/<NUM> may be compared to the service behavioral profile <NUM> generated by the machine learning model <NUM> (Block <NUM>). If the activity <NUM>/<NUM> conforms to the service behavioral profile <NUM> (Block <NUM>), then either or both of the inter-service/inter-container activity <NUM>/<NUM> and/or the containerized service <NUM> and <NUM> may be executed (Block <NUM>). However, if the inter-service/inter-container activity <NUM>/<NUM> fails to conform to the service behavioral profile <NUM> (Block <NUM>), then, in response, the malware alert notification <NUM> may be generated to indicate that evidence of the cloud malware <NUM> is detected in the cloud service <NUM> (Block <NUM>).

<FIG> illustrates a more detailed example of the operating environment. <FIG> is a more detailed block diagram illustrating the computer <NUM> (and thus the server <NUM> and the network member <NUM>). The cloud-service malware detection application <NUM> is stored in the memory subsystem or device <NUM>. One or more of the processors <NUM> communicate with the memory subsystem or device <NUM> and execute the cloud-service malware detection application <NUM>. Examples of the memory subsystem or device <NUM> may 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 computer <NUM> is known to those of ordinary skill in the art, no detailed explanation is needed.

The computer <NUM> may have any embodiment. This disclosure mostly discusses the computer <NUM> as the server <NUM>. The cloud malware detection service <NUM>, however, may be easily adapted to mobile computing, wherein the computer <NUM> may be a smartphone, a laptop computer, a tablet computer, or a smartwatch. The cloud malware detection service <NUM> may 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 service <NUM> may 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 service <NUM> may be easily incorporated into any vehicular controller.

The above examples of the cloud malware detection service <NUM> may be applied regardless of the networking environment. The cloud malware detection service <NUM> may be easily adapted to stationary or mobile devices having wide-area networking (e.g., <NUM>/LTE/<NUM> cellular), wireless local area networking (WI-FI®), near field, and/or BLUETOOTH® capability. The cloud malware detection service <NUM> may be applied to stationary or mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE <NUM> family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). The cloud malware detection service <NUM>, 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 service <NUM> may 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 service <NUM> may 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 computer <NUM> and the network members <NUM> may utilize any processing component, configuration, or system. For example, the cloud malware detection service <NUM> may 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 computer <NUM> may 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 service <NUM> may use packetized communications. When the computer <NUM>, the server <NUM>, or any network member <NUM> communicates via the communications network <NUM>, 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 network <NUM> may utilize any signaling standard. The cloud computing environment <NUM> may mostly use wired networks to interconnect the network members <NUM>. However, the cloud malware detection service <NUM> may 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 service <NUM> may also utilize other standards, such as the I. <NUM> 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 service <NUM> may 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 service <NUM>, 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.

As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms "includes," "comprises," "including," and/or "comprising," when used in this Specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Claim 1:
A method executed by a computer that detects a cloud malware in cloud services, comprising:
monitoring, by the computer, inter-service activities conducted between the cloud services in a cloud-computing environment;
comparing, by the computer, an inter-service activity of the inter-service activities to a service behavioral profile generated by a machine learning model trained, by the computer, using features extracted from historical observations of the inter-service activities;
wherein the machine learning model is a service-specific machine learning model (<NUM>) using specific inter-service activities (<NUM>, <NUM>) representing normal or expected service activities of each corresponding cloud service of the cloud services;
and wherein the service-specific machine learning model (<NUM>) is identified by a respective cloud service identifier (<NUM>) associated with the specific inter-service activities, and the service-specific machine learning model is trained, by the computer, with the specific inter-service activities (<NUM>, <NUM>); determining, by the computer, if the inter-service activity fails to conform to the service behavioral profile generated by the machine learning model; and
in response to the determining that the inter-service activity fails to conform to the service behavioral profile, generating, by the computer, a malware alert notification (<NUM>) indicating the cloud malware is detected in the cloud services.