Skip to content

Vultron Process Models

Vultron Process Models

graph TD
    RM[[Report Management]]
    EM[[Embargo Management]]
    CS[[Case State]]
    RM --> EM
    RM --> CS
    EM --> RM
    EM --> CS
    CS --> EM
    CS --> RM

The Vultron Protocol defines three main processes in terms of deterministic finite automata (DFAs):

  • Report Management
  • Embargo Management
  • Case State

Each of these processes interacts with the other two processes in the context of a CVD case.

A CVD case is coordinated by multiple agents (Reporters, Vendors, Coordinators, etc.), each running these processes in parallel and interacting with each other.

---
title: Vultron Protocol Agents Interacting
---
graph LR
    subgraph Agent2
        RM2[[Report Management]]
        EM2[[Embargo Management]]
        CS2[[Case State]]
    end
    subgraph Agent1
        RM1[[Report Management]]
        EM1[[Embargo Management]]
        CS1[[Case State]]
    end
    RM1 --> EM1
    RM1 --> CS1
    EM1 --> RM1
    EM1 --> CS1
    CS1 --> EM1
    CS1 --> RM1
    RM2 --> EM2
    RM2 --> CS2
    EM2 --> RM2
    EM2 --> CS2
    CS2 --> EM2
    CS2 --> RM2
    Agent1 --> Agent2
    Agent2 --> Agent1

Report Management process

The RM process should be reasonably familiar to anyone familiar with IT Service Management (ITSM) workflows such as problem, change, incident or service request management. In particular, any workflow in which work items (e.g., incident reports, problem tickets, change requests) are received, validated, prioritized, and work is subsequently completed, should map onto the RM process outlined here.

---
title: Report Management State Diagram
---
stateDiagram-v2
    direction LR
    S: Start
    R: Received
    I: Invalid
    V: Valid
    D: Deferred
    A: Accepted
    C: Closed

    [*] --> S
    S --> R : receive
    R --> I: invalidate
    R --> V : validate
    I --> V : validate
    V --> A : accept
    V --> D : defer
    A --> D : defer
    D --> A : accept
    A --> C : close
    D --> C : close
    I --> C : close
    C --> [*]

Read More...

Embargo Management process

For our purposes, an embargo is an informal agreement among peer CVD case Participants to refrain from publishing information about a vulnerability until some future point in time relative to the report at hand. Once an embargo has expired, there is no further restriction on publishing information about the vulnerability.

---
title: Embargo Management State Diagram
---
stateDiagram-v2
    direction LR
    [*] --> None
    state Pre-Embargo {
        None --> Proposed : propose
        Proposed --> Proposed : propose
        Proposed --> None : reject
        Proposed --> Active : accept
    }
    state Active_Embargo {
        Active --> Revise : propose
        Revise --> Active : accept
        Revise --> Active : reject
        Revise --> Revise : propose
        Revise --> eXited : terminate
        Active --> eXited : terminate
    }
    state Post-Embargo {
        eXited
    }
    eXited --> [*]

Read More...

Case State process

The CVD Case State (CS) model provides a high-level view of the state of a CVD case. In it we model two main aspects of the case:

  1. A Participant-specific Vendor Fix Path from initial vendor awareness through the deployment of a fix.
  2. A Participant-agnostic Public State summarizing both public and attacker awareness of the vulnerability.

These processes run in parallel, and the CS model captures the interactions between them.

---
title: Case State Diagram showing Participant-Agnostic and Participant-Specific Aspects
---
stateDiagram-v2
    direction LR
    CS: Case State Model
    state CS {
        ps: Participant-Specific
        state ps {
            [*] --> vfd
            vfd --> Vfd : V
            Vfd --> VFd : F
            VFd --> VFD : D
            VFD --> [*]
        }
        --
        g: Participant-Agnostic 
        state g {
            [*] --> pxa

            pxa --> Pxa : P
            pxa --> pXa : X
            pxa --> pxA : A

            pXa --> PXa : P
            pXa --> pXA : A

            pxA --> PxA : P
            pxA --> pXA : X

            Pxa --> PxA : A
            Pxa --> PXa : X

            pXA --> PXA : P
            PXa --> PXA : A
            PxA --> PXA : X
            PXA --> [*]
        }
    }
    [*] --> CS
    CS --> [*]

Read More...