In this 10 part series, we review the key components that are needed to formulate and apply a consistent, regimented cloud database security program that helps ensure data is only available through authorized access. Part 4 reviewed considerations related to asset discovery. Part 5 below unpacks vulnerability assessments including the step-by-step process and critical areas to check.
Ideally, a data breach will not be the signal that your databases are at risk. Unfortunately, however, that’s all too often the case. We wouldn’t regularly hear about data leaks if organizations knew there was a vulnerability that needed to be fixed before the breach occurred. This is where vulnerability assessments come in.
These assessments should be run regularly against all public cloud databases and backups because the cloud is dynamic and agile; the larger your environment and the more that it changes, the larger your risk profile grows.
Once your security configuration baseline has been established and you’ve gathered a complete database and access inventory, a vulnerability assessment comprising the following steps can be run.
Vulnerability Assessment Steps
- Scan for vulnerabilities - given the ephemeral nature of the cloud, it is nearly impossible to check every database and backup against security guidelines manually; this process has to be automated
- Document the security infrastructure as well as internal and external access
- Evaluate found vulnerabilities
- Specify risk levels; consider data sensitivity, the likelihood of someone exploiting the vulnerability and business impact
- Prioritize issues to be fixed - any sensitive data that’s at risk because of a critical vulnerability should receive the highest priority
- Implement the remediation process
Pro Tip: Tag databases by the business functions they support in order to clearly delineate any business processes that are, or were, at risk.
Areas to check include, but are not limited to:
Authentication / account access management
- Exploitation of privileged accounts
- Guest or public roles
- Roles that should have expired
- User rights
- IAM users in AWS accounts
- Is it enabled?
- Behind VPC
- Backup retention set
- Has access policy set
- Is not publicly available
- At rest and in transport
- Cluster data transfers
- Endpoints using CMK with KMS
- Use of defaults or weak passwords
- Out of the ordinary changes
- User access rights and roles
Updates and patches
- Are they enabled?
Pro Tip: Default passwords and lax requirements as well as demo and test accounts are often used because they speed up initial setup. Don’t do it. While trading security for time is not uncommon, it’s poor practice because these vulnerabilities will ultimately need to be reconfigured.
Besides being good practice, vulnerability scanning and management help achieve compliance with standards such as PCI DSS, GDPR and ISO 27001. Although some standards don’t explicitly state that vulnerability assessments are required, they often do mandate that organizations implement appropriate security measures, test controls, and mitigate risk. (We believe vulnerability assessments are a more effective way of determining database security in the cloud, than say, penetration tests.)
While scans for on premises databases are often set to match cycles corresponding with a particular policy, given the ephemeral nature of the cloud, we recommend running automated vulnerability assessments regularly, ideally scanning daily. This allows prompt action to be taken on the most severe issue in order to minimize the potential for data breaches.
Automating the assessment process promotes operational consistency, allows organizations to scan the entirety of their environment, and helps ensure accurate results. What's more, it saves organizations money in the long run because it provides a way to bypass breaches. Use security tools designed specifically for the cloud to assist with vulnerability assessments. Look for vendors who go beyond checking for standard misconfigurations and allow for customization. For example, many third party tools will rank vulnerabilities by severity. However, what one organization deems to be high severity another may deem to be medium or low. Additionally an organization may not agree with the rationale behind the severity ranking of a vulnerability. Look for vendors that allow you to customize the severity of vulnerabilities in addition to the standard ranking.
Read part 6 of this series where we discuss remediation, including how to proactively reduce risk.