Securing Your Application Perimeter: What to Test for Vulnerabilities

Wednesday, September 05, 2012

Fergal Glynn

68b48711426f3b082ab24e5746a66b36

Article by Jasmine Noel

Enterprises have been scanning web applications for security vulnerabilities for some time now.

So what’s the big deal between doing some application scans and securing your application perimeter?

Well the first thing is the sheer size and scale of today’s enterprise application perimeter – which we define as all of your Internet facing applications– including the enterprise applications accessed by mobile users, including SaaS provided applications used by the enterprise, platform and infrastructure as a service interfaces used by the enterprise, and web infrastructures inherited from recent mergers and acquisitions.

That is A LOT of applications for a typical enterprise. When you have to secure a perimeter with so much sprawl you quickly figure out that you must answer a fairly basic question – what should I be testing for vulnerabilities? As we’ve seen this is not a trivial question.

Secondly, when dynamic scanning engines were first designed they were primarily created as tools for penetration testers to use typically on a few select web applications deemed critical enough to warrant serious security testing. But times have changed, every Internet facing application is now a potential attack surface – every perimeter application needs vulnerability assessments.

To make matters more interesting, the speed at which new applications are being developed, hosted and (hopefully) decommissioned gives enterprises an application perimeter that is constantly evolving. This means that your security assessments must be completed several times a year to monitor and manage the integrity of your application perimeter.

Before you can even start thinking about an application security program to do routine testing you still have to answer that basic “what should I be testing” question. Enterprises typically do not have an accurate inventory of all their externally facing applications – i.e. they can’t readily answer that basic question.

The first step in answering that question is to provide the solution with some hints on where to start looking.

In a perfect world you’d be able to provide a single domain name mycompany.com or myorganization.org and the discovery engine would do the rest. In the real world however, the speed, accuracy and thoroughness of discovery results is still a function of the level of information you can provide about your perimeter.

Fortunately most organizations have plenty of data to get a web application discovery process started. For example, if you know a list of your domain names, a list of IP address ranges or can provide an export from your DNS service or your network port scanning tools, this will provide more than enough data to begin with.

Other types of information – such as keywords that are typically used in corporate domains – can also be useful for detecting applications that fit your corporate profile but may be outside the network ranges or domain patterns that you know about.

It is really important to find the web applications you don’t know about because you can’t secure what you can’t see. That is why inventory knowledge is so powerful – you can make better decisions on what to test, how to test it and therefore get better results out of your application security program.

Fortunately the first step to getting that inventory knowledge on your application perimeter is fairly simple.

Cross-posted from Veracode

Possibly Related Articles:
7581
Vulnerabilities
Information Security
Testing Application Security Vulnerabilities Scanners Penetration Testing Network Security Perimeter Security
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.