Ideally, you only allow the ports from the scanner to the other machines at the time that you're running the scan. If you have thousands of servers, you're *not* doing this manually; you're automating the process.
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/
