Attacks/Breaches
9/11/2012
06:44 AM
Dark Reading
Dark Reading
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%

A Guide To Network Vulnerability Management

How do you find the weak spots in your network? Here are some recommendations

[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.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-4988
Published: 2014-07-09
Heap-based buffer overflow in the xjpegls.dll (aka JLS, JPEG-LS, or JPEG lossless) format plugin in XnView 1.99 and 1.99.1 allows remote attackers to execute arbitrary code via a crafted JLS image file.

CVE-2014-0207
Published: 2014-07-09
The cdf_read_short_sector function in cdf.c in file before 5.19, as used in the Fileinfo component in PHP before 5.4.30 and 5.5.x before 5.5.14, allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted CDF file.

CVE-2014-0537
Published: 2014-07-09
Adobe Flash Player before 13.0.0.231 and 14.x before 14.0.0.145 on Windows and OS X and before 11.2.202.394 on Linux, Adobe AIR before 14.0.0.137 on Android, Adobe AIR SDK before 14.0.0.137, and Adobe AIR SDK & Compiler before 14.0.0.137 allow attackers to bypass intended access restrictions via uns...

CVE-2014-0539
Published: 2014-07-09
Adobe Flash Player before 13.0.0.231 and 14.x before 14.0.0.145 on Windows and OS X and before 11.2.202.394 on Linux, Adobe AIR before 14.0.0.137 on Android, Adobe AIR SDK before 14.0.0.137, and Adobe AIR SDK & Compiler before 14.0.0.137 allow attackers to bypass intended access restrictions via uns...

CVE-2014-3309
Published: 2014-07-09
The NTP implementation in Cisco IOS and IOS XE does not properly support use of the access-group command for a "deny all" configuration, which allows remote attackers to bypass intended restrictions on time synchronization via a standard query, aka Bug ID CSCuj66318.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.