Look at Vulnerability Sample and Suggestions

[jasonbreimer]

I wanted to start a conversation based upon sample vulnerability data from my organization. I attempted to rough map example data using the existing Security Findings structure. I did not include all fields but stuck closer to key/values my organization might produce. To make this more readable I included comments within the sample and then also copied them below separately. This does not include the addition of Host Profile > Device object though I strongly suggest we allow that in the future.

Sample Data:

"activity_id": 1,
    "activity_name": "Create",
    "category_name": "Findings",
    "category_uid": 2,
    "class_name": "Security Finding",
    "class_uid": 2001,
    "data_sources": [
        "Tanium Comply (Findings)"
    ],
    "finding": { #Is a "Finding" necessary for vulnerability? Is this extra level of metadata necessary?
        "last_seen_time": 1688573061671472,
        "first_seen_time": 1688573061671472,
        "title": "Tanium Comply (Findings)", #Should "title" in Security Finding Class be the name of the vulnerability?
        "uid": "9aaff580-1b4d-11ee-af3d-0242ac110003" #I think this requirement for uid at Security Finding class should be removed.
    },
    "vulnerabilities": {
        "cve": {
            "uid": "CVE-2023-34417",
             #CVE object needs Title, Criteria, and Remediation
            "product": { #Should we have a simpler to implement field for "affected products" that would allow an array of product names?
                "name": "Mozilla Firefox, Mozilla Firefox ESR, Mozilla Firefox",
                "lang": "en" #Some of these recommended fields like language in Product object don't always make sense for vulnerability. 
            },
            #Along with affected "product" we need a way to include affected OS/platform information. 
            "created_time": 1688573061671472, #We have these time values in CVE object, do we need them in "findings"?
            "modifed_time": 1688573061671472, 
            "type": FOOBAR #Does Vulnerability Type make sense for this data? This seems more related to attacks/malware.
            "cvss": { #How would you map multiple CVSS score versions? Can I have an array of cvss score objects?
                "base_score": 5,
                "overall_score": 5,
                "severity": High (7.0 – 10.0), #I see references to CVSS v2.0 and v3.0 in schema. Should we include v1.0?
                "vector_string": "AV:N/AC:L/Au:N/C:N/I:N/A:P"
                "version": "1"
            #CVE Object needs supporting links array field, like: "https://nvd.nist.gov/vuln/detail/CVE-2023-34417","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34417"     
        },
        "severity": High #Do we need severity at the vulnerability object level as well as CVSS Score object?
        "kb_articles": [
            "CEBA-2023:1098" #KB Articles might need its own Object. There's lots of interesting fields per KB. Such as OS, Release Dates, Bulletins, Title, CVE's, files, size, supporting links, etc. 
        ],
        "references": [ #Maybe References should be moved into CVE Object?
            "https://nvd.nist.gov/vuln/detail/CVE-2023-34417",
            "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34417"
        ],
        "related_vulnerabilities": [
            "CVE-2023-34417" #I'm not sure about Recommended for related_vulnerabilites.
        ]
    },
    "message": "Tanium Vulnerability Finding", #Is this necessary for a vulnerability?
    "metadata": {
        "log_provider": "Tanium Comply",
        "product": {
            "name": "Tanium Comply",
            "vendor_name": "Tanium",
            "version": "2.19.110.0000"
        },
        "profiles": [host], #Add Host Profile
        "version": "1.0.0-rc.3"
    },
    "resources": #This Resources Details should be replaced by the Host profile include Device.
    "severity": "High", #Do we need another severity at Security Finding Class?
    "severity_id": 3,
    "start_time": 1688573061672672, #How does start_time differ from time? 
    "state": "Resolved", #Does "state" make sense for a vulnerability?
    "state_id": 4,
    "time": 1688573061671911,
    "timezone_offset": 98,
    "type_name": "Security Finding: Create",
    "type_uid": 200101
}

