tenable_sc: add tenable_sc.vulnerability.age field

[efd6]

What does this PR do?

Retains a calculated vulnerability age in days from the first and last seen dates.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Closes Tenable SC (vulnerability) pipeline feature request: tenable_sc.vulnerability.age #7198

Screenshots

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-08-02T01:03:31.053+0000

• Duration: 20 min 31 sec

Test stats 🧪

Test	Results
Failed	0
Passed	19
Skipped	0
Total	19

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (3/3)	💚
Files	100.0% (3/3)	💚 5.0
Classes	100.0% (3/3)	💚 5.0
Methods	100.0% (45/45)	💚 12.923
Lines	96.978% (1123/1158)	👍 10.715
Conditionals	100.0% (0/0)	💚

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[chemamartinez]

LGTM

[chrisberkhout]

Looks good!

For me it is counterintuitive that a vulnerability doesn't "age" unless it continues to be seen. I might have called it "exposure_duration" or "days_observed" or something. However, "age" was requested by someone who knows Tenable SC and the domain better than I do so I assume it'll be fine. Also the field description is clear.

[chemamartinez]

For me it is counterintuitive that a vulnerability doesn't "age" unless it continues to be seen. I might have called it "exposure_duration" or "days_observed" or something. However, "age" was requested by someone who knows Tenable SC and the domain better than I do so I assume it'll be fine. Also the field description is clear.

Probably when this event arises it is because the vulnerability was detected in the last scan performed, so in theory it would still exist.

[efd6]

@jgreene-TrappTech Are you able to comment on the concerns above?

[jgreene-TrappTech]

Certainly. We have no attachment to age vs duration or another field. All that we seek is to have this as a calculated field via the pipeline so that we are not modifying the default pipelines or adding to them.

Typically, Vulnerability SLA's mandate that after a vulnerability is discovered, the product owner has N number of days to remediate. So the selection of age or vulnerability.age was derived from that language. As the SLA's vary between compliance initiatives, we simply represent days between first and last seen in the end user's reporting.

Currently we are using tenable_sc.vulnerability.age as a positive integer to indicate the time in days since first_seen and last_seen.

Hope that helps.

[efd6]

Thanks, the second part of the concern is whether events ever come through without a last seen, but with a first seen. Is this ever the case?

For the language and unit choice, I think days is the best given that it matches other fields in the tenable documents.

[jgreene-TrappTech]

First time seen and last time seen appear to be in every tenable_sc.vulnerability document. Where the vulnerability is seen for the first time, the first and last time seen are set to the time that the scan was completed. In a one week look back for one data_stream.namespace there were 4,260,444 hits and zero documents without both last_seen and first_seen populated.

Here is an example:

[efd6]

Thanks

[elasticmachine]

Package tenable_sc - 1.13.0 containing this change is available at https://epr.elastic.co/search?package=tenable_sc

[elasticmachine]

Package tenable_sc - 1.13.0 containing this change is available at https://epr.elastic.co/search?package=tenable_sc