Simplifying Nessus security scans with a spreadsheet model

Required Tools

You will need a spreadsheet program such as Microsoft Excel or OpenOffice (openoffice.org). For scanning tools you may use your commercial scanner, or download Nessus (nessus.org) and NMAP (insecure.org).

Step one: Collect inventory

Create a spreadsheet that lists all the systems you manage and the following columns: [TABLE]

So it might have a record set like the following:

[TABLE]

Completing the initial inventory of your network will take some doing, and it may require an overnight scan to cover the entire network. However, once you have the inventory you won't need to resort to mega scans for a long time. If you have an inventory of your network already, then you can jump to step two.

For large networks it's best to start with an NMAP or Nessus scan to collect the host names and related information. The owners and purpose data will take some time to populate, but this data may be gathered over time. Once you unplug a highly vulnerable system on the network, the owner usually becomes apparent very quickly. At the very least, define the IP addresses, host name, FQDN if known and OS information on systems attached to the network. Import existing data to the spreadsheet or run a scan and dump the information out as comma separated values.

Step two: System classification

The next step is to categorize the host lis

To continue reading for free, register below or login

Requires Membership to View

To gain access to this and all member only content, please provide the following information (all fields required):

First Name:
Last Name:
Country: Select... Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Congo, Democratic Republic of Cook Islands Costa Rica Cote D'Ivoire Croatia Cuba Cyprus Czech Republic Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Gambia, The Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard and McDonald Islands Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Korea, North Korea, South Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macau Macedonia Madagascar Malawi Malaysia Maldives Mali Malta Man, Isle of Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia Moldova Monaco Mongolia Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island Northern Mariana Islands Norway Oman Pakistan Palau Palestine Panama Panama Canal Zone Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Romania Russia Rwanda Saint Helena Saint Kitts and Nevis Saint Lucia Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia and Montenegro Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and South Sandwich Islands Spain Sri Lanka Sudan Suriname Svalbard Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand Timor-Leste Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu U.S. Minor Outlying Islands Uganda Ukraine United Arab Emirates United Kingdom United States Uruguay Uzbekistan Vanuatu Vatican City Venezuela Vietnam Virgin Islands Wallis and Futuna Islands Western Sahara Yemen Zambia Zimbabwe
Email Address:

I would like to receive a FREE subscription to Information Security magazine online.
YesNo

Do you manage, evaluate, recommend, implement, support or purchase security products, software or services?
YesNo

Please estimate the yearly security budget for your entire organization including all security products and services.
Please select... Over $10 Million $5 Million-$10 Million $1 Million-$4.9 Million $500,000-$999,999 $100,000-$499,999 $50,000-$99,999 $25,000-$49,999 $10,000-$24,999 Less than $10,000 None

What is your role in purchasing IT related products and services? (Check all that apply)
Technical decision maker
Financial decision maker
Recommend/Specify
Evaluate products
Implement Products/Services
Determine Needs
Create Security Strategy
None

By joining SearchSecurity.com you agree to receive email updates from the TechTarget network of sites, including updates on new content, magazine or event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile or unsubscribing via email.

TechTarget cares about your privacy. Read our Privacy Policy

Generally, I recommend that you use the worksheet's sort function to organize the data by criticality, then by purpose. This way, production Web servers, less important desktops and R&D systems are separated even if they reside on the same /24 network. The next major classification would be the OS and version. Such a classification would have a breakdown of the production and QA Web servers, desktops and development systems by OS and version. This is beneficial when a security vulnerability targeting a specific OS and version is announced. You can quickly determine which systems are vulnerable, and the criticality of the system can drive your patching order.

You can organize the data anyway that meets your particular security needs. These are just some helpful choices I have seen work well in the real world. Also, by having your production systems called out, you can take the proper precautions in running your scans as to avoid outages. You may also extend the spreadsheet with other fields as you please.

Step three: Scanning

With your systems list broken down into manageable segments, the next step is to set up your scan jobs. In Nessus, I generally name new scan jobs with the same names used in the spreadsheet. For example, I may have a job named "Production Web servers" that contains the entire list of IP addresses from the relevant server grouping in the spreadsheet, or a job named "New York Desktops," again using the same labels used in the spreadsheet. This approach provides a simplified dashboard-like interface that makes it easier to target specific environments when setting up jobs.

Coordinating job names offers you the benefit of improved performance, because it minimizes the number of plugins used by the scanner to only those needed for a specific platform. In the above example, I have a list of production Web servers. If they all are Linux-based, then my plugin selection can be limited to a handful of platform-specific issues. There's no reason to waste network bandwidth scanning for the latest Windows vulnerability when you have a Linux Web server.

Most scanning tools will accept a list of session profiles as described above. If you are using a tool other than Nessus, check your product documentation for details on how to set up your particular scanner to accept profiles that define a scan session.

If you are using port scanners like Nessus, then it's best to break up your target files into simple tab-delimited text files. For example, I can cut and paste or export the Web servers list to a text file for use by NMAP. NMAP has a flag whereby an external file can be used to enumerate hosts for scanning. The following text is from the NMAP MAN page:

It's useful to have both the NMAP and the full-blown scanner working side-by-side. The recent W32/NetSky-Z worm, for example, opened a backdoor listening on TCP port 665. If I only used my preset scan jobs I would need to scan all Windows subnets for the worm, but because I had my NMAP host files configured I was able to execute three commands and use the port flag to only scan for 665. The scans were done in less than 15 minutes.

Building a spreadsheet to divide your network into manageable IP spaces may take some time. However, the result is worth the initial investment when you find you have a powerful vulnerability management system at your fingertips.

[TABLE]