diff --git a/docs/howto/activitypub/activities/_acknowledge.md b/docs/howto/activitypub/activities/_acknowledge.md deleted file mode 100644 index 63d9a88..0000000 --- a/docs/howto/activitypub/activities/_acknowledge.md +++ /dev/null @@ -1,53 +0,0 @@ -# Acknowledging Other Messages - -The ActivityStreams vocabulary includes several activities that can be used to -indicate that a message or object has been read or acknowledged. These include: - -- `as:Read` -- `as:View` -- `as:Listen` - -Since most CVD cases are text-centric, we expect that the `as:Read` activity -will be the most commonly used. However, we also expect that the `as:View` and -`as:Listen` activities will be used in some cases, such as when a case -participant views a video or listens to an audio recording. - -We specifically defined `RmReadReport` as a subclass of `as:Read` to indicate -that a report has been read. This allows the receiver of a report to -acknowledge receipt without indicating anything more than that the report has -been read. That leaves `RmValidateReport` and `RmInvalidateReport` to indicate -a more specific action on the part of the receiver. - -```mermaid -flowchart LR - subgraph as:Offer - RmSubmitReport - end - subgraph as:Read - RmReadReport - end - subgraph as:Accept - RmValidateReport - end - RmSubmitReport --> RmReadReport - RmSubmitReport --> RmValidateReport -``` - -!!! info "More Acknowledgements in the Ontology" - - The [Vultron AS ontology](../../../reference/ontology/vultron_as.md) defines a - number of ActivityStreams activities that can serve as the various acknowledgements that are used in the Vultron - protocol. These include messages that are specifically `as:inReplyTo` a - message defined as one of the core protocol message types. - - For example, it is not necessary to send a separate `RmReadReport` message - if the `RmValidateReport` message is sent as a reply to the `RmSubmitReport` - message. The `RmValidateReport` message logically indicates that the - report has been read in order to have been validated. - -!!! tip "Like, Dislike and Flag" - - ActivityStreams vocabulary also includes actions that indicate an opinion - about a message or object, such as `as:Like`, `as:Dislike`, and `as:Flag`. - While these may be relevant to implementations of the Vultron protocol, we - do not have specific use cases for them at this time. diff --git a/docs/howto/activitypub/activities/_error.md b/docs/howto/activitypub/activities/_error.md deleted file mode 100644 index b76ecde..0000000 --- a/docs/howto/activitypub/activities/_error.md +++ /dev/null @@ -1,16 +0,0 @@ -# Error Handling - -While the ActivityStreams vocabulary doesn't include any specific error messages, -we can use the `as:Reject` activity to indicate that a message has been rejected -for some reason. We specify a number of specific error messages that can be -indicated based on what kind of message they are `as:inReplyTo`. - -```mermaid -flowchart LR - - vultron_proto:VultronMessageType --> VultronError - vultron_proto:CsMessageType --> CsError - vultron_proto:EmMessageType --> EmError - vultron_proto:GmMessageType --> GmError - vultron_proto:RmMessageType --> RmError -``` diff --git a/docs/howto/activitypub/activities/_establish_embargo.md b/docs/howto/activitypub/activities/_establish_embargo.md deleted file mode 100644 index 051340b..0000000 --- a/docs/howto/activitypub/activities/_establish_embargo.md +++ /dev/null @@ -1,32 +0,0 @@ -# Establishing an Embargo - -```mermaid -flowchart LR - subgraph as:Invite - EmProposeEmbargo - end - subgraph as:Question - ChoosePreferredEmbargo - end - subgraph as:Accept - EmAcceptEmbargo - end - subgraph as:Reject - EmRejectEmbargo - end - subgraph as:Announce - AnnounceEmbargo - end - subgraph as:Add - ActivateEmbargo - AddEmbargoToCase - end - EmProposeEmbargo --> EmAcceptEmbargo - EmProposeEmbargo --> ChoosePreferredEmbargo - ChoosePreferredEmbargo --> EmAcceptEmbargo - EmProposeEmbargo --> EmRejectEmbargo - ChoosePreferredEmbargo --> EmRejectEmbargo - EmAcceptEmbargo --> ActivateEmbargo - AddEmbargoToCase --> AnnounceEmbargo - ActivateEmbargo --> AnnounceEmbargo -``` diff --git a/docs/howto/activitypub/activities/_initialize_case.md b/docs/howto/activitypub/activities/_initialize_case.md deleted file mode 100644 index 3cdb7a3..0000000 --- a/docs/howto/activitypub/activities/_initialize_case.md +++ /dev/null @@ -1,16 +0,0 @@ -# Initializing a Case - -```mermaid -flowchart LR - subgraph as:Create - CreateCase - end - subgraph as:Add - AddReportToCase - AddParticipantToCase - AddNoteToCase - end - CreateCase --> AddReportToCase - CreateCase --> AddParticipantToCase - CreateCase --> AddNoteToCase -``` diff --git a/docs/howto/activitypub/activities/_initialize_participant.md b/docs/howto/activitypub/activities/_initialize_participant.md deleted file mode 100644 index ca6582e..0000000 --- a/docs/howto/activitypub/activities/_initialize_participant.md +++ /dev/null @@ -1,12 +0,0 @@ -# Initializing a CaseParticipant - -```mermaid -flowchart LR - subgraph as:Create - RmCreateParticipant - end - subgraph as:Add - AddParticipantToCase - end - RmCreateParticipant --> AddParticipantToCase -``` diff --git a/docs/howto/activitypub/activities/_invite_actor.md b/docs/howto/activitypub/activities/_invite_actor.md deleted file mode 100644 index 0a1866f..0000000 --- a/docs/howto/activitypub/activities/_invite_actor.md +++ /dev/null @@ -1,20 +0,0 @@ -# Inviting an Actor to a Case - -```mermaid -flowchart LR - subgraph as:Invite - RmInviteToCase - end - subgraph as:Accept - RmAcceptInviteToCase - end - subgraph as:Reject - RmRejectInviteToCase - end - subgraph as:Add - AddParticipantToCase - end - RmInviteToCase --> RmAcceptInviteToCase - RmInviteToCase --> RmRejectInviteToCase - RmAcceptInviteToCase --> AddParticipantToCase -``` diff --git a/docs/howto/activitypub/activities/_manage_case.md b/docs/howto/activitypub/activities/_manage_case.md deleted file mode 100644 index 009ec63..0000000 --- a/docs/howto/activitypub/activities/_manage_case.md +++ /dev/null @@ -1,65 +0,0 @@ -# Managing a Case - -Case management activities reflect the -[Report Management](../../../topics/process_models/rm/index.md) process model. - -```mermaid -flowchart LR - subgraph as:Offer - RmSubmitReport - end - subgraph as:Accept - RmValidateReport - end - subgraph as:Reject - RmInvalidateReport - end - subgraph as:Join - RmEngageCase - end - subgraph as:Leave - RmCloseCase - RmCloseReport - end - subgraph as:Ignore - RmDeferCase - end - subgraph as:Undo - RmReEngageCase - end - - RmSubmitReport --> RmValidateReport - RmSubmitReport --> RmInvalidateReport - RmValidateReport --> RmEngageCase - RmInvalidateReport --> RmValidateReport - RmEngageCase --> RmCloseCase - RmEngageCase --> RmDeferCase - RmValidateReport --> RmDeferCase - RmDeferCase --> RmEngageCase - RmDeferCase --> RmCloseCase - RmDeferCase --> RmReEngageCase - RmInvalidateReport --> RmCloseCase - RmInvalidateReport -.-> RmCloseReport -``` - -!!! tip "Close Case vs Close Report" - - Closing a report is only relevant when the report is not valid, because - valid reports should be converted to cases. Hence, we define the - `RmCloseReport` activity as a an option for when a report is invalidated - before a case is created. Both `RmCloseReport` and `RmCloseCase` are - defined as subclasses of `as:Leave` to indicate that they are both - activities that indicate that the actor's participation in the case or - report has ended. - -!!! tip "Re-Engaging a Case" - - The `RmReEngageCase` activity is used to re-engage a case that has been - deferred. Deferring a case is modeled as an `as:Ignore` - activity, since it is indicating that a participant has not entirely left - the case, but has instead deferred their participation for a period of - time. Re-engaging a case is modeled as an `as:Undo` activity, since it is - undoing the `as:Ignore` activity that was used to defer the case. - Alternatively, we could have just used the same `RmEngageCase` (`as:Join`) - activity. That might still be a better option, but we'll leave it as an - implementation choice for now. diff --git a/docs/howto/activitypub/activities/_manage_embargo.md b/docs/howto/activitypub/activities/_manage_embargo.md deleted file mode 100644 index 48e5218..0000000 --- a/docs/howto/activitypub/activities/_manage_embargo.md +++ /dev/null @@ -1,46 +0,0 @@ -# Managing an Embargo - -Once established, an embargo can be modified via a propose/accept/reject cycle. -It can also be terminated or removed from a case. - -!!! tip "Announce Embargo" - - The `AnnounceEmbargo` activity is used to indicate that an embargo has been - established or to remind participants of its status. It is used to announce - the embargo to the case participants. It is also used to draw attention to - significant changes to the embargo status over and above the corresponding - CaseStatus messages, such as when an embargo is deactivated or removed from - a case. - -```mermaid -flowchart LR - subgraph as:Invite - EmProposeEmbargo - end - subgraph as:Accept - EmAcceptEmbargo - end - subgraph as:Reject - EmRejectEmbargo - end - subgraph as:Add - ActivateEmbargo - AddEmbargoToCase - end - subgraph as:Remove - RemoveEmbargoFromCase - end - subgraph as:Announce - AnnounceEmbargo - end - - EmAcceptEmbargo --> AddEmbargoToCase - EmAcceptEmbargo --> ActivateEmbargo - AddEmbargoToCase --> EmProposeEmbargo - EmProposeEmbargo --> EmAcceptEmbargo - EmProposeEmbargo --> EmRejectEmbargo - EmRejectEmbargo --> EmProposeEmbargo - ActivateEmbargo --> RemoveEmbargoFromCase - ActivateEmbargo --> EmProposeEmbargo - RemoveEmbargoFromCase --> EmProposeEmbargo -``` diff --git a/docs/howto/activitypub/activities/_manage_participants.md b/docs/howto/activitypub/activities/_manage_participants.md deleted file mode 100644 index 05fbe12..0000000 --- a/docs/howto/activitypub/activities/_manage_participants.md +++ /dev/null @@ -1,49 +0,0 @@ -# Managing Case Participants - -Typically most cases involve multiple participants, having various roles -within the case. While the most common activities are inviting and adding -participants, we've also included activities for removing participants. - -create, add, remove, status updates - -```mermaid -flowchart LR - subgraph as:Invite - RmInviteToCase - end - subgraph as:Accept - RmAcceptInviteToCase - end - subgraph as:Reject - RmRejectInviteToCase - end - subgraph as:Create - RmCreateParticipant - RmCreateParticipantStatus - end - subgraph as:Add - AddParticipantToCase - AddStatusToParticipant - end - subgraph as:Remove - RemoveParticipantFromCase - end - RmInviteToCase --> RmAcceptInviteToCase - RmInviteToCase --> RmRejectInviteToCase - RmAcceptInviteToCase --> RmCreateParticipant - RmCreateParticipantStatus --> AddStatusToParticipant - RmCreateParticipant --> AddParticipantToCase - RmCreateParticipant --> RmCreateParticipantStatus - AddParticipantToCase --> RemoveParticipantFromCase - RemoveParticipantFromCase --> AddParticipantToCase -``` - -!!! tip "Create or Add, once again" - - Again, there appears to be some logical interchangeability of `as:Create` - with `as:Add` since both include a `target` property that can be used to - specify the object to which the new object is being added. We chose to - represent them separately here to acknowledge the difference between - creating a new object and adding an existing object to another object, but - in an actual implementation it may be acceptable to use either activity for - both cases. diff --git a/docs/howto/activitypub/activities/_report_vulnerability.md b/docs/howto/activitypub/activities/_report_vulnerability.md deleted file mode 100644 index f39b51b..0000000 --- a/docs/howto/activitypub/activities/_report_vulnerability.md +++ /dev/null @@ -1,32 +0,0 @@ -# Reporting a Vulnerability - -```mermaid -flowchart LR - subgraph as:Create - RmCreateReport - CreateCase - end - subgraph as:Read - RmReadReport - end - subgraph as:Offer - RmSubmitReport - end - subgraph as:Accept - RmValidateReport - end - subgraph as:Reject - RmInvalidateReport - end - subgraph as:Leave - RmCloseReport - end - - RmCreateReport --> RmSubmitReport - RmSubmitReport --> RmReadReport - RmSubmitReport --> RmValidateReport - RmSubmitReport --> RmInvalidateReport - RmInvalidateReport --> RmValidateReport - RmValidateReport --> CreateCase - RmInvalidateReport --> RmCloseReport -``` diff --git a/docs/howto/activitypub/activities/_status_updates.md b/docs/howto/activitypub/activities/_status_updates.md deleted file mode 100644 index 288d2b4..0000000 --- a/docs/howto/activitypub/activities/_status_updates.md +++ /dev/null @@ -1,55 +0,0 @@ -# Status Updates and Comments - -Here we have a number of activities that are used to update the status of a -case, or to add a comment to a case. - -```mermaid -flowchart LR - subgraph as:Add - AddNoteToCase - AddStatusToCase - AddStatusToParticipant - end - subgraph as:Create - CreateNote - CreateParticipantStatus - CreateStatus - end - CreateNote --> AddNoteToCase - CreateStatus --> AddStatusToCase - CreateParticipantStatus --> AddStatusToParticipant - AddStatusToParticipant -.-> AddStatusToCase - AddNoteToCase -.-> AddStatusToParticipant - AddNoteToCase -.-> AddStatusToCase -``` - -In addition to the Create/Add process for -each of these, there are sometimes additional activities that are triggered in -response to a status update or a comment: - -- A status update to a participant can trigger a status update to the case. -- A note might trigger a status update to a case or a participant. - -!!! tip "A Note on Notes" - - The ActivityStreams vocabulary includes a `Note` object, which is - used to represent a comment or short post. We use this object to represent - comments on a case. - -!!! tip "Create *then* Add vs Create with a Target" - - In this documentation, we use the `as:Create` activity to represent the - creation of a new object, such as a new note or a new status. We use the - `as:Add` activity to represent the addition of an existing object to another - object, such as adding a status to a case. - - However, it is likely acceptable within an ActivityPub implementation to - use the `as:Create` activity for both cases, since the `as:Create` activity - includes a `target` property that can be used to specify the object to - which the new object is being added. - - Sinilarly, it may also be acceptable to use the `as:Add` activity to - represent the creation of a new object, since the `as:Add` activity - includes a `object` property that can be used to specify the object that - is being created along with the `target` property that can be used to - specify the object to which the new object is being added. diff --git a/docs/howto/activitypub/activities/_suggest_actor.md b/docs/howto/activitypub/activities/_suggest_actor.md deleted file mode 100644 index 37bfe6e..0000000 --- a/docs/howto/activitypub/activities/_suggest_actor.md +++ /dev/null @@ -1,20 +0,0 @@ -# Suggesting an Actor for a Case - -```mermaid -flowchart LR - subgraph as:Offer - RecommendActor - end - subgraph as:Accept - AcceptActorRecommendation - end - subgraph as:Reject - RejectActorRecommendation - end - subgraph as:Invite - RmInviteToCase - end - RecommendActor --> AcceptActorRecommendation - RecommendActor --> RejectActorRecommendation - AcceptActorRecommendation --> RmInviteToCase -``` diff --git a/docs/howto/activitypub/activities/_transfer_ownership.md b/docs/howto/activitypub/activities/_transfer_ownership.md deleted file mode 100644 index 2c4dbc4..0000000 --- a/docs/howto/activitypub/activities/_transfer_ownership.md +++ /dev/null @@ -1,30 +0,0 @@ -# Transferring Case Ownership - -This was not part of the original Vultron protocol, but it seems like a -reasonable extension that could be useful in some cases, such as transferring a -case - -- from a researcher to a vendor -- from a vendor to an upstream vendor -- from a vendor to a coordinator -- from a coordinator to a vendor -- between coordinators - -```mermaid -flowchart LR - subgraph as:Invite - OfferCaseOwnershipTransfer - end - subgraph as:Accept - AcceptCaseOwnershipTransfer - end - subgraph as:Reject - RejectCaseOwnershipTransfer - end - subgraph as:Update - UpdateCase - end - OfferCaseOwnershipTransfer --> AcceptCaseOwnershipTransfer - OfferCaseOwnershipTransfer --> RejectCaseOwnershipTransfer - AcceptCaseOwnershipTransfer --> UpdateCase -``` diff --git a/docs/reference/iso_29147_2018.md b/docs/reference/iso_29147_2018.md deleted file mode 100644 index 3e7cd7a..0000000 --- a/docs/reference/iso_29147_2018.md +++ /dev/null @@ -1,59 +0,0 @@ -# ISO/IEC 29147:2018 Crosswalk - -{% include-markdown "../includes/not_normative.md" %} - -[ISO/IEC 29147:2018](https://www.iso.org/standard/72311.html) -**Information technology — Security techniques — Vulnerability disclosure** -also overlaps with the Vultron Protocol. - -
-
- -Perhaps unsurprisingly, clauses 5 through 9 of ISO/IEC 29147:2018 overlap significantly with the Vultron Protocol. - -!!! tip "Consistent Terminology" - - Our use of the following terms is consistent with ISO/IEC 29147:2018 - _§5.4 Systems, components, and services_: Systems, Components, Products, Services, Vulnerability, and Product interdependency. - - ISO/IEC 29147:2018 _§5.5 Stakeholder Roles_ includes _User_, _Vendor_, _Reporter_, and _Coordinator_. - We generally use _Deployer_ instead of _User_, but the rest are consistent. - -See the table below for a thorough cross-reference. - -| ISO/IEC
29147:2018
Clause | Sub-Clause | Vultron Protocol Mapping | -|:---------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 5.6 Vulnerability Handling Process Summary | 5.6.1 General
5.6.2 Preparation
5.6.3 Receipt
5.6.4 Verification
5.6.5 Remediation development
5.6.6 Release
5.6.7 Post-release | The first few subsections of ISO/IEC 29147:2018 §5.6 are recapitulated in [ISO/IEC 30111:2019](iso_30111_2019.md). Accordingly, see the corresponding rows on that page | -| | 5.6.8 Embargo period | [EM Discussion](../topics/process_models/em/principles.md) -| 5.7 Information exchange during vulnerability disclosure | send-report-to | [Message Types](formal_protocol/messages.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md)
$q^{rm} \in A + RS$ sender
$q^{rm} \in S \xrightarrow{r} R + RS$ receiver | -| | release-advisory-to | [Message Types](formal_protocol/messages.md)
[Prepare Publication Behavior](../topics/behavior_logic/publication_bt.md)
$q^{rm} \in A + GI$ sender
$q^{rm} \in \{R,V,A,D\} + GI$ receiver | -| 5.8 Confidentiality | | [Embargo Management Model](../topics/process_models/em/index.md)
[Transport Protocol](../howto/general_implementation.md#transport-protocol) | -| 5.9 Vulnerability advisories | | the [Public Awareness](../topics/process_models/cs/index.md#the-public-awareness-substate-p-p) substate
[Publication Behavior](../topics/behavior_logic/publication_bt.md) | -| 5.10 Vulnerability exploitation | | the [Exploit Public](../topics/process_models/cs/index.md#the-exploit-public-substate-x-x) substate
the [Attacks Observed](../topics/process_models/cs/index.md#the-attacks-observed-substate-a-a) substate
[Monitor Threats Behavior](../topics/behavior_logic/monitor_threats_bt.md) | -| 5.11 Vulnerabilities and risk | | [Interactions between the Vultron Protocol and SSVC](ssvc_crosswalk.md) -| 6 Receiving vulnerability reports | 6.1 General | the [Report Management Model](../topics/process_models/rm/index.md)
the [Vendor Awareness](../topics/process_models/cs/index.md#the-vendor-awareness-substate-v-v) substate
[Process RM Messages Behavior](../topics/behavior_logic/msg_rm_bt.md) | -| 6.2 Vulnerability reports | 6.2.1 General | the [Report Management Model](../topics/process_models/rm/index.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md) | -| | 6.2.2 Capability to receive reports | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
[Process RM Messages Behavior](../topics/behavior_logic/msg_rm_bt.md) | -| | 6.2.3 Monitoring | [Receiving and Processing Messages Behavior](../topics/behavior_logic/msg_intro_bt.md) | -| | 6.2.4 Report Tracking | the [Report Management Model](../topics/process_models/rm/index.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md)
[Case Object](../howto/case_object.md) | -| | 6.2.5 Report Acknowledgement | [RM Message Types](formal_protocol/messages.md#rm-message-types)
[Process RM Messages Behavior](../topics/behavior_logic/msg_rm_bt.md) | -| 6.3 Initial assessment | | [RM Message Types](formal_protocol/messages.md#rm-message-types)
[Report Prioritization Behavior](../topics/behavior_logic/rm_prioritization_bt.md) | -| 6.4 Further investigation | | [RM Message Types](formal_protocol/messages.md#rm-message-types)
[Do Work Behavior](../topics/behavior_logic/do_work_bt.md) | -| 6.5 On-going communication | | [Message Types](formal_protocol/messages.md) | -| 6.6 Coordinator involvement | - | [RM Interactions Between CVD Participants](../topics/process_models/rm/rm_interactions.md)
[Inviting Others to and Embargoed Case](../topics/process_models/em/working_with_others.md)
[Coordination with a Coordinator](../topics/formal_protocol/worked_example.md#coordinating_with_coordinator)
[Notify Others Behavior](../topics/behavior_logic/reporting_bt.md) | -| 6.7 Operational security | - | [Transport Protocol](../howto/general_implementation.md#transport-protocol) | -| 7 Publishing vulnerability advisories | all | [Publication Behavior](../topics/behavior_logic/publication_bt.md)
[CVD Case Substates](../topics/process_models/cs/index.md#cvd-case-substates) | -| | 7.3 Advisory publication timing | [Embargo Principles](../topics/process_models/em/principles.md) | -| | 7.4 Advisory elements | [Message Formats](../howto/general_implementation.md#message-formats) | -| | 7.5 Advisory communication | [Publication Behavior](../topics/behavior_logic/publication_bt.md) | -| | 7.6 Advisory format | [Message Formats](../howto/general_implementation.md#message-formats) | -| | 7.7 Advisory authenticity | [Identity Management](../howto/general_implementation.md#identity-management) | -| | 7.8 Remediations | [Deployment Behavior](../topics/behavior_logic/deployment_bt.md) | -| 8 Coordination | 8.1 General | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
the [Accepted](../topics/process_models/rm/index.md#the-accepted-a-state) state
[RM Interactions Between CVD Participants](../topics/process_models/rm/rm_interactions.md)
[Inviting Others to an Embargoed Case](../topics/process_models/em/working_with_others.md)
[Modeling an MPCVD AI Using Behavior Trees](../topics/behavior_logic/cvd_bt.md) | -| | 8.2 Vendors playing multiple roles | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
the [Accepted](../topics/process_models/rm/index.md#the-accepted-a-state) state
the [Fix Readiness](../topics/process_models/cs/index.md#the-fix-readiness-substate-f-f) Substate
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md) | -| 9 Vulnerability disclosure policy | 9.2.2 Preferred contact mechanism | [Receiving and Processing Messages Behavior](../topics/behavior_logic/msg_intro_bt.md) | -| | 9.3.2 Vulnerability report contents | [Case Object](../howto/case_object.md) | -| | 9.3.3 Secure communication options | [Transport Protocol](../howto/general_implementation.md#transport-protocol) | -| | 9.3.4 Setting communication expectations | [Default Embargoes](../topics/process_models/em/defaults.md)
[Transition Functions](formal_protocol/transitions.md)
[Report Management Behavior Tree](../topics/behavior_logic/rm_bt.md) | -| | 9.3.6 Publication | [Publication Behavior](../topics/behavior_logic/publication_bt.md) | -| | 9.4.3 Disclosure timeline | [Embargo Management Model](../topics/process_models/em/index.md) | diff --git a/docs/reference/iso_30111_2019.md b/docs/reference/iso_30111_2019.md deleted file mode 100644 index 30cbc02..0000000 --- a/docs/reference/iso_30111_2019.md +++ /dev/null @@ -1,34 +0,0 @@ -# ISO/IEC 30111:2019 Crosswalk - -{% include-markdown "../includes/not_normative.md" %} - -Clause 7 of [ISO/IEC 30111:2019](https://www.iso.org/standard/69725.html) -**Information technology — Security techniques — Vulnerability handling processes** -closely relates to the Vultron Protocol. - -
-
-The table below provides a mapping of ISO/IEC 30111:2019 onto the relevant concepts and sections of this documentation. - -| ISO/IEC
30111:2019
Clause | Sub-Clause | Vultron Protocol Mapping | -|:---------------------------------|:-------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 7.1.1 General | - | See details below | -| 7.1.2 Preparation | - | See details below | -| 7.1.3 Receipt | a) Internally Found Vulnerabilities | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
[RM Message Types](formal_protocol/messages.md#rm-message-types)
[Vulnerability Discovery Behavior](../topics/behavior_logic/vuldisco_bt.md)
$q^{rm} \in S \xrightarrow{r} R$ | -| | b) Externally Found Vulnerabilities | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
[RM Message Types](formal_protocol/messages.md#rm-message-types)
[Process RM Messages Behavior](../topics/behavior_logic/msg_rm_bt.md)
$q^{rm} \in S \xrightarrow{r} R$ | -| | c) Publicly Disclosed Vulnerabilities | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
[RM Message Types](formal_protocol/messages.md#rm-message-types)
[CS Message Types](formal_protocol/messages.md#cs-message-types)
[Monitor Threats Behavior](../topics/behavior_logic/monitor_threats_bt.md)
[Process RM Messages Behavior](../topics/behavior_logic/msg_rm_bt.md)
[Process CS Messages Behavior](../topics/behavior_logic/msg_cs_bt.md)
$q^{rm} \in S \xrightarrow{r} R$
$q^{cs} \in \cdot\cdot\cdot p \cdot\cdot \xrightarrow{\mathbf{P}} \cdot\cdot\cdot P \cdot\cdot$ | -| 7.1.4 Verification | a) Initial Investigation | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
[Report Validation Behavior](../topics/behavior_logic/rm_validation_bt.md)
$q^{rm} \in R \xrightarrow{v} V$ if valid
$q^{rm} \in R \xrightarrow{i} I$ if invalid | -| | b) Possible Process Exit
  1) Duplicate | attach to the original report | -| | b) Possible Process Exit
  2) Obsolete product | $q^{rm} \in I \xrightarrow{c} C$ if invalid
$q^{rm} \in V \xrightarrow{d} D \xrightarrow{c} C$ if valid | -| | b) Possible Process Exit
  3) Non-security | $q^{rm} \in I \xrightarrow{c} C$ | -| | b) Possible Process Exit
  4) Other vendor | [Reporting Behavior](../topics/behavior_logic/reporting_bt.md)
$q^{rm} \in V \xrightarrow{a} A$ | -| | c) Root Cause Analysis | [Do Work Behavior](../topics/behavior_logic/do_work_bt.md)
$q^{rm} \in A$ | -| | d) Further investigation | [Do Work Behavior](../topics/behavior_logic/do_work_bt.md)
$q^{rm} \in A$ | -| | e) Prioritization | the [Valid](../topics/process_models/rm/index.md#the-valid-v-state) state
[Report Prioritization Behavior](../topics/behavior_logic/rm_prioritization_bt.md)
$q^{rm} \in V \xrightarrow{d} D$ on defer
$q^{rm} \in V \xrightarrow{a} A$ on accept | -| | f) Inform reporter | [Report Validation Behavior](../topics/behavior_logic/rm_validation_bt.md)
[Report Prioritization Behavior](../topics/behavior_logic/rm_prioritization_bt.md)
Emit *RV*, *RI*, *RA*, *RD* messages as appropriate | -| 7.1.5 Remediation Development | all| the [Accepted](../topics/process_models/rm/index.md#the-accepted-a-state) state
the [Fix Readiness](../topics/process_models/cs/index.md#the-fix-readiness-substate-f-f) substate
[Fix Ready](../topics/process_models/model_interactions/rm_em_cs.md#fix-ready)
[Fix Development Behavior](../topics/behavior_logic/fix_dev_bt.md)
$q^{rm} \in A$
$q^{cs} \in Vfd\cdot\cdot\cdot \xrightarrow{\mathbf{V}} VFd\cdot\cdot\cdot$ | -| 7.1.6 Release | - | the [Fix Readiness](../topics/process_models/cs/index.md#the-fix-readiness-substate-f-f) substate
[Publication Behavior](../topics/behavior_logic/publication_bt.md)
$q^{cs} \in VFdp\cdot\cdot \xrightarrow{\mathbf{P}} VFdP \cdot\cdot$ | -| 7.1.7 Post-release | all | [Report Closure Behavior](../topics/behavior_logic/rm_closure_bt.md)
[Deployment Behavior](../topics/behavior_logic/deployment_bt.md)
$q^{cs} \in VF\cdot P \cdot\cdot$
$q^{rm} \in \{A,D\}$ | -| 7.2 Process Monitoring | all | [Deployment Behavior](../topics/behavior_logic/deployment_bt.md) | -| 7.3 Confidentiality | - | [Embargo Management Behavior](../topics/behavior_logic/em_bt.md) | -| 8 Supply chain considerations| - | [Reporting Behavior](../topics/behavior_logic/reporting_bt.md) | diff --git a/docs/reference/iso_5895_2022.md b/docs/reference/iso_5895_2022.md deleted file mode 100644 index 52d0315..0000000 --- a/docs/reference/iso_5895_2022.md +++ /dev/null @@ -1,33 +0,0 @@ -# ISO/IEC TR 5895:2022 Crosswalk - -{% include-markdown "../includes/not_normative.md" %} - -[ISO/IEC TR 5895:2022](https://www.iso.org/standard/81807.html) -**Cybersecurity — Multi-party coordinated vulnerability disclosure and handling** -intersects most directly with our topic. - -
-
- -The table below contains our mapping of relevant sections of that technical report to our protocol model. - -| ISO/IEC TR 5895:2022 Clause | Sub-Clause | Vultron Protocol Model | -|:----------------------------------------------------|:----------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 4 Concepts | 4.2.3 Risk Reduction Effectiveness | [Early Termination](../topics/process_models/em/early_termination.md#early-termination)
[Adding Participants to an Embargoed Case](../topics/process_models/em/working_with_others.md) | -| 5 MPCVD Scenarios in Scope | all | [Adding Participants to an Embargoed Case](../topics/process_models/em/working_with_others.md) | -| 6 MPCVD Stakeholders | all | [Terms and Definitions](../topics/background/terms.md) | -| 7 MPCVD Lifecycle | 7.2 Policy Development | the [Report Management Model](../topics/process_models/rm/index.md)
the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
[Default Embargoes](../topics/process_models/em/defaults.md)
[CVD Directory](../topics/future_work/cvd_directory.md) | -| | 7.3 Strategy development | [RM Interactions between CVD Participants](../topics/process_models/rm/rm_interactions.md)
[EM Discussion](../topics/process_models/em/principles.md) | -| | 7.4 Know your customers | [RM Interactions between CVD Participants](../topics/process_models/rm/rm_interactions.md)
[Adding Participants to an Embargoed Case](../topics/process_models/em/working_with_others.md) | -| | 7.5 Encrypted Communication Methods and Conference Calls | [Transport Protocol](../howto/general_implementation.md#transport-protocol) | -| | 7.6 Processes and Controls | See NDA Note in [Embargo Management Model](../topics/process_models/em/index.md) | -| 8 MPCVD lifecycle for each product | all | [Deployment Behavior](../topics/behavior_logic/deployment_bt.md)
[Fix Development Behavior](../topics/behavior_logic/fix_dev_bt.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md)
[Publication Behavior](../topics/behavior_logic/publication_bt.md)
$q^{rm} \in A$ | -| 9 MPCVD lifecycle for each vulnerability | 9.1 Receipt | the [Start](../topics/process_models/rm/index.md#the-start-s-state) state
the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
the [Vendor Awareness](../topics/process_models/cs/index.md#the-vendor-awareness-substate-v-v) substate
[Process RM Messages Behavior](../topics/behavior_logic/msg_rm_bt.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md)
$q^{rm} \in S \xrightarrow{r} R$
$q^{cs} \in vfd\cdot\cdot\cdot \xrightarrow{\mathbf{V}} Vfd\cdot\cdot\cdot$ | -| | 9.2 Verification | the [Received](../topics/process_models/rm/index.md#the-received-r-state) state
the [Valid](../topics/process_models/rm/index.md#the-valid-v-state) state
the [Valid](../topics/process_models/rm/index.md#the-invalid-i-state) state
[Embargo Principles](../topics/process_models/em/principles.md)
[Report Validation Behavior](../topics/behavior_logic/rm_validation_bt.md)
[Report Prioritization Behavior](../topics/behavior_logic/rm_prioritization_bt.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md)
$q^{rm} \in R \xrightarrow{v} V$ (valid)
$q^{rm} \in R \xrightarrow{i} I$ (invalid)
Emit *RV*. *RI*, *RA*, *RD* as appropriate | -| | 9.3 Remediation development | the [Accepted](../topics/process_models/rm/index.md#the-accepted-a-state) state
the [Fix Readiness](../topics/process_models/cs/index.md#the-fix-readiness-substate-f-f) substate
[Fix Ready](../topics/process_models/model_interactions/rm_em_cs.md#sec:cs_f_em/index.md)
[Fix Development Behavior](../topics/behavior_logic/fix_dev_bt.md)
$q^{rm} \in A$
$q^{cs} \in Vfd\cdot\cdot\cdot \xrightarrow{\mathbf{F}}VFd\cdot\cdot\cdot$ | -| | 9.4 Release | the [Fix Readiness](../topics/process_models/cs/index.md#the-fix-readiness-substate-f-f) substate
[Publication Behavior](../topics/behavior_logic/publication_bt.md)
$q^{cs} \in VFdp\cdot\cdot \xrightarrow{\mathbf{P}} VFDP\cdot\cdot$ | -| | 9.5 Post-release | [Report Closure Behavior](../topics/behavior_logic/rm_closure_bt.md)
[Deployment Behavior](../topics/behavior_logic/deployment_bt.md)
$q^{rm} \in \{A,D\}$
$q^{cs} \in VF\cdot P \cdot\cdot$ | -| | 9.6 Embargo Period | [RM Interactions between CVD Participants](../topics/process_models/rm/rm_interactions.md)
[EM Discussion](../topics/process_models/em/principles.md)
[Interactions Between the RM and EM Models](../topics/process_models/model_interactions/rm_em.md)
$q^{em} \not \in X$ | -| 10 Information exchange | - | [RM Interactions between CVD Participants](../topics/process_models/rm/rm_interactions.md)
[Message Types](formal_protocol/messages.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md) | -| 11 Disclosure | - | [Adding Participants to an Embargoed Case](../topics/process_models/em/working_with_others.md)
[Coordination with a Coordinator](../topics/formal_protocol/worked_example.md#sec:coordinating_with_coordinator)
[Publication Behavior](../topics/behavior_logic/publication_bt.md) | -| 12 Use case for hardware and further considerations | - | [Adding Participants to an Embargoed Case](../topics/process_models/em/working_with_others.md)
[Interactions Between the RM and EM Models](../topics/process_models/model_interactions/rm_em.md)
[Reporting Behavior](../topics/behavior_logic/reporting_bt.md) | diff --git a/docs/reference/iso_crosswalk.md b/docs/reference/iso_crosswalk.md deleted file mode 100644 index 16faf4d..0000000 --- a/docs/reference/iso_crosswalk.md +++ /dev/null @@ -1,10 +0,0 @@ -# ISO Crosswalk - -Three ISO standards are relevant to the Vultron Protocol. -We cross-reference them here to help readers understand how they relate to the Vultron Protocol. - -| ISO Document | ISO Title | Vultron Protocol Crosswalk | -| --- | --- |--------------------------------| -| [ISO/IEC 30111:2019](https://www.iso.org/standard/69725.html) | **Information technology — Security techniques — Vulnerability handling processes** | [ISO 30111](iso_30111_2019.md) | -| [ISO/IEC 29147:2018](https://www.iso.org/standard/72311.html) | **Information technology — Security techniques — Vulnerability disclosure** | [ISO 29147](iso_29147_2018.md) | -| [ISO/IEC TR 5895:2022](https://www.iso.org/standard/81807.html) | **Cybersecurity — Multi-party coordinated vulnerability disclosure and handling** | [ISO 5898](iso_5895_2022.md) |