In our last Vulnerability Management Evolution post we discussed scanning infrastructure, which remains an important part of vulnerability management. But we recognize that most attacks target applications directly, so we can no longer just scan the infrastructure and be done with it. We need to climb the stack and pay attention to the application layer, looking for vulnerabilities in application as well as the supporting components. But that requires us to define an ‘application’, which is surprisingly difficult.

A few years ago, the definition of application was fairly straightforward. Even in an N-tier app, with a variety of application servers and data stores, you largely controlled all the components of the application. Nowadays, not so much. Pre-assembled web stacks, open source application servers, third party crypto libraries, and cloud-provided services all make for quick application development, but blur the line between your application and the supporting infrastructure. You have little visibility into what’s going on behind the curtain, but you’re still responsible for securing it. For the purposes of our vulnerability/threat management discussion, we define the app as presentation and infrastructure. The presentation layer focuses on assembling information from a number of different sources – either internal or external to your enterprise. The user of the application couldn’t care less about where the data comes from. So from a threat standpoint you need to assess the presentation code for issues that put devices at risk.

But your focus on reducing attack surface of applications also requires you to pay attention to the infrastructure. That means the application servers, interfaces, and databases that assemble the data presented by the application. So you scan application servers and databases to find problems. Let’s dig into the two aspects of the application layer to assess: databases and application infrastructure.

Database Layer

Assessing databases is more similar to the scanning infrastructure than applications – you look for vulnerabilities in the DBMS (database management system). As with other infrastructure devices, databases can be misconfigured and might have improper entitlements, all of which pose risks to your environment. So assessment needs to focus on whether appropriate database patches have been installed, the configuration of the database, improper access control, entitlements, etc…

Let’s work through the key steps in database assessment:

• Discovery: First you need to know where your databases are. That means a discovery process, preferably automated to find both known and unknown databases. You need to be wary of shadow IT, where lines of business and other groups build their own data stores – perhaps without the operational mojo of your data center group. You should also make sure you are continuously searching for new databases because they can pop up anywhere, at any time, just like rogue access points – and they do.
• Vulnerabilities: You will also look for vulnerabilities in your DBMS platform, which requires up-to-date tests for database issues. Your DB assessment provider should have a research team to keep track of the newest and latest attacks on whatever database platforms you use. Once something is found, information about exposure and workarounds & remediations, is critical for making your job easier.
• Configurations: Configuration checking a DBMS is slightly different – you are assessing mostly internals. Be sure to you check the database both with credentials (as an authorized user) and without credentials (which more accurately represents a typical outside attacker). Both scenarios are common in database attacks, so make sure your configuration is sufficiently locked against both of them.
• Access Rights and Entitlements: Aside from default accounts and passwords, focus your efforts on making sure no users (neither humans nor applications) have additional entitlements that put the database platform at risk. For example, you need to ensure credentials of de-provisioned users have been removed and that accounts which only need read access don’t have the ability to DROP TABLES. And you need to verify that users – especially administrators – cannot ‘backdoor’ the database through local system privileges. Part of this is housekeeping, but you need to pay attention – make sure your databases are configured correctly to avoid unnecessary risk.

Finally, we know this research focuses more on vulnerability/threat identification and assessment, but over time you will see even tighter integration between evolved vulnerability/threat management platforms and tactics to remediate problems. We have written a detailed research report on Database Assessment, and you should track our Database Security Platform research closely so you can shorten your exposure window by catching problems and taking action more quickly.

Application Layer

Application assessment (especially of web applications) is a different animal. Mostly because you have to actually ‘attack’ the application to find vulnerabilities, which might exist within the application code or the infrastructure components it is built on. Obviously you need to crawl through the app to find issues to fix issues. There are a several different types of app security testing (as discussed in Building a Web App Security Program), so we will just summarize here.

• Platform Vulnerabilties: This is the stuff we check for when scanning infrastructure and databases. Applications aren’t ‘stand-alone’ – they depend on infrastructure and inherit vulnerabilities from their underlying components. The clearest example is a content management system, where a web app built on Drupal inherits all the vulnerabilities of Drupal, unless they are somehow patched worked around.
• Static Application Security Testing (SAST): Also called “white box testing”, SAST involves developers analyzing source to identify coding errors. This is not normally handled by security teams – it is normally part of a secure development lifecycle (SDLC).
• Dynamic Application Security Testing (DAST): Also known as “black box testing”, DAST is the attempt to find application defects using bad inputs, using fuzzing and other techniques. This doesn’t involve access to the source code, so some security teams get involved in DAST, but it is still largely seen as a development responsibility because thorough DAST testing can be destructive to the app, and so shouldn’t be used on production applications.

Web App Scanners

But the technology most relevant to the evolution of vulnerability management is the web application scanner. Many of the available vulnerability management offerings offer an add-on capability to scan applications and their underlying infrastructures to identify vulnerabilities by automating the types of attacks typically used by web attackers. So what’s the difference between a web app scanner and DAST? Mostly the depth of analysis. Web app scanning can (and should) happen both before and after deployment, and tends to be the responsibility of the security and/or audit team.

The key capability of a web application scanner is automation of the typical attacks launched against web applications – such as cross-site scripting (XSS), SQL injection, and directory traversal. Most of the web app scanners available today offer from 25 to 40 distinct attacks to test. You will also see a lot of verbiage about supporting attack lists such as the OWASP Top 10 and the SANS 20 Critical Security Controls. Make sure the tool you select can perform a comprehensive set of attacks against your applications.

But a number of the attacks in those lists fall outside the purview of an automated scanner, and target application logic flaws. Keep the generic nature of those lists in mind as you use them. And understand the inherent limitations of any tool launching automated web attacks. Your tool should track known vulnerabilities for common application platforms, from PHP through full content management and blogging systems, such as Drupal and WordPress.

The other key feature to consider is accuracy. Applications are complicated beasts, and typically have a number of controls in play at any given time. So any automated tool inevitably generates a bunch of false positives, and every alert needs to be investigated by a human to determine whether it represents a real issue. Part of your evaluation process should involve using the scanner against some existing applications to evaluate the number and type of false positives produced. You can’t avoid them completely, but you can minimize the impact and look for a better signal:noise ratio. Don’t buy a tool that creates more work than it eliminates.

Human Factors

There are limitations to how much any DAST or Web App Scanner can find. There is no way for an automated technology to detect logic flaws within an application. So to truly understand the vulnerabilities in an application you also need a human to check the logic, respond to the error codes, and generally work through the false positives. We are big fans of tools, as they can do the grunt work and provide a level of code coverage not available or affordable using manual techniques. But you always need a skilled analyst to wade through the results and understand what is really an exposure that needs to be dealt with immediately.

With that we have covered the core capabilities of an evolved vulnerability management platform. But features do not a platform make, so next we will dig into some enterprise features needed for a vulnerability management program.