wiki:SacmVulnerabilityAssessmentHackathon

SACM Vulnerability Assessment Hackathon Information

Goals and Outcomes

Originally determined on-list (see https://mailarchive.ietf.org/arch/msg/sacm/LskQ7tj9Wvy1-0DSlEN_VakYj64)

GOAL: Running code demonstrating the communication needs between identified components as they pertain to the on-request collection case through the scenario, where that case is described at https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario.

OUTCOME: We will have specific understanding of components' boundaries and the necessary information flows (including information being communicated) between them.

GOAL: Leverage existing collected data in a data repository.

OUTCOME: Demonstrate that previously collected data can be reused to support vulnerability assessment

GOAL: Running code to extend that base case to include a mechanism capable of monitoring a given set of endpoint attributes for change.

OUTCOME: We will have specific understanding of additional architectural considerations for handling monitoring vs. on-request collection, as well as any additional information flows required.

User Story

A vendor identifies a vulnerability in their software product being exploited in the wild. The vendor produces a new version of their software and publishes a vulnerability bulletin (Vulnerability Description Information) that advises customers to upgrade to this new version to address the vulnerability. The product versions have both a SWID tag and a CoSWID tag. As a customer using the affected products, we need to build a vulnerability assessment system that is capable of detecting which version of the software is installed and compare that version with the affected versions, so that we know whether we are presently vulnerable. The Collector (or Collectors) will be capable of gathering software inventory information from one or more target endpoints by:

  1. Requesting software inventory information for the affected software based on an ad-hoc request.
  2. Reporting the software inventory as software changes occur

Collected software inventory information will be stored in an Endpoint Repository and will be compared to Vulnerability Detection Data retrieved from the Vulnerability Detection Data Repository - results will be stored in the Assessment Results Repository. The Vulnerability Detection Data will be derived from the vendor-provided information in some useful way to be determined by the Vulnerability Assessor. (This derivation need not be automatic for the purpose of this exercise.)

Components and Existing Functionality

Agreed upon components are (as discussed here: https://mailarchive.ietf.org/arch/msg/sacm/u2cppct5RgwnOdfQoZnlkMN7t2w):

  • Vulnerability Detection Data Repository
  • Vulnerability Assessor
  • Endpoint Repository
  • Collector
  • Target Endpoint
  • Assessment Results Repository

Several sources have come forward to offer existing functionality we might leverage for this effort.

Last modified 2 years ago Last modified on Jun 9, 2017, 9:13:19 AM