It's crucial to have a well-defined process for responding to vulnerabilities, both on a regular schedule and in emergencies. By prioritizing vulnerabilities based on risk and following a remediation schedule, organizations can effectively mitigate threats to their environment. An integrated Threat & Vulnerability Management (TVM) system tracks vulnerabilities over time and guides mitigation efforts.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26, which you can download at https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4. It outlines security principles for cloud providers and cloud consumers. More information on AWS vulnerability management best practices can be found in the AWS Security Hub documentation: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-cis.html

Who should care?

Several roles should pay close attention to this control:

• Security analysts responsible for identifying and triaging vulnerabilities
• IT operations teams tasked with patching and remediation
• Risk managers who prioritize vulnerabilities based on business impact
• Compliance officers ensuring adherence to SLAs and regulatory requirements

What is the risk?

Failing to promptly address vulnerabilities leaves systems open to exploit by attackers. This could lead to:

• Data breaches exposing sensitive customer or corporate data
• Malware infections disrupting business operations
• Website defacements damaging brand reputation
• Ransomware attacks causing costly downtime

The extent of damage depends on the severity of the vulnerability and value of the impacted assets. An effective remediation schedule reduces risk by closing vulnerabilities in order of priority.

What's the care factor?

Security teams should make vulnerability management a top priority. Overdue, unpatched vulnerabilities are low-hanging fruit for attackers. Breaches can inflict major financial and reputational harm.

However, some lower-severity bugs may not warrant dropping everything to remediate. Prioritization is key to balancing security with business needs. SLAs help manage expectations.

When is it relevant?

A vulnerability remediation schedule makes sense whenever an organization:

• Performs vulnerability scanning to identify security gaps
• Needs to triage a large backlog of vulnerabilities
• Wants to fix flaws most likely to be exploited first
• Must meet patching deadlines set by compliance mandates

It may be less critical for disconnected test/dev systems or those storing only low-value data.

What are the trade-offs?

Implementing this control requires:

• Ongoing time and effort to assess and prioritize vulnerabilities
• Potential disruptions to patch production systems quickly
• Opportunity cost of diverting staff from feature development
• Licensing for vulnerability management and patching tools

However, this pales in comparison to incident response costs after a breach. An ounce of prevention is worth a pound of cure.

How to make it happen?

1. Implement vulnerability scanning tools to automatically detect issues
2. Integrate scan results into a centralized TVM platform
3. Assess risk of each flaw based on CVSS severity and asset criticality
4. Categorize vulns as emergency (patch ASAP), high (30 days), medium (60 days), low (90 days) priority
5. Assign remediation tasks to owner and track progress in TVM
6. Develop and test patches in a staging environment
7. Schedule maintenance window and notify stakeholders of impact
8. Deploy patches to production and confirm remediation with re-scan
9. Update TVM and produce metrics showing reduction in risk over time

What are some gotchas?

• Remediation SLAs must be realistic and achievable by IT ops
• Scanning tools require credentials with appropriate permissions (e.g. AWS EC2 instance IAM role) to assess hosts: https://docs.aws.amazon.com/inspector/latest/userguide/inspector_prerequisites.html
• Emergency out-of-band patches can be disruptive to business
• Legacy systems may be hard to patch and require compensating controls
• Patch testing is crucial to avoid breaking changes but takes time
• Decentralized asset management can lead to blind spots in TVM coverage

What are the alternatives?

• Deploying Web Application Firewalls and Runtime Application Self-Protection to detect/block attacks on unpatched systems
• Implementing robust network segmentation and access controls to limit blast radius
• Using immutable infrastructure and rebuilding from known-good images vs patching
• Adopting serverless and PaaS architectures to minimize patching burden

However, these solutions don't eliminate the need to eventually fix vulnerabilities at the source.

Explore further

• CIS AWS Foundations Benchmark section 3 on vulnerability management: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls.html
• AWS EC2 documentation on automating patches with Systems Manager: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/systems-manager-automation.html
• NIST SP 800-40 Guide to Enterprise Patch Management Planning: https://csrc.nist.gov/publications/detail/sp/800-40/rev-3/draft

By prioritizing based on risk, using TVM tools, and sticking to SLAs, organizations can reduce their attack surface in a sustainable way. But it requires ongoing commitment.

‍