Describing vulnerabilities in online services (SaaS, Cloud, web services)

[adulau@discourse.ossbase.org]

Workshop Follow-up: Advisories for Online Services

During our last workshop in Luxembourg on November 24th, a question was raised by a GNA (GCVE Numbering Authorities) regarding the ability to record and publish security advisories for online services.

We quickly reviewed the Common Vulnerabilities and Exposures (CVE) record format as used in BCP-05 and identified the following challenges when describing vulnerabilities in online services:

Challenges with the CVE Record Format

1. Versioning

• A traditional version number rarely exists for continuously deployed online services, unless they incorporate off-the-shelf software (e.g., WordPress) where a version change may be tracked.
• Proposed Strategy: An alternative strategy is to use a date/timestamp in the version field to indicate when the patch was deployed by the vendor on the vulnerable service online, effectively describing the service state after the fix.

2. Identifying the Affected Asset (CPE)

• The current Common Platform Enumeration (CPE) format Reference: NIST CPE Specificationdoes not inherently include a reference to a hostname or specific online Uniform Resource Locator (URL).
• The standard CPE format uses the following types:
  • a for Applications
  • h for Hardware
  • o for Operating Systems
• Proposed Extension (idea): The format could be extended by adding s for Service. In this case, the vendor field could be used for the hostname (or service name) and the product field could describe the scope (e.g., a specific path or component) of the online vulnerability.

CVSS and Specific Notes

3. Common Vulnerability Scoring System (CVSS)

• The CVSS score and metrics still apply.
• The Attack Vector metric will almost universally be set to Network (often interpreted as remote) since the service is accessible online.

4. Specific Advisory Notes

• The Specific Notes or comments section should be used to provide critical context for consumers. Examples include:
  • "No customer action/patch required; vendor fixed on server side."
  • "Tenant-isolation issue in multi-tenant service."
  • "service mis-configuration"

Proposed Format Extension in BCP-05

For tracking the service scope, the existing GCVE format (if used as a meta format for advisories) could be extended in the BCP-05 structure to include the proposed service-scoping information (like hostname/path) in a dedicated field, even if the primary CPE itself remains un-updated.

Discuss this on our forum.

[adulau@discourse.ossbase.org]

A tag is used in CVE record format to describe Exclusively Hosted Service with the following definition:

All known software and/or hardware affected by this CVE Record is known to exist only in the affected hosted service. If the vulnerability affects both hosted and on-prem software and/or hardware, then the tag should not be used.

This could be an approach to specify this "tag":

CVE records tags and recommended taxonomies in GCVE

Following the last working-group meeting with the MISP core team, many questions were raised concerning the tags and taxonomies used in the vulnerability ecosystem, including the CVE Program, GCVE, and others. The CVE P…

ossbase.org (discourse.ossbase.org)

Discuss this on our forum.

[adulau@discourse.ossbase.org]

CRIT is trying to solve a real gap: package-oriented identifiers like CPE/PURL do not model cloud resources well, because cloud resources are runtime objects with provider-specific identifiers and exposure depends on timing, propagation, and remediation state. The draft is explicit about that, and the repo reflects it with dictionaries, schemas, samples, and a validator.

GitHub - Vulnetix/ietf-crit-spec: Cloud Resource Identifier Templates (CRIT) — IETF specification for machine-readable cloud vulnerability records

Cloud Resource Identifier Templates (CRIT) — IETF specification for machine-readable cloud vulnerability records - Vulnetix/ietf-crit-spec

GitHub (github.com)

They also extend the CVE record format with an x_ record just like GCVE. Yes, the ADP needs become like a major importance for the CVE Program.

CRIT records are naturally produced by parties closest to the platform semantics: cloud providers, specialized researchers, managed detection vendors, and vertical ecosystems. The draft even defines “producer” and “consumer” roles and warns that a producer aggregating multiple upstreams must handle natural-key collisions.

GCVE’s GNA model would help here because it gives each producer a stable namespace and publishing authority. That is cleaner than assuming all high-quality CRIT output ultimately needs to be mediated through the CVE pipeline or one ADP publisher. This would allow faster publication.

Potential improvements in CRIT Internet-Draft

Keep vuln_id generic, not effectively “must be CVE”.Then add:

• aliases[]
• issuer
• scheme or id_namespace (cve, gcve, maybe others)

The draft already defines “vulnerability identifier” generically, even though the examples are CVEs.

Outcome

• CRIT solves the cloud-resource modeling problem
• GCVE solves the decentralized publication and federation problem

Discuss this on our forum.