Point Dorset, Wellington

Malware protection in compute workloads in AWS is a topic that I’ve been looking into recently. After working with security auditors for a few weeks (adding up a few months now), I was essentially forced to evaluate all the possible scenarios for malware protection in AWS for typical workloads.

Typical Malware Protection Requirements

The following key features can be identified as typical malware protection requirements for most solutions.


Regardless of the approach for malware detection and protection, the need for the process to be automated is a key requirement. This removes the human intervention from the execution part of the loop which reduces costs and potential windows for errors. At the same time, automated malware scans can improve reactive protection strategies to be somewhat proactive, based on the parameters of the solution. A frequently run vulnerability scan could potentially close off gaps that threat actors could exploit to install malware, mitigating untreated risk levels for malware protection in a solution.

Threat Intelligence Sources

Malware and vulnerability scanners work off of threat intelligence databases. These are common vulnerability and malware signature databases that can be used to keep the scanning jobs relevant and up to date. The malware protection should be able to incorporate these sources in to the design with minimal administration overhead.


There is no rule that forces cloud based solutions to only use Cloud-Native malware protection strategies. In fact, whichever design that works best with existing infrastructure and support services (security event and incident management, general incident response processes, service desks) could be the best solution. However, for newly designed solutions, making use of cloud-native solutions reduces both the operational overhead and potentially the cost of licensing and management for third party solutions. Such a service should integrate seemlessly with the compute services of the solution, providing features like agentless scanning, resource detection, and cloud provider managed threat intelligence.

Compliance Requirements

While implementing a solution wide malware protection design will not make you ISO27001 compliant, it is still good to understand the general compliance landscape around malware protection.

ISO27001 refers to malware protection with regards to organizational stance on user awareness, detection, prevention, and recovery controls for malware. While there are process and culture components that should be implemented, for organizational information processing systems, implementing a malware protection design is still part of the core controls that make up this requirement.

Based on the ISO27001 requirements, NZISM refers to malware protection mainly in Standard Operating Environments (SOE) section. This is in relation to developing and maintaining secure and trusted workstations.

However, each organization and solution could adapt its own set of security requirements that are more specific to the context. This can include detecting and guarding against vulnerabilities and malware in business logic execution. While some typical AWS compute instances may be considered as SOEs in some contexts, each use case might be different for compliance requirements for cloud based solutions.

Malware Protection in AWS

Having briefly discussed the typical compliance requirements for malware protection, let’s consider more AWS specific details of the topic.


The following compute services are the most common targets to be considered for malware protection designs.

  1. EC2 - AMIs and running instance storage should be subject to proactive scans for vulnerabilities and malware. New instances should be part of these scans automatically to achieve the best possible posture against malware.
  2. ECS - While ECS runtime might be out of the user’s part of the shared responsibility model in AWS for Fargate based compute workloads, the Container images that compose the runtime for each Task should still be subjected to malware protection scans. EC2 based runtime instances are covered in the EC2 scans.
  3. Lambda Functions - Lambda functions being the most managed solution out of these compute services, can be vulnerable to malware through supply chain attacks. Dependencies that are packed into a function layer should be scanned frequently (ideally, on each test build) for malicious or compromised libraries and artefacts
  4. EKS - While both ECS and EKS make use of Containers as the baseline compute process in the user’s part of the share responsibility model in AWS, K8s itself brings its own security requirements and checks. These are formulated in a well structured manner in CIS Benchmarks for EKS, a more specific version of generic K8s CIS Benchmarks.


Third Party Host-based Malware Scanners

Each user managed compute instance could be installed malware scanners like anti-virus tools that may continuously or on-demand, scan the runtime and the file system for known malware signatures. While this can be really specific to each type of runtime used on the solution (ex: different scanners for Linux and Windows hosts), the management overhead for a design like this can be quite high. Each machine image will have to be managed separately and the images themselves need to be constantly kept up to date to make sure threat intelligence sources are updated. Furthermore, host based malware scanners could be compromised by malicious actors if the underlying host is compromised, since most of these scanners do not check for vulnerabilities from an external point of view (ex: network configuration gaps). For ephemeral workloads that do not store data that cannot be reproduced, host based malware scanners may be overkill while still not providing the vulnerability assessments to keep the deployment safe.

Most importantly, these scanners may be able to cover only EC2 instances for their malware scans. This makes this approach less desirable, especially when the operational overhead is considered.

ECR Basic Scanning

ECR Basic Scanning is a feature enabled at the Container Registry level to detect vulnerabilities in the Container Images pushed to an ECR Container Registry. The Threat Intelligence for Basic Scanning is based on the Clair project by Redhat Quay. Clair supports the Docker image format that ECR uses and is frequently updated.

It is recommended to enable ECR Basic Scanning to perform scans on image push, rather than manually triggering scan. This goes back to the point of automated scanning discussed at the top, where simple vulnerability scanning could mitigate a broad range of malware based risks in the solution. Any potential malware should be detected before the Container image is used to spawn a runtime. Furthermore, Basic Scanning sends events to Amazon EventBridge when a scan job is done. This enables an automated response loop, where (for example), scan results that show any number of CRITICAL findings result in the pushed image being blacklisted, untagged, or deleted off the repository.

ECR Basic Scanning is a free service, which is better replaced by Enhanced Scanning.

Amazon Inspector

Amazon Inspector is a cloud-native proactive vulnerability scanning service that covers the most number of targets discussed before. It scans EC2 instances for software and network level vulnerabilities, without having to use an additional agent than the AWS SSM Agent that most solutions will already include.

For Container Images, Amazon Inspector is able to perform Enhanced Scanning for images pushed to ECR registries. Unlike Basic Scanning, Enhanced Scanning is able to perform continuous scanning, which can be helpful to reduce the time to find and mitigate newly discovered vulnerabilities.

Lambda functions code and layers can be part of Amazon Inspector vulnerability scans as well. While the support for runtimes is somewhat limited, the function code and dependencies are scanned as the function is updated with the latest code.

All the findings can be centralised into AWS Security Hub which provides a single pane of glass view into the security posture of an AWS Organization.

Amazon Inspector is priced mainly on the volume of data scanned, i.e. the usage based pricing model AWS services generally provide.

GuardDuty Malware Protection

GuardDuty Malware Protection is a feature introduced relatively recently. Just as GuardDuty in overall, GuardDuty Malware Protection is a reactive service. It scans for malicious activity in EC2 EBS based workloads. Unlike Amazon Inspector, this does not scan Container images or AMIs. Therefore, the malicious activity has to be executed for GuardDuty Malware Protection to flag it as a finding.

The scans are agentless, meaning not even SSM agent needs to live in the instance that is subject to scan. The scanning jobs themselves are triggered when GuardDuty detects a selected list of findings on EC2 instances or Container workloads running on EC2 instances. Snapshots of the EBS disks attached to the EC2 instances that cause these findings are then taken to be scanned seperately from live instances. This makes sure that scanning jobs are not impacting system performance. Those snapshots in which malware is detected are retained for further manual/external system based inspection.


As it is evident from the above approaches, no single option is a “the” solution for malware protection. Depending on the solution a combination of approaches will be needed to cover Containers, EC2 instances, Serverless functions, and their runtime images.

For example, a solution that has moderate malware protection requirements (based on impact, likelihood of being targeted, the severity of data being compromised, and residual risk after other mitigations are applied), only using using Amazon Inspector for proactive vulnerability scans may be enough for most solutions.

In others, a comprehensive solution with supply chain protection enforced at the CI pipelines, benchmarks, GuardDuty, Amazon Inspector, and GuardDuty Malware Protection may be required.