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 isn't going to answer all your questions, but it may be useful information nevertheless, if only as a "this is what I currently do" sort of report. I currently sync NIST's CVE feed and cross reference it with our Jira instance. This is done using these two tools: https://github.com/jschauma/nvdsync https://github.com/jschauma/nvdXjira Together, the two tools are known as 'cvebot' internally. They consume the following feeds: https://nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-recent.xml https://nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-modified.xml We have one project in our Jira that is used to track CVEs; each CVE gets one ticket in this project to track it. 'nvdXjira' processes CVEs from the NIST feeds: - for any CVE in the feed that we do not already have a ticket for in the VULN project, it creates one - for any CVE that we already have a ticket for, it checks whether or not it contains all the details from NIST; if not, it appends them - for any CVE mentioned in any ticket of _any_ of the Jira projects, it will link those tickets to the VULN ticket as being 'related' 'nvdXjira' consumes configuration files that describe certain actions for the software patterns noted in the CVE as well as for any labels a ticket may have been tagged with. That is, it will automatically: - assign tickets to an individual - create a blocker ticket in another project - cancel tickets - send an email to the given address (mailing lists, for example) notifying it of the ticket - add individuals as 'watchers' to the ticket By default, all tickets in the VULN project are unassigned, but ticket creation triggers a mail to be sent to a list. If a ticket has not been assigned 24 hours after it has been created, and it is still open, then 'nvdXjira' will randomly assign the ticket to a member of a given unix group for triaging. If a ticket that is not resolved has not seen any updates in two weeks, 'nvdXjira' will update the ticket with a nagging comment. This system has a number of advantages and a number of disadvantages. I'm not yet entirely convinced it is worth the effort, but it is getting better with time and depending on how much care you put into the triaging process. That is, simple as it is, it is somewhat of a learning system: the more accurately you tell it about the software in your environment, the better it can assign tickets to the right parties or just close them out. The problem is that it requires a lot of "training". For example, my current configuration has almost 500 "cancel" actions (which are regular expressions, so they catch more than just one applicable software), since a lot of the stuff that comes in simply doesn't apply. The initial triaging of the tickets then falls into three categories: - we know we don't use it => add to cancel-actions - we know we use it => assign, possibly add to auto-assign / auto-notify actions - we don't know whether we use it or not => now go and find somebody who might know The last part is the most painful. If I believe we might use software X here or there, I can point some people at the ticket, who often feel like I tossed them a hot potato and they should drop everything and ugprade their systems, when in fact the best action is just an investigation in how far the CVE does (or doesn't) apply, and to identify follow-up actions and remediations only as a second step. Some teams have embraced this, and now get blocker tickets automatically opened; the plan is to the auto-close the VULN ticket if/when all blockers have been resolved. For some software, you need to coach a large number of different teams to investgiate the impact in their environment. This takes time, and of course every team uses Jira or ticket tracking and triaging in their own unique way. At worst, this system is perceived as creating pointless busy work. On the bright side, the system has also been observed to (without any manual intervention by the security team) have teams patch vulnerable systems based on the input/data from this bot. It has also been useful in tying together efforts across different teams in trying to assess the impact of or patch a given vulnerability. We have further plans to integrate this with port scanning / fingerprinting tools to more precisely be able to assess the impact of certain CVEs. For example, when a CVE for nginx comes in, and we can identify the hosts that are currently running nginx and then track down host owners to assign the tickets do, we end up with a nice graph of possible impact. Having a unique Jira project for all this with one ticket per CVE allows us to get lots of numbers that pointy-haired managers like. Querying that by, for example, CVSS score (which gets added as a label to each ticket) provides for some additional information. As I said, I'm still ambivalent about whether or not it creates more ill will amongst teams receiving the tickets that it's worth, or if it's just a question more accurate training of the system to better auto-assign / auto-close until it's a less annoying burden for the security team to triage the unassigned tickets. Anyway, hope you find this useful. -Jan
pgpLvC_B185hI.pgp
Description: PGP signature
_______________________________________________ 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/
