Database Vulnerability Scanning

Vulnerability scanning is a very important part of obtaining and keeping a FedRAMP ATO, and generally scanning is a well understood topic.  However, there are some nuances that can make things a bit complicated. FedRAMP requires three types of scanning: Infrastructure, Web App, and Database. 

Infrastructure is straight forward -- this is an authenticated scan of your hosts. Web app scanning is straightforward as well. Using a tool like accunetix to scan a URL or some web server / api. With database scanning it is less clear, and we’ve had the most questions around this aspect of continuous monitoring / scanning. 

Some common questions that we’ve seen: 

• What is an actual database scan? Do you scan the host, or something else? Is it redundant to Infra scan?  

• If you are using a PaaS like AWS RDS from a “shared responsibility” standpoint, who’s responsibility is it to scan the database? Unfortunately, in some cases, the PMO hasn’t helped clarify this and is leaving cloud providers to figure it out. 

• If we don’t have access to affect configuration changes to RDS databases, then how can we scan and remediate the findings? 

Ok, so let’s answer some of these questions: 

• First of all, let’s have a clear definition of a database scan. A vulnerability scan is scanning database ports with a plugin (like the DB Plugin for nessus) and credentials for a privileged database user. What we saw when we ran a credentialed scan on the test databases with database plugins enabled in AWS, were vulnerabilities that can be remediated by SQL commands.  

• If utilizing a service such as RDS from AWS, the responsibility is on the customer. For services like Dynamo DB, there is no way to scan in this way due to the nature of it. AWS had done a good job recently of clarifying responsibility for database scanning and we’ll have a link in the show notes. https://aws.amazon.com/security/penetration-testing/ 

• If you scan and enumerate the vulnerabilities and you do not have access to affect the config changes, then they become vendor dependencies on the POAM. What we saw when we ran a credentialed scan on the test databases with database plugins enabled in AWS, were vulnerabilities that can be remediated by SQL commands.