Questions/Comments/Recommendations
#Is a "Finding" necessary for vulnerability? Is this extra level of metadata necessary?
#Should "title" in Security Finding Class be the name of the vulnerability?
#I think this requirement for uid at Security Finding class should be removed.
#CVE object needs Title, Criteria, and Remediation
#Should we have a simpler to implement field for "affected products" that would allow an array of product names?
#Some of these recommended fields like language in Product object don't always make sense for vulnerability.
#We have these time values in CVE object, do we need them in "findings"?
#Along with affected "product" we need a way to include affected OS/platform information.
#Does Vulnerability Type make sense for this data? This seems more related to attacks/malware.
#How would you map multiple CVSS score versions? Can I have an array of cvss score objects?
#I see references to CVSS v2.0 and v3.0 in schema. Should we include v1.0?
#CVE Object needs supporting links array field, like: "https://nvd.nist.gov/vuln/detail/CVE-2023-34417","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34417"
#Do we need severity at the vulnerability object level as well as CVSS Score object?
#KB Articles might need its own Object. There's lots of interesting fields per KB. Such as OS, Release Dates, Bulletins, Title, CVE's, files, size, supporting links, etc. **This would also allow independent mapping of OS patching data.
#Maybe References should be moved into CVE Object?
#I'm not sure about Recommended for related_vulnerabilites.
#Add Host Profile
#This Resources Details should be replaced by the Host profile include Device.
#Do we need another severity at Security Finding Class?
#How does start_time differ from time?
#Does "state" make sense for a vulnerability?

[floydtree]

Notes from Findings weekly call -

For the new Vulnerability Findings class -

#Is a "Finding" necessary for vulnerability? Is this extra level of metadata necessary? - Yes

#Should "title" in Security Finding Class be the name of the vulnerability? - Yes - add title in the base

#I think this requirement for uid at Security Finding class should be removed ? - finding.uid change to recommended (Jason - not all products produce a uid for vuln)

#CVE object needs Title, Criteria, and Remediation - Yes - change - remove/keep finding.remediation?, add vuln.cve.remediation

#Should we have a simpler to implement field for "affected products" that would allow an array of product names?
#Some of these recommended fields like language in Product object don't always make sense for vulnerability.
change cve.products[]

#We have these time values in CVE object, do we need them in "findings"?
Yes, timestamp fields in the findings object are specifically about the subjective timestamps reported by the scanner/product whereas the ones in the cve object are objective about the cve itself.

#Does Vulnerability Type make sense for this data? This seems more related to attacks/malware.
https://www.cvedetails.com/vulnerabilities-by-types.php

#How would you map multiple CVSS score versions? Can I have an array of cvss score objects?
#I see references to CVSS v2.0 and v3.0 in schema. Should we include v1.0?
change cve.cvss[]

#CVE Object needs supporting links array field, like: "https://nvd.nist.gov/vuln/detail/CVE-2023-34417","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34417"

#Do we need severity at the vulnerability object level as well as CVSS Score object?
#Do we need another severity at Security Finding Class?
Agree, we should remove severity from the vulnerability object. The base severity would be used to report the severity about the finding itself.

#KB Articles might need its own Object. There's lots of interesting fields per KB. Such as OS, Release Dates, Bulletins, Title, CVE's, files, size, supporting links, etc. **This would also allow independent mapping of OS patching data.
Agree

#I'm not sure about Recommended for related_vulnerabilites.
Agree, should be optional

#Add Host Profile
Agree

#This Resources Details should be replaced by the Host profile include Device.
Resource Details is currently used as a target of the finding, we should discuss more.

#How does start_time differ from time?
This is an artifact of using the same base event for all classes in OCSF.

#Does "state" make sense for a vulnerability?
Yes, it would be the state of the finding itself

Pending -
#Maybe References should be moved into CVE Object?
#Along with affected "product" we need a way to include affected OS/platform information.

[jasonbreimer]

Based upon feedback and notes from prior call I have boiled these down further. I dropped anything that should stay as-is. A couple of these items may need additional discussion which I have noted. Please comment if I have missed anything.

