[The following is excerpted from "A Guide to Network Vulnerability Management," a new report posted this week on Dark Reading's Vulnerability Management Tech Center.]

In most cases, the conduit for a damaging attack against a key application or a server will be the IP network. Deploying an aggressive network vulnerability assessment and management program will help you close vulnerabilities in your applications. This isn't as easy as it sounds, though.

The unfortunate reality of big-business IT is that app developers and security pros often don't collaborate on the best way to address the problems of application and network vulnerability issues. It's important to build a bridge between the app and security side because changes to an application could introduce new vulnerabilities that security pros should know about, while changes to the network could introduce new attack vectors against an application that app developers should know about.

At the end of the day, network vulnerability management should not be seen as a one-time or periodic health check. Instead, network-focused vulnerability management should be viewed as an ongoing, standard IT process.

The best way to minimize the risk that a key application will be attacked and exploited in unforeseen ways is to constantly look for the holes in your network that you know hackers will use to attack your critical systems.

If you're trying to build an approach to vulnerability management from square one, the best place to start is to perform a discovery and an audit. You can't really think about a long-term set of policies and procedures for ongoing network vulnerability scanning until you know where your exposure is and why you're exposed in the first place.

What network vulnerability management is really about is discovering possible attack vectors to each host and device on the network, and addressing them in a way that makes an attack more difficult.

For example, if your environment is running mostly Windows, then log on to a random Web or application server and from a command prompt run a netstat –a to view all of the TCP/UDP ports on which your server is listening.

I recently did this from a random server in my lab environment. I saw many red flags indicating areas I would need to address before placing this server into production. Specifically, TCP 25 (SMTP), TCP 80 (HTTP) and TCP 3389 (RDP) were open, and a TFTP server was running because the server was listening on UDP port 69.

Of course, it's not practical to log on to each server in a large environment and use netstat to determine what ports and services are exposed on a given host. An auditor, as well as an attacker, is more likely to use a vulnerability scanner or a tool like Nmap to quickly port scan an entire subnet looking for hosts that have interesting ports exposed.

During discovery, you may find that all of your routers and switches still have the public read-only SNMP community string enabled. In my lab, I know that I have a few new devices that have the default public SNMP community enabled. As I snmpwalk a few of the new routers, I see that I can easily discover what type of router is in play and what revision of code is running on the chassis. As an attacker, just having that knowledge alone is enough to build a strategy for cracking into a router or switching infrastructure over time.

For an overview of other network vulnerability scanning techniques -- and some tips on how to perform them -- download the free report on network vulnerability scanning.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.