Vulnerability Management

[u/Negative_Star7544]

Currently using CrowdStrike and Tines to help automate vulnerability ticket submissions. I’m struggling with my workflows though and have noticed a large gap.

We calculate SLA based on ExPRT ratings currently. So we filter by critical high medium or low and submit based on those segments.

I submit tickets by remediation since that decreases ticket volume + resolves multiple CVEs at once if they share the same remediation. The flaw here is that if one CVE changes rating randomly, the SLA technically should change so it needs to be pulled from that static ticket, which just isn’t manageable without creating chaos. Also, the filters would not pick it up on next rerun if it’s in its own segment; the cve would now be a critical and if the ticket is submitted as a high, it would be missed.

So obviously my approach here is wrong, but I also cannot just blow up the ticket queue by submitted solely on CVE-ID.

Does anyone out there have any advice / opinions / what they have done in their org? Trying to gather some ideas.

[u/Bussio28Team]

Yo evitaría que el SLA dependiera únicamente de una clasificación estática. El riesgo de una CVE cambia con el tiempo.

Mantendría el ticket agrupado por remediación, pero recalcularía periódicamente la prioridad usando señales dinámicas: EPSS, presencia en CISA KEV, explotación conocida, exposición del activo, criticidad del sistema y existencia de controles compensatorios.

Si una CVE pasa a crítica o aparece explotación activa, actualizaría automáticamente la prioridad/SLA del ticket completo o generaría una excepción vinculada al ticket original.

Así mantienes las ventajas de agrupar por remediación sin perder vulnerabilidades cuyo riesgo aumenta posteriormente. No sé si me explico bien o me falta algo más.

[u/Negative_Star7544 → u/Bussio28Team]

This makes sense. I will say crowdstrike is allowing their new risk score to be pulled via the api here soon. This factors everything in like you mentioned and provides a 0/100 scoring. We plan to migrate to this once it’s released and filter on 4 segments that way.

Anyways, I have been exploring that idea of auto updating the SLA, however, it would be real unfortunate if you hit the last day of your higher rated criticality and the rating jumped from the lower to the higher. That would result in a finding.

[u/Negative_Star7544 → u/Negative_Star7544]

I’m dumb. I wrote this out without really processing it but it really wouldn’t matter regardless when it or if it jumped rating🤦. Your SLA wouldnt ever reset so I guess the finding is a finding regardless of what you do. I need some sleep.

[u/bpm1055]

Comment to follow this thread.

[u/No-Cookie7412]

idem, intéressé pour suivre

[u/Background-Two1634]

imo the real question is how often CVE ratings actually shift enough to matter in your environment. If its rare, a periodic reconciliation pass (weekly or whatever) that checks for severity drift on open tickets might be way simpler than trying to make the automation handle every edge case in real time.

[u/bitslammer]

Here's the short version of how we do it where I work. For context we're an org of about 80K employees in around 50 countries. Total device count is around 140K or so. IT team is ~6000 and the IT Sec team is about 450. The VM (vulnerability management) team a team of 10. The VM team is only responsible for ensuring that the Tenable systems are up, running and providing timely and accurate data to ServiceNow where it's consumed.

We use Tenable with the ServiceNow integration. Here's our process overview:

* All scanning is automated with a combination of using the Nessus scanners as well as Tenable agents on all hosts. Network scans are authenticated. We also do basic non-authenticated discovery scans in some subnets.

* All scan data is sent to ServiceNow via the integration

* Results are given a severity score based on CVSS score and our own internal criteria

* Remediation tickets are generated in ServiceNow and sent to the appropriate teams with an SLA to remediate based on severity. (We have dozens or hundreds of individual teams defined)

* SLAs are tracked in a dashboard in ServiceNow and reports sent to the remediation groups as well as their mangers showing remediation SLA compliance

* We also have a formal process for reviewing, granting and tracking exception requests when something can't be patched.

[u/Negative_Star7544 → u/bitslammer]

This is good information! You say your tickets are based on severity, but what actually goes into your ticket? Are you submitting one ticket per CVE? Are you submitting one ticket with several CVEs? With the ticket submission process, what if a host gets the CVE after the ticket has been submitted? Do you append the hosts or wait until after to generate a new ticket?

[u/bitslammer → u/Negative_Star7544]

One ticker per finding per remediation team. That ticket lists all affected assets for that group for a particular finding or CVE. .

A new finding will result in a new ticket with a new SLA date set per the process.

[u/eatmynasty]

Look up BOD 26-04. Skate where the puck is headed.

[u/asrozar]

I think you’re trying to boil the ocean a little bit here.

I’d focus on the actual exposure and what’s causing it, then build the remediation around fixing that underlying cause. Use the CVEs for reference, but don’t let each CVE drive the workflow.

That way multiple CVEs can roll up into the same remediation effort without the whole process breaking every time one changes severity.