1. Look at finding.uid as optional, vulnerability detection may not have a UID per CVE.
2. Changes to CVE object, needs fields like Title, Criteria, Remediation. This may involve changing finding.remediation and/or creating new object vuln.cve.remediation.
3. Affected Products array. Needs discussion.
4. Product object has language, does that make sense? *This is small maybe ignore?
5. Need to be able to map multiple CVSS score types.
6. CVE Object needs support links array. Needs discussion, this might be moving References into the CVE Object.
7. Severity removed from Vulnerability object.
8. New KBArticles Object with fields like OS, Release Date, Bulletins, Title, CVE's (array), files, size, supporting links.
9. related_vulnerabilites should be recommended.
10. Add Host Profile.
11. References moved into CVE Object - Pending
12. Affected OS/platform - Pending

[jasonbreimer]

I started to tackle some discussed changes to Vulnerability, CVE, and CVSS Objects.

Quick notes on changes:

1. move description from vuln to cve
2. copy title into cve
3. copy severity into cve
4. copy references from vuln to cve. CVE will contains MITRE public sector author links, Vuln contain private sector enrichment author links.
5. replace kb_articles with remediation object in vuln object
6. cvss score version additions to the cvss object

My Next Steps:

1. Look at Product object. Need to account for lists of products, as well as the Common Platform Enumeration (CPE) Dictionary format. Example: cpe:/o:intel:dual_band_wireless-ac_3168_firmware
2. Look at Remediation > Kb_articles. kb_articles should have its own object containing:
   article_id: the knowlege base id. Like: CESA-2023:1332 or KB5021085
   title: the name/title of the item. Like: glib2 Security Update
   severity: patch severity
   release_date: patch release date
   cves (array of cve's)
   os: the operating system type
   bulletin: An identifier that MS uses. Like: MS06-061
   size: size in bytes
   classification: the type of patch. Like: Security Updates

{
  "caption": "CVE",
  "description": "The Common Vulnerabilities and Exposures (CVE) object represents publicly disclosed cybersecurity vulnerabilities defined in CVE Program catalog (<a target='_blank' href='https://cve.mitre.org/'>CVE</a>). There is one CVE Record for each vulnerability in the catalog.",
  "extends": "object",
  "name": "cve",
  "attributes": {
    "cvss": {
      "requirement": "recommended"
    },
    "severity": {
      "requirement": "recommended"
    },
    "title": {
      "description": "The title of the vulnerability.",
      "requirement": "recommended"
    },
    "desc": {
      "description": "The description of the vulnerability.",
      "requirement": "optional"
    },
    "cwe":{
      "requirement": "optional"
    },
    "modified_time": {
      "description": "The Record Modified Date identifies when the CVE record was last updated.",
      "requirement": "optional"
    },
    "created_time": {
      "description": "The Record Creation Date identifies when the CVE ID was issued to a CVE Numbering Authority (CNA) or the CVE Record was published on the CVE List. Note that the Record Creation Date does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.",
      "requirement": "recommended"
    },
    "uid": {
			"caption": "CVE ID",
      "description": "The Common Vulnerabilities and Exposures unique number assigned to a specific computer vulnerability. A CVE Identifier begins with 4 digits representing the year followed by a sequence of digits that acts as a unique identifier. For example: <code>CVE-2021-12345</code>.",
      "requirement": "required"
    },
    "references": {
      "description": "Supporting links from MITRE, NVD, NIST, etc.",
      "requirement": "recommended"
    },
    "product": {
      "description": "The product where the vulnerability was discovered.",
      "requirement": "optional"
    },
    "type": {
			"caption": "Vulnerability Type",
      "description": "<p>The vulnerability type as selected from a large dropdown menu during CVE refinement.</p>Most frequently used vulnerability types are: <code>DoS</code>, <code>Code Execution</code>, <code>Overflow</code>, <code>Memory Corruption</code>, <code>Sql Injection</code>, <code>XSS</code>, <code>Directory Traversal</code>, <code>Http Response Splitting</code>, <code>Bypass something</code>, <code>Gain Information</code>, <code>Gain Privileges</code>, <code>CSRF</code>, <code>File Inclusion</code>. For more information see <a target='_blank' href='https://www.cvedetails.com/vulnerabilities-by-types.php'>Vulnerabilities By Type</a> distributions.",
      "requirement": "recommended"
    }
  }
}

 {
  "description": "The vulnerability object describes details related to the observed vulnerability",
  "caption": "Vulnerability Details",
  "name": "vulnerability",
  "extends": "object",
  "attributes": {
    "cve": {
      "requirement": "optional"
    },
    "title": {
      "description": "The title of the vulnerability.",
      "requirement": "recommended"
    },
    "severity": {
      "description": "The severity of the vulnerability.",	
      "requirement": "recommended"
    },
    "cwe": {
      "requirement": "recommended"
    },
    "first_seen_time": {
      "description": "The time the vulnerabilty was first detected.",
      "requirement": "recommended"
    },
    "last_seen_time": {
      "description": "The time the vulnerabilty was last detected.",
      "requirement": "recommended"
    },
    "fix_available": {
      "requirement": "optional"
    },
    "remediation": {
      "requirement": "optional"
    },
    "references": {
      "description": "Supporting links from vulnerabilty authors.",
      "requirement": "recommended"
    },
    "packages": {
      "requirement": "recommended"
    },
    "related_vulnerabilities": {
      "requirement": "optional"
    },
    "vendor_name": {
      "description": "The vendor who identified the vulnerability.",
      "requirement": "recommended"
    }
  },
  "constraints":{
    "at_least_one": [
      "cve",
      "cwe"
    ]
  }
}

{
  "caption": "CVSS Score",
  "description": "The Common Vulnerability Scoring System (<a target='_blank' href='https://www.first.org/cvss/'>CVSS</a>) object provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity.",
  "extends": "object",
  "name": "cvss",
  "attributes": {
    "v1_base_score": {
      "description": "The CVSS base score. For example: <code>9.1</code>.",
      "requirement": "optional"
    },
    "v2_base_score": {
      "description": "The CVSS base score. For example: <code>9.1</code>.",
      "requirement": "optional"
    },
    "v3_base_score": {
      "description": "The CVSS base score. For example: <code>9.1</code>.",
      "requirement": "required"
    },    
    "depth": {
      "requirement": "recommended"
    },
    "metrics": {
      "description": "The Common Vulnerability Scoring System metrics.This attribute contains information on the CVE's impact. If the CVE has been analyzed, this attribute will contain any CVSSv2 or CVSSv3 information associated with the vulnerability. For example: <code> {{\"Access Vector\", \"Network\"}, {\"Access Complexity\", \"Low\"}, ...}</code>.",
      "requirement": "optional"
    },
    "v1_overall_score": {
      "description": "The CVSS overall score, impacted by base, temporal, and environmental metrics. For example: <code>9.1</code>.",
      "requirement": "optional"
    },
    "v2_overall_score": {
      "description": "The CVSS overall score, impacted by base, temporal, and environmental metrics. For example: <code>9.1</code>.",
      "requirement": "optional"
    },
    "v3_overall_score": {
      "description": "The CVSS overall score, impacted by base, temporal, and environmental metrics. For example: <code>9.1</code>.",
      "requirement": "recommended"
    },
    "v1_severity": {
      "description": "<p>The Common Vulnerability Scoring System (CVSS) Qualitative Severity Rating. A textual representation of the numeric score.</p><strong>CVSS v2.0</strong><ul><li>Low (0.0 – 3.9)</li><li>Medium (4.0 – 6.9)</li><li>High (7.0 – 10.0)</li></ul></p><strong>CVSS v3.0</strong><ul><li>None (0.0)</li><li>Low (0.1 - 3.9)</li><li>Medium (4.0 - 6.9)</li><li>High (7.0 - 8.9)</li><li>Critical (9.0 - 10.0)</li></ul>",
      "requirement": "optional"
    },
    "v2_severity": {
      "description": "<p>The Common Vulnerability Scoring System (CVSS) Qualitative Severity Rating. A textual representation of the numeric score.</p><strong>CVSS v2.0</strong><ul><li>Low (0.0 – 3.9)</li><li>Medium (4.0 – 6.9)</li><li>High (7.0 – 10.0)</li></ul></p><strong>CVSS v3.0</strong><ul><li>None (0.0)</li><li>Low (0.1 - 3.9)</li><li>Medium (4.0 - 6.9)</li><li>High (7.0 - 8.9)</li><li>Critical (9.0 - 10.0)</li></ul>",
      "requirement": "optional"
    },
    "v3_severity": {
      "description": "<p>The Common Vulnerability Scoring System (CVSS) Qualitative Severity Rating. A textual representation of the numeric score.</p><strong>CVSS v2.0</strong><ul><li>Low (0.0 – 3.9)</li><li>Medium (4.0 – 6.9)</li><li>High (7.0 – 10.0)</li></ul></p><strong>CVSS v3.0</strong><ul><li>None (0.0)</li><li>Low (0.1 - 3.9)</li><li>Medium (4.0 - 6.9)</li><li>High (7.0 - 8.9)</li><li>Critical (9.0 - 10.0)</li></ul>",
      "requirement": "recommended"
    },
    "v1_vector_string": {
      "requirement": "optional"
    },
    "v2_vector_string": {
      "requirement": "optional"
    },
    "v3_vector_string": {
      "requirement": "recommended"
    },
    "version": {
      "description": "The CVSS version. For example: <code>3.1</code>.",
      "requirement": "required"
    }
  }
}

[floydtree]

Leaving comments per individual bullet point -

1. move description from vuln to cve - sounds good
2. copy title into cve - Okay to move it from vuln to cve instead of copying?
3. copy severity into cve - Don't we have a CVSS object in cve to address various vuln scores for the cve?
4. copy references from vuln to cve. CVE will contains MITRE public sector author links, Vuln contain private sector enrichment author links. - sounds good
5. replace kb_articles with remediation object in vuln object - sounds good
6. cvss score version additions to the cvss object - Instead of adding new fields, can't we just make cvss an array in the cve object? Consequently, we don't need to add the version prefixed individual fields and yet accommodate all the version info when available?

[jasonbreimer]

I've mocked up a new kb_articles object for attributes that describe the kb article from the OS vendor. These are attributes that describe the actual "patch" itself.

New dictionary items: article, bulletin, superceeded, kbarticle_classification
New Object: kb_articles

{
  "caption": "Kb Articles",
  "description": "The Kb Articles object contains metadata for the operating system patch or kb",
  "extends": "object",
  "name": "kb_articles",
  "attributes": {
    "title": {
      "description": "The title of the kb article.",		
      "requirement": "recommended"
    },
    "article": {
      "description": "The kb article identifier.",		
      "requirement": "recommended"
    },
    "os": {
      "description": "The os of the kb article",
      "requirement": "recommended"
    },
    "severity": {
      "description": "The severity of the kb article.",
      "requirement": "recommended"
    },
    "bulletin": {
      "description": "The bulletin name for the kb article.",
      "requirement": "optional"
    },
    "product": {
      "description": "The product name from the Operating System vendor kb article",
      "requirement": "optional"
    },
    "superceeded": {
      "description": "The kb article has been superceeded by another kb article",
      "requirement": "optional"
    },
    "created_time": {
      "description": "The date the kb article was released by the Operating System vendor",
      "requirement": "optional"
    },
    "size": {
      "description": "The size in bytes for the kb article",
      "requirement": "optional"
    },
    "kbarticle_classification": {
      "description": "The classification of the kb article by the Operating System vendor",
      "requirement": "optional"
    },
    "cves": {",
      "description": "An array of CVE titles associated with the kb article",
      "requirement": "optional"
    }
  }
}

[floydtree]

Assuming, these are placeholder descriptions.

1. article: can we use src_url instead? -> kb_article.src_url (just thinking about reusability)

2. os: assuming you want the existing object?

3. severity: Considering we have severity in the vulnerability object, does kb_article need its own severity? (the way it is structured, each vulnerability object will have it's own kb_articles[] array.

4. product: are looking to add the entire product object?

5. kbarticle_classification: we can avoid redundancy by using classification (kb_article.classification) vs (kb_article.kbarticle_classification)

6. cves: would this be a new attribute? Currently cve is an object. Using the object here would create a redundancy - vulnerability object already contains cve, then when we add kb_articles in the vulnerability object, it will again contain an array of cve objects.

   Also, taking a step back, can we avoid adding cves in kb_article altogether? Considering the relationship between/context for kb_article & cve will be established by them being a part of the same vulnerability object.

[jasonbreimer]

Great, thank you Rajas!

Yes exactly I wanted to get some agreement on these attributes and objects, names/descriptions, etc first.

Comments below, I also realized I didn't add a data sample for context. See below as well.

1. The value would be "KB5025239". Does that fit in with src_url?
2. Yes, I think so. I want the "patch" vendor's operating system details. I think I can use name and os_type from OS object.
3. I do think this object needs its own severity. The OS vendor can provide a severity level for the patch itself. That severity would not be tied to the vulnerability severity.
4. Yes, the patch could apply to something like "silverlight" or "Azure Stack Data Box"
5. Yes good call
6. There is an existing attribute cves with type "CVE Array" which I thought would be a good fit. We can chat in more detail and logic is circular, but that is the nature of the data relationships. But you would certainly have data like: Findings > CVE > KB > Array of CVES. A "patch" can have multiple CVE's and a CVE can have multiple patches.
   (https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15)

Patch Data Sample

Title="2023-04 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5025239)" 
Severity="None"
Release-Date="4/10/2023" 
Bulletins="None" 
Size-in-Bytes="9901389138"
KB-Articles="KB5025239" 
CVE-IDs="CVE-2023-21554 CVE-2023-21727 CVE-2023-21729 CVE-2023-21769 CVE-2023-24883 CVE-2023-24884 CVE-2023-24885 CVE-2023-24886 CVE-2023-24887 CVE-2023-24912 CVE-2023-24914 CVE-2023-24924 CVE-2023-24925 CVE-2023-24926 CVE-2023-24927 CVE-2023-24928 CVE-2023-24929 CVE-2023-24931 CVE-2023-28216 CVE-2023-28217 CVE-2023-28218 CVE-2023-28219 CVE-2023-28220 CVE-2023-28221 CVE-2023-28222 CVE-2023-28224 CVE-2023-28225 CVE-2023-28226 CVE-2023-28227 CVE-2023-28228 CVE-2023-28229 CVE-2023-28232 CVE-2023-28233 CVE-2023-28234 CVE-2023-28236 CVE-2023-28237 CVE-2023-28238 CVE-2023-28241 CVE-2023-28243 CVE-2023-28246 CVE-2023-28248 CVE-2023-28249 CVE-2023-28250 CVE-2023-28252 CVE-2023-28253 CVE-2023-28266 CVE-2023-28267 CVE-2023-28269 CVE-2023-28270 CVE-2023-28271 CVE-2023-28272 CVE-2023-28273 CVE-2023-28274 CVE-2023-28275 CVE-2023-28276 CVE-2023-28293 CVE-2023-28298 CVE-2023-28302" 
Superseded="False"
OS-Type="Windows" 
Product="Windows 11" 
Classification="Security Updates"

[jasonbreimer]

Regarding change to Product object we discussed for Common Platform Enumeration.
Please see: https://nvd.nist.gov/products/cpe

I think we should keep it simple and under the Product object create a new attribute "cpe".

Data value Examples:
cpe:/a:notepad-plus-plus:notepad%2b%2b:::x64,cpe:/o:microsoft:windows_10
cpe:/a:zoom:zoom_client_it_admin,cpe:/a:zoom:zoom_client,cpe:/o:microsoft:windows_10

[floydtree]

Leaving some notes of what we discussed in the weekly Findings call -

@floydtree to add timestamp fields to the vulnerability object and publish the PR for the new vuln class

@jasonbreimer to create a new kb_article object with the following considerations, and add the new object to the vulnerability object

1. Instead of creating a new field article, uid will be utilized.
2. src_url/references will be added to the new kb_article object
3. related_vulnerabilities[] will be used store vuln ids in the kb_articles object (cve_uids can be also be created, but I think this existing attribute does the job, curious if you think otherwise)
4. cpe will be created and added to the product object