Cloud 101CircleEventsBlog

For Game-Changing Cloud Workload Protection, Focus on Quality Over Quantity

For Game-Changing Cloud Workload Protection, Focus on Quality Over Quantity

Blog Article Published: 03/27/2024

Written by Tenable Cloud Security.

The infamous Log4J software vulnerability shook the software industry in 2021 by catching much of the IT security community unprepared. Log4J is used in nearly every modern application, so the flaw impacted enterprise cloud services globally.

What is the preferred way to prepare for the next vulnerability showstopper - and for vulnerabilities in general? Coping with vulnerabilities isn’t a matter of mitigating all findings. Rather, you should adopt a manageable approach by correlating vulnerabilities across OS packages, applications, libraries and more, to determine their potential business impact, prioritize and mitigate accordingly.

To improve your resilience to the next widespread vulnerability, it is essential that you understand common and optimal workload protection practices.


What Is Cloud Workload Protection (CWP)?

A cloud workload is an application, service, capability or specified amount of work that consumes cloud-based resources such as computing or memory power. Cloud workloads include virtual machines, container images, runtime containers and serverless functions.


Figure - The many different “faces” of a cloud workload

Born in the complex mass of infrastructure and policy that make up cloud environments, cloud workloads often have flaws and weaknesses that can expose sensitive data and be exploited. The cloud’s constantly-changing nature makes such issues likely to crop up at any time. A key pillar of a cloud security strategy therefore involves protecting workloads from threats that can compromise their integrity, and lead to data breaches and security incidents.

Cloud workload protection (CWP) as commonly practiced involves applying a mix of security controls and actions throughout the workload lifecycle. This includes ongoing scanning of workloads to identify vulnerabilities, malware, misconfigurations, suspicious activity, secrets or sensitive data exposure, and other weaknesses. It includes prioritizing the most critical risks, informing stakeholders, and remediating and responding. Compliance is another focus area of CWP common practices but can be a “false friend” in that it is no guarantee of security.

In summary, workload protection is the process – and a security and compliance best practice – of preserving workload integrity and notifying stakeholders, such as DevSecOps teams, of risks requiring mitigation.

Here’s what’s wrong with common approaches to cloud workload protection:

  • Overfocusing on workload compliance and assessing workload risk in a vacuum
  • Trying to tackle as many vulnerabilities as possible
  • Focusing on the tool and overlooking process

Let’s take a closer look.


The Wrong Way of Thinking about CWP

Many CISOs want a “set and forget” type of tool for protecting cloud workloads – but effective cybersecurity doesn’t work like that. No CWP tool provides workloads with total protection. In reality:

  • You will never have bulletproof workloads
  • There will always be workload-related misconfigurations and security posture issues caused by the interplay of tens of thousands of cloud infrastructure components
  • Cybersecurity is too complex to compartmentalize management of cloud workload risk

Part of the misconception and misuse around CWP tools comes from their common use for addressing compliance. Using a CWP solution for compliance is important as you want to continually scan workloads for regulatory violations that can put sensitive data at risk. Regulatory standards also offer good ideas for security best practices for workloads and cloud security posture. However if you use your CWP tool to tick the compliance checkbox, you are likely not using it as effectively as possible. More importantly, as noted, being cloud compliant doesn’t mean your environment is secure. Your auditors and compliance teams may be satisfied but you may miss understanding or addressing workload risk that can have serious impact.

And risk severity does not determine a vulnerability’s true impact. Finding a critical Common Vulnerabilities and Exposures (CVE) is not enough to instruct teams to remediate. In the multilayered cloud, a vulnerability’s seeming severity may be offset by a mitigating policy or permissions set that protects against potential risk coming to fruition.


The Key to Effective CWP – Best Effort Prevention

A CWP tool can reveal tens of thousands of vulnerabilities. You must prioritize which to address first, and how. The key lies in assessing vulnerabilities for remediation based on their correlated true risk.

CWP tools don’t provide unequivocal workload protection, rather, are one security component in an ecosystem. CWP tools contribute to this ecosystem and receive correlated intelligence from the other security components, including related to cloud and Kubernetes configurations, as well as identities and their access to resources – and even infrastructure as code. An integrated approach to cloud security surfaces vulnerabilities not just in their volume and severity but by what actually needs remediating.


How to prioritize a vulnerability for remediation?

Every vulnerability finding is different and has its own potential impact. Determining its impact requires assessing many factors, including the affected resource’s function and risk factors.

