6 Cloud Security Best Practices for Vulnerability Management

Utilize a Vulnerability Scanner

One of the biggest problems security teams face with cloud vulnerability management is a lack of visibility in multi-cloud and hybrid environments. A vulnerability scanner can help automate security tests to identify misconfigurations and compare your environment against a database of vulnerabilities. Utilizing these tools can also help you maintain compliance as you address data security risks.

Some things to consider in a vulnerability scanner:

• The scan should provide context for the vulnerability so that you can prioritize when it needs to be fixed. If a vulnerability is only detected in containers that are not deployed, it may be less of a priority than a vulnerability found in running workloads.
• Integrate code scanning into your CI/CD process to catch vulnerabilities before they deploy live.
• Scan for dependencies in third-party libraries and frameworks, preferably during the building process so metadata is available.
• Use an image scanning tool to discover vulnerabilities in container images.
• Run both external scans for systems that are exposed to the open internet, as well as internal scans, which are done from the point of view of an attacker already in your network.

Understand the Shared Responsibility Model

The shared responsibility model defines what aspects of security the cloud service provider (CSP) is responsible for versus what you as the consumer are responsible for. For example, in a software-as-a-service model, the CSP is responsible for the code of the application, however, you are still responsible for setting up configurations such as multi-factor authentication.

In a platform-as-a-service model, the CSP may be responsible for patching middleware, but that doesn’t necessarily mean that patches are applied automatically. You may still be responsible for testing and pushing the button to deploy the update. Never assume that the CSP is taking care of something. Pay close attention to your service level agreement and reach out to your account representative if you’re unsure of what potential vulnerabilities you’re responsible for.

If you don’t have the resources for extensive vulnerability management, serverless offerings move even more of the security responsibility, including the virtual machine and container runtime, to the cloud service provider and let you focus on front-end development. You should still scan the cloud tasks that you’re deploying in a serverless environment.

Go Beyond Scanning with Penetration Testing

Regular, automated scanning is an essential part of managing vulnerabilities in the cloud, but vulnerability scanning isn’t perfect. It can give false positives or miss vulnerabilities completely. Penetration testing exploits found vulnerabilities to demonstrate the actual impact a successful attack would have on your business operations. Penetration testing should be used in conjunction with vulnerability scanning to catch threats that may have been missed and provide context to the vulnerabilities the scan detected. Penetration testing can help determine which vulnerabilities need to be prioritized based on the conditions that need to be in place for the vulnerability to be exploited and the potential damage the exploit could do to your organization.

When conducting penetration testing in the cloud, you should keep in mind the shared responsibility model and what penetration testing activities are permitted by your cloud service provider. Your service level agreement will likely define the scope of testing that is allowed and how frequently it can be done. This may be a deciding factor in whether to perform black box testing. In this simulation, the testers are given no prior knowledge or cloud access, gray box testing, where limited privilege is given, or white box testing, where penetration testers are given full root-level access.

Pay Attention to Misconfigurations

Misconfigurations are the source of many of the vulnerabilities you’ll encounter in the cloud. Document all of the security-relevant settings in your components and the correct values. Additionally, put in place a system of benchmarking to regularly check for configuration drift.

Here are some common misconfigurations to keep an eye on:

• Storage Access: Authenticated users doesn’t just mean people in your organization. It means all users with an account with that CSP. Make sure that you’re implementing an identity and access management policy that limits access to solely what is needed, and storage buckets are properly configured to only provide access to the users that need it.
• Secrets Management: Take advantage of secret management tools that your cloud provider offers, such as AWS Secrets Manager or Azure Key Vault, to make sure that your passwords and credentials aren’t unknowingly available to the public.
• Ports: Overly permissive access and leaving ports open to the internet are common entry points for attackers. Make sure that you’re restricting both inbound and outbound port access.

You can find more information about cloud compliance from the Cloud Security Alliance. They offer certifications to help you stay ahead of misconfigurations, such as their Certificate of Cloud Auditing Knowledge. 

Don’t Forget Your Containers

According to the Cloud Native Computing Foundation (CNCF), the use of containers increased by 300% between 2016 and 2020. Containers make it easier and faster to test, develop, and launch applications, but this can lead to security being neglected in the race to deployment. Traditional vulnerability scans aren’t typically well suited for containers since they aren’t designed to have the CPU power to run the agents. They also don’t have a traditional network login that would be required for an agentless scan. Container security tends to rely on image scanning and putting in place best practices to reduce image vulnerabilities.

Here are some tips for securing your containers:

• Only use approved images and registries.
• Use signed images and create policies to enforce those signatures so you know container images haven’t been compromised.
• Implement least privilege policies and whitelist files and executables to limit what your containers can run.
• Restrict container privileges at runtime to limit the impact of a vulnerability in your containers.
• Keep logs and monitor things like system calls to detect abnormal behavior. Set up alerts for these triggers, as well as things like excessive resource usage, which is another indicator that something is amiss.
• Scan the hosts running your containers. In the event that a container does get compromised, an attacker may be able to use vulnerabilities in the host to move laterally and compromise other parts of your cloud instance. Additionally, scanning the host makes sure that you haven’t missed replacing a vulnerable image in any of your containers after deploying a fix.

Define Vulnerability Metrics

How do you determine which vulnerabilities to address first? The Common Vulnerability Scoring System (CVSS) provides a standard for rating vulnerabilities, but you also have to keep in mind the context of these vulnerabilities, such as where they are located in your environment and other countermeasures you may have in place to mitigate them. The results of your vulnerability scans and penetration tests will provide you with the context needed to decide which ones to address first. Understandably, you may not have the bandwidth to get to all vulnerabilities immediately, but you should put in place some metrics that you will use to demonstrate to stakeholders that your vulnerability management program is successful. These might include:

• Mean Time to Remediate: When calculating this metric, consider the severity of the vulnerability. Keep in mind also that remediation may not be installing a patch. It may instead be turning off a feature, so the vulnerability is not exploitable, or fixing a misconfiguration.
• Percentage of Systems with Open Vulnerabilities: What percentage of your systems and applications have vulnerabilities, what is the severity of these vulnerabilities, and where are they located (internal vs. internet-facing)?
• Percentage of False Positives and Negatives: Are your tools alerting you to actual vulnerabilities that need addressing, or is time being wasted on false positives and negatives?

Are you interested in collaborating with other security professionals to improve your vulnerability management program? RH-ISAC members can join RH-ISAC’s vulnerability management working group to participate in vulnerability management discussions and exchange of best practices. Learn more about RH-ISAC membership.