Luke Youngblood writes: >One of the real issues I face is a loss of credibility with other >departments in the company that I'm responsible for scanning. All it takes
>is one small outage caused by a Nessus scan and now I'm responsible and the >other department is understandably paranoid about being scanned again. Exactly! It is very hard to explain to non-technical decision makers, customers, etc. that some unknown tool (Nessus) is in the right and their 2-3 year old network device that has never given them troubles has troubles. I'm working with another client today and made sure we do a MAC-by-MAC inventory prior to running any scans. I'd have to believe other Nessus users in non-enterprise land (e.g. small banks) may have to take things from the bottom up as well. It'll take two additional days of assessment time for them, but we'll go into a scan with much better preparation. I've used a checklist for each connected device to have the client sign off that it has been backed up and/or configuration documented in the event the scan causes difficulties. I see four old HP Jet Direct servers and per Sonny's comment, I'm halfway expecting a surprise. >The list you suggest would be helpful in my environment too. Is this something the Nessus folks would be interested in maintaining (I'd prefer to not re-invent any wheels as I've got enough F/OSS projects I've signed onto already). Sonny's comment about recovery steps and/or work-arounds might be something definitely worth including in any such database; e.g. is this just a hard boot recovery or is the configuration usually lost. Jamie _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
