Free, Web Application Vulnerability Assessment Essentials: Your First Step to a Highly Secure Web Site

If an organization isn't taking a systematic and proactive approach to web security, and to running a web application vulnerability assessment in particular, then that organization isn't defended against the most rapidly increasing class of attacks. Web-based attacks can lead to lost revenue, the theft of customers' personally identifiable financial information, and falling out of regulatory compliance with a multitude of government and industry mandates: the Payment Card Industry Data Security Standard (PCI) for merchants, HIPAA for health care organizations or Sarbanes-Oxley for publicly traded companies.  In fact, the research firm Gartner estimates that 75 percent of attacks on web security today are aimed straight at the application layer.

Conducting Your Vulnerability Assessment: The First Steps

There are a number of reasons your organization may need to conduct a vulnerability assessment. It could be simply to conduct a checkup regarding your overall web security risk posture. But if your organization has more than a handful of applications and a number of servers, a vulnerability assessment of such a large scope could be overwhelming. The first thing you need to decide is what applications need to be assessed, and why. It could be part of your PCI DSS requirements, or to meet HIPAA requirements. Or the scope could be the web security of a single, ready-to-be-deployed application.

Once you've figured out the scope, you need to prioritize the applications that need to be assessed. If you're accessing a single, new application, that decision is easy. But if you're on the precipice of accessing every web application in your architecture, you have some decisions to make. Whether you're looking at the web security of applications your own, or only those that take part in online sales transactions, you need to inventory and prioritize the applications to be assessed.

Depending on the scope and purpose of your vulnerability assessment, it makes sense to start looking at the web security of your crucial applications first - for instance, those that conduct the most transactions or dollar volume - and work down from there. Or it could be starting with all applications that touch those that process and store sales transactions.

No matter your scope, or the purpose of your vulnerability assessment, other aspects of your architecture always need to be considered when listing and prioritizing your applications. For instance, any externally facing applications - even those that don't contain sensitive information - need to be given high priority. The same is true for externally hosted applications, whether they are Internet-facing or directly connected to back-end systems. Any applications that are accessible by the Internet, or hosted by others, should be subject to a vulnerability assessment. You can't assume that an application is secure just because it is hosted by a third-party, just as you can't assume that just there is no risk just because a web application, form, or entire site doesn't handle sensitive information. In both cases, any web security vulnerabilities could very likely lead an attacker directly to your most critical network segments and applications.

The Vulnerability Assessment

Now you're ready for the vulnerability assessment. Believe it or not, much of the hard work is already done: deciding the scope, and then classifying and prioritizing your applications. Now, assuming you've already acquired a web security scanner and have identified who will conduct the manual scan for business logic errors, you're ready to take a whack at your application. 

The resulting report, based on the security health of the application, will provide you a list of high, medium, and low priority vulnerabilities. At this point, you'll need someone to vet the automated vulnerability assessment results to find any false positives, or vulnerabilities identified by the scanner, but don't actually exist. If it seems overwhelming, don't fret; we'll delve into how to prioritize and remedy these web security vulnerabilities in the next installment. About the same time as your automated vulnerability assessment, the manual assessment will be underway. During the manual assessment, the expert will look for logic errors in the application: Is it possible for users to conduct transactions in ways the developers hadn't anticipated? Such as the ability of someone to tamper with application values that are being passed from the client to the server to alter the price of an item. The manual vulnerability assessment will end with a list of all vulnerabilities to web security found, and the assessor should prioritize the risks posed by each problem - based on the ease of exploiting the vulnerability, and the potential harm that could result if an attacker is successful.

Now you have your list of web security vulnerabilities, both technical and logic. And, if your organization is like most others, you have some remedying work to do. The challenge now is to prioritize what needs to be fixed, so that your existing applications can be hardened, and those being built can be remedied and safely placed into production.

While the list of web security issues may be long, you've completed the first major phase on the road to a highly secure application. Take comfort in the fact that your vulnerability assessment has identified problems in your applications before they were attacked by competitors, lone-hackers, or organized crime. In the next article, Effective Web Application Vulnerability Remediation Strategies, we'll show you how to prioritize your remediation work so that development time isn't prolonged, and existing applications at risk are remedied before they can be attacked.