Vulnerability management

Note

Automate the identification, classification, remediation, and mitigation of security vulnerabilities.

Currently, tens of thousands of security vulnerabilities exist, with more being discovered on a regular basis. With this growing threat it is critical to identify vulnerabilities, assess the vulnerability's impact to your business and security posture, and determine course of action. Some actions should be automated, yet many require a risk decision based on downstream impacts of updates, upgrades, linked systems and end-user impacts.

Organizations should strive to build a vulnerability management program that addresses your top security and business risks, and where possible automatically discovers and routes vulnerability findings in near real-time to the appropriate teams. They can then take immediate action using up-to-date common vulnerabilities and exposures (CVE) information. Review network accessibility to create context-based risk scores that help prioritize and address vulnerable resources. Scan AWS workloads for software vulnerabilities and unintended network exposures. As your environment grows and evolves, so should your vulnerability management program. Over time, procedures should be documented, tested, and shared with stakeholders. We encourage you to use automation in every step of your vulnerability management process.

Start

Your environment is a key factor in building the foundations of a vulnerability management program. Organizations should know where vulnerabilities exist, how they increase the threat surface, and avoid the risk of an unknown asset introducing vulnerabilities into the environment. Understand your assets and the asset lifecycle within the environment. Consider the following:

• How are assets provisioned onto the network?

• Are assets created via API call with traceability and explicit permissions?

• What security agents must be installed and configured on those assets?

• How are assets deployed consistently from a secure and approved known good configuration, such as Amazon Machine Images (AMIs), containers, Lambda functions, and IaC templates?

• How will those assets be monitored and tracked throughout their lifecycle for vulnerabilities?

• How will identified vulnerabilities be patched and remediated?

On AWS, there are multiple services and scaling mechanisms available, including partner solutions. These can help you gain a better understanding of your resources and the vulnerabilities affecting them. For example, you can use AWS Config to generate an asset inventory of your resources and monitor your configuration state. You also can deploy managed or custom rules to detect resources that fall out of configuration compliance. You can use Amazon Inspector for automated and scheduled vulnerability scanning at scale across EC2 instances, container images stored in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda functions. All Amazon Inspector findings are prioritized and continuously updated. EC2 Image Builder can be used to create patched, hardened, and approved AMIs from which to deploy your instances. You can also use tags to identify and classify AWS resources, and use AWS Lambda and Amazon EventBridge to automatically tag new EC2 instances that are launched manually or via Auto Scaling mechanisms. Finally, Resource Groups and AWS Systems Manager can be used to organize, manage, and automate tasks on many resources at one time, either on-demand or with a defined schedule.

In the early stages of building a vulnerability management program, start to think about roles and responsibilities, and draft runbooks to remediate identified vulnerabilities. Some considerations might include:

• Who is responsible for creating, managing, and updating the AMIs?

• Who is responsible for managing and monitoring the resource inventory and configuration compliance?

• Who is responsible for managing the vulnerability scanning solution?

• What procedure will be followed for remediating identified vulnerabilities?

Advance

Customers can identify and manage their resources and continuously scan those resources for vulnerabilities. Use a different remediation playbook for each operating system type and have clearly established maintenance windows. Automate alerts to notify resource owners of vulnerabilities, and add human testing to the automated scans that are already taking place. For example, customers can use red teaming exercises and penetration testing to identify vulnerabilities in the system architecture that may have been missed by the automated scanning tools.

On AWS, services to consider include AWS Systems Manager, which allows customers to create playbooks, maintenance windows, and automated patching strategies. These can be applied to specific operating systems or resources based on tag value. AWS Systems Manager Patch Manager and AWS Systems Manager Run Command can help perform patching and run commands on an entire fleet of instances. Amazon EventBridge, Amazon Simple Notification Service (Amazon SNS), and AWS Lambda can orchestrate alerting and remediation workflows. This reduces the mean time to respond and recover from identified vulnerabilities. Since AWS services are tightly integrated, Amazon Inspector findings can easily be forwarded to an EventBridge event bus. This takes finding details and sends them to any downstream system, such as alerting workflows or Lambda functions for auto-remediation. Finally, Systems Manager provides an audit trail of all actions, patches, and maintenance tasks, which is a requirement in many compliance frameworks, standards, and regulations.

In the Advanced stage of building a vulnerability management program, consider regular testing, performing Game Days and table top exercises, formalizing remediation playbooks, and automating most processes. Some examples might include:

• Performing zero-day vulnerability exercises.

• Measuring key performance indicators on a continuous basis, such as mean-time-to-detect, respond, and recover.

• Determining where you can apply force patching to workloads in non-production environments to ensure readiness for production-level patching. An example is creating a remediation playbook within Systems Manager that automates patching during defined maintenance windows.

• Regularly training non-security personnel on company policy and security best practices.

Excel

Organizations that want to excel in vulnerability management will have:

• Both manual and automated mechanisms in place to identify vulnerabilities continuously (scanning tools and penetration tests)

• Regularly tested remediation playbooks driven by automation pipelines

• Accurate and near real-time visibility into resources on the network and vulnerabilities affecting those resources

• Key performance indicators and metrics established to measure the program's performance and improvement over time

• Well-defined roles and responsibilities with regular employee training

• Clear vulnerability management standards and policies that are adopted across the organization

Mature vulnerability management programs include stakeholders outside the core security team, such as the governance, risk, and compliance (GRC), internal and external audit, application developers, product managers, and infrastructure engineers. A vulnerability management policy should be created that clearly outlines what the process is to identify, detect, respond, and recover from vulnerabilities. It must show what is expected from application teams that are provisioning and managing resources on the network, and have remediation service level agreements (SLAs) to follow for various operating system types.

As your environment grows, AWS recommends having a single security account within your AWS Organizations from which to run your security tooling. A delegated administrator account will perform administrative functions for the AWS Services, and may include the security account based on your security services. With this security account in place you can send all vulnerabilities, findings, and logs to this account for centralized security monitoring and alerting. For example, if you're using Amazon Inspector for vulnerability scanning and you have 100 AWS accounts to manage, delegate Amazon Inspector administration to the security account and enable from the Amazon Inspector console. This allows your security team to monitor vulnerabilities from one place rather than having to login to each account, and follows best practices for a multi-account environment. Additionally, distributed security ownership implies that each of your workload teams should have visibility to the vulnerabilities and findings in order to address them directly.

Lastly, regardless of the tooling that is implemented, you should enforce access controls that prevent account users from disabling or modifying vulnerability management tooling and workflows. For example, make sure that users are unable to modify Amazon Inspector, AWS Config, and Systems Manager settings if those services are being used. This can be achieved through IAM policies attached to the user, group, or role, or by implementing SCPs within AWS Organizations.

Review the resources, services, best practices, and partner solutions that have been widely adopted in thousands of other environments to guide your implementation.