The following is from a presentation I gave on Nessus at NYU.  Please do not use or copy without accreditation to Pamela Dean.  Thanks.


Nessus is a multiple platform client/server remote network security scanning tool. The server is supported on Windows, Linux, Mac OS, and UNIX. Clients can be web based as well as mobile (IOS, Android).

Nessus is capable of scanning multiple targets at once and upon completion of its scan, it raises alerts if it discovers any vulnerability that hackers could use to gain access to any computer that is connected to a network.  It does this by running thousands of checks on a given target, testing to see if any of these attacks could be used to break into the computer or otherwise harm it.

The way Nessus does this is by utilizing plugins to determine which flaws exist on the target hosts. Plugins are small programs that look for specific vulnerabilities. Nessus contains tens of thousands of plugins in more than 47 families.


When Nessus connects to the Internet it automatically downloads the latest plugins which will enable it to recognize and report on the latest known software weaknesses. There is also an embedded scripting language (known as NASL) for writing your own custom plugins.

When Nessus detects vulnerability, it also suggests the best way you can mitigate the vulnerability.


There are many different types of government and financial compliance requirements and guides but of the two licensing models offered by Nessus, one being the Professional Feed for Commercial use and the second being the Home Feed which is free and for personal use only, the Home Feed allows no compliance or audit checks and has some limits including being able to only scan up to 16 IP addresses.

For purposes of this presentation, I googled the following information and grabbed images of PCI DSS audits that were run on another system that used the Professional Feed.

So how does Nessus check Compliance?

Tenable makes an industry assumption. Here’s how:

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed by the credit card industry to help merchants enhance payment account data security. A key component of complying with PCI DSS for all merchants is to have internet-facing e-commerce sites pass a vulnerability scan that does not show any:

  • SQL injection vulnerabilities
  • Cross-site scripting (XSS) vulnerabilities
  • Directory traversal vulnerabilities
  • HTTP response splitting vulnerabilities
  • Out of date or insecure SSL encryption
  • Any vulnerabilities with a CVSS score greater than 4
  • Information leakage issues

Tenable ascertains that since most Nessus Professional Feed users are not PCI Approved Scanning Vendors (ASVs), they are likely performing a vulnerability scan to prepare for an official audit.

Although PCI DSS requires many tests to be performed, Nessus includes at least three families of plugins to assist you in providing a quick overview of your scan results:

  • #33929 PCI DSS Compliance
  • #33930 PCI DSS Compliance: Passed
  • #33931 PCI DSS Compliance: Tests Requirements

When a PCI DSS scan is configured on Nessus, it will automatically collect the results of the scan and report anything that makes a scanned host non-compliant with PCI DSS. This will be reported by plugin #33929, as seen below:

An example is shown below from a host that failed compliance after it was audited for PCI DSS compliance:


As you can read in the description, the Remote web server is vulnerable to cross-site (XSS) attacks, implements old SSL2.0 cryptography, runs obsolete software, or is affected by dangerous vulnerabilities. Many links are also provided to assist the Security Team including more specific output from the plugins.

From Tenable’s Site:

What policies do you audit against?

Tenable has developed several different audit policies for UNIX and Windows platforms. These are available as .audit text files to Professional Feed subscribers on our Tenable Support Portal on the “Downloads” page. Tenable has taken into consideration many aspects of common compliance audits, such as the requirements of SOX, FISMA, HIPAA, PCI, and others while writing these. CIS Benchmarks, NIST, NSA, and other organizations’ recommended best practices are audited against as well.

We also provide files to audit databases, presence of anti-virus software, detection of viruses and searching for plain text sensitive content. Audit files are created and updated regularly both by Tenable staff and the Tenable community.


When I read the description on the example screenshot above that indicated the Host had a vulnerability to cross-site (XSS) I thought about OWASP as an industry standard. OWASP’s TOP TEN is recognized as a standard, so I decided to investigate OWASP and NESSUS to find out what plugins would a Security Professional use to test against the OWASP TOP TEN.

What is OWASP?


Briefly, OWASP (The Open Web Application Security Project) is an open community dedicated to raising awareness about application security by identifying some of the most critical risks facing organizations today. The Top 10 project is referenced by many standards, books, tools, and organizations, including MITRE, PCI DSS, DISA, FTC, and many more. The OWASP Top 10 was initially released in 2003 and minor updates were made in 2004, 2007, and this 2010 release below:

