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 --> [*]
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 --> [*]
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:
- A Participant-specific Vendor Fix Path from initial vendor awareness through the deployment of a fix.
- 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 --> [*]