Joris,
Yes, multiple tickets for the same issue will then sit in the queue. (or not if they closed or moved the ticket; itâll come right back on the next scan)
Their tickets are not my responsibility so I do not interfere with what they do with the tickets.
If something cannot be fixed, you (or they) can say so using a note on the result in question and override the result. (accepting the situation or explain why it is a false positive or something).
You can configure the override to be valid for all future scans of the particular task (or all tasks) (and for some time etc.â) which avoids new tickets being created.
I doubt you can or even want to keep track of their tickets. Strange things happen to tickets, some even get set to resolved while the issue is clearly notâŠ
I understand you do not want to clutter the ticketing system but it only gets that way (which should make alarm bells ring somewhere) if they donât do their job.
When you do not report a finding because the same finding was there last month and someone threw that ticket away⊠youâll get nowhere.
(Donât you have anything written down about how long a certain CVSS score vulnerability may exist when found?)
For reporting we make reports manually based on some filters to group certain systems and the result counts. (yes, we put the numbers in excel and make a nice graph)
We have too many systems to report on every task separately. Even general reports are not very helpful because systems and vulnerabilities (or non-compliances) come and go.
(We named tasks according to groups to filter âm out, for example the name would be âdomain Linux â system xyzâ; you cannot (easily) filter on the comments but we use those to quickly identify if itâs a private or public system and usually we have the target IP in there as well)
We can show which groups have the most issues and where improvements are clearly visible. Usually we manually point out the big improvements and not so much do any shaming; the numbers, graph(s) and tickets do enough. From my experience, shaming doesnât improve much and can be quite devastating in the long run.
If you have so many results that it would fill queues instantly and bury people under work (letâs face it, this happens a lot in large organizations when you first start scanning); do not automatically make tickets.
(or perhaps only for very high CVSS scores)
Make some tickets manually for the major issues which require a resolution asap. Fix the others using a separate (dedicated) security issue team and enforce a baseline to avoid such findings on new systems. Then later when the organization is more in control you can automate the tickets.
You can also ease your organization in to it all by not starting to scan everything but make them onboard their systems, get admins involved. Besides the obvious vulnerability it also helps them for example check their firewall and encryption configurations.
Tickets and onboarding are not your responsibility, allow their manager do his or her job.
Thijs Stuurman
Security Operations Center | KPN Internedservices B.V.
***@internedservices.nl<mailto:***@internedservices.nl> | ***@kpn.com<mailto:***@kpn.com>
T: +31(0)299476185 | M: +31(0)624366778
PGP Key-ID: 0x16ADC048 (https://pgp.surfnet.nl/)
Fingerprint: 2EDB 9B42 D6E8 7D4B 6E02 8BE5 6D46 8007 16AD C048
W: https://www.internedservices.nl<https://www.internedservices.nl/> | L: https://nl.linkedin.com/in/thijsstuurman
Van: Openvas-discuss [mailto:openvas-discuss-***@wald.intevation.org] Namens Joris
Verzonden: donderdag 7 december 2017 10:13
CC: openvas-***@wald.intevation.org
Onderwerp: Re: [Openvas-discuss] Reporting on delta's between scans on same host
Thanks Thijs!
You made me think about past results and not having to care about it: It is true that the tickets will be only generated on current results. On the other hand, does that mean that you create multiple tickets for the same issue if it appears in 2 consecutive scans?
We're interested in differential for 2 other reasons:
- from a security culture perspective, it would be interesting to report on reduction on vulnerabilities and create some noise about who is doing well and who is not.
- some systems will have issues which cannot be remediated per se. By differential reporting, we can look at new stuff and the report would not be cluttered by old stuff we already knew about / ticketed.
Best regards
Joris
On Thu, Dec 7, 2017 at 10:05 AM, Thijs Stuurman <***@internedservices.nl<mailto:***@internedservices.nl>> wrote:
You can schedule the scans to repeat them.
Personally I wasnât happy with the built in scheduler and automated one myself using python talking to the gvm-tools API.
(https://github.com/Thijssss/openvas_scheduler which might help you automate things yourself, gvm-tools also has example scripts: https://bitbucket.org/greenbone/gvm-tools)
I am not going for differences really; any finding with a CVSS score of > 4 will trigger an alert which sends an email to our ticketing system.
Once a month I start my scheduler which will start any job that hasnât run for 3 weeks or so. (I could leave it running in a screen forever but I still supervise and time it all, when it is not running I got time to update scan systems)
If you go to tasks and click on the Reports > Total number you can see an overview of all the reports and quickly see if things improved or not.
There is a compare button (underneath Actions, next to âdeleteâ so be careful), click on two and youâll get a comparison overview.
Still, why care about past results; itâs the latest scan result that counts in my book.
Thijs Stuurman
Security Operations Center | KPN Internedservices B.V.
***@internedservices.nl<mailto:***@internedservices.nl> | ***@kpn.com<mailto:***@kpn.com>
T: +31(0)299476185<tel:+31%20299%20476%20185> | M: +31(0)624366778<tel:+31%206%2024366778>
PGP Key-ID: 0x16ADC048 (https://pgp.surfnet.nl/)
Fingerprint: 2EDB 9B42 D6E8 7D4B 6E02 8BE5 6D46 8007 16AD C048
W: https://www.internedservices.nl<https://www.internedservices.nl/> | L: https://nl.linkedin.com/in/thijsstuurman
Van: Openvas-discuss [mailto:openvas-discuss-***@wald.intevation.org<mailto:openvas-discuss-***@wald.intevation.org>] Namens Joris
Verzonden: donderdag 7 december 2017 09:51
Aan: openvas-***@wald.intevation.org<mailto:openvas-***@wald.intevation.org>
Onderwerp: [Openvas-discuss] Reporting on delta's between scans on same host
Hello list,
Using the scanner here and are pretty impressed with the results and the web GUI.
Our next move is basically to identify differences between consecutive scans on hosts (was a vulnerability patched? was a new vulnerability introduced on the system?)
Based on my understanding, the system does not support this natively but I can be wrong. How do others solve this issue? Do you build automation around it ?
Best regards
Joris