Here are cross-references to each member of the Top 10:

  1. A1: Injection
  2. A2: Cross-Site Scripting (XSS)
  3. A3: Broken Authentication and Session Management
  4. A4: Insecure Direct Object References
  5. A5: Cross-Site Request Forgery (CSRF)
  6. A6: Security Misconfiguration
  7. A7: Insecure Cryptographic Storage
  8. A8: Failure to Restrict URL Access
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards

In 2011, since Tenable is a sponsor of OWASP, it specifically added technology and checks to Nessus scanner to make it easier to find risks identified by OWASP.

Here are steps on how to configure a Nessus application scan that will test for the OWASP Top 10 issues:

  1. Create a new policy. (Policies -> Add)
  2. Under the “General” tab options, set up a scan as you normally would. Ensure at least one TCP-based port scanner is selected and provide a list of ports with web servers running on the host(s). Note: Only use this method if you are absolutely sure you know of all web servers running on the targets. Otherwise, select a port range so that Nessus can detect web servers and applications to audit.


3. Under the “Plugins” tab, ensure the following plugin families are enabled:

  • CGI abuses – This plugin family checks for a wide range of commercial and open source applications that have documented vulnerabilities. These checks include software detection, information disclosure, SQL injection, file inclusion, overflows and more.
  • CGI abuses : XSS – This plugin family checks for a wide range of commercial and open source applications that have documented Cross-site Scripting (XSS) vulnerabilities.
  • Database – Many web applications will utilize a database for storing large amounts of data. SQL injection attacks are designed to target database servers via web applications.
  • FTP – Some sites use FTP for administrators to upload web application content or update the application.
  • General – This plugin family contains plugins that identify operating systems via HTTP, perform a wide variety of SSL checks and more.
  • Service detection – Contains checks for a wide variety of services and technologies, many of which support web servers and applications.
  • Web servers – This plugin family contains over 500 checks for vulnerabilities in popular web servers including Apache, Tomcat, IIS and WebSphere. In addition, this plugin family includes checks for frameworks such as PHP, common web server issues associated with the HTTP(S) protocol, OpenSSL checks and more.


4. Under the “Preferences” tab, there are several drop-down menus with additional configuration options that must be specified:

  • Under “Global variable settings”, select “Enable CGI scanning”. Optionally, the “Thorough tests (slow)” can be enabled and “Report verbosity” can be set to “Verbose” to provide additional vulnerability checks and better reporting.
  • The “HTTP cookies import” drop-down can be used to import cookies as a means for authenticating to the application. This is not explicitly required, but some means of authentication should be provided.
  • The “HTTP login page” drop-down provides over a dozen options that direct Nessus to a custom web application. This includes the URL to the login page (e.g., /application/login.php), login form (i.e., if the login data is sent to a different location), relevant form fields for authentication (the “user” and “pass” variables should be changed to reflect your application, %USER% and %PASS% are pulled from the “Login configurations” drop-down menu) and options that control how Nessus behaves in relation to the authentication process.
  • The “Login configurations” can be used if the application is protected using HTTP Basic Authentication, Digest or NTLM.
  • The “Web Application Tests Settings” drop-down contains several important options for enabling testing of custom applications. The “Enable web applications tests” must be enabled, or Nessus will only scan for known vulnerabilities based on prior public disclosures. This page also contains options for limiting the time to test an application, use of POST requests, the type of argument values to use (refer to the Nessus User Guide for additional information on this option) and more.
  • The “Web mirroring” drop-down directs Nessus’ behavior for mirroring the application, a step performed before tests are calculated and run. The total number of pages or depth of mirroring can be controlled, along with the starting page and a delimited list of regular expressions that are used to match web pages that Nessus will exclude (e.g., logout|emailus.php).


The new OWASP T10 Scan policy has been submitted.



Run the Scan.



Scan Results:


Addendum 1


Addendum 2


Addendum 3



  4. com/nessus-installation-on-backtrack-5/


Compliance Checks FAQ

  1. What do the compliance checks audit against?
  2. How do I create my own audit policies?
  3. Can the audit policies test for “XYZ”?
  4. Do I need to run an agent to perform these checks?
  5. What sort of performance impact will these have on the scanned servers?
  6. What do I need to run compliance checks?
  7. How is a compliance check different than a vulnerability scan?
  8. What systems can be audited?
  9. What policies do you audit against?
  10. Are compliance checks available for all Nessus platforms?
  11. How do I get compliance checks?
  12. Is there a charge for the compliance check plugins?
  13. How do I configure the compliance check plugins to match my security policy?
  14. How do I enable the compliance checks during my scan?
  15. Are compliance checks enabled by default when I do a scan?



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.