To determine vulnerability impact, you must have and maintain a full and continuously updated inventory of all workloads (applications, services,...), assets (data and other resources), identities and infrastructure in your cloud environment. It should include a software bill of materials (SBOM). Enrich the inventory by continually categorizing its components by business function, sensitivity and other relevant labels.

This context-rich inventory enables you to correlate vulnerabilities across OS packages, applications and libraries. To improve your impact-analysis accuracy, factor in additional workload characteristics, including:

  • Network exposure - Not just public exposure of assets but any network configuration that creates wider exposure such as being publicly available on the internet.
  • IAM and permission levels - A relationship map of entitlements between resources and identities, to assess risk related to excessive permissions.
  • Security posture of all resources such as identities - Understanding which resources have poor security hygiene can reveal inflated risk of a workload vulnerability.
  • Exposure of dependencies – Components that are not within your control but will be affected by a vulnerability.
  • Third-party exposure - Ensure that communications are in place for third-party partners to inform you of their vulnerability exposure as such incidents can put your data or network at risk.

Understanding the full impact also requires taking into account a workload vulnerability’s potential blast radius and business implications. Consider, too, how likely it is – or not –that a given vulnerability will occur.


Scanning for vulnerabilities and malware

Whether performed by a cloud workload protection tool or manually, vulnerability scanning involves checking for weaknesses or flaws in software or configurations that could be used maliciously to gain access, steal data or cause damage. This includes looking for outdated software versions, unpatched vulnerabilities and weak passwords. It also involves looking for malware such as viruses, worms, and ransomware, as well as suspicious files, processes and any network activity that may suggest the presence of malware. Integrated cloud security platforms prioritize and put findings in context.


Your Playbook for Taking Mitigating Action

After workload vulnerabilities have been prioritized as having potential for critical business impact, what’s next? Taking mitigating action is where the cloud security trifecta of technology, best practice process and people comes together.


Remediation

Effectively managing workload risk requires remediating high-risk vulnerabilities. Your CWP solution will integrate the critical vulnerability findings in your organizational workflows such as Jira, ServiceNow and Slack.

Teams on the receiving end will be able to take investigative and follow-up actions that include:

Step 1. Querying logs. Logs help determine if unusual activity points to an incident having occurred. CWP solutions typically store cloud provider logs (such as AWS CloudTrail) for activities going back six months or more. Teams can use logs to make smart and predefined queries to research and better understand the vulnerability. They can also conduct forensic analysis, including of network misconfigurations, and review security alerts.

Step 2. Responding to the scanning results. Stakeholders use the vulnerability management tools and your organizational processes to respond to findings. Today’s tools automate scanning, prioritization of the findings in context, remediation, and even reporting, simplifying efforts – and helping teams focus on the risks of greatest import. Be sure teams have a clear idea of what – when an incident has transpired – needs to be checked to determine any fallout from exposure.

Step 3. Patching and remediation. Teams must be able to remediate the most critical vulnerabilities using - for practical and productivity reasons -the fewest people resources.

You should have a checklist and procedures for patching regularly and, for serious detected vulnerabilities, on demand. The process should define:

  • Who signs off on the completed patching. Patching can affect business functions so signoff should involve relevant business stakeholders.
  • Testing procedures, separate for each workload, for determining if the patch has resolved the vulnerability.
  • Time goals for patching, ideally defined by potential impact. Consider time goals within regular intervals and for on demand including how soon after vulnerability detection the patching must take place.


Conclusion

The dynamic, distributed and layered nature of cloud makes workloads forever prone to misconfigurations and security posture issues. Cloud workload protection tools are not effective if compartmentalized – such as used for compliance only. Security best practice falls short – and resources are wasted – if teams are expected to tackle vulnerabilities without vetted impact.

The best approach to protecting your workloads is to manage and mitigate vulnerabilities from a risk perspective: fix what matters most. The only way to accurately prioritize the potential impact of a workload vulnerability is with a platform that integrates workload protection among other cloud security pillars and analyzes risk across infrastructure, data, identities, network and applications.

An event on the scale of Log4J is near-impossible to prevent but CWP done right will put you ahead of the curve.

For more information on CWP and how you can integrate cloud infrastructure risk prevention into your security strategy read the whitepaper “Holistic Security for AWS, Azure and GCP: Comprehensive Cloud-Native Application Protection for Multi-Cloud Environments.

Share this content on your favorite social network today!