Issue specific fields #
| Field | Description |
|---|---|
| labels | Issue Labels, defined in ECS required: No type: dictionary engagement: Not used example: object, key value pairs TBD |
| tags | Defined in ECS as a base fields (https://www.elastic.co/guide/en/ecs/current/ecs-base.html Base Fields | Elastic Common Schema (ECS) Reference [8.3] | Elastic) can be used on a source specific or customer specific way. required: No (can be blank) type: keyword array engagements: Not used example: [“Not an Issue”] |
| vulnerability.is_active | Indicates whether this issue is active as defined by the source system. This is a calculated field defined as an issue being: is_removed = false is_suppressed = false is_filtered = false and for PenTest test is “Found” required: Yes (calculated by the Manger) type: boolean engagements: Visible, not editable example: true |
| vulnerability.source_severity | Best Practice Indicates the severity of the issue, can be source-specific required: No type: keyword engagements: Visible, same as Severity, Required Example: Best Practice |
| vulnerability.found_date | When the issue was first found in an scan type: timestamp engagements: Visible, Required example: 2020-12-28T22:42:19.165783 |
| vulnerability.id | Identifier used to identify this issue from an external source (not this instance) The identification (ID) is the number portion of a vulnerability entry. It includes a unique identification number for the vulnerability. For example (Common Vulnerabilities and Exposure CVE ID type: keyword engagements: Not visible example: CVE-2019-00001 |
| vulnerability.is_filtered | Whether or not this issue is filtered or hidden type: boolean engagements: Not visible example: false |
| vulnerability.is_removed | Indicates whether this issues has stopped appearing in scans type: boolean engagements: Visible, Required example: false |
| vulnerability.is_suppressed | Indicates whether this issue has been suppressed type: boolean engagements: Visible, Optional example: false |
| vulnerability.location | Location of issue (i.e. URL or file) type: keyword engagements: Visible, Optional example: myfile.js |
| vulnerability.location_full | Full location with path of issue (i.e. URL or file) type: text engagements: Visible, Optional example: https://www.saltworks.io/myfile.js |
| vulnerability.removed_date | When the issue stopped appearing in scans type: timestamp engagements: Visible Optional (default to when an issue is removed if not provided via GUI) example: <date field> |
| vulnerability.report_id | Duplication of saltminer.report_id to make ECS happy Had to duplicate this for ECS and filtering across entities to both work keyword vulnerability.report_id Duplication of saltminer.report_id to make ECS happy Had to duplicate this for ECS and filtering across entities to both work Yes Yes keyword |
| vulnerability.test_status | For Pentest, indicates status of vulnerability testing. Must be one of these: [Tested, Not Tested, Found, Not Found, Out of Scope)Definition: Tested: Tested the issue but it WAS NOT found Not Tested: Have not looked at it yet Found: Looked for it and found it to be real. Not Found (May not be needed)Out of Scope type: keyword example: Tested |
| vulnerability.category | The type of system or architecture that the vulnerability affects. These may be platform-specific (for example, Debian or SUSE) or general (for example, Database or Firewall). For example (Qualys vulnerability categories) This field must be an array. type: keyword engagement: Not used, hard coded to Application Note: This field should contain an array of value. Application is the most common value for SaltMiner but some scanners may provide different values. example: [“Application”] |
| vulnerability.classification | CVSS The classification of the vulnerability scoring system. For example (https://www.first.org/cvss/ ) ECS – this is used at some customers for export to external systems and for SSC comes from a linked rules datasource. May need to be a list instead of a single type: keyword engagement: not used example: CVSS |
| vulnerability.description | The description of the vulnerability that provides additional context of the vulnerability. For example (Common Vulnerabilities and Exposure CVE description) type: keyword (w/.text) Multi-fields: vulnerability.description.text (type: match_only_text) example: In macOS before 2.12.6, there is a vulnerability in the RPC… ECS – also includes vulnerability.description which is a keyword field. For SSC, will have to come from linked rules datasource The description of the vulnerability that provides additional context of the vulnerability. For example: CVE description ECS – also includes vulnerability.description which is a keyword field. For SSC, will have to come from linked rules datasource. Often long descriptive text about the specific issue goes here. engagement: Visible, Optional required: No type: keyword |
| vulnerability.enumeration | The type of identifier used for this vulnerability. For example (https://cve.mitre.org/about/ ) required: No type: keyword engagement: Not used example: CVE |
| vulnerability.name | Name or short description of issue required: Yes type: keyword (w/.text) engagement: Visible, Required example: SQL Injection |
| vulnerability.reference | CVE – CVE-2019-6111 A resource that provides additional information, context, and mitigations for the identified vulnerability. This could replace sor_url from SSC, or it could be used to provide a CVE/CWE reference URL if known type: keyword engagement: Visible, Optional (different from References!) example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 |
| vulnerability.severity | Critical/High/Medium/Low, indicates the severity of the issue Critical What other factors (impact/likelihood/etc.) should be included when considering risk? Should we have a risk score? type: keyword engagement: Visible, Required example: Critical |
| saltminer.critical saltminer.high saltminer.medium saltminer.low saltminer.info | System generated field for counting severity values. If vulnerability.severity = “Critical” then saltminer.critical = 1 else saltminer.critical = 0 This pattern continues for High through Info requires: Yes type: Integer engagement: Not visible, calculated by back end. |
| saltminer.custom_data | Placeholder for customer custom data related to an issue type: object engagement: Not used |
| saltminer.attributes.<attribute_name> | Custom attributes that apply to ISSUES used in visualizations and so on. Net new custom attributes only related to an issue. required: No type: keyword engagement: Not used example: saltminer.attributes.issue_name_in_french: “Quelque chose de mauvais” |
| vulnerability.audit.audited | Whether this issue has been reviewed by an auditor. Defaults to false if null type: boolean engagement: Not Used example: false |
| vulnerability.audit.auditor | Auditor that reviewed this issue type: keyword (w/.text) engagement: Not Used example: John Doe |
| vulnerability.audit.last_audit | Timestamp from the last audit type: timestamp engagement: Not Used example: 2020-12-28T22:42:19.165783 |
| vulnerability.scanner.api_url | REST API URL Source specific API data reference URL, links back to source data required: No type: text engagement: Not Used |
| vulnerability.scanner.gui_url | URL to view issue in GUI Source specific reference URL, link back to original record in source system required: No type: text engagement: Not used |
| vulnerability.scanner.id | Unique identifier from source for this issue. required: Yes type: keyword engagement: Not Used example: 12345 |
| vulnerability.scanner.assessment_type | Scan assessment type. Must be one of these: SAST, DAST, OSS, PENTEST SAST required: Yes type: keyword engagement: Visible, Optional engagement: Not used |
| vulnerability.scanner.product | SCA Product used to run the scan. SCA, FOD, WebInspect required: Yes type: keyword engagement: Visible, Optional engagement: Not used |
| vulnerability.scanner.vendor | Fortify / FOD / Checkmarx Vendor for the scanner used to identify this issue type: keyword engagement: Visible, Optional example: Fortify vulnerability.scanner.vendor Vendor for the scanner used to identify this issue Yes Yes keyword Fortify / FOD / Checkmarx Fortify |
| vulnerability.score.base | Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Base scores cover an assessment for exploitability metrics (attack vector, complexity, privileges, and user interaction), impact metrics (confidentiality, integrity, and availability), and scope. For example (CVSS v3.1 Specification Document ) type: float engagement: Not Used example: 5.5 vulnerability.score.base 0 to 10 score, Base scores cover an assessment for exploitability metrics (attack vector, complexity, privileges, and user interaction), impact metrics (confidentiality, integrity, and availability), and scope. ECS – Scores can range from 0.0 to 10.0, with 10.0 being the most severe No Yes float 5.5 5.5 |
| vulnerability.score.environmental | Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Environmental scores cover an assessment for any modified Base metrics, confidentiality, integrity, and availability requirements. For example (CVSS v3.1 Specification Document ) type: float engagement: Not Used example: 5.5 vulnerability.score.environmental 0 to 10 score. Environmental scores cover an assessment for any modified Base metrics, confidentiality, integrity, and availability requirements. ECS – Scores can range from 0.0 to 10.0, with 10.0 being the most severe No Yes float vulnerability.score.environmental 5.5 |
| vulnerability.score.temporal | Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Temporal scores cover an assessment for code maturity, remediation level, and confidence. For example (CVSS v3.1 Specification Document ) type: float engagement: Not Used |
| vulnerability.score.version | The National Vulnerability Database (NVD) provides qualitative severity rankings of “Low”, “Medium”, and “High” for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as they are defined in the CVSS v3.0 specification. CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profit organization, whose mission is to help computer security incident response teams across the world. For example (NVD – Vulnerability Metrics ) type: keyword engagement: Not Used example: 2.0 |
| Source specific attributes | |
| saltminer.source.analyzer | Source-specific analyzer (in this case, Fortify SCA would use a SQL_Injection analyzer) No No keyword Semantic Configuration |
| saltminer.source.issue_status | Source-specific issue status (in this case, Fortify) requires: No type: keyword example: Under Review |
| saltminer.source.kingdom | Source-specific kingdom identifier for this issue required: No type: keyword example: Encapsulation |
| saltminer.source.likelihood | Source-specific likelihood score (fortify-specific in this case) required: No type: float example: 3.2 |
| The following fields are used for Engagements only (PenTest) | |
| vulnerability.proof | Pentest markdown field containing proof of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown |
| vulnerability.details | Pentest markdown field containing details of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown |
| vulnerability.implication | Pentest markdown field containing implications of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown |
| vulnerability.recommendation | Pentest markdown field containing recommendation for resolution of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown |
| vulnerability.references | Pentest markdown field containing references for found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown |
| vulnerability.category | The type of system or architecture that the vulnerability affects. These may be platform-specific (for example, Debian or SUSE) or general (for example, Database or Firewall). For example (Qualys vulnerability categories) This field must be an array. type: keyword Engagement: Not Used Note: this field should contain an array of values. example: [“Firewall”] |
| saltminer.is_vulnerability | Whether the issue is a vulnerability or not (always has a value) true In some cases, we may end up loading ‘best practice’ or ‘fyi’ entries that aren’t actually vuls type: boolean engagement: Not Used |
| saltminer.report_id | The unique report or scan identification number as provided by the scanning vendor type: keyword engagement: Not Used 1205 |
| saltminer.scan_date | Timestamp from the related scan where the issue was last found 2018-06-29T12:36:52.430+0000 Represents the scan date when this issue was last found / confirmed type: timestamp engagement: Not Used example: 2020-12-28T22:42:19.165783 |
| saltminer.scan_id | ??????? keyword Yes Yes Yes SaltMiner unique scan identifier |
| saltminer.engagement.attributes | attributes that flow down from the Engagement object. Populated by enrichment |
Flow down fields #
Asset Inventory #
- saltminer.asset_inv.is_production
- saltminer.asset_inv.name
- saltminer.asset_inv.description
- saltminer.asset_inv.version
- saltminer.asset_inv.attributes
- saltminer.asset_inv.key
Engagements #
For Issues that were found as part of an engagement the following fields flow down
- saltminer.engagement.publish_date
- saltminer.engagement.name
- saltminer.engagement.customer
- saltminer.engagement.summary
- saltminer.engagement.scan_id
- saltminer.engagement.attributes
Assets #
- saltminer.asset.last_scan-days_policy
- saltminer.asset.config_name
- saltminer.asset.source_type
- saltminer.asset.sub_type
- saltminer.asset.is_retired
- saltminer.asset.version_id
- saltminer.asset.asset_type
- saltminer.asset.host
- saltminer.asset.ip
- saltminer.asset.scheme
- saltminer.asset.port
- saltminer.asset.is_production
- saltminer.asset.name
- saltminer.asset.description
- saltminer.asset.version
- saltminer.asset.attributes
- saltminer.scan.scan_date