-
Notifications
You must be signed in to change notification settings - Fork 12
Vulnerability Data in RBA Framework #86
Hello all- long-time RBA practitioner, first-time caller here... I was curious what the community's thoughts were on utilizing vulnerability scan data in an RBA deployment. The idea was raised within my org, and my initial thought was finding a way to implement as a risk factor, but I'm struggling to wrap my head around how to get data from the vulnerability scanner logs (preferably via the Splunk data model) to eventually feed into risk factor calculations.
The other idea proposed was to implement this data as a risk rule itself, which could be the simpler route provided we limit/suppress how often it adds risk to the ecosystem.
Thanks in advance, looking forward to hearing any thoughts or feedback!
All reactions
Replies: 1 comment 6 replies
I like the idea of having this live in a lookup file, that way its easy to update as vulnerabilities are remediated and no longer pose an active risk. And maybe keep a little overlap in coverage, like 7 days, in the event someone was able to take advantage of a vulnerability and got persistence but was slow in the rest of their attack.
You would want the vuln. scans sent to splunk automatically and then build a search that writes the info you want to the lookup file. Or you could do it manually but that would be a pain long term.
Then in your risk incident rule, pull that data in using the lookup command and add a manual risk score based on the severity of the vulnerability and device.
All reactions
So I was thinking if you were to update the lookup to remove systems that are no longer vulnerable, you could have another search that looks at a lookup of resolved_vulns.csv that could reduce the risk of the host by what you increased it by.
If using ES you could create a filed named is_vulnerable, and have it default to no, and use the lookup to populate vulnerable machines in the asset lookup and give more context there too to help keep track of vulnerable machines.
Just some off the cuff ideas.
All reactions
Thanks for that input! A couple interesting considerations in here... first would be thinking about the vulnerability as adding a standing level of risk to an asset until remediated. I've typically worked with "rolling windows" of risk (i.e. risk in past 24 hours, past 7 days), but this definitely makes sense for those that are mindful of the asset's "permanent" risk levels.
Above all, accounting for patching and remediation definitely would need to be a main consideration for any model; one that will hopefully become more clear when we start properly onboarding the data (i.e. will it produce an event with the status of every endpoint, OR will it only produce events when a vulnerability is detected?). My hope is that we could still utilize a single saved search to populate a single lookup with the vulnerability data, but the saved search may have to get fancy in how it presents the status of the asset. For example, using latest() to display the current state, identifying the timestamp for the event in which the state changed, playing with time windows to account for any slow/persistent attacks as mentioned above, etc.
All reactions
Meant to add: we could also use filters depending on whether we want the lookup to only show assets that had a vulnerability in the past X number of days, in order to save a little bit of processing power when the lookup is referenced in the RIR, risk rule, etc.
All reactions
Also depending on your environment, some meta-scoring might be in order. IE with vuln scanner results, there are often machines with dozens if not hundreds of vulns, but usually mediums/lows. Even with highs, things could get out of control. So you can do a saved search like this:
| index=vuln_data sourcetype=vuln_data
| stats by asset, signature, severity
| stats count(eval(LIKE(severity,"Critical"))) as crit_count count(eval(LIKE(severity,"High"))) as high_count list(signature) as sigs by asset
| eval mod_count = 0
| eval mod_count = case(
crit_count = 0,mod_count,
crit_count > 1,mod_count+4,
crit_count = 1,mod_count+2,
true(),mod_count)
| eval mod_count = case(
high_count = 0,mod_count,
high_count < 5,mod_count+1,
high_count > 4,mod_count+2,
true(),mod_count)
| outputlookup vuln_data.csv
Then use that in asset lookups to add the mod_count field, have the sigs |inputlookup'ed to your dashboards or notables, and different risk factors for that field value in mod_count. You could determine what threshold of lows or mediums are relevant to your organization as well, it's just an example.
This meta-scoring stacking is how oldschool RBA asset/identity scoring worked and it gives a lot of flexibility when a flat score or count just doesn't give enough control.
All reactions
Thanks for this insight as well Haylee! Definitely agree on the idea that not all vulnerabilities are created equal, and my colleagues and I had similarly discussed that low and medium severity, may not be worth adding risk based on our main end goals.
Also like how this accounts for multiple vulnerabilities; a rabbit hole I'm slightly afraid to look down, but a realistic scenario all the same!
I believe all the feedback so far has converged on the idea that we: A) want to use a lookup via saved search, and B) would likely have to implement this within our risk calculating for a given notable, as well as any custom risk-based dashboards for best results. Again, thanks to all who have provided input and thoughts so far. Not entirely sure the protocol for GitHub forum upkeep, but I'm happy to close the discussion if I don't see any other posts here soon.