Tenable Blog

Recently I gave a presentation at the “SANS Penetration Testing Summit ” titled "Zen and The Art Of An Internal Penetration Testing Program". This presentation outlines the steps required to create a successful program and perform internal penetration testing. There are several key components that must exist to create a successful program:

• Getting Management Buy-In - This is the first and most important step. Management must understand the testing strategy and be kept in the loop on the results and remediation. Business units must also be consulted to determine the impact scanning will have on their environment to establish a schedule for scanning. It does not matter what kind of testing you plan to perform, from vulnerability scans with Nessus to full-blown penetration testing, you must get the approval from management.

Over the past few months, I’ve had the chance to speak with many different federal government customers who have rolled out FDCC compliance programs. These programs feature central management and auditing of large numbers of desktop configurations. A few years ago, I heard a government administrator proclaim that “satellites would fall out of the sky” when these settings went in place, but recently, I hear federal executives speak about a reduction in volume of help-desk calls and fewer virus outbreaks. So how do you know if FDCC is working for your organization?

This blog discusses some key issues to consider when looking at FDCC or any other type of configuration auditing guidelines. I often ask potential customers, conference speakers and federal CIOs the following questions. The answers I receive often provide clues into how effective the overall FDCC program is.

In a recent video interview Bruce Schneier, CTO of BT Global Services, and our very own Marcus Ranum, CSO here at Tenable Network Security discussed the new cybersecurity czar position and how it may, or may not, help to improve the overall state of information security.

Imagine a scenario where you are tasked to audit the security of an organization’s efforts to “cloud-source” applications, operating systems, databases and other aspects of IT infrastructure. You want to fire up your favorite network scanner, Nessus, but are warned that some of the outsourced companies have clauses that prevent auditing, network scanning or security testing. Even still – some of the technology is at the API or SQL level and there isn’t even an identifiable OS to scan. Last, even though you may be able to perform a scan quickly, some of the cloud resources get charged at an hourly rate and the act of auditing costs your company money that the application group did not budget for. Fortunately, passive vulnerability scanning can help audit remote resources that are now off your network and “in the cloud”.

At a recent OWASP meeting in Princeton, NJ I gave a short presentation on some techniques to have Nessus dig deeper into your web applications. There are several approaches to web application testing:

"Blind Tests" - Often a penetration tester is provided a range of address spaces and some rules of engagement to define the parameters of the test. Information such as which IP addresses and/or hostnames are running web servers is not typically provided, nor is a list of which web applications are running on those web servers. Nessus contains functionality to identify running web servers and vulnerable web applications, which is is very useful if you have large amounts of address space to scan. This does not replace manual testing, but provides a starting point for detailed web application tests.