|
| 1 | +# IEP009: IntelMQ Data Format: Describe product and mark vulnerabilities |
| 2 | + |
| 3 | +The original intention behind IntelMQ was to track malicious connections. Today we see |
| 4 | +increasing use in tracking known vulnerabilities in specific online accessible software. IntelMQ |
| 5 | +Data Format does not natively support any kind of identification of which product is affected, or |
| 6 | +presentation of the vulnerability list. The only existing method is to use the `extra` field. |
| 7 | + |
| 8 | +This IEP aims to address the increasing use of vulnerability reports by proposing additional |
| 9 | +harmonisation fields. |
| 10 | + |
| 11 | +## Background |
| 12 | + |
| 13 | +You can see an increasing amount of vulnerability-related data being handled by IntelMQ (such as |
| 14 | +vulnerability reports from ShadowServer [[1]](https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-http-report/) [[2]](https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-exchange-server-report/)). |
| 15 | +Vulnerable online-accessible devices are also an ongoing problem [[3 (de)]](https://cert.at/de/warnungen/2023/10/kritische-sicherheitslucke-in-cisco-ios-xe-aktiv-ausgenutzt) [[4 (de)]](https://cert.at/de/warnungen/2023/10/kritische-sicherheitslucke-in-citrix-netscaler-adc-und-netscaler-gateway-aktiv-ausgenutzt-updates-verfugbar), |
| 16 | +and informing the constituencies about them is an important task for many security teams. |
| 17 | + |
| 18 | +## Use cases |
| 19 | + |
| 20 | +Assuming that events are properly tagged with product and vulnerability information, the following |
| 21 | +use cases are possible: |
| 22 | + |
| 23 | + * Clearly indicate the affected software/device to network administrators, thereby improving their |
| 24 | + response time. |
| 25 | + * Deduplicate vulnerability information from different sources. |
| 26 | + * Group vulnerabilities that affect the same product, e.g. for bulk distribution. |
| 27 | + * Easily analyse collected data for vulnerability statistics. |
| 28 | + |
| 29 | +## Solution considerations |
| 30 | + |
| 31 | +Existing solutions actively use e.g. the `extra` field to mark affected devices and |
| 32 | +vulnerabilities (e.g. [[5]](https://github.com/The-Shadowserver-Foundation/report_schema/blob/c45354ef8abcfdc049b1d665eac2bc1310973a88/intelmq.json#L13082-L13090)), but do not allow for |
| 33 | +compatibility between between data from different sources. |
| 34 | + |
| 35 | +Another important question is how much information should be included in the IDF itself. Both |
| 36 | +product and vulnerability may have several related pieces of information (product: versions, |
| 37 | +release dates, available updates; vulnerability: an ID, affected versions, common weakness |
| 38 | +enumeration IDS, ...). Including all possible information in the IDF would make it too complex |
| 39 | +without a real improvement in data handling. |
| 40 | + |
| 41 | +In terms of interoperability and vulnerability identification, the important reference is |
| 42 | +the Common Platform Enumeration [[6]](https://nvd.nist.gov/products/cpe). This is de facto |
| 43 | +a standard for identifying affected devices. |
| 44 | + |
| 45 | +## Proposal |
| 46 | + |
| 47 | +This IEP focuses changes on the identification of the existing product and vulnerabilities, which |
| 48 | +will easily retrieve other related information. For the best interoperability and querying, it's |
| 49 | +recommended to follo |
| 50 | +w the CPE naming convention [[7]](https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf) and/or the official CPE Product Dictionary [[6]](https://nvd.nist.gov/products/cpe), where applicable. |
| 51 | +The terms _vendor_, _product_, _version_ are used here in the sense defined by CPE specification. |
| 52 | + |
| 53 | +In addition, the following assumptions are made: |
| 54 | + * The primary role of an IntelMQ event in this context is to identify a vulnerable product on an |
| 55 | + Internet-facing device. Therefore, only the currently used product should be listed; if a |
| 56 | + vulnerability affects multiple products or their versions, it's not relevant information. |
| 57 | + * An event may list multiple vulnerabilities in an observed product, but not in multiple products |
| 58 | + on the same device. If a server contains multiple vulnerable products, multiple events should be |
| 59 | + generated by the parser or used in communication between IntelMQ instances. The IntelMQ operator |
| 60 | + can later decide to batch them in their own workflow. |
| 61 | + * All but one of the suggested fields are strictly for machine processing. It is recommended to |
| 62 | + follow the CPE convention and it's dictionary, but to keep the flexibility (e.g. when CPE |
| 63 | + information is not available), only the lower case string needs to be used. Also the |
| 64 | + vulnerability IDs, which are not part of the CPE, should use lower case for better comparability |
| 65 | + between different sources. |
| 66 | + * There are some existing fields such as `event_description.text`, `event_description.url` that |
| 67 | + can be used to store additional information for human operators. As such, the proposed fields |
| 68 | + do not include any description other than the product name. |
| 69 | + * Machine-readable fields can still be used to retrieve additional information, e.g. query |
| 70 | + vulnerability databases for advisory URL or CPE product dictionary to get the human-readable |
| 71 | + product name. |
| 72 | + |
| 73 | +Thus, the following new fields are proposed: |
| 74 | + |
| 75 | +| Group | Name | IDF type | Description | Example » |
| 76 | +| - | ---- | ---- | ----- | - | |
| 77 | +| Product | `product.name` | `String` | A human readable product name. If a machine-readable format isn't available, this field should be used. It can directly use the version identification strings presented by the product. If not given, a good enough value can usually be constructed by concatenating `product.product` and `product.version`, or by consulting external sources such as the CPE Product Dictionary. | `openssh_/8.9` | |
| 78 | +|Product | `product.vendor` | `LowercaseString` | Vendor name, recommended being as _vendor_ in the CPE format. | `openbsd` | |
| 79 | +| Product | `product.product` | `LowercaseString` | Product name, recommended being as the _product_ in the CPE format. | `openssh` | |
| 80 | +| Product | `product.version` | `LowercaseString` | Product version, recommended being as _version_ in the CPE format | `8.9` | |
| 81 | +| Product | `product.vulnerabilities` | `LowercaseString` | List of vulnerability IDs, separated by semicolons. It's recommended to use a CVE ID where available, and other easily retrievable IDs in other cases, e.g. Github Advisory Database ID [[8]](https://docs.github.com/en/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/browsing-security-advisories-in-the-github-advisory-database). Each vulnerability should only be listed once, and multiple values should be used if there are several different vulnerabilities. However, it's not necessary for a source to list all possible vulnerabilities for a given piece of software. | `cve-2023-38408;cve-2023-28531;cve-2008-3844;cve-2007-2768` | |
| 82 | + |
| 83 | +This should only be added to the `event` schema. |
0 commit comments