AWS provides a set of security controls to protect its own infrastructure, but it’s important to be aware that…
the security of the individual servers is the responsibility of the client — not Amazon — as part of the shared responsibility model. This distinction is not always understood.
Amazon will secure the hardware, software, networking and facilities that run AWS cloud services, but the client assumes responsibility for managing other environments, including guest OSes, all patching and updates, application software security, identity and access management, firewall configuration and more.
In this shared responsibility model, it wouldn’t be viable for Amazon to provide vulnerability management, as it would require the cloud provider to have access to administrator- or root-level credentials for each server, which would be a data privacy nightmare.
Equally important to note is although the Amazon-owned infrastructure is regularly tested for vulnerabilities, this does not imply security on the individual IP addresses your enterprise controls. IP addresses within AWS should be treated in the same way as any private or public IP addresses, and corporate vulnerability management policies should be extended to include servers hosted within AWS.
To fulfill their end of the shared responsibility model, enterprises must conduct regular AWS vulnerability scanning. Here’s how to get the job done.
1. Choose an AWS vulnerability scanner
Historically, AWS required express permission to run any form of vulnerability assessment on servers within the AWS infrastructure. Rules were updated in 2016 to allow organizations to run vulnerability scans on EC2 instances, network address translation gateways and Elastic Load Balancers, Amazon Relational Database Service, CloudFront, Amazon API Gateway, Lambda and Lambda edge functions, and Elastic Beanstalk. To ensure compliance with its rules, be sure to check AWS’ latest policies before running a scan.
Scans can be performed manually, but these are often time-consuming and error-prone. The best method to conduct AWS vulnerability scans is to install a virtual instance of a vulnerability scanning appliance directly into AWS. The exact appliance you choose will depend on your enterprise’s vulnerability scanning needs and the expertise of your security admins.
Many appliances are designed to work with AWS’ shared security model to ensure enterprises don’t violate Amazon’s penetration testing and vulnerability scanning rules. Such tools are available from a variety of third-party vendors, such as Qualys’ Virtual Scanner Appliance or Tenable’s Nessus. Open source options are also available, such as Scout2 or Pacu, as are tools directly from AWS. For example, the Amazon Inspector vulnerability assessment service is for apps deployed on EC2.
Appliances can be purchased from the Amazon Marketplace and delivered via an Amazon Machine Image (AMI). Once a subscription to the vulnerability scanner is purchased, the AMI instance can be launched from within the AWS EC2 console — accessible through the AWS management console. The virtual scanning appliance subscription usually requires an existing subscription to the relevant vulnerability scanning SaaS. In some cases, the AMI is included as part of the standard subscription to the SaaS; in others, it is an added extra feature.
Virtual vulnerability scanning appliances are generally able to scan private and public IP addresses within EC2 and Amazon Virtual Private Cloud, private IP addresses connected to Amazon via an IPSec VPN, and public IP addresses on the internet.
When choosing a scanner, also consider how often scans will be conducted. Appliances can be scheduled to run at any frequency and are often conducted quarterly, biannually or annually. Some tools also offer real-time monitoring. The cadence depends largely on your assets and the reasons for the scan. Is it to fulfill an organizational security requirement, or to check a box on your compliance checklist? SOC 2, HIPAA, ISO 27001, PCI DSS and FedRAMP, among other regulations, require such scans.
Remember, continuity is key. Assessments are not a one-and-done task. Conducting regular AWS vulnerability scanning will ensure security holes are caught and remediated in a timely manner.
The cost of running the vulnerability scanning virtual appliance is split into two parts. First, there is the cost of the bring-your-own-license for the AMI. Second, AWS requires a fee for running the appliance. This fee covers the compute capacity — this is the largest cost — which is based on the instance type, the amount of storage used and the amount of data that is transferred in and out.
2. Run the scan to identify risks
Once you’ve chosen a vulnerability scanner, installed it and mapped the systems in your environment, it’s time to perform the scan. The appliance will search your system for common vulnerabilities, such as these:
- mistakes in software code
- software misconfiguration
- unpatched software
- compliance issues
Many tools can also identify the following:
Note, Amazon does not allow the use of such tools to perform the following:
- DDoS attacks or simulations
- protocol flooding
- resource request flooding
3. Analyze results and address vulnerabilities
Choosing a scanner and performing a scan are only the first steps to AWS vulnerability scanning. Organizations must also ensure they have the relevant technical expertise on staff to interpret the results of the scans.
Once risks are identified and categorized, enterprises should put a plan in place to remediate security gaps, update any processes that may have led to those issues occurring and adopt security controls to prevent them from occurring in the future. Third-party and open source tools generally list the vulnerabilities — ranked critical, high, medium and low — as compared to providing an index, such as in the Common Vulnerabilities and Exposures database. Many tools also offer prioritized response plans and recommendations.
Some virtual scanners, if provided with valid administrator credentials (for Windows) or root (on Unix systems), can provide patching levels for both operating system and third-party software, as well as vulnerabilities in system configuration.
Some tools offer a register feature that enables enterprises to map their assets to threats for historic and future analysis. Other tools in third-party appliances include asset discovery, intrusion detection, insider threat detection, user behavior analytics, cloud activity monitoring and more.
Although vulnerability scanners are useful tools, they can be prone to false positives, and some may lack the ability to rate the severity of vulnerabilities within the context of your specific organization. As long as this is understood, vulnerability scanning should form an integral part of deploying servers within AWS.