It's a good question, actually. At the end of the day, it's all about what you want to accomplish and the risk trade-offs you're willing to make. In a loosely controlled environment, you can learn a tremendous amount about your risk and management gaps by using credentialed vulnerability scanning. In environments where there is high confidence around how you manage your systems, credentialed vulnerability scanning might be less informative (but in many cases will still reveal a surprise or two).
In my experience, credentialed vulnerability scanning has been so informative (and as I said, sometimes surprising) that I think it's a reasonable risk to accept. I'd be interested to hear more about how folks are restricting credentialed vulnerability scanning access. Thanks, Matt On Tue, Mar 18, 2014 at 12:39 PM, A O Doll <[email protected]> wrote: > Question from a rookie here: > Is it wise to rely on a scanner to check critical points? If the scanner > has its own set of priveleges, is it feasible that someone might use this > as a means to attack the network? > > Also, a suggestion for output: > Each scan is logged in a spreadsheet with a date and time, and any issues > raised. The spreadsheet is emailed internally to the operator, who can then > review it. > > ------------------------------ > Date: Mon, 17 Mar 2014 17:13:55 -0400 > From: [email protected] > To: [email protected] > Subject: Re: [lopsa-discuss] Tracking CVEs / security updates > > > In the past (at companies under PCI compliance) we've had a vulnerability > scanner that runs at intervals (monthly or quarterly) and tells you what > needs to be patched (or covered with paperwork, ie "documentation of > mitigating controls.") It is updated with the latest CVE entries on its own > interval, presumably before scanning. > > The scanner may dump its output into a ticket system, or not. Depends on > how you want to track the work. > > > On Mon, Mar 17, 2014 at 2:23 PM, Phil Pennock < > [email protected]> wrote: > > What are people currently using for tracking status of security updates > of software which you depend upon in production? This is separate from > "apply vendor security updates" as it pertains to the items which you > build from source or with custom packaging, because it's a core part of > the line of business, or for whatever other reason. > > Just tickets in your regular ticketing system, perhaps in a special > queue? Something else? What sort of automation? > > Eg, a vendor security notice (Ubuntu USN or whatever) comes in; does it > tie into existing tickets with CVEs already tracked and handled, or is > it a new issue? Is it partly for something already dealt with, but > there's an extra CVE which was fixed and which needs a new rollout? > How do you track when you'll need customer/client notification, vs just > being able to hotfix? How do you track release qualification status? > > If you're using an existing ticketing system with some customisation, > are there any templates which you can share? > > Thanks, > -Phil > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > > > > _______________________________________________ Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list > provided by the League of Professional System Administrators > http://lopsa.org/ > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
