From 767903fccbe6a5e049be29083a5c08da85a5daef Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 27 Oct 2023 10:31:18 -0400 Subject: [PATCH 1/6] markdownlint -fix --- Acknowledgements.md | 2 - COPYRIGHT.md | 4 +- ContributionInstructions.md | 24 ++--- Contributors.md | 2 +- LICENSE.md | 4 +- README.md | 46 ++++----- doc/README.md | 2 +- docs/about/acknowledgements.md | 2 +- docs/about/contributing.md | 2 +- docs/about/faq.md | 6 +- docs/about/license.md | 2 +- docs/howto/case_object.md | 38 ++++--- docs/howto/em_icalendar.md | 48 +++++---- docs/howto/general_implementation.md | 12 +-- docs/howto/index.md | 6 +- docs/howto/process_implementation.md | 34 +++---- docs/includes/curr_ver.md | 2 +- docs/index.md | 12 +-- docs/reference/case_states/index.md | 2 +- .../case_states/state__v__f__d__p__x__a_.md | 3 +- .../case_states/state__v__f__d__p__x_a.md | 3 +- .../case_states/state__v__f__d__p_x_a_.md | 3 +- .../case_states/state__v__f__d__p_xa.md | 3 +- .../case_states/state__v__f__d_p_x__a_.md | 3 +- .../case_states/state__v__f__d_p_x_a.md | 3 +- .../case_states/state__v__f__d_px_a_.md | 3 +- .../case_states/state__v__f__d_pxa.md | 3 +- .../case_states/state__v__f_d_p__x__a_.md | 3 +- .../case_states/state__v__f_d_p__x_a.md | 3 +- .../case_states/state__v__f_d_p_x_a_.md | 3 +- .../case_states/state__v__f_d_p_xa.md | 3 +- .../case_states/state__v__f_dp_x__a_.md | 3 +- .../case_states/state__v__f_dp_x_a.md | 3 +- .../case_states/state__v__f_dpx_a_.md | 3 +- .../reference/case_states/state__v__f_dpxa.md | 3 +- .../case_states/state__v_fd_p__x__a_.md | 3 +- .../case_states/state__v_fd_p__x_a.md | 3 +- .../case_states/state__v_fd_p_x_a_.md | 3 +- .../reference/case_states/state__v_fd_p_xa.md | 3 +- .../case_states/state__v_fdp_x__a_.md | 3 +- .../reference/case_states/state__v_fdp_x_a.md | 3 +- .../reference/case_states/state__v_fdpx_a_.md | 3 +- docs/reference/case_states/state__v_fdpxa.md | 3 +- .../case_states/state_vfd_p__x__a_.md | 3 +- .../reference/case_states/state_vfd_p__x_a.md | 3 +- .../reference/case_states/state_vfd_p_x_a_.md | 3 +- docs/reference/case_states/state_vfd_p_xa.md | 3 +- .../reference/case_states/state_vfdp_x__a_.md | 3 +- docs/reference/case_states/state_vfdp_x_a.md | 3 +- docs/reference/case_states/state_vfdpx_a_.md | 3 +- docs/reference/case_states/state_vfdpxa.md | 3 +- docs/reference/code/index.md | 1 - docs/reference/formal_protocol/conclusion.md | 13 ++- docs/reference/formal_protocol/index.md | 6 +- docs/reference/formal_protocol/messages.md | 41 ++++---- docs/reference/formal_protocol/states.md | 98 +++++++++---------- docs/reference/formal_protocol/transitions.md | 52 +++------- docs/reference/glossary.md | 42 +------- docs/reference/index.md | 3 +- docs/reference/iso_29147_2018.md | 7 +- docs/reference/iso_30111_2019.md | 7 +- docs/reference/iso_5895_2022.md | 8 +- docs/reference/iso_crosswalk.md | 2 - docs/reference/ssvc_crosswalk.md | 33 +++---- docs/topics/background/cvd_success.md | 7 +- docs/topics/background/index.md | 33 +++---- docs/topics/background/interoperability.md | 16 +-- docs/topics/background/notation.md | 17 ++-- docs/topics/background/overview.md | 27 +++-- docs/topics/background/terms.md | 10 +- docs/topics/background/versioning.md | 7 +- .../behavior_logic/acquire_exploit_bt.md | 3 +- docs/topics/behavior_logic/cvd_bt.md | 15 ++- docs/topics/behavior_logic/deployment_bt.md | 15 ++- docs/topics/behavior_logic/do_work_bt.md | 20 ++-- docs/topics/behavior_logic/em_bt.md | 9 +- docs/topics/behavior_logic/em_eval_bt.md | 3 - docs/topics/behavior_logic/em_propose_bt.md | 7 +- docs/topics/behavior_logic/em_terminate_bt.md | 1 - docs/topics/behavior_logic/fix_dev_bt.md | 6 +- .../topics/behavior_logic/id_assignment_bt.md | 3 +- docs/topics/behavior_logic/index.md | 4 - .../behavior_logic/monitor_threats_bt.md | 7 +- docs/topics/behavior_logic/msg_cs_bt.md | 25 ++--- docs/topics/behavior_logic/msg_em_bt.md | 26 +++-- docs/topics/behavior_logic/msg_intro_bt.md | 1 - docs/topics/behavior_logic/msg_other_bt.md | 7 +- docs/topics/behavior_logic/msg_rm_bt.md | 9 +- docs/topics/behavior_logic/publication_bt.md | 3 +- docs/topics/behavior_logic/reporting_bt.md | 16 +-- docs/topics/behavior_logic/rm_bt.md | 3 +- docs/topics/behavior_logic/rm_closure_bt.md | 4 +- .../behavior_logic/rm_prioritization_bt.md | 3 +- .../topics/behavior_logic/rm_validation_bt.md | 2 +- docs/topics/behavior_logic/vuldisco_bt.md | 4 - docs/topics/formal_protocol/worked_example.md | 34 +++---- docs/topics/future_work/cvd_directory.md | 29 +++--- docs/topics/future_work/index.md | 7 +- docs/topics/future_work/mod_sim.md | 9 +- docs/topics/future_work/ontology.md | 6 +- docs/topics/future_work/reward_functions.md | 26 +++-- docs/topics/index.md | 3 +- docs/topics/process_models/cs/cs_model.md | 48 ++++----- docs/topics/process_models/cs/index.md | 46 +++++---- .../process_models/cs/vfdpxa_diagram.md | 36 +++---- .../process_models/dfa_notation_definition.md | 3 +- docs/topics/process_models/em/defaults.md | 13 --- .../process_models/em/early_termination.md | 17 ++-- docs/topics/process_models/em/index.md | 87 +++++++--------- docs/topics/process_models/em/negotiating.md | 17 ++-- docs/topics/process_models/em/principles.md | 12 +-- docs/topics/process_models/em/split_merge.md | 5 +- .../process_models/em/working_with_others.md | 49 +++++----- docs/topics/process_models/index.md | 4 +- .../model_interactions/index.md | 8 +- .../model_interactions/rm_em.md | 14 +-- .../model_interactions/rm_em_cs.md | 30 +++--- docs/topics/process_models/rm/index.md | 50 ++++------ .../process_models/rm/rm_interactions.md | 35 +++---- docs/topics/user_stories/index.md | 3 - docs/topics/user_stories/story_2022_002.md | 3 +- docs/topics/user_stories/story_2022_003.md | 1 - docs/topics/user_stories/story_2022_004.md | 1 - docs/topics/user_stories/story_2022_005.md | 1 - docs/topics/user_stories/story_2022_006.md | 3 +- docs/topics/user_stories/story_2022_007.md | 1 - docs/topics/user_stories/story_2022_008.md | 1 - docs/topics/user_stories/story_2022_009.md | 1 - docs/topics/user_stories/story_2022_010.md | 3 +- docs/topics/user_stories/story_2022_011.md | 1 - docs/topics/user_stories/story_2022_012.md | 3 +- docs/topics/user_stories/story_2022_013.md | 1 - docs/topics/user_stories/story_2022_014.md | 1 - docs/topics/user_stories/story_2022_015.md | 3 +- docs/topics/user_stories/story_2022_016.md | 5 +- docs/topics/user_stories/story_2022_017.md | 3 +- docs/topics/user_stories/story_2022_018.md | 1 - docs/topics/user_stories/story_2022_019.md | 1 - docs/topics/user_stories/story_2022_020.md | 3 +- docs/topics/user_stories/story_2022_021.md | 1 - docs/topics/user_stories/story_2022_022.md | 1 - docs/topics/user_stories/story_2022_023.md | 1 - docs/topics/user_stories/story_2022_024.md | 3 +- docs/topics/user_stories/story_2022_025.md | 3 +- docs/topics/user_stories/story_2022_026.md | 3 +- docs/topics/user_stories/story_2022_027.md | 1 - docs/topics/user_stories/story_2022_028.md | 1 - docs/topics/user_stories/story_2022_029.md | 1 - docs/topics/user_stories/story_2022_030.md | 1 - docs/topics/user_stories/story_2022_031.md | 1 - docs/topics/user_stories/story_2022_032.md | 1 - docs/topics/user_stories/story_2022_033.md | 1 - docs/topics/user_stories/story_2022_034.md | 1 - docs/topics/user_stories/story_2022_035.md | 1 - docs/topics/user_stories/story_2022_036.md | 1 - docs/topics/user_stories/story_2022_037.md | 5 +- docs/topics/user_stories/story_2022_038.md | 3 +- docs/topics/user_stories/story_2022_039.md | 1 - docs/topics/user_stories/story_2022_040.md | 3 +- docs/topics/user_stories/story_2022_041.md | 1 - docs/topics/user_stories/story_2022_042.md | 1 - docs/topics/user_stories/story_2022_043.md | 1 - docs/topics/user_stories/story_2022_044.md | 1 - docs/topics/user_stories/story_2022_045.md | 1 - docs/topics/user_stories/story_2022_046.md | 1 - docs/topics/user_stories/story_2022_047.md | 1 - docs/topics/user_stories/story_2022_048.md | 1 - docs/topics/user_stories/story_2022_049.md | 1 - docs/topics/user_stories/story_2022_050.md | 1 - docs/topics/user_stories/story_2022_051.md | 1 - docs/topics/user_stories/story_2022_052.md | 1 - docs/topics/user_stories/story_2022_053.md | 1 - docs/topics/user_stories/story_2022_054.md | 1 - docs/topics/user_stories/story_2022_055.md | 3 +- docs/topics/user_stories/story_2022_056.md | 3 +- docs/topics/user_stories/story_2022_057.md | 3 +- docs/topics/user_stories/story_2022_058.md | 1 - docs/topics/user_stories/story_2022_059.md | 1 - docs/topics/user_stories/story_2022_060.md | 1 - docs/topics/user_stories/story_2022_061.md | 1 - docs/topics/user_stories/story_2022_062.md | 3 +- docs/topics/user_stories/story_2022_063.md | 1 - docs/topics/user_stories/story_2022_064.md | 1 - docs/topics/user_stories/story_2022_065.md | 1 - docs/topics/user_stories/story_2022_066.md | 1 - docs/topics/user_stories/story_2022_067.md | 1 - docs/topics/user_stories/story_2022_068.md | 1 - docs/topics/user_stories/story_2022_069.md | 1 - docs/topics/user_stories/story_2022_070.md | 1 - docs/topics/user_stories/story_2022_071.md | 1 - docs/topics/user_stories/story_2022_072.md | 1 - docs/topics/user_stories/story_2022_073.md | 1 - docs/topics/user_stories/story_2022_074.md | 1 - docs/topics/user_stories/story_2022_075.md | 1 - docs/topics/user_stories/story_2022_076.md | 1 - docs/topics/user_stories/story_2022_077.md | 1 - docs/topics/user_stories/story_2022_078.md | 1 - docs/topics/user_stories/story_2022_079.md | 1 - docs/topics/user_stories/story_2022_080.md | 1 - docs/topics/user_stories/story_2022_081.md | 1 - docs/topics/user_stories/story_2022_082.md | 1 - docs/topics/user_stories/story_2022_083.md | 1 - docs/topics/user_stories/story_2022_084.md | 3 +- docs/topics/user_stories/story_2022_085.md | 3 +- docs/topics/user_stories/story_2022_086.md | 1 - docs/topics/user_stories/story_2022_087.md | 1 - docs/topics/user_stories/story_2022_088.md | 1 - docs/topics/user_stories/story_2022_089.md | 1 - docs/topics/user_stories/story_2022_090.md | 1 - docs/topics/user_stories/story_2022_091.md | 1 - docs/topics/user_stories/story_2022_092.md | 1 - docs/topics/user_stories/story_2022_093.md | 1 - docs/topics/user_stories/story_2022_094.md | 1 - docs/topics/user_stories/story_2022_095.md | 1 - docs/topics/user_stories/story_2022_096.md | 1 - docs/topics/user_stories/story_2022_097.md | 1 - docs/topics/user_stories/story_2022_098.md | 1 - docs/topics/user_stories/story_2022_099.md | 1 - docs/topics/user_stories/story_2022_100.md | 5 +- docs/topics/user_stories/story_2022_101.md | 3 +- docs/topics/user_stories/story_2022_102.md | 3 +- docs/topics/user_stories/story_2022_103.md | 1 - docs/topics/user_stories/story_2022_104.md | 1 - docs/topics/user_stories/story_2022_105.md | 1 - docs/topics/user_stories/story_2022_106.md | 1 - docs/topics/user_stories/story_2022_107.md | 3 +- docs/topics/user_stories/story_2022_108.md | 3 +- docs/topics/user_stories/story_2022_109.md | 3 +- docs/topics/user_stories/story_2022_110.md | 3 +- docs/topics/user_stories/story_2022_111.md | 1 - docs/topics/user_stories/table.md | 5 +- docs/tutorials/index.md | 1 - 232 files changed, 706 insertions(+), 1033 deletions(-) diff --git a/Acknowledgements.md b/Acknowledgements.md index c03b34ec..5ff8146d 100644 --- a/Acknowledgements.md +++ b/Acknowledgements.md @@ -15,6 +15,4 @@ This work is funded in part by of the Software Engineering Institute, a federally funded research and development center sponsored by the United States Department of Defense. - DM23-0698 - diff --git a/COPYRIGHT.md b/COPYRIGHT.md index 3c184d49..aab14d09 100644 --- a/COPYRIGHT.md +++ b/COPYRIGHT.md @@ -1,4 +1,4 @@ -# Copyright © 2023 Carnegie Mellon University. +# Copyright © 2023 Carnegie Mellon University This material is based upon work funded and supported by the Department of Homeland Security under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center sponsored by the United States Department of Defense. @@ -8,7 +8,7 @@ The view, opinions, and/or findings contained in this material are those of the [DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. -This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu. +This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at . Carnegie Mellon®, CERT® and CERT Coordination Center® are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. diff --git a/ContributionInstructions.md b/ContributionInstructions.md index 82b36b04..13ad39c9 100644 --- a/ContributionInstructions.md +++ b/ContributionInstructions.md @@ -4,7 +4,7 @@ By making any Contribution to this project, you agree to the terms outlined belo **IF YOU DO NOT AGREE TO THESE TERMS, DO NOT SUBMIT ANY CONTRIBUTION TO THIS PROJECT.** -# TERMS OF SUBMISSION (“Agreement”): +# TERMS OF SUBMISSION (“Agreement”) ## 1. Definitions @@ -12,7 +12,7 @@ By making any Contribution to this project, you agree to the terms outlined belo - "**Contribution**" means any work of authorship, including but not limited to source code, object code, patch, tool, sample, graph, specification, manual documentation, that is Submitted by You to Us in which You own or assert ownership of the Copyright. -- "**Copyright**" means all rights protecting works of authorship owned or controlled by You, including copyright, moral +- "**Copyright**" means all rights protecting works of authorship owned or controlled by You, including copyright, moral and neighboring rights, as appropriate, for the full term of their existence including any extensions by You. - "**Material**" means the work of authorship which is made available by Us to third parties. When this Agreement covers more than one software project, the Material means the work of authorship to which the Contribution was Submitted. @@ -39,22 +39,22 @@ provided that this license is conditioned upon compliance with Section 2.2. ### 2.2 Outbound License -Based on the grant of rights in Section 2.1, if We include Your Contribution in a Material, +Based on the grant of rights in Section 2.1, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. -As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license +As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. -### 2.3 Moral Rights. +### 2.3 Moral Rights -If moral rights apply to the Contribution, to the maximum extent permitted by law, You waive and agree not to assert +If moral rights apply to the Contribution, to the maximum extent permitted by law, You waive and agree not to assert such moral rights against Us or our successors in interest, or any of our licensees, either direct or indirect. - -### 2.4 Our Rights. + +### 2.4 Our Rights You acknowledge that We are not obligated to use Your Contribution as part of the Material and may decide to include any Contribution We consider appropriate. - -### 2.5 Reservation of Rights. + +### 2.5 Reservation of Rights Any rights not expressly assigned or licensed under this section are expressly reserved by You. @@ -72,7 +72,7 @@ Contribution. **(c)** The grant of rights under Section 2 does not violate any grant of rights which You have made to third parties, including Your employer. If You are an employee, You warrant that Your employer has approved this Agreement. If You are less than eighteen years old, Your parent or guardian must sign a printed version of this Agreement and send it -to permission@sei.cmu.edu. +to . **(d)** You shall make each Contribution in full compliance with U.S. export control laws. @@ -87,7 +87,7 @@ of this Agreement. ## 4. Miscellaneous **4.1** This Agreement will be governed by and construed in accordance with the laws of Pennsylvania excluding its -conflicts of law provisions. +conflicts of law provisions. **4.2** This Agreement sets out the entire agreement between You and Us for Your Contributions to Us and overrides all other agreements or understandings. diff --git a/Contributors.md b/Contributors.md index 3f0c7fbc..6fdeecd8 100644 --- a/Contributors.md +++ b/Contributors.md @@ -1,6 +1,6 @@ # Contributors Contributors: -https://github.com/CERTCC/Vultron/graphs/contributors + Carnegie Mellon University diff --git a/LICENSE.md b/LICENSE.md index eba9dfa3..3d24032f 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -17,13 +17,13 @@ persons to whom the Software is furnished to do so, subject to the following con The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. -## ACKNOWLEDGEMENTS AND DISCLAIMERS: +## ACKNOWLEDGEMENTS AND DISCLAIMERS This program may include and/or can make use of certain third party source code, object code, documentation and other files ("Third Party Software"). The Third Party Software that is used by this program is dependent upon your system configuration. By using this program, You agree to comply with any and all relevant Third Party Software terms and conditions contained in any such Third Party Software or separate license file distributed with such Third Party -Software. The parties who own the Third Party Software ("Third Party Licensors") are intended third party beneficiaries +Software. The parties who own the Third Party Software ("Third Party Licensors") are intended third party beneficiaries to this License with respect to the terms applicable to their Third Party Software. Third Party Software licenses only apply to the Third Party Software and not any other portion of this program or this program as a whole. diff --git a/README.md b/README.md index 975f2938..a9ad54ae 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ Vultron is a research project to explore the creation of a federated, decentrali coordinated vulnerability disclosure (CVD). It has grown out of the CERT/CC's decades of experience in coordinating global response to software vulnerabilities. The goal is to create a protocol that can be used by any organization to coordinate the disclosure of vulnerabilities in information processing systems (software, hardware, services, etc.), -and to build a community of interoperability across independent organizations processes and policies that can work +and to build a community of interoperability across independent organizations processes and policies that can work together to coordinate appropriate responses to vulnerabilities. Vultron is a collection of ideas, models, code, and work in progress, and is not yet ready for production use. @@ -13,66 +13,68 @@ Vultron is a collection of ideas, models, code, and work in progress, and is not Vultron is a continuation of the [CERT/CC](https://www.sei.cmu.edu/about/divisions/cert/index.cfm)'s work on improving the coordination of vulnerability disclosure and response. Our previous work in this area includes: + - The CERT Guide to Coordinated Vulnerability Disclosure -([Version 1.0](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330), +([Version 1.0](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330), [Version 2.0](https://vuls.cert.org/confluence/display/CVD) ) -- Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC) +- Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC) ([Version 1.0](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=636379), [Version 2.0](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=653459), [github](https://github.com/CERTCC/SSVC) ) -- The Vulnerability Information and Coordination Environment (VINCE) +- The Vulnerability Information and Coordination Environment (VINCE) ([blog post](https://insights.sei.cmu.edu/news/certcc-releases-vince-software-vulnerability-collaboration-platform/), [github](https://github.com/CERTCC/VINCE) ) - + - A variety of related research, including - [Cybersecurity Information Sharing: Analysing an Email Corpus of Coordinated Vulnerability Disclosure](https://www.research.ed.ac.uk/en/publications/cybersecurity-information-sharing-analysing-an-email-corpus-of-co) - [Historical Analysis of Exploit Availability Timelines](https://www.usenix.org/conference/cset20/presentation/householder) -More recently, the CERT/CC has been working towards formalizing this knowledge into a protocol for CVD. +More recently, the CERT/CC has been working towards formalizing this knowledge into a protocol for CVD. This work began with [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513), -which also appeared in an abridged form as [Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures](https://dl.acm.org/doi/10.1145/3477431) +which also appeared in an abridged form as [Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures](https://dl.acm.org/doi/10.1145/3477431) in the ACM Journal _Digital Threats: Research and Practice_. In 2022, we published a collection of [Coordinated Vulnerability Disclosure User Stories](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=886543) derived from both our process modeling work and from the experience of building VINCE. That same year, we published [Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198), which serves as the basis for the work contained in this repository. -# So what *is* Vultron? +# So what _is_ Vultron? Vultron is: + - A set of high-level processes representing the steps involved in coordinated vulnerability disclosure -- A formal protocol describing the interactions of those processes +- A formal protocol describing the interactions of those processes - A set of behavior logic that can be implemented as either procedures for humans to follow or (in many cases) code that can perform actions in response to state changes in a case with minimal human input - A minimal data model for what information is necessary to track participant status and the overall case status through the course of handling a CVD case -The above were all initially described in the +The above were all initially described in the [Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198) report. In this repository, we are taking the first steps towards implementing the protocol and behavior logic described in that -report. -Currently, the work is focused on mapping the formal protocol onto the syntax and semantics of the [ActivityPub](https://www.w3.org/TR/activitypub/) -protocol. +report. +Currently, the work is focused on mapping the formal protocol onto the syntax and semantics of the [ActivityPub](https://www.w3.org/TR/activitypub/) +protocol. Examples of our first steps in that direction can be found in [doc/examples](doc/examples) - -# What is Vultron *not*? +# What is Vultron _not_? Vultron is **not** a drop-in replacement for any particular + - _tracking system_—e.g., [Bugzilla](https://www.bugzilla.org/), [Jira](https://www.atlassian.com/software/jira) -- _CVD or threat coordination tool_—e.g., [VINCE](https://github.com/CERTCC/VINCE), [MISP](https://www.misp-project.org/) +- _CVD or threat coordination tool_—e.g., [VINCE](https://github.com/CERTCC/VINCE), [MISP](https://www.misp-project.org/) - _Vulnerability disclosure program_—e.g., [DC3 VDP](https://www.dc3.mil/Missions/Vulnerability-Disclosure/Vulnerability-Disclosure-Program-VDP/) - _Vulnerability disclosure platform or service_—e.g., [HackerOne](https://hackerone.com/), [Bugcrowd](https://www.bugcrowd.com/), [Synack](https://www.synack.com/) Instead, it is our hope that Vultron could serve as a _lingua franca_ for the exchange of vulnerability case coordination information -between those systems and services. +between those systems and services. -Vultron is not a vulnerability priortization tool, although it is intended to be compatible with common +Vultron is not a vulnerability priortization tool, although it is intended to be compatible with common prioritization schemes like [SSVC](https://github.com/CERTCC/SSVC) and [CVSS](https://www.first.org/cvss/). Vultron is not intended to be a product, rather it's meant to be a feature set that can be implemented in a variety of @@ -87,18 +89,18 @@ For more about our work in modeling, formalizing, and describing the CVD process - [SEI Podcast on Vultron](https://youtu.be/8WiSmhxJ2OM) (2023-02-24) - [CERT Guide to Coordinated Vulnerabilty Disclosure](https://vuls.cert.org/confluence/display/CVD) (2017, 2019) - [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) (2021) - - (abridged as) [Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures](https://dl.acm.org/doi/10.1145/3477431) (2022) + - (abridged as) [Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures](https://dl.acm.org/doi/10.1145/3477431) (2022) - [Coordinated Vulnerability Disclosure User Stories](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=886543) (2022) - [Multi-Method Modeling and Analysis of the Cybersecurity Vulnerability Management Ecosystem](https://resources.sei.cmu.edu/asset_files/WhitePaper/2019_019_001_550437.pdf) (2019) is a snapshot of some related System Dynamics and Agent-based modeling we did of CVD and related processes. - [Coordinated Vulnerability Disclosure is a Concurrent Process](https://youtu.be/vhA0duqGzmQ) (2015) -is an older talk which looks at a number of prior models of the CVD process, and shows some of our early +is an older talk which looks at a number of prior models of the CVD process, and shows some of our early attempts to formally describe the concurrency aspects of the CVD process. # License and Copyright We are still working out the correct licensing model for this effort, but for now, this repository is covered by the -included [copyright statement](COPYRIGHT.md). +included [copyright statement](COPYRIGHT.md). If you have feedback on this topic (including whether the copyright/license is causing difficulty for you to collaborate -with us on this project), please let us know in an [issue](https://github.com/CERTCC/Vultron/issues/new). \ No newline at end of file +with us on this project), please let us know in an [issue](https://github.com/CERTCC/Vultron/issues/new). diff --git a/doc/README.md b/doc/README.md index de92dd3e..57003a7e 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,6 +1,6 @@ # Vultron Docs What's here: + - [User Stories](/docs/topics/user_stories/) - [Activity Vocabulary Examples](/doc/examples/) - diff --git a/docs/about/acknowledgements.md b/docs/about/acknowledgements.md index ab85c8d8..64af29e4 100644 --- a/docs/about/acknowledgements.md +++ b/docs/about/acknowledgements.md @@ -1 +1 @@ -{% include-markdown "../../Acknowledgements.md" %} \ No newline at end of file +{% include-markdown "../../Acknowledgements.md" %} diff --git a/docs/about/contributing.md b/docs/about/contributing.md index 488921c7..d3ca8e33 100644 --- a/docs/about/contributing.md +++ b/docs/about/contributing.md @@ -2,4 +2,4 @@ ## Contribution Instructions -{% include-markdown "../../ContributionInstructions.md" heading-offset=2 %} \ No newline at end of file +{% include-markdown "../../ContributionInstructions.md" heading-offset=2 %} diff --git a/docs/about/faq.md b/docs/about/faq.md index 8c544c37..ad7a224c 100644 --- a/docs/about/faq.md +++ b/docs/about/faq.md @@ -2,12 +2,11 @@ ## What do we need to move the Vultron Protocol to widespread use? -First, we need to finish the protocol and get it to a sufficiently stable state that we can start to use it even in +First, we need to finish the protocol and get it to a sufficiently stable state that we can start to use it even in test environments. We're not there yet. In the meantime, there are a number of other things that can help. We're looking for help with: - ## How do we apply encryption to ActivityPub messages to enable end-to-end encryption? We're of the opinion that encrypted messaging is a feature that should be available to all users of @@ -26,7 +25,7 @@ Some relevant links include: post [Towards End-to-End Encryption for Direct Messages in the Fediverse](https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/) - [Issue #225](https://github.com/w3c/activitypub/issues/225) on the W3C ActivityPub Github repo talks about the need for encrypted content, but it seems to have been closed without a solution in 2017. - - However, a much more + - However, a much more recent [April 2023 comment](https://github.com/w3c/activitypub/issues/225#issuecomment-1493887382) mentions: > If we restrict to direct message (with a single recipient) one may just encrypt the message (Note) payload using @@ -45,4 +44,3 @@ We'd be interested to know how we could help with efforts to bring encrypted mes ## What are the requirements for contributing? See [CONTRIBUTING](contributing.md) - diff --git a/docs/about/license.md b/docs/about/license.md index 80ff42fe..d88e5154 100644 --- a/docs/about/license.md +++ b/docs/about/license.md @@ -1 +1 @@ -{% include-markdown "../../LICENSE.md" %} \ No newline at end of file +{% include-markdown "../../LICENSE.md" %} diff --git a/docs/howto/case_object.md b/docs/howto/case_object.md index c7df1f2d..651595ae 100644 --- a/docs/howto/case_object.md +++ b/docs/howto/case_object.md @@ -7,8 +7,8 @@ and [formalisms](../reference/formal_protocol/index.md) that define the Vultron The object model we describe is intended to provide the necessary core information for an implementation of the [formal protocol](../reference/formal_protocol/index.md). The diagram below depicts a UML Class Diagram of the `Case` model. -It is not the minimal possible model required by the Vultron Protocol; for example, strictly speaking, a -Participant does not need to attempt to track the state of every other Participant, but it might help to do so. +It is not the minimal possible model required by the Vultron Protocol; for example, strictly speaking, a +Participant does not need to attempt to track the state of every other Participant, but it might help to do so. Rather, this model is intended to be compact yet sufficient for an implementation to effectively track the coordination effort of an MPCVD case. @@ -139,7 +139,7 @@ See [below](#the-message-class) for more details. ## The `Report` Class The `Report` class represents the vulnerability report that serves as the impetus for the case. -Since it is possible for multiple reports to arrive that describe the same vulnerability, the cardinality of the +Since it is possible for multiple reports to arrive that describe the same vulnerability, the cardinality of the composition relationship allows for a `Case` to have many `Reports`. In most `Cases`, however, there will be only a single associated `Report`. @@ -147,7 +147,7 @@ In most `Cases`, however, there will be only a single associated `Report`. The `Message` class represents a protocol message as outlined in [Message Types](../reference/formal_protocol/messages.md). We expect that any implementation of this model will expand this data type to include numerous message-related attributes. -Here, we highlight the minimum requirements that the protocol demands: +Here, we highlight the minimum requirements that the protocol demands: - Each `Message` has an identified sender (who is a `Participant` in the case) and one or more message types as enumerated in [Message Types](../reference/formal_protocol/messages.md). @@ -156,8 +156,8 @@ types as enumerated in [Message Types](../reference/formal_protocol/messages.md) Conceptually, one might think of the `Case` as a shared object among engaged `Participants` and that `Messages` are sent to the `Case` for all `Participants` to see. -In other words, the `Case` acts as a broadcast domain, a topic queue, or a blackboard pattern (depending on your -preferences for networking or software engineering terminology). +In other words, the `Case` acts as a broadcast domain, a topic queue, or a blackboard pattern (depending on your +preferences for networking or software engineering terminology). Because of this shared-channel assumption, we could have omitted the `recipient` attribute from the `Message` class, as the `Case` itself can serve as the recipient of each message emitted by any `Participant`. Implementations of this model could, of course, choose a more traditional messaging model with specified recipients, so @@ -185,7 +185,6 @@ The attributes of the `Participant` class are as follows: : A set of flags indicating the Role(s) this `Participant` plays in the `Case` - For example, an organization might be the Vendor in one case and the Coordinator in another. `rm_state` @@ -203,12 +202,11 @@ For example, an organization might be the Vendor in one case and the Coordinator : A Boolean attribute that indicates whether the `Participant` should be included in future communications about the `Case` - -For example, a Reporter who bows out of a case shortly after reporting it to a Coordinator might be listed as a +For example, a Reporter who bows out of a case shortly after reporting it to a Coordinator might be listed as a `Participant` with `case_engagement=False` and could, therefore, be left out of further communication about the case. !!! tip inline end - + As discussed in [Embargo Principles](../topics/process_models/em/principles.md#sec:embargo_engagement), it is possible for a `Participant` to exit a case while still agreeing to abide by the terms of the extant embargo. @@ -217,27 +215,26 @@ For example, a Reporter who bows out of a case shortly after reporting it to a C : A Boolean attribute that indicates the expectation that a `Participant` is adhering to any existing embargo - -Continuing our example of a Reporter leaving a case early, they might still be cooperative and indicate their -`embargo_adherence=True`. +Continuing our example of a Reporter leaving a case early, they might still be cooperative and indicate their +`embargo_adherence=True`. A more hostile `Participant` exit could warrant setting `embargo_adherence=False`, likely triggering an embargo teardown procedure as a consequence. -`Participants` can also emit (send) and receive messages. +`Participants` can also emit (send) and receive messages. -!!! tip +!!! tip The `+` on `receive_message` indicates that this capability is accessible to others (i.e., you can send a `Participant` a message). On the contrary the `-` on `emit_message` conveys that this capability is only accessible to the `Participant` class itself (i.e., each `Participant` gets to decide if, when, and what messages to send). -#### `Vendor` and `Deployer` `Participant` Classes. +#### `Vendor` and `Deployer` `Participant` Classes The presence of the `VendorParticipant` and `DeployerParticipant` classes---depicted as implementations of the `Participant` class---is necessitated by the discussion in [States](../reference/formal_protocol/states.md), where we describe how Vendors and Deployers have unique parts to play in the creation, delivery, and -deployment of fixes within the CVD process. +deployment of fixes within the CVD process. These two classes add the `vfd_state` attribute with different possible values. Vendors can take on one of four possible values (`vfd`, `Vfd`, `VFd`, and `VFD`), whereas Deployers only have two possible values (`..d` and `..D`). @@ -246,7 +243,7 @@ Other than that, Vendors and Deployers have the same attributes as other `Partic ## The `Contact` Class Since a `Participant` is a specific relationship between an individual or organization and the `Case` itself, -we can safely assume that those individuals or organizations exist and persist independently of the `Cases` they +we can safely assume that those individuals or organizations exist and persist independently of the `Cases` they participate in. Hence, each `Participant` class in a `Case` is associated with a long-lived `Contact` record that represents an individual or organization. @@ -273,8 +270,7 @@ The remainder of the class diagram above consists of classes representing the Ro - The `Role` flags are consistent with the roles we defined in [Terms and Definitions](../topics/background/terms.md), as taken from the [CVD Guide](https://vuls.cert.org/confluence/display/CVD). - `Message Type` flags are consistent with [Message Types](../reference/formal_protocol/messages.md). -- The other enumeration classes are consistent with the [Report Management](../topics/process_models/rm/index.md), [Embargo Management](../topics/process_models/em/index.md), -and [Case State](../topics/process_models/cs/index.md) process models and their respective state machines. +- The other enumeration classes are consistent with the [Report Management](../topics/process_models/rm/index.md), [Embargo Management](../topics/process_models/em/index.md), +and [Case State](../topics/process_models/cs/index.md) process models and their respective state machines. Note that we split the [CS model](../topics/process_models/cs/cs_model.md) states into two separate enumerations to reflect the participant-agnostic and participant-specific portions of the model described in [Model Interactions](../topics/process_models/model_interactions/index.md). - diff --git a/docs/howto/em_icalendar.md b/docs/howto/em_icalendar.md index 6097f97a..796b817d 100644 --- a/docs/howto/em_icalendar.md +++ b/docs/howto/em_icalendar.md @@ -8,7 +8,7 @@ We are including this page because the ideas outlined here were instrumental to The embargo negotiation process—in terms of the proposal, acceptance, rejection, etc.—is strikingly parallel to the process of scheduling a meeting in a calendaring system. To that end, we note the potential application of the [`iCalendar`](https://en.wikipedia.org/wiki/ICalendar) protocol specified in [RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545) to the -[EM process](../topics/process_models/em/index.md) with the semantics described in this section. +[EM process](../topics/process_models/em/index.md) with the semantics described in this section. While we anticipate that future CVD APIs could adopt an `iCalendar`-compatible syntax like `jCal` ([RFC 7265](https://datatracker.ietf.org/doc/html/rfc7265)), for this conceptual mapping, we use the basic `iCalendar` syntax from [RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545). @@ -34,8 +34,6 @@ A mapping of EM concepts to `iCalendar` field mappings is provided in the table | Embargo Status $q^{em} \in N$ due to lack of acceptance quorum | `STATUS:CANCELLED` | _ER_ | | Other | `CATEGORIES:EMBARGO`
`RSVP: TRUE` | - | - - !!! note "" Reflecting the non-binding nature of embargoes, each `ATTENDEE` SHOULD be marked as `ROLE=OPT-PARTICIPANT` in the invitation. @@ -45,7 +43,7 @@ A mapping of EM concepts to `iCalendar` field mappings is provided in the table Vulnerability details MUST NOT appear in the iCalendar data. !!! note "" - + A case or vulnerability identifier SHOULD appear in the `VEVENT` `SUMMARY` along with the words "embargo expiration." @@ -69,22 +67,22 @@ The `iCalendar` `ATTENDEE:partstat=DELEGATED` value has no semantic equivalent i Following the model of inviting a group of attendees to a meeting, a proposed embargo can be achieved as follows: -1. An `ORGANIZER` sends an embargo invitation, represented by a +1. An `ORGANIZER` sends an embargo invitation, represented by a `VEVENT` with `STATUS:TENTATIVE` listing Participants as `ATTENDEE`s ($q^{em} \in N \xrightarrow{p} P$). -2. Each `ATTENDEE` has `partstat=NEEDS-ACTION` set on the invitation, +2. Each `ATTENDEE` has `partstat=NEEDS-ACTION` set on the invitation, indicating that they have not yet accepted it. -3. Individual `ATTENDEE`s acknowledge (`partstat=TENTATIVE`), accept +3. Individual `ATTENDEE`s acknowledge (`partstat=TENTATIVE`), accept (`partstat=ACCEPTED`), or decline (`partstat=DECLINED`). Their response is sent to the `ORGANIZER`. -4. If the `ORGANIZER` determines that there is a quorum of accepts, +4. If the `ORGANIZER` determines that there is a quorum of accepts, they mark the `VEVENT` as `STATUS:CONFIRMED` ($q^{em} \in P \xrightarrow{a} A$). -5. If the `ORGANIZER` determines that there is no sufficient quorum of +5. If the `ORGANIZER` determines that there is no sufficient quorum of accepts, they mark the new `VEVENT` as `STATUS:CANCELLED` ($q^{em} \in P \xrightarrow{r} N$). @@ -92,10 +90,10 @@ proposed embargo can be achieved as follows: Counterproposals can be achieved in two ways: -1. by declining an initial invitation and then proposing a new one +1. by declining an initial invitation and then proposing a new one ($q^{em} \in P \xrightarrow{r} N \xrightarrow{p} P$) -2. by proposing a new embargo without declining the first one +2. by proposing a new embargo without declining the first one ($q^{em} \in P \xrightarrow{p} P$) Either way, this is analogous to requesting a proposed meeting to be @@ -112,42 +110,42 @@ revision to the new embargo instead, which we cover next. This process assumes that an existing embargo is represented by a `VEVENT` with`STATUS:CONFIRMED`. Similar to rescheduling an existing meeting, a proposed change to an -existing embargo can be achieved as follows. +existing embargo can be achieved as follows. -1. A new proposal is made as a `VEVENT` with `STATUS:TENTATIVE` and the +1. A new proposal is made as a `VEVENT` with `STATUS:TENTATIVE` and the same `ATTENDEE` list as the existing one ($q^{em} \in A \xrightarrow{p} R$). -2. Each `ATTENDEE` on the new invitation has `partstat=NEEDS-ACTION` +2. Each `ATTENDEE` on the new invitation has `partstat=NEEDS-ACTION` set, indicating that they have not yet accepted the new invitation. -3. Individual `ATTENDEE`s acknowledge (`partstat=TENTATIVE`), accept +3. Individual `ATTENDEE`s acknowledge (`partstat=TENTATIVE`), accept (`partstat=ACCEPTED`), or decline (`partstat=DECLINED`). Their response is sent to the `ORGANIZER`. -4. If the `ORGANIZER` determines that there is a quorum of accepts +4. If the `ORGANIZER` determines that there is a quorum of accepts ($q^{em} \in R \xrightarrow{a} A$), they - 1. mark the new `VEVENT` as `STATUS:CONFIRMED` + 1. mark the new `VEVENT` as `STATUS:CONFIRMED` - 2. mark the old `VEVENT` as `STATUS:CANCELLED` + 2. mark the old `VEVENT` as `STATUS:CANCELLED` -5. If the `ORGANIZER` determines that there is no sufficient quorum of +5. If the `ORGANIZER` determines that there is no sufficient quorum of accepts ($q^{em} \in R \xrightarrow{r} A$), they - 1. mark the new `VEVENT` as `STATUS:CANCELLED` + 1. mark the new `VEVENT` as `STATUS:CANCELLED` - 2. retain the old `VEVENT` as `STATUS:CONFIRMED` + 2. retain the old `VEVENT` as `STATUS:CONFIRMED` ## Terminating an Existing Embargo Terminating an existing embargo ($q^{em} \in \{A,R\} \xrightarrow{t} X$) can be triggered in one of two ways: -- A *normal* exit occurs when the planned embargo end time has +- A _normal_ exit occurs when the planned embargo end time has expired. -- An *abnormal* exit occurs when some external event causes the +- An _abnormal_ exit occurs when some external event causes the embargo to fail, such as when the vulnerability or its exploit has been made public, attacks have been observed, etc., as outlined in [Early Termination](../topics/process_models/em/early_termination.md). @@ -156,11 +154,11 @@ Translating this into `iCalendar` semantics, we have the following, which assumes an existing embargo is represented by a `VEVENT` with `STATUS:CONFIRMED`. -1. *Normal termination*: The `VEVENT` retains its `STATUS:CONFIRMED` +1. _Normal termination_: The `VEVENT` retains its `STATUS:CONFIRMED` and passes quietly from the future through the present into the past. -2. *Abnormal termination*: The `ORGANIZER` sets the `VEVENT` to +2. _Abnormal termination_: The `ORGANIZER` sets the `VEVENT` to `STATUS:CANCELLED` and sends it out to the `ATTENDEE` list. The above is consistent with our premise in diff --git a/docs/howto/general_implementation.md b/docs/howto/general_implementation.md index ec68c23d..712c0522 100644 --- a/docs/howto/general_implementation.md +++ b/docs/howto/general_implementation.md @@ -12,13 +12,13 @@ Message formats can be thought of as two related problems: ### Structure and Semantic Content of Each Message Type -In addition to the commentary throughout this section, messages will likely need to have some sort of consistent header +In addition to the commentary throughout this section, messages will likely need to have some sort of consistent header information and some content specifically designed to address the semantic needs of each message type. Such a format must include fields, datatypes, and an underlying formatting structure. ### Container Syntax for Messaging and Data Exchange -While we have a predilection for JSON Schema-defined formats, other format specifications (e.g., XSD or protobuf) could +While we have a predilection for JSON Schema-defined formats, other format specifications (e.g., XSD or protobuf) could serve implementers' needs just as well. In fact, to the degree possible, it seems preferable for the container syntax to remain a late-binding decision in implementation. As long as the structure and semantics are well defined, most standard data formats should be adaptable to the task. @@ -35,7 +35,6 @@ As long as the structure and semantics are well defined, most standard data form We anticipate that emerging formats like the [OASIS CSAF](https://oasis-open.github.io/csaf-documentation/) and ontologies like the [NIST Vulnerability Data Ontology](https://github.com/usnistgov/vulntology) ([Vulntology](https://github.com/usnistgov/vulntology)) will play a part. - ## Transport Protocol We have not specified how Vultron Protocol implementations connect to each other. @@ -45,13 +44,12 @@ For example, an XMPP message-routing system might be desired, or even blockchain to portions of this protocol as well. !!! note "" - - Vultron Protocol Implementations SHOULD use common API patterns (e.g., REST, WebSockets). + Vultron Protocol Implementations SHOULD use common API patterns (e.g., REST, WebSockets). ## Identity Management -We have not addressed Participant authentication as part of the protocol, but obviously implementers will need to +We have not addressed Participant authentication as part of the protocol, but obviously implementers will need to determine how Participants know who they are talking to. Individual user accounts with multi-factor authentication are the de facto standard for modern CVD tools, but in an interoperable MPCVD world, the assumption of centralized identity management may not be practical. @@ -68,7 +66,7 @@ necessary for Vultron Protocol implementations. ### Protecting Data in Transit It may be sufficient for implementations to rely on transport-layer encryption (e.g., TLS), but end-to-end encryption -may be desirable in some cases. +may be desirable in some cases. For now at least, we leave this decision to implementers. !!! note "" diff --git a/docs/howto/index.md b/docs/howto/index.md index 29ac0ae3..4fef7a25 100644 --- a/docs/howto/index.md +++ b/docs/howto/index.md @@ -14,14 +14,14 @@ Here we collect some guidance for potential implementations of Vultron. -While a complete protocol implementation specification remains a work in progress, we do have a few additional +While a complete protocol implementation specification remains a work in progress, we do have a few additional suggestions for potential implementers. In this section, you will find: - an abstract [case object](case_object.md) for use in tracking MPCVD cases - Notes on the [core Vultron Protocol subprocesses](process_implementation.md) (RM, EM, and CS), including how the CS model might integrate with other processes -- A few thoughts on the [Embargo Management Process](em_icalendar.md) and how it might be implemented using the `iCalendar` protocol. +- A few thoughts on the [Embargo Management Process](em_icalendar.md) and how it might be implemented using the `iCalendar` protocol. - [General notes](general_implementation.md) on future implementations. Over time, we plan to expand this section of the documentation to include: @@ -38,5 +38,3 @@ Over time, we plan to expand this section of the documentation to include: organizations' workflow management systems. As such, they are focused on the exchange of information and data necessary for the MPCVD process to function and will not likely be sufficient to fully address any individual organization's vulnerability response process. - - diff --git a/docs/howto/process_implementation.md b/docs/howto/process_implementation.md index 7549ac54..7d8f8c26 100644 --- a/docs/howto/process_implementation.md +++ b/docs/howto/process_implementation.md @@ -3,7 +3,7 @@ {% include-markdown "../includes/not_normative.md" %} Integrating the Vultron Protocol into everyday MPCVD operations requires each Participant to consider how their business processes -interact with the individual [RM](../topics/process_models/rm/index.md), [EM](../topics/process_models/em/index.md), +interact with the individual [RM](../topics/process_models/rm/index.md), [EM](../topics/process_models/em/index.md), and [CS](../topics/process_models/cs/index.md), process models, respectively. Here we offer some thoughts on where such integration might begin. @@ -14,13 +14,13 @@ incident or service request workflow. As such, the RM process could be implemented as a JIRA ticket workflow, as part of a Kanban process, etc. The main modifications needed to adapt an existing workflow are to intercept the key milestones and emit the appropriate RM messages: -- when the reports are received (_RK_) +- when the reports are received (_RK_) -- when the report validation process completes (_RI_, _RV_) +- when the report validation process completes (_RI_, _RV_) -- when the report prioritization process completes (_RA_, _RD_) +- when the report prioritization process completes (_RA_, _RD_) -- when the report is closed (_RC_) +- when the report is closed (_RC_) ### Vulnerability Draft Pre-Publication Review @@ -30,9 +30,9 @@ The main modifications needed to adapt an existing workflow are to intercept the MPCVD case Participants often share pre-publication drafts of their advisories during the embargo period. Our protocol proposal is mute on this subject because it is not strictly necessary for the MPCVD process to complete successfully. -However, as we observe in the [ISO Crosswalk](../reference/iso_crosswalk.md), the _GI_ and _GK_ message types appear to provide sufficient mechanics for this +However, as we observe in the [ISO Crosswalk](../reference/iso_crosswalk.md), the _GI_ and _GK_ message types appear to provide sufficient mechanics for this process to be fleshed out as necessary. -This draft-sharing process could be built into the [*prepare publication*](../topics/behavior_logic/publication_bt.md#prepare-publication-behavior) process, where appropriate. +This draft-sharing process could be built into the [_prepare publication_](../topics/behavior_logic/publication_bt.md#prepare-publication-behavior) process, where appropriate. ## EM Implementation Notes @@ -47,7 +47,7 @@ onto [`iCalendar`](https://en.wikipedia.org/wiki/ICalendar) protocol semantics. In our protocol design, we were careful to focus the EM process on establishing when publication restrictions are lifted. -That is not the same as actually scheduling publications following the embargo termination. +That is not the same as actually scheduling publications following the embargo termination. Our experience at the CERT/CC shows that this distinction is rarely a significant problem since many case Participants simply publish at their own pace shortly after the embargo ends. However, at times, case Participants may find it necessary to coordinate even more closely on publication scheduling. @@ -60,29 +60,29 @@ Because part of the CS model is Participant specific and the other is global to Similar to the RM process, which is specific to each Participant, the _vfd_ process is individualized to each Vendor (or Deployer, for the simpler $d \xrightarrow{\mathbf{D}} D$ state transition). -Modifications to the Vendor's development process to implement the Vultron Protocol are expected to be minimal and are +Modifications to the Vendor's development process to implement the Vultron Protocol are expected to be minimal and are limited to the following: -- acknowledging the Vendor's role on report receipt with a _CV_ message +- acknowledging the Vendor's role on report receipt with a _CV_ message -- emitting a _CF_ message when a fix becomes ready (and possibly terminating any active embargo to open the door to publication) +- emitting a _CF_ message when a fix becomes ready (and possibly terminating any active embargo to open the door to publication) -- (if relevant) issuing a _CD_ message when the fix has been deployed +- (if relevant) issuing a _CD_ message when the fix has been deployed -Non-Vendor Deployers are rarely involved in MPCVD cases, but when they are, their main integration point is to emit a +Non-Vendor Deployers are rarely involved in MPCVD cases, but when they are, their main integration point is to emit a _CD_ message when deployment is complete. ### The _pxa_ Process -On the other hand, the _pxa_ process hinges on monitoring public and private sources for evidence of information leaks, +On the other hand, the _pxa_ process hinges on monitoring public and private sources for evidence of information leaks, research publications, and adversarial activity. In other words, the _pxa_ process is well positioned to be wired into Participants' threat intelligence and threat analysis capabilities. The goal would be to emit _CP_, _CX_, and _CA_ messages as appropriate when such evidence is detected. Some portions of this process can be automated: -- Human analysts and/or automated search agents can look for evidence of early publication of vulnerability information. +- Human analysts and/or automated search agents can look for evidence of early publication of vulnerability information. -- IDS and IPS signatures might be deployed prior to fix availability to act as an early warning of adversary activity. +- IDS and IPS signatures might be deployed prior to fix availability to act as an early warning of adversary activity. -- Well-known code publication and malware analysis platforms can be monitored for evidence of exploit publication or use. +- Well-known code publication and malware analysis platforms can be monitored for evidence of exploit publication or use. diff --git a/docs/includes/curr_ver.md b/docs/includes/curr_ver.md index 08e3a216..4ed2435e 100644 --- a/docs/includes/curr_ver.md +++ b/docs/includes/curr_ver.md @@ -1,3 +1,3 @@ !!! info "Current Version" - The current version of the Vultron Protocol is `{%include-markdown "../../VERSION" %}`. \ No newline at end of file + The current version of the Vultron Protocol is `{%include-markdown "../../VERSION" %}`. diff --git a/docs/index.md b/docs/index.md index 78388e67..55da9b95 100644 --- a/docs/index.md +++ b/docs/index.md @@ -10,7 +10,7 @@ - [Implementing Vultron](howto/index.md), which provides guidance for potential implementations of Vultron - [Reference](reference/formal_protocol/index.md), which provides the formal protocol specification -The Vultron Protocol is a research project to explore the creation of a federated, decentralized, and open source protocol for +The Vultron Protocol is a research project to explore the creation of a federated, decentralized, and open source protocol for coordinated vulnerability disclosure (CVD). It has grown out of the CERT/CC's decades of experience in coordinating global response to software vulnerabilities. Our goal is to create a protocol that can be used by any organization to coordinate the disclosure of vulnerabilities in @@ -23,7 +23,6 @@ The Vultron Protocol is a collection of ideas, models, code, and work in progres ## How this documentation is organized - !!! tip inline "Learning About Vultron" The [Learning Vultron](tutorials/index.md) section is intended to eventually include tutorials and other @@ -54,8 +53,7 @@ We are using the [Diátaxis Framework](https://diataxis.fr/) to organize our doc oriented around the different ways that people might need to learn about and use the Vultron Protocol. Our current focus is on the [Understanding Vultron](topics/background/index.md) section, which describes the protocol -in detail. - +in detail. ## Background @@ -80,8 +78,8 @@ Our recent work in this area includes: - [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) (MPCVD), which also appeared in an abridged form as [Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures](https://doi.org/10.1145/3477431) in the -ACM Journal Digital Threats: Research and Practice +ACM Journal Digital Threats: Research and Practice - A collection of [Coordinated Vulnerability Disclosure User Stories](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=886543) derived from both our process modeling work and from the experience of building VINCE. - These user stories are collected in the [User Stories](topics/user_stories/index.md) section of this documentation. + These user stories are collected in the [User Stories](topics/user_stories/index.md) section of this documentation. - [Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198) (MPCVD), - which serves as the basis for the work contained here. \ No newline at end of file + which serves as the basis for the work contained here. diff --git a/docs/reference/case_states/index.md b/docs/reference/case_states/index.md index 4062146a..5acc8479 100644 --- a/docs/reference/case_states/index.md +++ b/docs/reference/case_states/index.md @@ -1,6 +1,7 @@ # Case States + This directory contains a description of each state in the case model. ## States @@ -39,4 +40,3 @@ This directory contains a description of each state in the case model. | [VFDPxA](state__v__f__d__p_x_a_.md) | Vendor Is Aware Of Vulnerability| Fix Is Ready| Fix Has Been Deployed| Public Is Aware Of Vulnerability| No Exploits Have Been Made Public| Attacks Have Been Observed | | [VFDPXa](state__v__f__d__p__x_a.md) | Vendor Is Aware Of Vulnerability| Fix Is Ready| Fix Has Been Deployed| Public Is Aware Of Vulnerability| Exploits Have Been Made Public| No Attacks Have Been Observed | | [VFDPXA](state__v__f__d__p__x__a_.md) | Vendor Is Aware Of Vulnerability| Fix Is Ready| Fix Has Been Deployed| Public Is Aware Of Vulnerability| Exploits Have Been Made Public| Attacks Have Been Observed | - diff --git a/docs/reference/case_states/state__v__f__d__p__x__a_.md b/docs/reference/case_states/state__v__f__d__p__x__a_.md index fc14673e..8e3234f2 100644 --- a/docs/reference/case_states/state__v__f__d__p__x__a_.md +++ b/docs/reference/case_states/state__v__f__d__p__x__a_.md @@ -1,6 +1,7 @@ # VFDPXA + | Key | Value | | --- | --- | | State | VFDPXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VFdPXA](state__v__f_d_p__x__a_.md)
• [VFDpXA](state__v__f__d_p_x__a_.md)
• [VFDPxA](state__v__f__d__p_x_a_.md)
• [VFDPXa](state__v__f__d__p__x_a.md)
| | Successors
(prefer higher scores) |• None
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| | Possible Sequences From This State |• None
| diff --git a/docs/reference/case_states/state__v__f__d__p__x_a.md b/docs/reference/case_states/state__v__f__d__p__x_a.md index 505ccbe6..2cd6b3ae 100644 --- a/docs/reference/case_states/state__v__f__d__p__x_a.md +++ b/docs/reference/case_states/state__v__f__d__p__x_a.md @@ -1,6 +1,7 @@ # VFDPXa + | Key | Value | | --- | --- | | State | VFDPXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VFdPXa](state__v__f_d_p__x_a.md)
• [VFDpXa](state__v__f__d_p_x_a.md)
• [VFDPxa](state__v__f__d__p_xa.md)
| | Successors
(prefer higher scores) |• [VFDPXA](state__v__f__d__p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
| +| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md)
| | Possible Sequences From This State |• [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f__d__p_x_a_.md b/docs/reference/case_states/state__v__f__d__p_x_a_.md index 9965a220..dfb5d2b1 100644 --- a/docs/reference/case_states/state__v__f__d__p_x_a_.md +++ b/docs/reference/case_states/state__v__f__d__p_x_a_.md @@ -1,6 +1,7 @@ # VFDPxA + | Key | Value | | --- | --- | | State | VFDPxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VFdPxA](state__v__f_d_p_x_a_.md)
• [VFDpxA](state__v__f__d_px_a_.md)
• [VFDPxa](state__v__f__d__p_xa.md)
| | Successors
(prefer higher scores) |• [VFDPXA](state__v__f__d__p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md)
| | Possible Sequences From This State |• [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f__d__p_xa.md b/docs/reference/case_states/state__v__f__d__p_xa.md index f4b1a846..d46bec71 100644 --- a/docs/reference/case_states/state__v__f__d__p_xa.md +++ b/docs/reference/case_states/state__v__f__d__p_xa.md @@ -1,6 +1,7 @@ # VFDPxa + | Key | Value | | --- | --- | | State | VFDPxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VFdPxa](state__v__f_d_p_xa.md)
• [VFDpxa](state__v__f__d_pxa.md)
| | Successors
(prefer higher scores) |• [VFDPxA](state__v__f__d__p_x_a_.md) (score=2.33)
• [VFDPXa](state__v__f__d__p__x_a.md) (score=2.52)
| -| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md)
| +| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md)
| | Possible Sequences From This State |• [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f__d_p_x__a_.md b/docs/reference/case_states/state__v__f__d_p_x__a_.md index f3732ca9..910afb59 100644 --- a/docs/reference/case_states/state__v__f__d_p_x__a_.md +++ b/docs/reference/case_states/state__v__f__d_p_x__a_.md @@ -1,6 +1,7 @@ # VFDpXA + | Key | Value | | --- | --- | | State | VFDpXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Exploit Type 3
• Zero Day Attack Type 3
| | Predecessors |• [VFDpxA](state__v__f__d_px_a_.md)
| | Successors
(prefer higher scores) |• [VFDPXA](state__v__f__d__p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md)
| | Possible Sequences From This State |• [**P**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f__d_p_x_a.md b/docs/reference/case_states/state__v__f__d_p_x_a.md index b865d07f..a7afd1a9 100644 --- a/docs/reference/case_states/state__v__f__d_p_x_a.md +++ b/docs/reference/case_states/state__v__f__d_p_x_a.md @@ -1,6 +1,7 @@ # VFDpXa + | Key | Value | | --- | --- | | State | VFDpXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Exploit Type 3
| | Predecessors |• [VFDpxa](state__v__f__d_pxa.md)
| | Successors
(prefer higher scores) |• [VFDPXa](state__v__f__d__p__x_a.md) (score=2.52)
| -| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md)
| +| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md)
| | Possible Sequences From This State |• [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f__d_px_a_.md b/docs/reference/case_states/state__v__f__d_px_a_.md index ccb6d9a3..30a3f527 100644 --- a/docs/reference/case_states/state__v__f__d_px_a_.md +++ b/docs/reference/case_states/state__v__f__d_px_a_.md @@ -1,6 +1,7 @@ # VFDpxA + | Key | Value | | --- | --- | | State | VFDpxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Attack Type 3
| | Predecessors |• [VFdpxA](state__v__f_dpx_a_.md)
• [VFDpxa](state__v__f__d_pxa.md)
| | Successors
(prefer higher scores) |• [VFDpXA](state__v__f__d_p_x__a_.md) (score=2.52)
• [VFDPxA](state__v__f__d__p_x_a_.md) (score=2.33)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md)
| | Possible Sequences From This State |• [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f__d_pxa.md b/docs/reference/case_states/state__v__f__d_pxa.md index 431d5f0a..3ec4dc82 100644 --- a/docs/reference/case_states/state__v__f__d_pxa.md +++ b/docs/reference/case_states/state__v__f__d_pxa.md @@ -1,6 +1,7 @@ # VFDpxa + | Key | Value | | --- | --- | | State | VFDpxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VFdpxa](state__v__f_dpxa.md)
| | Successors
(prefer higher scores) |• [VFDpxA](state__v__f__d_px_a_.md) (score=4.35)
• [VFDpXa](state__v__f__d_p_x_a.md) (score=4.71)
• [VFDPxa](state__v__f__d__p_xa.md) (score=4.35)
| -| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md)
| +| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md)
| | Possible Sequences From This State |• [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_d_p__x__a_.md b/docs/reference/case_states/state__v__f_d_p__x__a_.md index ec59bf77..cf0fd7a8 100644 --- a/docs/reference/case_states/state__v__f_d_p__x__a_.md +++ b/docs/reference/case_states/state__v__f_d_p__x__a_.md @@ -1,6 +1,7 @@ # VFdPXA + | Key | Value | | --- | --- | | State | VFdPXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VfdPXA](state__v_fd_p__x__a_.md)
• [VFdpXA](state__v__f_dp_x__a_.md)
• [VFdPxA](state__v__f_d_p_x_a_.md)
• [VFdPXa](state__v__f_d_p__x_a.md)
| | Successors
(prefer higher scores) |• [VFDPXA](state__v__f__d__p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md)
| | Possible Sequences From This State |• [**D**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_d_p__x_a.md b/docs/reference/case_states/state__v__f_d_p__x_a.md index a90e4ef6..008c9211 100644 --- a/docs/reference/case_states/state__v__f_d_p__x_a.md +++ b/docs/reference/case_states/state__v__f_d_p__x_a.md @@ -1,6 +1,7 @@ # VFdPXa + | Key | Value | | --- | --- | | State | VFdPXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VfdPXa](state__v_fd_p__x_a.md)
• [VFdpXa](state__v__f_dp_x_a.md)
• [VFdPxa](state__v__f_d_p_xa.md)
| | Successors
(prefer higher scores) |• [VFdPXA](state__v__f_d_p__x__a_.md) (score=0.00)
• [VFDPXa](state__v__f__d__p__x_a.md) (score=2.52)
| -| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md)
| +| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md)
| | Possible Sequences From This State |• [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_d_p_x_a_.md b/docs/reference/case_states/state__v__f_d_p_x_a_.md index 9c1e335e..e137eb5e 100644 --- a/docs/reference/case_states/state__v__f_d_p_x_a_.md +++ b/docs/reference/case_states/state__v__f_d_p_x_a_.md @@ -1,6 +1,7 @@ # VFdPxA + | Key | Value | | --- | --- | | State | VFdPxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VfdPxA](state__v_fd_p_x_a_.md)
• [VFdpxA](state__v__f_dpx_a_.md)
• [VFdPxa](state__v__f_d_p_xa.md)
| | Successors
(prefer higher scores) |• [VFdPXA](state__v__f_d_p__x__a_.md) (score=0.00)
• [VFDPxA](state__v__f__d__p_x_a_.md) (score=2.33)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md)
| | Possible Sequences From This State |• [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_d_p_xa.md b/docs/reference/case_states/state__v__f_d_p_xa.md index 8dcffbcf..dc7d1f21 100644 --- a/docs/reference/case_states/state__v__f_d_p_xa.md +++ b/docs/reference/case_states/state__v__f_d_p_xa.md @@ -1,6 +1,7 @@ # VFdPxa + | Key | Value | | --- | --- | | State | VFdPxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [VfdPxa](state__v_fd_p_xa.md)
• [VFdpxa](state__v__f_dpxa.md)
| | Successors
(prefer higher scores) |• [VFdPxA](state__v__f_d_p_x_a_.md) (score=1.50)
• [VFdPXa](state__v__f_d_p__x_a.md) (score=1.71)
• [VFDPxa](state__v__f__d__p_xa.md) (score=4.35)
| -| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md)
| +| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md)
| | Possible Sequences From This State |• [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_dp_x__a_.md b/docs/reference/case_states/state__v__f_dp_x__a_.md index d0d496d1..07f8bf03 100644 --- a/docs/reference/case_states/state__v__f_dp_x__a_.md +++ b/docs/reference/case_states/state__v__f_dp_x__a_.md @@ -1,6 +1,7 @@ # VFdpXA + | Key | Value | | --- | --- | | State | VFdpXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Exploit Type 3
• Zero Day Attack Type 3
| | Predecessors |• [VFdpxA](state__v__f_dpx_a_.md)
| | Successors
(prefer higher scores) |• [VFdPXA](state__v__f_d_p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md)
| | Possible Sequences From This State |• [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_dp_x_a.md b/docs/reference/case_states/state__v__f_dp_x_a.md index acbcca67..16315310 100644 --- a/docs/reference/case_states/state__v__f_dp_x_a.md +++ b/docs/reference/case_states/state__v__f_dp_x_a.md @@ -1,6 +1,7 @@ # VFdpXa + | Key | Value | | --- | --- | | State | VFdpXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Exploit Type 3
| | Predecessors |• [VFdpxa](state__v__f_dpxa.md)
| | Successors
(prefer higher scores) |• [VFdPXa](state__v__f_d_p__x_a.md) (score=1.71)
| -| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md)
| +| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md)
| | Possible Sequences From This State |• [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_dpx_a_.md b/docs/reference/case_states/state__v__f_dpx_a_.md index 5e2702c1..ded9b796 100644 --- a/docs/reference/case_states/state__v__f_dpx_a_.md +++ b/docs/reference/case_states/state__v__f_dpx_a_.md @@ -1,6 +1,7 @@ # VFdpxA + | Key | Value | | --- | --- | | State | VFdpxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Attack Type 3
| | Predecessors |• [VfdpxA](state__v_fdpx_a_.md)
• [VFdpxa](state__v__f_dpxa.md)
| | Successors
(prefer higher scores) |• [VFdpXA](state__v__f_dp_x__a_.md) (score=1.56)
• [VFdPxA](state__v__f_d_p_x_a_.md) (score=1.50)
• [VFDpxA](state__v__f__d_px_a_.md) (score=4.35)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md)
| | Possible Sequences From This State |• [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v__f_dpxa.md b/docs/reference/case_states/state__v__f_dpxa.md index 06bbf42e..8b2e6e19 100644 --- a/docs/reference/case_states/state__v__f_dpxa.md +++ b/docs/reference/case_states/state__v__f_dpxa.md @@ -1,6 +1,7 @@ # VFdpxa + | Key | Value | | --- | --- | | State | VFdpxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [Vfdpxa](state__v_fdpxa.md)
| | Successors
(prefer higher scores) |• [VFdpxA](state__v__f_dpx_a_.md) (score=2.56)
• [VFdpXa](state__v__f_dp_x_a.md) (score=2.93)
• [VFdPxa](state__v__f_d_p_xa.md) (score=2.71)
• [VFDpxa](state__v__f__d_pxa.md) (score=6.04)
| -| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md)
| +| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md)
| | Possible Sequences From This State |• [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fd_p__x__a_.md b/docs/reference/case_states/state__v_fd_p__x__a_.md index 480ab7a8..9594c517 100644 --- a/docs/reference/case_states/state__v_fd_p__x__a_.md +++ b/docs/reference/case_states/state__v_fd_p__x__a_.md @@ -1,6 +1,7 @@ # VfdPXA + | Key | Value | | --- | --- | | State | VfdPXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 3
• Zero Day Exploit Type 2
• Zero Day Attack Type 2
| | Predecessors |• [vfdPXA](state_vfd_p__x__a_.md)
• [VfdpXA](state__v_fdp_x__a_.md)
• [VfdPxA](state__v_fd_p_x_a_.md)
• [VfdPXa](state__v_fd_p__x_a.md)
| | Successors
(prefer higher scores) |• [VFdPXA](state__v__f_d_p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md)
| | Possible Sequences From This State |• [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fd_p__x_a.md b/docs/reference/case_states/state__v_fd_p__x_a.md index 4d0d74af..70cc34d4 100644 --- a/docs/reference/case_states/state__v_fd_p__x_a.md +++ b/docs/reference/case_states/state__v_fd_p__x_a.md @@ -1,6 +1,7 @@ # VfdPXa + | Key | Value | | --- | --- | | State | VfdPXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 3
• Zero Day Exploit Type 2
| | Predecessors |• [vfdPXa](state_vfd_p__x_a.md)
• [VfdpXa](state__v_fdp_x_a.md)
• [VfdPxa](state__v_fd_p_xa.md)
| | Successors
(prefer higher scores) |• [VfdPXA](state__v_fd_p__x__a_.md) (score=0.00)
• [VFdPXa](state__v__f_d_p__x_a.md) (score=1.71)
| -| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md)
| +| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md)
| | Possible Sequences From This State |• [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fd_p_x_a_.md b/docs/reference/case_states/state__v_fd_p_x_a_.md index 6f64b91b..017a1e76 100644 --- a/docs/reference/case_states/state__v_fd_p_x_a_.md +++ b/docs/reference/case_states/state__v_fd_p_x_a_.md @@ -1,6 +1,7 @@ # VfdPxA + | Key | Value | | --- | --- | | State | VfdPxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 3
• Zero Day Attack Type 2
| | Predecessors |• [vfdPxA](state_vfd_p_x_a_.md)
• [VfdpxA](state__v_fdpx_a_.md)
• [VfdPxa](state__v_fd_p_xa.md)
| | Successors
(prefer higher scores) |• [VfdPXA](state__v_fd_p__x__a_.md) (score=0.00)
• [VFdPxA](state__v__f_d_p_x_a_.md) (score=1.50)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md)
| | Possible Sequences From This State |• [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fd_p_xa.md b/docs/reference/case_states/state__v_fd_p_xa.md index e09e3e42..e2825e73 100644 --- a/docs/reference/case_states/state__v_fd_p_xa.md +++ b/docs/reference/case_states/state__v_fd_p_xa.md @@ -1,6 +1,7 @@ # VfdPxa + | Key | Value | | --- | --- | | State | VfdPxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 3
| | Predecessors |• [vfdPxa](state_vfd_p_xa.md)
• [Vfdpxa](state__v_fdpxa.md)
| | Successors
(prefer higher scores) |• [VfdPxA](state__v_fd_p_x_a_.md) (score=0.83)
• [VfdPXa](state__v_fd_p__x_a.md) (score=1.08)
• [VFdPxa](state__v__f_d_p_xa.md) (score=2.71)
| -| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md)
| +| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md)
| | Possible Sequences From This State |• [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fdp_x__a_.md b/docs/reference/case_states/state__v_fdp_x__a_.md index fa6b16db..430e6fb4 100644 --- a/docs/reference/case_states/state__v_fdp_x__a_.md +++ b/docs/reference/case_states/state__v_fdp_x__a_.md @@ -1,6 +1,7 @@ # VfdpXA + | Key | Value | | --- | --- | | State | VfdpXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Exploit Type 2
• Zero Day Exploit Type 3
• Zero Day Attack Type 2
• Zero Day Attack Type 3
| | Predecessors |• [VfdpxA](state__v_fdpx_a_.md)
| | Successors
(prefer higher scores) |• [VfdPXA](state__v_fd_p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md)
| | Possible Sequences From This State |• [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fdp_x_a.md b/docs/reference/case_states/state__v_fdp_x_a.md index 32a217af..ca0eef78 100644 --- a/docs/reference/case_states/state__v_fdp_x_a.md +++ b/docs/reference/case_states/state__v_fdp_x_a.md @@ -1,6 +1,7 @@ # VfdpXa + | Key | Value | | --- | --- | | State | VfdpXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Exploit Type 2
• Zero Day Exploit Type 3
| | Predecessors |• [Vfdpxa](state__v_fdpxa.md)
| | Successors
(prefer higher scores) |• [VfdPXa](state__v_fd_p__x_a.md) (score=1.08)
| -| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md)
| +| Possible Sequences To This State |• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md)
| | Possible Sequences From This State |• [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fdpx_a_.md b/docs/reference/case_states/state__v_fdpx_a_.md index ae6b451e..252aadd9 100644 --- a/docs/reference/case_states/state__v_fdpx_a_.md +++ b/docs/reference/case_states/state__v_fdpx_a_.md @@ -1,6 +1,7 @@ # VfdpxA + | Key | Value | | --- | --- | | State | VfdpxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Attack Type 2
• Zero Day Attack Type 3
| | Predecessors |• [vfdpxA](state_vfdpx_a_.md)
• [Vfdpxa](state__v_fdpxa.md)
| | Successors
(prefer higher scores) |• [VfdpXA](state__v_fdp_x__a_.md) (score=0.67)
• [VfdPxA](state__v_fd_p_x_a_.md) (score=0.83)
• [VFdpxA](state__v__f_dpx_a_.md) (score=2.56)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md)
| | Possible Sequences From This State |• [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state__v_fdpxa.md b/docs/reference/case_states/state__v_fdpxa.md index e5da5049..4ce25873 100644 --- a/docs/reference/case_states/state__v_fdpxa.md +++ b/docs/reference/case_states/state__v_fdpxa.md @@ -1,6 +1,7 @@ # Vfdpxa + | Key | Value | | --- | --- | | State | Vfdpxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Not Applicable
| | Predecessors |• [vfdpxa](state_vfdpxa.md)
| | Successors
(prefer higher scores) |• [VfdpxA](state__v_fdpx_a_.md) (score=1.00)
• [VfdpXa](state__v_fdp_x_a.md) (score=1.42)
• [VfdPxa](state__v_fd_p_xa.md) (score=1.42)
• [VFdpxa](state__v__f_dpxa.md) (score=3.43)
| -| Possible Sequences To This State |• [**V**](state__v_fdpxa.md)
| +| Possible Sequences To This State |• [**V**](state__v_fdpxa.md)
| | Possible Sequences From This State |• [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfd_p__x__a_.md b/docs/reference/case_states/state_vfd_p__x__a_.md index f18672bd..7e2d3ca0 100644 --- a/docs/reference/case_states/state_vfd_p__x__a_.md +++ b/docs/reference/case_states/state_vfd_p__x__a_.md @@ -1,6 +1,7 @@ # vfdPXA + | Key | Value | | --- | --- | | State | vfdPXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 2
• Zero Day Vulnerability Type 3
• Zero Day Exploit Type 1
• Zero Day Exploit Type 2
• Zero Day Attack Type 1
• Zero Day Attack Type 2
| | Predecessors |• [vfdpXA](state_vfdp_x__a_.md)
| | Successors
(prefer higher scores) |• [VfdPXA](state__v_fd_p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md)
| | Possible Sequences From This State |• [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfd_p__x_a.md b/docs/reference/case_states/state_vfd_p__x_a.md index ba64ce1b..36f30385 100644 --- a/docs/reference/case_states/state_vfd_p__x_a.md +++ b/docs/reference/case_states/state_vfd_p__x_a.md @@ -1,6 +1,7 @@ # vfdPXa + | Key | Value | | --- | --- | | State | vfdPXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 2
• Zero Day Vulnerability Type 3
• Zero Day Exploit Type 1
• Zero Day Exploit Type 2
| | Predecessors |• [vfdpXa](state_vfdp_x_a.md)
| | Successors
(prefer higher scores) |• [VfdPXa](state__v_fd_p__x_a.md) (score=1.08)
| -| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md)
| +| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md)
| | Possible Sequences From This State |• [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfd_p_x_a_.md b/docs/reference/case_states/state_vfd_p_x_a_.md index 5cbd85ac..98047f97 100644 --- a/docs/reference/case_states/state_vfd_p_x_a_.md +++ b/docs/reference/case_states/state_vfd_p_x_a_.md @@ -1,6 +1,7 @@ # vfdPxA + | Key | Value | | --- | --- | | State | vfdPxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 2
• Zero Day Vulnerability Type 3
• Zero Day Attack Type 1
• Zero Day Attack Type 2
| | Predecessors |• [vfdpxA](state_vfdpx_a_.md)
| | Successors
(prefer higher scores) |• [VfdPxA](state__v_fd_p_x_a_.md) (score=0.83)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md)
| | Possible Sequences From This State |• [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfd_p_xa.md b/docs/reference/case_states/state_vfd_p_xa.md index da4cf6cf..f5ed6ee2 100644 --- a/docs/reference/case_states/state_vfd_p_xa.md +++ b/docs/reference/case_states/state_vfd_p_xa.md @@ -1,6 +1,7 @@ # vfdPxa + | Key | Value | | --- | --- | | State | vfdPxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 2
• Zero Day Vulnerability Type 3
| | Predecessors |• [vfdpxa](state_vfdpxa.md)
| | Successors
(prefer higher scores) |• [VfdPxa](state__v_fd_p_xa.md) (score=1.42)
| -| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md)
| +| Possible Sequences To This State |• [**P**](state_vfd_p_xa.md)
| | Possible Sequences From This State |• [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfdp_x__a_.md b/docs/reference/case_states/state_vfdp_x__a_.md index 56137686..b3b51585 100644 --- a/docs/reference/case_states/state_vfdp_x__a_.md +++ b/docs/reference/case_states/state_vfdp_x__a_.md @@ -1,6 +1,7 @@ # vfdpXA + | Key | Value | | --- | --- | | State | vfdpXA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 1
• Zero Day Exploit Type 1
• Zero Day Exploit Type 2
• Zero Day Exploit Type 3
• Zero Day Attack Type 1
• Zero Day Attack Type 2
• Zero Day Attack Type 3
| | Predecessors |• [vfdpxA](state_vfdpx_a_.md)
| | Successors
(prefer higher scores) |• [vfdPXA](state_vfd_p__x__a_.md) (score=0.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md)
| | Possible Sequences From This State |• [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfdp_x_a.md b/docs/reference/case_states/state_vfdp_x_a.md index f76aa5f3..be4cd1fc 100644 --- a/docs/reference/case_states/state_vfdp_x_a.md +++ b/docs/reference/case_states/state_vfdp_x_a.md @@ -1,6 +1,7 @@ # vfdpXa + | Key | Value | | --- | --- | | State | vfdpXa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 1
• Zero Day Exploit Type 1
• Zero Day Exploit Type 2
• Zero Day Exploit Type 3
| | Predecessors |• [vfdpxa](state_vfdpxa.md)
| | Successors
(prefer higher scores) |• [vfdPXa](state_vfd_p__x_a.md) (score=0.83)
| -| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md)
| +| Possible Sequences To This State |• [**X**](state_vfdp_x_a.md)
| | Possible Sequences From This State |• [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfdpx_a_.md b/docs/reference/case_states/state_vfdpx_a_.md index 384c732b..4a00f904 100644 --- a/docs/reference/case_states/state_vfdpx_a_.md +++ b/docs/reference/case_states/state_vfdpx_a_.md @@ -1,6 +1,7 @@ # vfdpxA + | Key | Value | | --- | --- | | State | vfdpxA | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 1
• Zero Day Attack Type 1
• Zero Day Attack Type 2
• Zero Day Attack Type 3
| | Predecessors |• [vfdpxa](state_vfdpxa.md)
| | Successors
(prefer higher scores) |• [vfdpXA](state_vfdp_x__a_.md) (score=0.00)
• [vfdPxA](state_vfd_p_x_a_.md) (score=0.50)
• [VfdpxA](state__v_fdpx_a_.md) (score=1.00)
| -| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md)
| +| Possible Sequences To This State |• [**A**](state_vfdpx_a_.md)
| | Possible Sequences From This State |• [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/case_states/state_vfdpxa.md b/docs/reference/case_states/state_vfdpxa.md index c680a80b..8b7dd23f 100644 --- a/docs/reference/case_states/state_vfdpxa.md +++ b/docs/reference/case_states/state_vfdpxa.md @@ -1,6 +1,7 @@ # vfdpxa + | Key | Value | | --- | --- | | State | vfdpxa | @@ -13,5 +14,5 @@ | Zeroday_Type |• Zero Day Vulnerability Type 1
| | Predecessors |• None
| | Successors
(prefer higher scores) |• [vfdpxA](state_vfdpx_a_.md) (score=0.00)
• [vfdpXa](state_vfdp_x_a.md) (score=0.50)
• [vfdPxa](state_vfd_p_xa.md) (score=0.83)
• [Vfdpxa](state__v_fdpxa.md) (score=1.25)
| -| Possible Sequences To This State |• None
| +| Possible Sequences To This State |• None
| | Possible Sequences From This State |• [**A**](state_vfdpx_a_.md) → [**X**](state_vfdp_x__a_.md) → [**P**](state_vfd_p__x__a_.md) → [**V**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**P**](state_vfd_p_x_a_.md) → [**V**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**A**](state_vfdpx_a_.md) → [**V**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**X**](state_vfdp_x_a.md) → [**P**](state_vfd_p__x_a.md) → [**V**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**P**](state_vfd_p_xa.md) → [**V**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**X**](state__v_fdp_x__a_.md) → [**P**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**P**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**A**](state__v_fdpx_a_.md) → [**F**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**X**](state__v_fdp_x_a.md) → [**P**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**X**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**A**](state__v_fd_p_x_a_.md) → [**F**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**A**](state__v_fd_p__x__a_.md) → [**F**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**X**](state__v_fd_p__x_a.md) → [**F**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**P**](state__v_fd_p_xa.md) → [**F**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**X**](state__v__f_dp_x__a_.md) → [**P**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**P**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**A**](state__v__f_dpx_a_.md) → [**D**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**X**](state__v__f_dp_x_a.md) → [**P**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**X**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**A**](state__v__f_d_p_x_a_.md) → [**D**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**A**](state__v__f_d_p__x__a_.md) → [**D**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**X**](state__v__f_d_p__x_a.md) → [**D**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**P**](state__v__f_d_p_xa.md) → [**D**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**X**](state__v__f__d_p_x__a_.md) → [**P**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**A**](state__v__f__d_px_a_.md) → [**P**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**X**](state__v__f__d_p_x_a.md) → [**P**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**A**](state__v__f__d__p_x_a_.md) → [**X**](state__v__f__d__p__x__a_.md)
• [**V**](state__v_fdpxa.md) → [**F**](state__v__f_dpxa.md) → [**D**](state__v__f__d_pxa.md) → [**P**](state__v__f__d__p_xa.md) → [**X**](state__v__f__d__p__x_a.md) → [**A**](state__v__f__d__p__x__a_.md)
| diff --git a/docs/reference/code/index.md b/docs/reference/code/index.md index 38fa9a3d..bc68441c 100644 --- a/docs/reference/code/index.md +++ b/docs/reference/code/index.md @@ -7,4 +7,3 @@ See [Case States](case_states.md) for more information. ::: vultron.errors - diff --git a/docs/reference/formal_protocol/conclusion.md b/docs/reference/formal_protocol/conclusion.md index f0239f28..a4a7b4e0 100644 --- a/docs/reference/formal_protocol/conclusion.md +++ b/docs/reference/formal_protocol/conclusion.md @@ -32,7 +32,7 @@ where | $succ$ | a partial function mapping for each $i$ and $j$, $S_i \times M_{ij} \rightarrow S_i \textrm{ and } S_i \times M_{ji} \rightarrow S_i$ indicating the state changes arising from the sending and receiving of messages between Participants. | [Transitions](transitions.md) | !!! note inline end "Legend" - + | Symbol | Description | |:-------:|:-------------------------| | ↼ | Message Received | @@ -47,7 +47,7 @@ A summary of the MPCVD state model $S_i$ for an individual Participant is shown The Report Management (RM) state model is shown below. Note that with the exception of receiving reports, the RM process primarily focuses on Participants communicating -their status to other Participants, as it is primarily emitting messages as opposed to receiving them. +their status to other Participants, as it is primarily emitting messages as opposed to receiving them. ```mermaid stateDiagram-v2 @@ -65,7 +65,6 @@ stateDiagram-v2 I --> C : c (#8640;RC) ``` - ### Embargo Management The Embargo Management (EM) state model is shown below. @@ -145,8 +144,8 @@ stateDiagram-v2 The symbol $\prec$ is read as *precedes*. -In [Defining CVD Success](../../topics/background/cvd_success.md), we defined a set of 12 ordering preferences over the -6 events in the Case State model. The symbols for these preferences refer to the transition events in the Case State +In [Defining CVD Success](../../topics/background/cvd_success.md), we defined a set of 12 ordering preferences over the +6 events in the Case State model. The symbols for these preferences refer to the transition events in the Case State diagrams above. | Ordering Preference | Notation | @@ -165,5 +164,5 @@ diagrams above. | Vendor Awareness Before Attacks Observed | **V** $\prec$ **A** | !!! tip "Worked Example" - - A [worked example](../../topics/formal_protocol/worked_example.md) of the protocol in action is available. \ No newline at end of file + + A [worked example](../../topics/formal_protocol/worked_example.md) of the protocol in action is available. diff --git a/docs/reference/formal_protocol/index.md b/docs/reference/formal_protocol/index.md index 60367265..a332120e 100644 --- a/docs/reference/formal_protocol/index.md +++ b/docs/reference/formal_protocol/index.md @@ -12,9 +12,9 @@ models described elsewhere. ## Communication Protocol Definitions {#sec:protocol_definition} -A communication protocol allows independent processes, represented as finite state machines, to coordinate their state +A communication protocol allows independent processes, represented as finite state machines, to coordinate their state transitions through the passing of messages. [Brand and Zafiropulo](https://doi.org/10.1145/322374.322380) defined -a protocol as follows. +a protocol as follows. !!! note "_Protocol_ Formally Defined" @@ -82,5 +82,3 @@ multiple roles in a given case. The total number of processes $N$ is simply the count of unique Participants. $$N = |Participants| = | Reporters \cup Vendors \cup Coordinators \cup Deployers \cup Others |$$ - - diff --git a/docs/reference/formal_protocol/messages.md b/docs/reference/formal_protocol/messages.md index c8c5d3fb..9afedf1b 100644 --- a/docs/reference/formal_protocol/messages.md +++ b/docs/reference/formal_protocol/messages.md @@ -9,7 +9,7 @@ MPCVD process: - Vendor - Coordinator - Deployer - + Here we will examine the messages passed between them. Revisiting the definitions from the [Formal Protocol Introduction](index.md): @@ -19,7 +19,7 @@ Revisiting the definitions from the [Formal Protocol Introduction](index.md): $M_{ii}$ empty for all $i$: $M_{ij}$ represents the messages that can be sent from process $i$ to process $j$. -The message types in the Vultron Protocol arise primarily from the following principle taken directly from the +The message types in the Vultron Protocol arise primarily from the following principle taken directly from the [CVD Guide](https://vuls.cert.org/confluence/display/CVD/2.3.+Avoid+Surprise): !!! quote "Avoid Surprise" @@ -57,7 +57,7 @@ If you are looking for a one-sentence summary of the entire Vultron Protocol, th As a reminder, those transitions are shown at right. We will address the specific circumstances when each message should be emitted in -[Transitions](transitions.md), but first we need to +[Transitions](transitions.md), but first we need to introduce the message types this recommendation implies. We cover messages associated with each state model, in turn, below, concluding the section with a few message types not directly connected to any particular state model. @@ -65,12 +65,12 @@ directly connected to any particular state model. ## RM Message Types !!! tip inline end "Finders have hidden states" - + As we discuss in [RM Interactions](../../topics/process_models/rm/rm_interactions.md#the-secret-lives-of-finders), the Finder's states $q^{rm} \in \{R,I,V\}$ are not observable to the CVD process because Finders start coordination only when they have already reached $q^{rm} = A$. -With the exception of the Finder/Reporter, each Participant's involvement in a CVD case starts with the receipt of a +With the exception of the Finder/Reporter, each Participant's involvement in a CVD case starts with the receipt of a report from another Participant who is already in the $Accepted$ ($q^{rm} \in A$) state. The remainder of a Participant's RM process is largely independent of the other Participants' RM processes. Therefore, the RM message types are primarily used to inform other Participants of the sender's state. @@ -89,7 +89,6 @@ Therefore, the RM message types are primarily used to inform other Participants | $RK$ | Report Acknowledgement | A message acknowledging the receipt of any RM message listed above. | | $RE$ | Report Error | A message indicating a Participant received an unexpected RM message. | - A summary of the RM message types is shown below. !!! note "RM Message Types" @@ -97,7 +96,7 @@ A summary of the RM message types is shown below. $$M^{rm} = \{RS,RI,RV,RD,RA,RC,RK,RE\}$$ All state changes are from the Participant's (sender's) perspective, not the recipient's perspective. -We will see in [Transitions](transitions.md) that the receipt of a *Report Submission* is the +We will see in [Transitions](transitions.md) that the receipt of a *Report Submission* is the only message whose *receipt* directly triggers an RM state change in the receiver. All other RM messages are used to convey the sender's status. @@ -114,7 +113,7 @@ All other RM messages are used to convey the sender's status. Instead, duplicate reports SHOULD pass through $Valid$ ($q^{rm} \in V$), although they MAY be subsequently (immediately or otherwise) deferred ($q^{rm} \in V \xrightarrow{d} D$) in favor of the original. - + !!! note "" Participants SHOULD track the RM states of the other Participants in the case. @@ -124,7 +123,7 @@ Furthermore, while these messages are expected to inform the receiving Participa this protocol intentionally does not specify any other recipient RM state changes upon receipt of an RM message. ## EM Message Types - + Whereas the RM process is unique to each Participant, the EM process is global to the case. Therefore, we begin with the list of message types a Participant SHOULD emit when their EM state changes. @@ -170,8 +169,6 @@ changes: **Vendor Awareness** ($CV$) messages SHOULD be sent only by Participants with direct knowledge of the notification (i.e., either by the Participant who sent the report to the Vendor or by the Vendor upon receipt of the report). - - A summary of the CS message types is shown below. !!! note "CS Message Types" @@ -191,15 +188,14 @@ be sent). | $GK$ | General Acknowledgement | A message from a Participant indicating their receipt of a GI message. | | $GE$ | General Error | A message indicating a general error has occurred. | - Examples of general inquiry messages include but are not limited to -- asking or responding to a question -- requesting an update on a Participant's status -- requesting review of a draft publication -- suggesting a potential Participant to be added to a case -- coordinating other events -- resolving a loss of Participant state synchronization +- asking or responding to a question +- requesting an update on a Participant's status +- requesting review of a draft publication +- suggesting a potential Participant to be added to a case +- coordinating other events +- resolving a loss of Participant state synchronization A summary of the General message types is shown below. @@ -240,8 +236,8 @@ For convenience, we collected these into the table below. | CS | $CA$ | Attacks Observed | $\cdot\cdot\cdot\cdot\cdot a \xrightarrow{\mathbf{A}} \cdot\cdot\cdot\cdot\cdot A$ | | CS | $CK$ | CS Acknowledgement | any valid CS message | | CS | $CE$ | CS Error | any unexpected CS message | -| * | $GI$ | General Inquiry | any time | -| * | $GK$ | General Acknowledgement | any valid GI message | +| *| $GI$ | General Inquiry | any time | +|* | $GK$ | General Acknowledgement | any valid GI message | | * | $GE$ | General Error | any unexpected GI message | !!! note "Message Types Formally Defined" @@ -256,7 +252,4 @@ For convenience, we collected these into the table below. \end{array} \right\}\textrm{ where $i \neq j$; $\varnothing$ otherwise; for $i,j \leq N$}$$ - -Message _formats_ are left as [future work](../../topics/future_work/index.md). - - +Message *formats* are left as [future work](../../topics/future_work/index.md). diff --git a/docs/reference/formal_protocol/states.md b/docs/reference/formal_protocol/states.md index 6ee28892..afa17957 100644 --- a/docs/reference/formal_protocol/states.md +++ b/docs/reference/formal_protocol/states.md @@ -18,12 +18,12 @@ Good Participant situation awareness makes for good CVD decision making. Participants SHOULD track the state of other Participants in a case to inform their own decision making as it pertains to the case. -Elsewhere, we provide an example [Case Object](../../howto/case_object.md) model to facilitate such tracking. +Elsewhere, we provide an example [Case Object](../../howto/case_object.md) model to facilitate such tracking. However, the protocol we are developing is expected to function even when incomplete information is available to any given Participant. !!! note "" - + Adequate operation of the protocol MUST NOT depend on perfect information across all Participants. A generic state model for a CVD Participant can be composed from the Cartesian product of $\mathcal{Q}^{rm}$, @@ -93,10 +93,10 @@ Note that the above definition splits the case state ($vfd \xrightarrow{\mathbf{V}} Vfd \xrightarrow{\mathbf{F}} VFd \xrightarrow{\mathbf{D}} VFD$) and the public-exploit-attack ($pxa \xrightarrow{\dots} PXA$) sub-models from the [Case State Model](../../topics/process_models/cs/index.md). -This is done for two reasons. +This is done for two reasons. First, it gives us a more compact notation to represent the 32 states of the CS model. -Second, as described in [Model Interactions](../../topics/process_models/model_interactions/index.md), it highlights the fact that -the Vendor fix path represents the state of an individual Participant, whereas the public-exploit-attack sub-model +Second, as described in [Model Interactions](../../topics/process_models/model_interactions/index.md), it highlights the fact that +the Vendor fix path represents the state of an individual Participant, whereas the public-exploit-attack sub-model represents facts about the world at large. Because not all Participants are Vendors or Deployers, Participants might not have a corresponding @@ -125,10 +125,10 @@ In the remainder of this section, we detail these differences. ## Unreachable States For any Participant, the RM $Closed$ state implies that the EM and CVD Case states do -not matter. +not matter. Similarly, for any Participant, the RM $Start$ state represents a case that the -Participant doesn't even know about yet. -Therefore, the $Start$ state also implies that the EM and CVD Case states do not matter. +Participant doesn't even know about yet. +Therefore, the $Start$ state also implies that the EM and CVD Case states do not matter. We use $*$ to represent the "don't care" value. ???+ note "Unreachable EM and CS States when RM is in _Closed_ or _Start_" @@ -153,7 +153,7 @@ Furthermore, when a vulnerability becomes public, the EM state no longer matters Taken together, we can modify our state model to reflect these limitations. The result is shown below. -!!! note "Participant States With Unreachable States Removed" +!!! note "Participant States With Unreachable States Removed" $$ S_i % = \mathcal{Q}^{rm} \times \mathcal{Q}^{em} \times \mathcal{Q}^{cs} @@ -256,23 +256,23 @@ This means that each Participant must be in one of 352 possible states. ## Vendors (Fix Suppliers) Vendors are the sole providers of fixes. -Therefore, they are the only Participants in a CVD case for which the $Vfd \xrightarrow{\mathbf{F}} VFd \xrightarrow{\mathbf{D}} VFD$ +Therefore, they are the only Participants in a CVD case for which the $Vfd \xrightarrow{\mathbf{F}} VFd \xrightarrow{\mathbf{D}} VFD$ path is possible. -Furthermore, since they are Vendors by definition, they do not have access to the $vfd$ state or the $\varnothing$ +Furthermore, since they are Vendors by definition, they do not have access to the $vfd$ state or the $\varnothing$ state that was just added. As a Vendor has a report in $Received$, it is, by definition, at least in the $Vfd$ case state. Vendors create fixes only when they are in the $Accepted$ RM state. -Because the $Received$, $Invalid$, and $Valid$ states come strictly *before* the $Accepted$ state in the RM DFA, +Because the $Received$, $Invalid$, and $Valid$ states come strictly _before_ the $Accepted$ state in the RM DFA, there is no way for the Vendor to be in either $VFd$ or $VFD$ while in any of those states. ???+ note "Vendor CS States When RM is in _Received_, _Invalid_, or _Valid_" $$q^{rm}_{Vendor} \in \{R,I,V\} \implies q^{cs}_{Vendor} \in Vfd\cdot\cdot\cdot$$ -Vendors with the ability to deploy fixes themselves have access to three states in the fix path: $\{Vfd,~VFd,~VFD\}$. +Vendors with the ability to deploy fixes themselves have access to three states in the fix path: $\{Vfd,~VFd,~VFD\}$. However, this is not always the case. -Vendor Participants without a deployment capability can only create fixes, limiting them to the middle two states in +Vendor Participants without a deployment capability can only create fixes, limiting them to the middle two states in the fix path: $\{Vfd,~VFd\}$. Additional discussion of the distinction between Vendors with and without a deployment capability can be found in [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513). @@ -454,15 +454,15 @@ As tallied below, there are 128 possible states for a Vendor with deployment cap ## Non-Vendor Deployers -We just explained that not all Vendors are Deployers. +We just explained that not all Vendors are Deployers. Likewise, not all Deployers are Vendors. Most CVD cases leave Non-Vendor Deployers entirely out of the CVD process, so their appearance is expected to be rare in actual cases. -However, there are scenarios when an MPCVD case may include Non-Vendor Deployers, such as when a vulnerability in some +However, there are scenarios when an MPCVD case may include Non-Vendor Deployers, such as when a vulnerability in some critical infrastructure component is being handled or when the Vultron Protocol is used in the context of a Vulnerability Disclosure Program (VDP). These Non-Vendor Deployers participate only in the $d \xrightarrow{\mathbf{D}} D$ transition on the fix path. -Similar to the [Vendor](#vendors-fix-suppliers) scenario above, it is expected that Deployers actually deploy fixes only when they are in the +Similar to the [Vendor](#vendors-fix-suppliers) scenario above, it is expected that Deployers actually deploy fixes only when they are in the RM $Accepted$ state (implying their intent to deploy). Therefore, their set of possible states is even more restricted than Vendors, as shown below. @@ -476,7 +476,7 @@ Therefore, their set of possible states is even more restricted than Vendors, as I \\ V \\ \end{bmatrix} - \times + \times % embargo state \begin{bmatrix} N \\ @@ -485,21 +485,21 @@ Therefore, their set of possible states is even more restricted than Vendors, as R \\ X \\ \end{bmatrix} - \times + \times % case state \begin{bmatrix} \begin{bmatrix} d \\ \end{bmatrix} - \times + \times \begin{bmatrix} p \\ \end{bmatrix} - \times + \times \begin{bmatrix} x \\ \end{bmatrix} - \times + \times \begin{bmatrix} a \\ A \\ @@ -508,9 +508,9 @@ Therefore, their set of possible states is even more restricted than Vendors, as {}\\ \begin{bmatrix} D \\ - A \\ + A \\ \end{bmatrix} - \times + \times % embargo state \begin{bmatrix} N \\ @@ -519,22 +519,22 @@ Therefore, their set of possible states is even more restricted than Vendors, as R \\ X \\ \end{bmatrix} - \times + \times % case state \begin{bmatrix} \begin{bmatrix} d \\ D \\ \end{bmatrix} - \times + \times \begin{bmatrix} p \\ \end{bmatrix} - \times + \times \begin{bmatrix} x \\ \end{bmatrix} - \times + \times \begin{bmatrix} a \\ A \\ @@ -546,27 +546,27 @@ Therefore, their set of possible states is even more restricted than Vendors, as I \\ V \\ \end{bmatrix} - \times + \times % embargo state \begin{bmatrix} * \\ \end{bmatrix} - \times + \times % case state \begin{bmatrix} \begin{bmatrix} d \\ \end{bmatrix} - \times + \times \begin{bmatrix} P \\ \end{bmatrix} - \times + \times \begin{bmatrix} x \\ X \\ \end{bmatrix} - \times + \times \begin{bmatrix} a \\ A \\ @@ -575,30 +575,30 @@ Therefore, their set of possible states is even more restricted than Vendors, as {} \\ \begin{bmatrix} D \\ - A \\ + A \\ \end{bmatrix} - \times + \times % embargo state \begin{bmatrix} * \\ \end{bmatrix} - \times + \times % case state \begin{bmatrix} \begin{bmatrix} d \\ D \\ \end{bmatrix} - \times + \times \begin{bmatrix} P \\ \end{bmatrix} - \times + \times \begin{bmatrix} x \\ X \\ \end{bmatrix} - \times + \times \begin{bmatrix} a \\ A \\ @@ -616,14 +616,14 @@ states, as we show next. |S_{i_{Deployer}}| = & 1 + \big(3 \cdot 5 \cdot (1 \cdot 1 \cdot 1 \cdot 2)\big) + \big(2 \cdot 5 \cdot (2 \cdot 1 \cdot 1 \cdot 2)\big) \\ & + \big(3 \cdot 1 \cdot (1 \cdot 1 \cdot 2 \cdot 2)\big) + \big(2 \cdot 1 \cdot (2 \cdot 1 \cdot 2 \cdot 2)\big) + 1 \\ % = & 2 + 30 + 40 + 12 + 16 \\ - = & 100 \\ + = & 100 \\ \end{split}$$ ## Non-Vendor, Non-Deployer Participants Finally, CVD cases often involve Participants who are neither Vendors nor Deployers. Specifically, Finder/Reporters fall into this category, as do Coordinators. -Other roles, as outlined in the [*CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD), +Other roles, as outlined in the [_CERT Guide to Coordinated Vulnerability Disclosure_](https://vuls.cert.org/confluence/display/CVD), could be included here as well. Because they do not participate directly in the Vendor fix path, these Non-Vendor, Non-Deployer CVD Participants fall into the $\varnothing$ case substate we added above. @@ -812,7 +812,7 @@ become Reporters have only 29 possible states during a CVD case. $$ \begin{split} |S_{i_{Reporter}}| = & \big(2 \cdot 5 \cdot (1 \cdot 1 \cdot 1 \cdot 2)\big) + \big(2 \cdot 1 \cdot (1 \cdot 1 \cdot 2 \cdot 2)\big) + 1 \\ % = & 20 + 8 + 1 \\ - = & 29 \\ + = & 29 \\ \end{split}$$ ## A Lower Bounds on MPCVD State Space @@ -825,7 +825,6 @@ Now we can touch on the lower bounds of the state space of an MPCVD case. Generically, we would expect the state space for $N$ Participants to take the form given at right. - The upper bound on the MPCVD state space is simply $352^N \approx 10^{2.55N}$. However, because of the Role-specific limits just described, we already know that this overcounts the possible states significantly. @@ -835,12 +834,12 @@ drastically reduce the state space for an MPCVD case. Why? There are two reasons: -1. Because they represent facts about the outside world, the eight +1. Because they represent facts about the outside world, the eight $\cdot\cdot\cdot pxa \rightarrow \cdot\cdot\cdot PXA$ CS substates are global to the case, not to individual Participants. This means all Participants should rapidly converge to the same substate. -2. Similarly, the five EM states are also global to the case and should converge rapidly. +2. Similarly, the five EM states are also global to the case and should converge rapidly. Given these two observations, we can pull those Participant-agnostic terms out of the state calculations for individual Participants, @@ -883,14 +882,14 @@ So our state space looks like With these values in mind, we see that -- A two-party (Finder-Vendor) case might have a lower bound state space of $40 \times 3 \times 16 = 1,920$ states. +- A two-party (Finder-Vendor) case might have a lower bound state space of $40 \times 3 \times 16 = 1,920$ states. -- A case like Meltdown/Spectre (with six Vendors and no Coordinators) might have $40 \times 3 \times 16^{6} \approx 10^{9}$ states. +- A case like Meltdown/Spectre (with six Vendors and no Coordinators) might have $40 \times 3 \times 16^{6} \approx 10^{9}$ states. -- A large, but not atypical, 200-Vendor case handled by the CERT/CC might have +- A large, but not atypical, 200-Vendor case handled by the CERT/CC might have $40 \times 3 \times 16^{200} \times 7 \approx 10^{244}$ possible configurations. -- In the case of the log4j vulnerability [CVE-2021-44228](https://www.kb.cert.org/vuls/id/930724) in December +- In the case of the log4j vulnerability [CVE-2021-44228](https://www.kb.cert.org/vuls/id/930724) in December 2021, the CERT/CC notified around 1,600 Vendors after the vulnerability had been made public. Had this been an embargoed disclosure, the case would have a total state space around $10^{2000}$. @@ -919,7 +918,6 @@ Deployers, and other Participants are shown below. | Other | $(S,N,pxa)$ | | Finder/Reporter | $(A,N,pxa)$ | - For a case to really begin, the Finder must at least reach the $A$ state. Therefore, at the point when a second party finds out about the vulnerability from a Finder, the Finder/Reporter is presumed to be already at $q_{Finder}=(A, N, pxa)$. diff --git a/docs/reference/formal_protocol/transitions.md b/docs/reference/formal_protocol/transitions.md index 9927eb11..3a9c273d 100644 --- a/docs/reference/formal_protocol/transitions.md +++ b/docs/reference/formal_protocol/transitions.md @@ -3,10 +3,10 @@ {% include-markdown "../../includes/normative.md" %} In this section, we describe the transition functions for the RM, EM, and CVD Case processes, respectively. -Note that while the RM process is largely independent of the other two process models, the EM and CVD process models +Note that while the RM process is largely independent of the other two process models, the EM and CVD process models have some noteworthy interactions, which we will cover in detail. -Revisiting the formal protocol definition from the [introduction](index.md): +Revisiting the formal protocol definition from the [introduction](index.md): !!! note "Transition Function Defined" @@ -18,7 +18,6 @@ Revisiting the formal protocol definition from the [introduction](index.md): message $x$ in state $s$. It is a transmission if $x$ is from $M_{ij}$ and a reception if $x$ is from $M_{ji}$. - !!! tip "Notation Conventions on this Page" - By convention, CS states are labeled in the order $vfdpxa$. @@ -29,7 +28,6 @@ Revisiting the formal protocol definition from the [introduction](index.md): - Left-harpoons ($\leftharpoondown$) indicate a message received. - Right-harpoons ($\rightharpoonup$) indicate a message sent. - ## RM Transition Functions Because it only reflects an individual Participant's report handling status, @@ -69,7 +67,7 @@ Otherwise, Participants SHOULD send $RE$ regardless of the state when any error is encountered. - + !!! note "" Recipients MAY ignore messages received on $Closed$ cases. @@ -99,7 +97,7 @@ Otherwise, ($GI$) as to the nature of the error. !!! note inline end "RM Messages Sent and State Transitions" - + $$S_i \times M_{ij}^{rm} \rightarrow S_i$$ ### RM Messages Sent and State Transitions @@ -107,7 +105,6 @@ Otherwise, The table below lists each RM message type and the states in which that message is appropriate to send along with the corresponding sender state transition. - | Sender Preconditions
$s_n \in S_i$
$q^{cs},q^{rm},q^{em}$ | Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Message Type
$\rightharpoonup$
$M_{ij}$ | |:-----------------------------------------------------------------:|:------------------------------------------------------------------------:|:-------------------------------------------------------:| | $*,A,*$ | $-, -, -$ | $RS$ | @@ -119,17 +116,15 @@ corresponding sender state transition. | $*,*,*$ | $-, -, -$ | $RE$ | | $*,*,*$ | $-, -, -$ | $RK$ | - !!! note inline end "RM Messages Received and State Transitions" $$S_i \times M_{ji}^{rm} \rightarrow S_i$$ ### RM Messages Received and State Transitions -The table below lists the effects of receiving RM messages on the receiving Participant's state coupled with the +The table below lists the effects of receiving RM messages on the receiving Participant's state coupled with the expected response message. - | Received Msg.
$\leftharpoondown$
$M_{ji}$ | Receiver Precondition
$s_n \in S_i$
$q^{cs},q^{rm},q^{em}$ | Receiver Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Response Msg.
$\rightharpoonup$
$M_{ij}$ | |:-------------------------------------------------:|:------------------------------------------------------------------:|:---------------------------------------------------------------------------------:|:------------------------------------------------:| | $*$ | $*,C,*$ | $-,-,-$ | $-$ | @@ -187,11 +182,9 @@ $q^{cs}$ is in $\cdot\cdot\cdot pxa$ or not. Participants SHOULD acknowledge ($EK$) and inquire ($GI$) about the nature of any error reported by an incoming $EE$ message. - !!! note inline end "EM Messages Sent and State Transitions" - - $$S_i \times M_{ij}^{em} \rightarrow S_i$$ + $$S_i \times M_{ij}^{em} \rightarrow S_i$$ ### EM Messages Sent and State Transitions @@ -213,7 +206,6 @@ the corresponding sender state transition. | $*,\lnot C,*$ | $-,-,-$ | $EK$ | | $*,\lnot C,*$ | $-,-,-$ | $EE$ | - !!! note inline end "EM Messages Received and State Transitions" $$S_i \times M_{ji}^{em} \rightarrow S_i$$ @@ -227,7 +219,6 @@ The next table lists the effects of receiving an EM message to the receiving Par Incoming EM Messages do not trigger any change in $q^{cs}$ or $q^{rm}$. When CS is $q^{cs} \not \in \cdot\cdot\cdot pxa$, embargoes are not viable. - | Received Msg.
$\leftharpoondown$
$M_{ji}$ | Receiver Precondition
$s_n \in S_i$
$q^{cs},q^{rm}$ | Receiver Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Response Msg.
$\rightharpoonup$
$M_{ij}$ | |:--------------------------------------------------------:|:-----------------------------------------------------------:|:---------------------------------------------------------------------------------:|:------------------------------------------------:| | $EP$ | $\cdot\cdot\cdot pxa, \lnot C, N$ | $-,-,\xrightarrow{p} P$ | $EK$ | @@ -239,7 +230,7 @@ The next table lists the effects of receiving an EM message to the receiving Par | $EC$ | $\cdot\cdot\cdot pxa, \lnot C, R$ | $-,-,\xrightarrow{a} A$ | $EK$ | | $ER$ | $*, \lnot C, P$ | $-,-,\xrightarrow{r} N$ | $EK$ | | $ET$ | $*, \lnot C, A$ | $-,-,\xrightarrow{t} X$ | $EK$ | -| $ET$ | $*, \lnot C, R$ | $-,-,\xrightarrow{t} X$ | $EK$ | +| $ET$ | $*, \lnot C, R$ | $-,-,\xrightarrow{t} X$ | $EK$ | | $ET$ | $*, \lnot C, X$ | $-,-,-$ | $EK$ | | $EP$ | $\lnot \cdot\cdot\cdot pxa,\lnot C, N$ | $-,-,-$ | $ER$ | | $EP$ | $\lnot \cdot\cdot\cdot pxa,\lnot C, P$ | $-,-,\xrightarrow{r} N$ | $ER$ | @@ -252,7 +243,6 @@ The next table lists the effects of receiving an EM message to the receiving Par | $EK$ | $*,\lnot C,*$ | $-,-,-$ | $-$ | | Any EM msg. not
addressed above | $*,\lnot C,*$ | $-,-,-$ | $EE$ | - ## CVD Transition Functions !!! tip inline end "Participant-Specific State Messages Promote Shared Situation Awareness" @@ -265,7 +255,7 @@ Therefore, the receiver of a message indicating another Participant has changed status is not expected to change their own state as a result. However, this is not the case for the remainder of the CS substates. -As above, the appropriate Participant response to receiving CS messages (namely, those surrounding *Public Awareness*, +As above, the appropriate Participant response to receiving CS messages (namely, those surrounding *Public Awareness*, *Exploit Public*, or *Attacks Observed*) depends on the state of the EM process. !!! note "" @@ -274,14 +264,13 @@ As above, the appropriate Participant response to receiving CS messages (namely, of publicly available information about the vulnerability or its exploit code. - !!! note "" Participants SHOULD initiate embargo termination upon becoming aware of attacks against an otherwise unpublished vulnerability. !!! note inline end "CS Messages Sent and State Transitions" - + $$S_i \times M_{ij}^{cs} \rightarrow S_i$$ ### CS Messages Sent and State Transitions @@ -289,14 +278,11 @@ As above, the appropriate Participant response to receiving CS messages (namely, The following table lists each CVD message type and the states in which that message is appropriate to send along with the corresponding sender state transition. - - !!! tip "Notes on CS Messages Sent and State Transitions" Note that when a CS message induces a $q^{rm}$ or $q^{em}$ state change, the corresponding RM or EM message should be sent as indicated in the tables above. - | Sender Precondition
$(s_n \in S_i)$
$q^{cs},q^{rm},q^{em}$ | Sender Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Message Type
$\rightharpoonup$
$M_{ij}$ | |:------------------------------------------------------------------:|:-------------------------------------------------------------------------------:|:-----------------------------------------------:| | $vfd \cdot\cdot\cdot,S,*$ | $\xrightarrow{\mathbf{V}} Vfd \cdot\cdot\cdot, \xrightarrow{r} R,-$ | $CV$ | @@ -315,18 +301,15 @@ the corresponding sender state transition. | $\cdot\cdot\cdot\cdot\cdot a,\lnot C,P$ | $\xrightarrow{\mathbf{A}} \cdot\cdot\cdot\cdot\cdot A, -,\xrightarrow{r} N$ | $CA$ | | $\cdot\cdot\cdot\cdot\cdot a,\lnot C,\{A,R\}$ | $\xrightarrow{\mathbf{A}} \cdot\cdot\cdot\cdot\cdot A, -,\xrightarrow{t} X$ | $CA$ | - !!! note inline end "CS Messages Received and State Transitions" $$S_i \times M_{ji}^{cs} \rightarrow S_i$$ - ### CS Messages Received and State Transitions The following table lists the effects of receiving a CS message to the receiving Participant's state coupled with the expected response message. - | Received Msg.
$\leftharpoondown$
$M_{ji}$ | Receiver Precondition
$s_n \in S_i$
$q^{cs},q^{rm},q^{em}$ | Receiver Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Response Msg.
$\rightharpoonup$
$M_{ij}$ | |:-------------------------------------------------:|:------------------------------------------------------------------:|:---------------------------------------------------------------------------------:|:------------------------------------------------:| | $CV$ | $*,\lnot C,*$ | $-,-,-$ | $CK$ | @@ -349,11 +332,10 @@ CS message to the receiving Participant's state coupled with the expected respon | $CE$ | $*,\lnot C,*$ | $-,-,-$ | $CK+GI$ | | $CK$ | $*,\lnot C,*$ | $-,-,-$ | $-$ | - ## General Transition Functions -Finally, for the sake of completeness, we show that general inquiries, acknowledgments, and errors are otherwise independent -of the rest of the processes. +Finally, for the sake of completeness, we show that general inquiries, acknowledgments, and errors are otherwise independent +of the rest of the processes. No state changes are expected to occur based on the receipt of a General message. !!! tip "General Messages are not a *No-Op*" @@ -363,15 +345,13 @@ No state changes are expected to occur based on the receipt of a General message state change to either the sender or receiver Participants. !!! note inline end "General Messages Sent and State Transitions" - + $$S_i \times M_{ij}^{gen} \rightarrow S_i$$ ### General Messages Sent and State Transitions The following table lists each general message and the states in which it is appropriate to send along with the -corresponding sender state. - - +corresponding sender state. | Sender Precondition
$(s_n \in S_i)$
$q^{cs},q^{rm},q^{em}$ | Sender Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Message Type
$\rightharpoonup$
$M_{ij}$ | |:------------------------------------------------------------------:|:-------------------------------------------------------------------------------:|:-----------------------------------------------:| @@ -385,13 +365,11 @@ corresponding sender state. ### General Messages Received and State Transitions -The next table lists the effects of receiving a general message to the receiving Participant's state coupled with the +The next table lists the effects of receiving a general message to the receiving Participant's state coupled with the expected response message. - - | Received Msg.
$\leftharpoondown$
$M_{ji}$ | Receiver Precondition
$s_n \in S_i$
$q^{cs},q^{rm},q^{em}$ | Receiver Transition
$(s_n \xrightarrow{} s_{n+1})$
$q^{cs},q^{rm},q^{em}$ | Response Msg.
$\rightharpoonup$
$M_{ij}$ | |:-------------------------------------------------:|:------------------------------------------------------------------:|:---------------------------------------------------------------------------------:|:------------------------------------------------:| | $GI$ | $*,*,*$ | $-,-,-$ | $GK$ | | $GK$ | $*,*,*$ | $-,-,-$ | $-$ | -| $GE$ | $*,*,*$ | $-,-,-$ | $GI$ | \ No newline at end of file +| $GE$ | $*,*,*$ | $-,-,-$ | $GI$ | diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md index 9ca2b8eb..ce717f5f 100644 --- a/docs/reference/glossary.md +++ b/docs/reference/glossary.md @@ -8,17 +8,14 @@ : Association for Computing Machinery - `AI` : Artificial Intelligence - `API` : Application Programming Interface - `CERT/CC` : CERT Coordination Center at the Software Engineering Institute (SEI) @@ -28,27 +25,22 @@ : Cybersecurity and Infrastructure Security Agency, part of the United States of America (US) Department of Homeland Security (DHS) - `CNA` : Common Vulnerabilities and Exposures (CVE) Numbering Authority CS Coordinated Vulnerability Disclosure (CVD) Case State - `CSAF` : Common Security Advisory Framework by OASIS - `CVD` : Coordinated Vulnerability Disclosure - `CVE` : Common Vulnerabilities and Exposures by The MITRE Corporation (MITRE) - `CVSS` : Common Vulnerability Scoring System, maintained by Forum of Incident Response @@ -57,17 +49,14 @@ : Directed Acyclic Graph - `DFA` : Deterministic Finite Automaton - `DHS` : US Department of Homeland Security - `DTRAP` : Digital Threats: Research and Practice, an Association for Computing @@ -77,10 +66,9 @@ : Embargo Management - `FFRDC` -: Federally Funded Research and Development Center +: Federally Funded Research and Development Center `FIRST` @@ -94,41 +82,33 @@ : Intrusion Detection System - `IETF` : Internet Engineering Task Force - `IPS` : Intrusion Prevention System - `ITSM` : Information Technology Service Management - `JSON` : JavaScript Object Notation - `MITRE` : The MITRE Corporation - `MPCVD` : Multi-Party Coordinated Vulnerability Disclosure - `NDA` : Non-Disclosure Agreement - `NIST` : National Institute of Standards and Technology, part of the US Department of @@ -138,57 +118,46 @@ : Non-Player Character - `OEM` : Original Equipment Manufacturer - `OT` : Operational Technology - `OWL` : Web Ontology Language, a World Wide Web Consortium (W3C) standard - `PoC` : Proof of Concept - `protobuf` : Protocol Buffers - `REST` : Representational State Transfer - `RM` : Report Management - `SAAS` : Software-as-a-Service - `SAML` : Security Assertion Markup Language - `SBOM` : Software Bill of Materials - `SEI` : Software Engineering Institute, a Federally Funded Research and Development Center @@ -198,38 +167,31 @@ : Stakeholder-Specific Vulnerability Categorization - `UML` : Unified Modeling Language - `US` : United States of America - `VDP` : Vulnerability Disclosure Program - `W3C` : World Wide Web Consortium - `XML` : Extensible Markup Language, a W3C standard - `XMPP` -: Extensible Messaging and Presence Protocol, an Internet Engineering Task +: Extensible Messaging and Presence Protocol, an Internet Engineering Task Force (IETF) standard `XSD` : Extensible Markup Language (XML) Schema Definition, a W3C standard - diff --git a/docs/reference/index.md b/docs/reference/index.md index 36c9feb9..611e9eba 100644 --- a/docs/reference/index.md +++ b/docs/reference/index.md @@ -12,10 +12,9 @@ If you are familiar enough with the Vultron Protocol that you're interested in implementing it, see [Implementing Vultron](../howto/index.md). And finally, if you're just trying to understand the CVD process, we recommend that you start with the [CERT Guide to Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD/). - The Vultron Protocol Reference includes the formal Vultron Protocol specification, and crosswalks the protocol with other related standards and protocols, including: - [Formal Protocol](formal_protocol/index.md) - [ISO Crosswalk](iso_crosswalk.md) -- [SSVC Crosswalk](ssvc_crosswalk.md) \ No newline at end of file +- [SSVC Crosswalk](ssvc_crosswalk.md) diff --git a/docs/reference/iso_29147_2018.md b/docs/reference/iso_29147_2018.md index f4bf2a39..3e7cd7a7 100644 --- a/docs/reference/iso_29147_2018.md +++ b/docs/reference/iso_29147_2018.md @@ -9,7 +9,6 @@ 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" @@ -25,13 +24,13 @@ 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.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) +| 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) | @@ -39,7 +38,7 @@ See the table below for a thorough cross-reference. | | 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.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) | diff --git a/docs/reference/iso_30111_2019.md b/docs/reference/iso_30111_2019.md index f52fbcd6..aa5d4123 100644 --- a/docs/reference/iso_30111_2019.md +++ b/docs/reference/iso_30111_2019.md @@ -2,7 +2,7 @@ {% include-markdown "../includes/not_normative.md" %} -Clause 7 of [ISO/IEC 30111:2019](https://www.iso.org/standard/69725.html) +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. @@ -10,7 +10,6 @@ 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 | @@ -18,7 +17,7 @@ The table below provides a mapping of ISO/IEC 30111:2019 onto the relevant conce | 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 | +| 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$ | @@ -32,4 +31,4 @@ The table below provides a mapping of ISO/IEC 30111:2019 onto the relevant conce | 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) | \ No newline at end of file +| 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 index c4cad6af..cda02d56 100644 --- a/docs/reference/iso_5895_2022.md +++ b/docs/reference/iso_5895_2022.md @@ -2,9 +2,9 @@ {% 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. +[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.

@@ -30,4 +30,4 @@ The table below contains our mapping of relevant sections of that technical repo | | 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) | \ No newline at end of file +| 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 index d5598881..16faf4d8 100644 --- a/docs/reference/iso_crosswalk.md +++ b/docs/reference/iso_crosswalk.md @@ -8,5 +8,3 @@ We cross-reference them here to help readers understand how they relate to the V | [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) | - - diff --git a/docs/reference/ssvc_crosswalk.md b/docs/reference/ssvc_crosswalk.md index eadfe29f..1f19525a 100644 --- a/docs/reference/ssvc_crosswalk.md +++ b/docs/reference/ssvc_crosswalk.md @@ -3,8 +3,8 @@ {% include-markdown "../includes/not_normative.md" %} In the context of the Vultron Protocol, once a report has been validated -(i.e., it is in the RM [_Valid_](../topics/process_models/rm/index.md#the-valid-v-state) state, $q^{rm} \in V$), it must be prioritized to -determine what further effort, if any, is necessary. +(i.e., it is in the RM [_Valid_](../topics/process_models/rm/index.md#the-valid-v-state) state, $q^{rm} \in V$), it must be prioritized to +determine what further effort, if any, is necessary. While any prioritization scheme might be used, here we demonstrate an application of the [SSVC](https://github.com/CERTCC/SSVC) model. ## SSVC Supplier and Deployer Trees @@ -31,7 +31,7 @@ the _Deployer Tree_. \end{cases}$$ !!! note "SSVC _Deployer Tree_ Mapping to RM States" - + $$\label{eq:ssvc_deployer_tree_output} q^{rm} \in \begin{cases} @@ -58,7 +58,7 @@ We remind readers of a key takeaway from the protocol requirements in the main part of this documentation: !!! note "" - + Vendors SHOULD communicate their prioritization choices when making either a _defer_ ($\{V,A\} \xrightarrow{d} D$) or _accept_ ($\{V,D\} \xrightarrow{a} A$) transition out of the _Valid_, @@ -85,13 +85,12 @@ Similar to the _Supplier Tree_ mapping above, the mapping here is simple, as sho \end{Bmatrix} \\ \end{cases}$$ - Again, whereas the _Decline_ output maps directly to the RM [_Deferred_](../topics/process_models/rm/index.md#the-deferred-d-state) state, the remaining two states (_Track_ and _Coordinate_) imply the necessity for distinct processes within the Coordinator's RM [_Accepted_](../topics/process_models/rm/index.md#the-accepted-a-state) state. -On the other hand, the SSVC _Coordinator Publish Tree_ falls entirely within the Coordinator's _Accepted_ state, so its +On the other hand, the SSVC _Coordinator Publish Tree_ falls entirely within the Coordinator's _Accepted_ state, so its output does not directly induce any Coordinator RM state transitions. -However, a number of its decision points *do* touch on the protocol models, which we cover next. +However, a number of its decision points _do_ touch on the protocol models, which we cover next. ## SSVC Decision Points and the Vultron Protocol @@ -120,13 +119,12 @@ These values map directly onto state subsets in the [Case State (CS) model](../t A value of _None_ implies that no exploits have been made public, and no attacks have been observed (i.e., $q^{cs} \in \cdot\cdot\cdot\cdot xa$). -The _PoC_ value means that an exploit is public, but no attacks have been observed -(i.e., $q^{cs} \in \cdot\cdot\cdot\cdot Xa$). +The _PoC_ value means that an exploit is public, but no attacks have been observed +(i.e., $q^{cs} \in \cdot\cdot\cdot\cdot Xa$). Finally, the _Active_ value indicates attacks are occurring (i.e., $q^{cs} \in \cdot\cdot\cdot\cdot\cdot A$). These case states and SSVC values are equivalent in both directions, hence our use of the "if-and-only-if" ($\iff$) symbol. - ### Report Public The SSVC _Report Public_ decision point also maps directly onto the [CS model](../topics/process_models/cs/index.md). @@ -144,7 +142,7 @@ As above, "$\iff$" indicates the bidirectional equivalence. ### Supplier Contacted -If the Supplier (Vendor) has been notified (i.e., there is reason to believe they are at least in the RM [_Received_](../topics/process_models/rm/index.md#the-received-r-state) +If the Supplier (Vendor) has been notified (i.e., there is reason to believe they are at least in the RM [_Received_](../topics/process_models/rm/index.md#the-received-r-state) state, equivalent to the $V\cdot\cdot\cdot\cdot\cdot$ CS state subset) the _Supplier Contacted_ value should be _Yes_, otherwise it should be _No_. @@ -157,17 +155,16 @@ otherwise it should be _No_. No & \iff q^{rm}_{Vendor} \in S \text{ or } q^{cs}_{Vendor} \in vfd \cdot\cdot\cdot \\ \end{cases}$$ - ### Report Credibility -Unlike most of the other SSVC decision points covered here that form a part of a Participant's report prioritization -process *after* report validation, the _Report Credibility_ decision point forms an important step in the Coordinator's +Unlike most of the other SSVC decision points covered here that form a part of a Participant's report prioritization +process _after_ report validation, the _Report Credibility_ decision point forms an important step in the Coordinator's validation process. In fact, it is often the only validation step possible when the Coordinator lacks the ability to reproduce a vulnerability whether due to constraints of resources, time, or skill. Thus, a value of _Credible_ can be expected to lead to an RM transition to [_Valid_](../topics/process_models/rm/index.md#the-valid-v-state) ($q^{rm} \in R \xrightarrow{v} V$), -assuming any additional validation checks also pass. -On the contrary, _Not-Credible_ always implies the RM transition to [_Invalid_](../topics/process_models/rm/index.md#the-invalid-i-state) ($q^{rm} \in R \xrightarrow{i} I$) +assuming any additional validation checks also pass. +On the contrary, _Not-Credible_ always implies the RM transition to [_Invalid_](../topics/process_models/rm/index.md#the-invalid-i-state) ($q^{rm} \in R \xrightarrow{i} I$) because "Valid-but-not-Credible" is a contradiction. !!! note "SSVC _Report Credibility_ Decision Point Mapped to RM States" @@ -185,7 +182,7 @@ From the Coordinator's perspective, if enough Suppliers in a CVD case have commu (i.e., enough Vendors are in the RM _Accepted_ state already or are expected to make it there soon from either the _Received_ or _Valid_ states), then the SSVC value would be _Active_. -Vendors in _Invalid_ or _Closed_ can be taken as disengaged, and it might be appropriate to select _Unresponsive_ for +Vendors in _Invalid_ or _Closed_ can be taken as disengaged, and it might be appropriate to select _Unresponsive_ for the SSVC _Engagement_ decision point. Vendors in either _Received_ or _Deferred_ might be either _Active_ or _Unresponsive_, depending on the specific report @@ -322,5 +319,3 @@ graph LR yet to actively engage in the case for whatever reason—as indicated by their failure to reach the RM _Accepted_ state or demonstrate progress toward it by at least getting to RM _Valid_ ($q^{rm} \in \{A,V\}$)—then they can be categorized as _Uncooperative/Unresponsive_. - - diff --git a/docs/topics/background/cvd_success.md b/docs/topics/background/cvd_success.md index e433ace0..a80e64a4 100644 --- a/docs/topics/background/cvd_success.md +++ b/docs/topics/background/cvd_success.md @@ -1,8 +1,7 @@ # What Does *Success* Mean in CVD? - We take as a base set of criteria the ordering preferences given in the -2021 report +2021 report [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://doi.org/10.1184/R1/16416771) by Householder and Spring. @@ -18,7 +17,7 @@ in the lifespan of every vulnerability, shown in the table below. | Fix Deployed | **D** | Attacks Observed | **A** | Our 2021 [report](https://doi.org/10.1184/R1/16416771) -defines a set of 12 ordering preferences over these 6 events. +defines a set of 12 ordering preferences over these 6 events. We present them in roughly descending order of desirability according to the partial order developed in that report. Items closer to the top of the list are indicators of CVD skill. @@ -138,7 +137,6 @@ adversaries are far ahead of defenders. ## Summary - Taken together, these twelve ordering preferences constitute the minimum set of outcomes we hope to facilitate with the Vultron protocol. @@ -148,4 +146,3 @@ set of outcomes we hope to facilitate with the Vultron protocol. | $\mathbf{V} \prec \mathbf{X}$ | $\mathbf{F} \prec \mathbf{X}$ | $\mathbf{D} \prec \mathbf{X}$ | | $\mathbf{V} \prec \mathbf{A}$ | $\mathbf{F} \prec \mathbf{A}$ | $\mathbf{D} \prec \mathbf{A}$ | | $\mathbf{P} \prec \mathbf{X}$ | $\mathbf{P} \prec \mathbf{A}$ | $\mathbf{X} \prec \mathbf{A}$ | - diff --git a/docs/topics/background/index.md b/docs/topics/background/index.md index 73ddbcda..1667b820 100644 --- a/docs/topics/background/index.md +++ b/docs/topics/background/index.md @@ -32,11 +32,11 @@ Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD): Any given CVD case is made up of many individual disclosure events, for example, -- from a Finder to one or more Vendors and/or Coordinators -- from Vendors and Coordinators to other Vendors and Coordinators -- from Finders, Vendors, and Coordinators to Deployers and the Public +- from a Finder to one or more Vendors and/or Coordinators +- from Vendors and Coordinators to other Vendors and Coordinators +- from Finders, Vendors, and Coordinators to Deployers and the Public -In recent years, software supply chains have evolved such that software library and component vulnerabilities have +In recent years, software supply chains have evolved such that software library and component vulnerabilities have become just as much a part of the everyday CVD process as vulnerabilities in Vendors' proprietary code. This means that many CVD cases we encounter require coordination across multiple vendors. As a result, we find it decreasingly useful to differentiate between "traditional" (i.e., two-party) CVD and MPCVD. @@ -44,9 +44,9 @@ In this documentation, we use both terms interchangeably. $$CVD \iff MPCVD$$ -Practically speaking, this means that readers should not infer from our use of _CVD_ in one place that we meant to -exclude the multi-party scenario, nor that our use of _MPCVD_ implies the exclusion of the single-vendor CVD scenario. -Instead, our intent is to construct a protocol that adequately addresses the MPCVD scenario where +Practically speaking, this means that readers should not infer from our use of *CVD* in one place that we meant to +exclude the multi-party scenario, nor that our use of *MPCVD* implies the exclusion of the single-vendor CVD scenario. +Instead, our intent is to construct a protocol that adequately addresses the MPCVD scenario where $N_{vendors} \geq 1$ and for which the "traditional" CVD case is merely a special (and often simpler) case where $N_{vendors} = 1$. @@ -59,21 +59,21 @@ is one of four foundational documents aimed at increasing the professionalization of the CVD process. The following is the full set of foundational documents (thus far): -- *The CERT Guide to Coordinated Vulnerability Disclosure* (the +- *The CERT Guide to Coordinated Vulnerability Disclosure* (the *CVD Guide*) in both its [original](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330) and [updated](https://vuls.cert.org/confluence/display/CVD) forms, provides a "field guide" perspective to the CVD process and its natural extension into MPCVD. -- The [*Stakeholder-Specific Vulnerability Categorization*](https://github.com/CERTCC/SSVC) +- The [*Stakeholder-Specific Vulnerability Categorization*](https://github.com/CERTCC/SSVC) provides decision support for prioritizing vulnerability response activities closely associated with the CVD process. -- [*A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure*](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) - describes a model that encompasses all possible CVD case histories into a set of measures and metrics for the +- [*A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure*](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) + describes a model that encompasses all possible CVD case histories into a set of measures and metrics for the efficacy of CVD processes. That report is an expanded version of [*Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures*](https://dl.acm.org/doi/10.1145/3477431), an article published in the ACM Journal [Digital Threats: Research and Practice](https://dl.acm.org/journal/dtrap). -- *Designing Vultron*, the report on which this documentation was based, proposes an abstract formal protocol for +- *Designing Vultron*, the report on which this documentation was based, proposes an abstract formal protocol for MPCVD, ties together various concepts from all three of the above. Whereas the [*CVD Guide*](https://vuls.cert.org/confluence/display/CVD) offers a narrative description of both the CVD @@ -112,7 +112,7 @@ Both usages are relevant to this effort. First, insofar as we seek to scale the MPCVD process through the use of automation and software-augmented human processes, we wish to propose a formal technical protocol that can serve as the basis of such technical tools. The [Formal Protocol](../../reference/formal_protocol/index.md) section of this documentation addresses this first definition in -specific detail after explicating its component parts and their interactions in +specific detail after explicating its component parts and their interactions in [Report Management](../process_models/rm/index.md), [Embargo Management](../process_models/em/index.md), [Case State](../process_models/cs/index.md), and [Model Interactions](../process_models/model_interactions/index.md). @@ -123,17 +123,16 @@ technical formalities of communicating code but also extend to the expected behaviors of the human Participants that rely on it. In this second sense, we address the term *protocol* in these ways: -- The [*CVD Guide*](https://vuls.cert.org/confluence/display/CVD) +- The [*CVD Guide*](https://vuls.cert.org/confluence/display/CVD) offers a *narrative* protocol for practitioners to follow based on decades of accumulated experience and observation of the CVD process at the CERT/CC. -- The [Case State model](../process_models/cs/index.md) from [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) +- The [Case State model](../process_models/cs/index.md) from [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) offers a *prescriptive* protocol outlining the high-level goals of the CVD process, as derived from a first-principles approach to possible CVD case histories. -- This documentation and the [report](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198) it is based +- This documentation and the [report](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198) it is based on describes a *normative* protocol designed to structure and guide practitioners toward those goals. To that end, we offer this documentation as a proposal for such an MPCVD protocol. - diff --git a/docs/topics/background/interoperability.md b/docs/topics/background/interoperability.md index 61411395..35742b78 100644 --- a/docs/topics/background/interoperability.md +++ b/docs/topics/background/interoperability.md @@ -1,7 +1,7 @@ # The Need for Interoperability in Coordinated Vulnerability Disclosure The overall goal of our Vultron Protocol effort is to achieve *interoperability* among CVD process implementations according to the -broad definition of that term found in the 2004 report, [*Current Perspectives on Interoperability*](https://doi.org/10.1184/R1/6572852.v1) by Brownsword et al.: +broad definition of that term found in the 2004 report, [*Current Perspectives on Interoperability*](https://doi.org/10.1184/R1/6572852.v1) by Brownsword et al.: !!! note inline "Brownsword et al. on *Interoperability*" @@ -20,7 +20,7 @@ If we were to go in the reverse order, we might wind up with systems that exchange data quickly and accurately yet still fail to accomplish the mutually beneficial outcomes that MPCVD sets out to achieve. Carney et al. illustrate the importance of semantic interoperability in their 2005 report -[*Some Current Approaches to Interoperability*](https://doi.org/10.1184/R1/6584258.v1): +[*Some Current Approaches to Interoperability*](https://doi.org/10.1184/R1/6584258.v1): !!! quote "Carney et al. on semantic interoperability" @@ -66,27 +66,27 @@ write, trust: it is better to know that you cannot trust a particular party than to misplace trust in a party -The protocol we propose is intended to promote trust between MPCVD Participants both within an individual case as well +The protocol we propose is intended to promote trust between MPCVD Participants both within an individual case as well as over time and across cases. ## Objectives The objectives of this documentation are as follows: -1. Provide a set of common primitives to serve as an ontological +1. Provide a set of common primitives to serve as an ontological foundation for CVD process definitions across organizations. -2. Construct abstract workflows that support the inter-organizational +2. Construct abstract workflows that support the inter-organizational coordination and synchronization required for the CVD process to be successful. -3. From those primitives and workflows, identify a set of message types +3. From those primitives and workflows, identify a set of message types needed for the CVD process to function. -4. Provide high-level requirements for the semantic content of those +4. Provide high-level requirements for the semantic content of those message types. -5. Explore options for the syntactic representation of those message +5. Explore options for the syntactic representation of those message types. diff --git a/docs/topics/background/notation.md b/docs/topics/background/notation.md index cab3f8c1..62455642 100644 --- a/docs/topics/background/notation.md +++ b/docs/topics/background/notation.md @@ -7,7 +7,7 @@ This page provides a reference for the conventions and notation used throughout ## Documentation Conventions -We are using the [_Admonitions_](https://squidfunk.github.io/mkdocs-material/reference/admonitions/) (call-outs) provided by +We are using the [_Admonitions_](https://squidfunk.github.io/mkdocs-material/reference/admonitions/) (call-outs) provided by [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/) to highlight specific types of information in this documentation. @@ -30,7 +30,7 @@ documentation. Statements in boxes like this are informative notes. They provide additional information that may be helpful in understanding the normative requirements. -!!! tip +!!! tip Statements in boxes like this are tips. They provide additional information that might point to other resources, or provide additional context that may be @@ -54,15 +54,15 @@ documentation. We use this (as you'll see below) as an indicator that a page contains normative content. -!!! warning - +!!! warning + This is a warning. -Material for MkDocs supports a number of other [admonitions](https://squidfunk.github.io/mkdocs-material/reference/admonitions/). +Material for MkDocs supports a number of other [admonitions](https://squidfunk.github.io/mkdocs-material/reference/admonitions/). We're generally trying to keep our usage consistent with the admonition names used in the Material for MkDocs -[documentation](https://squidfunk.github.io/mkdocs-material/reference/admonitions/), but we'd also like to list the +[documentation](https://squidfunk.github.io/mkdocs-material/reference/admonitions/), but we'd also like to list the ones we use here for completeness and clarity. -If you spot us using one that is not listed here, or being inconsistent with the above in our usage, please let us +If you spot us using one that is not listed here, or being inconsistent with the above in our usage, please let us know by [opening an issue](https://github.com/CERTCC/Vultron/issues). ### Normative and Non-Normative Pages @@ -75,7 +75,7 @@ We use the following conventions to indicate whether a page contains normative r {% include-markdown "../../includes/normative.md" %} Pages that contain normative requirements are marked with a banner at or near the top of the page: - + !!! info "Recognizing Non-Normative Pages" {% include-markdown "../../includes/not_normative.md" %} @@ -85,7 +85,6 @@ We use the following conventions to indicate whether a page contains normative r We include it on pages where that may not be clear, for example on pages where we are describing a specific implementation in terms of SHOULD, MUST, MAY, etc. statements, but those statements are not intended to be normative requirements. - ## Mathematical Notation In all of these definitions, we take the standard [Zermelo-Fraenkel set theory](https://en.wikipedia.org/wiki/Zermelo%E2%80%93Fraenkel_set_theory). diff --git a/docs/topics/background/overview.md b/docs/topics/background/overview.md index cffbf6a3..66364a33 100644 --- a/docs/topics/background/overview.md +++ b/docs/topics/background/overview.md @@ -5,12 +5,12 @@ MPCVD is comprised of independent Participants performing their own CVD-related ## Process Models Those processes can be represented by Finte State Machines (FSMs), specifically as Deterministic Finite Automata (DFAs). -CVD processes (and the DFAs representing them) can be decomposed hierarchically. +CVD processes (and the DFAs representing them) can be decomposed hierarchically. We propose three main DFAs as the core of our Vultron Protocol: -1. A [Report Management](../process_models/rm/index.md) DFA represents each CVD Participant's engagement with a particular report -2. An [Embargo Management](../process_models/em/index.md) DFA negotiates and establishes the timing of future disclosures and publications -3. A [Case State](../process_models/cs/index.md) DFA tracks the events in [CVD Substates](../process_models/cs/index.md#cvd-case-substates), +1. A [Report Management](../process_models/rm/index.md) DFA represents each CVD Participant's engagement with a particular report +2. An [Embargo Management](../process_models/em/index.md) DFA negotiates and establishes the timing of future disclosures and publications +3. A [Case State](../process_models/cs/index.md) DFA tracks the events in [CVD Substates](../process_models/cs/index.md#cvd-case-substates), as originally described in [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513). [Model Interactions](../process_models/model_interactions/index.md) contains a discussion of the interactions @@ -18,28 +18,28 @@ among these three state machine models. ## Formal Protocol -However, a set of agents independently executing processes is not coordinated, and if they are not coordinated, +However, a set of agents independently executing processes is not coordinated, and if they are not coordinated, then whatever they are doing does not deserve the name CVD. Hence, there is a need for a protocol to describe the interactions necessary to coordinate these processes. -[Communicating FSMs](https://doi.org/10.1145/322374.322380) provide a formal way to define a communications protocol, which coordinates the activities of +[Communicating FSMs](https://doi.org/10.1145/322374.322380) provide a formal way to define a communications protocol, which coordinates the activities of independent DFAs through the interchange (e.g., sending and receiving) of messages. We map our multiple DFA model onto a formal protocol definition in [Formal Protocol](../../reference/formal_protocol/index.md). -### Behavior Logic +### Behavior Logic An MPCVD protocol needs to do more than just provide formally defined communication mechanisms. It also needs to normalize the expected behaviors and activities that the communication protocol enables. -In this sense, our protocol expands upon -[ISO/IEC 29147:2018](https://www.iso.org/standard/72311.html), +In this sense, our protocol expands upon +[ISO/IEC 29147:2018](https://www.iso.org/standard/72311.html), [ISO/IEC 30111:2019](https://www.iso.org/standard/69725.html), and [ISO/IEC TR 5895:2022](https://www.iso.org/standard/81807.html), which, taken together, provide a high-level normative standard for CVD activities. -Developed in response to the growing complexity of video game Non-Player Character (NPC) Artificial Intelligence (AI) +Developed in response to the growing complexity of video game Non-Player Character (NPC) Artificial Intelligence (AI) Finite State Machines (FSMs), Behavior Trees offer a way to organize and describe agent behaviors in a straightforward, understandable way. -Using Behavior Trees, agent processes can be modeled as sets of behaviors (e.g., pre-conditions, actions, and +Using Behavior Trees, agent processes can be modeled as sets of behaviors (e.g., pre-conditions, actions, and post-conditions) and the logic that joins them together. Today, Behavior Trees are used in video game software to develop realistic NPCs and in robotics to create reactive and adaptive behaviors from autonomous agents. @@ -47,7 +47,7 @@ Behavior Trees offer a high potential for automating complex tasks through a hie actions required to complete those tasks. The behaviors we are interested in modeling are the various CVD activities described in the -[*CVD Guide*](https://vuls.cert.org/confluence/display/CVD) (e.g., find contacts, send reports, validate reports, +[*CVD Guide*](https://vuls.cert.org/confluence/display/CVD) (e.g., find contacts, send reports, validate reports, prioritize reports, create fixes, publish reports, publish fixes, deploy fixes). We use [Behavior Trees](../behavior_logic/index.md) to describe MPCVD Participant activities and their interactions with the [formal protocol](../../reference/formal_protocol/index.md). @@ -69,7 +69,6 @@ Reference material includes *Multi-party coordinated vulnerability disclosure and handling*. - an [SSVC Crosswalk](../../reference/ssvc_crosswalk.md) provides a mapping between the Vultron Protocol and relevant portions of the [Stakeholder Specific Vulnerability Categorization](https://github.com/CERTCC/SSVC) - ([SSVC](https://github.com/CERTCC/SSVC)), a vulnerability response prioritization + ([SSVC](https://github.com/CERTCC/SSVC)), a vulnerability response prioritization model also developed by the CERT/CC - a [Glossary](../../reference/glossary.md) of terms used in this documentation - diff --git a/docs/topics/background/terms.md b/docs/topics/background/terms.md index 830c713b..c7db0395 100644 --- a/docs/topics/background/terms.md +++ b/docs/topics/background/terms.md @@ -4,7 +4,7 @@ Throughout this documentation, we refer to CVD Roles from the [*CERT Guide to Co Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD): !!! info "Finder" - + The individual or organization that identifies the vulnerability !!! info "Reporter" @@ -25,7 +25,7 @@ in [SSVC](https://github.com/CERTCC/SSVC) Version 2 and above. The individual or organization that must deploy a patch or take other remediation action -The *Deployer* role is synonymous with the *User* role in +The *Deployer* role is synonymous with the *User* role in [ISO/IEC 29147:2018](https://www.iso.org/standard/72311.html) and [ISO/IEC 30111:2019](https://www.iso.org/standard/69725.html), @@ -36,7 +36,6 @@ while the other roles are named consistent with those standards. An individual or organization that facilitates the coordinated response process - We also add a new role in this documentation, which we expect to incorporate into a future version of the *CVD Guide*: @@ -45,8 +44,8 @@ into a future version of the *CVD Guide*: An individual or organization that publishes exploits Exploit Publishers might be the same as Finders, Reporters, Coordinators, or -Vendors, but this is not guaranteed. -For example, Vendors that produce tools for Cybersecurity Red Teams might play a combination +Vendors, but this is not guaranteed. +For example, Vendors that produce tools for Cybersecurity Red Teams might play a combination of roles: Finder, Reporter, Vendor, Coordinator, and/or Exploit Publisher. Finally, we have a few additional terms to define: @@ -66,4 +65,3 @@ Finally, we have a few additional terms to define: A diagram showing the relationship between CVD Cases, Participants, and Reports can be found in [Case Object](../../howto/case_object.md). - diff --git a/docs/topics/background/versioning.md b/docs/topics/background/versioning.md index fa53f7d0..f0c07d97 100644 --- a/docs/topics/background/versioning.md +++ b/docs/topics/background/versioning.md @@ -12,12 +12,12 @@ anticipation of future revisions, we have chosen a semantic versioning scheme for the Vultron Protocol. Specifically, Vultron Protocol versions will be assigned according to the format `MAJOR.MINOR.MICRO`, where -- `MAJOR` represents the zero-indexed major version for the release. +- `MAJOR` represents the zero-indexed major version for the release. -- `MINOR` represents a zero-indexed counter for minor releases that +- `MINOR` represents a zero-indexed counter for minor releases that maintain compatibility with their MAJOR version. -- `MICRO` represents an optional zero-indexed micro-version (patch) +- `MICRO` represents an optional zero-indexed micro-version (patch) counter for versions that update a MINOR version. Trailing zero values may be omitted (e.g., `3.1` and `3.1.0` denote the @@ -31,4 +31,3 @@ future use. Because of the early nature of the current protocol, as of this writing, no backward compatibility commitments are made or implied within the `0.x` versions. We anticipate this commitment will change as we get closer to a major release. - diff --git a/docs/topics/behavior_logic/acquire_exploit_bt.md b/docs/topics/behavior_logic/acquire_exploit_bt.md index 9e47bd23..fc073339 100644 --- a/docs/topics/behavior_logic/acquire_exploit_bt.md +++ b/docs/topics/behavior_logic/acquire_exploit_bt.md @@ -1,6 +1,6 @@ # Acquire Exploit Behavior -Some Vendors or other CVD Participants might require a proof-of-concept exploit to accompany an incoming report for it +Some Vendors or other CVD Participants might require a proof-of-concept exploit to accompany an incoming report for it to pass their validation checks. To that end, an Acquire Exploit Behavior Tree is shown below. @@ -44,4 +44,3 @@ privilege. The overall behavior returns *Success* when either an exploit is acquired or when one is not desired and is therefore deferred. It can fail in the scenario where an exploit is desired but not acquired. - diff --git a/docs/topics/behavior_logic/cvd_bt.md b/docs/topics/behavior_logic/cvd_bt.md index ffba0604..d479a900 100644 --- a/docs/topics/behavior_logic/cvd_bt.md +++ b/docs/topics/behavior_logic/cvd_bt.md @@ -24,34 +24,33 @@ flowchart LR The main sequence is comprised of four main tasks: -- (A) [*Discover Vulnerability.*](vuldisco_bt.md) Although not all Participants have the +- (A) [*Discover Vulnerability.*](vuldisco_bt.md) Although not all Participants have the ability or motive to discover vulnerabilities, we include it as a task here to call out its importance to the overall CVD process. This task returns *Success* regardless of whether a vulnerability is found to allow execution to pass to the next task. -- (B) [*Receive Messages*](msg_intro_bt.md). All coordination in CVD between Participants is done through +- (B) [*Receive Messages*](msg_intro_bt.md). All coordination in CVD between Participants is done through the exchange of messages, regardless of how those messages are conveyed, stored, or presented. The receive messages task represents the Participant's response to receiving the various messages defined in the [formal protocol](../../reference/formal_protocol/index.md). Due to the degree of detail required to cover all the various message types, decomposition of this task node is deferred until [later](msg_intro_bt.md) so we can cover the next two items - first. Before we proceed, it is sufficient to know that a new report arriving in the *receive messages* behavior + first. Before we proceed, it is sufficient to know that a new report arriving in the *receive messages* behavior sets $q^{rm} \in S \xrightarrow{r} R$ and returns *Success*. -- (C) [*Report Management*](rm_bt.md). This task embodies the [RM process](../process_models/rm/index.md) +- (C) [*Report Management*](rm_bt.md). This task embodies the [RM process](../process_models/rm/index.md) as integrated into the [formal protocol](../../reference/formal_protocol/index.md). -- (D) [*Embargo Management*](em_bt.md). Similarly, this task represents the +- (D) [*Embargo Management*](em_bt.md). Similarly, this task represents the [EM process](../process_models/em/index.md) as integrated into the [formal protocol](../../reference/formal_protocol/index.md). A further breakdown of a number of CVD tasks that fall outside the scope of the [formal protocol](../../reference/formal_protocol/index.md) can be found in [Do Work](do_work_bt.md). -In that section, we examine a number of behaviors that Participants may include as part of the work they do for reports -in the _Accepted_ RM state ($q^{rm}\in A$). +In that section, we examine a number of behaviors that Participants may include as part of the work they do for reports +in the *Accepted* RM state ($q^{rm}\in A$). Behaviors and state changes resulting from changes to the [CS model](../process_models/cs/index.md) are scattered throughout the other Behavior Trees where relevant. - diff --git a/docs/topics/behavior_logic/deployment_bt.md b/docs/topics/behavior_logic/deployment_bt.md index 81021e17..532add46 100644 --- a/docs/topics/behavior_logic/deployment_bt.md +++ b/docs/topics/behavior_logic/deployment_bt.md @@ -77,12 +77,12 @@ It consists of two subprocesses: prioritize deployment and deploy. The prioritize deployment behavior is shown in (C2) the fallback node in the center of the diagram. The subgoal is for the deployment priority to be established, as indicated by the Deployer's RM state $q^{rm} \in \{D,A\}$. -For example, a Deployer might use the [SSVC Deployer Tree](https://github.com/CERTCC/SSVC) to decide whether (and when) +For example, a Deployer might use the [SSVC Deployer Tree](https://github.com/CERTCC/SSVC) to decide whether (and when) to deploy a fix or mitigation. If the deployment priority evaluation indicates further action is needed, - the report management state is set to $q^{rm} \in A$ -- an $RA$ message is emitted, and +- an $RA$ message is emitted, and - the overall prioritization behavior succeeds Otherwise, when the deployment is *Deferred*, it results in a transition to state $q^{rm} \in D$ and @@ -92,19 +92,18 @@ emission of an $RD$ message. It short-circuits to *Success* if either the deployment is *Deferred* or has already occurred. The main sequence can fire in two cases: -1. when the Deployer is also the Vendor and a fix is ready +1. when the Deployer is also the Vendor and a fix is ready ($q^{cs} \in F$) -2. when the Deployer is not the Vendor but the fix is both ready and +2. when the Deployer is not the Vendor but the fix is both ready and public ($q^{cs} \in P$ and $q^{cs} \in F$) Assuming either of these conditions is met, -- the deploy fix task can run, -- the case status is updated to $q^{cs} \in D$, and +- the deploy fix task can run, +- the case status is updated to $q^{cs} \in D$, and - $CD$ emits on *Success* Should the deployment sequence fail for any reason, a fallback is possible if undeployed mitigations are available. -(D) Finally, returning to the top part of the tree, Participants might choose to monitor the deployment process should they +(D) Finally, returning to the top part of the tree, Participants might choose to monitor the deployment process should they have the need to. - diff --git a/docs/topics/behavior_logic/do_work_bt.md b/docs/topics/behavior_logic/do_work_bt.md index 5a0c3240..0aa344c8 100644 --- a/docs/topics/behavior_logic/do_work_bt.md +++ b/docs/topics/behavior_logic/do_work_bt.md @@ -9,7 +9,7 @@ In this section, we will expand on the set of behaviors shown in the diagram bel !!! tip inline end "Why is this a parallel node?" The *do work* node is a parallel node because it is not necessary for a Participant to complete all of these tasks in order to complete their CVD work. - We intentionally do not specify any *Success* criteria regarding what fraction of its children must succeed. + We intentionally do not specify any *Success* criteria regarding what fraction of its children must succeed. Decisions about which (and how many) of the following tasks are necessary for a Participant to complete work on their $Accepted$ CVD cases are left to the discretion of individual Participants. @@ -40,16 +40,12 @@ flowchart LR Specifically, we will cover the following tasks, each in its own subsection. -- [Deployment](deployment_bt.md) -- [Developing a fix](fix_dev_bt.md) -- [Reporting to others](reporting_bt.md) -- [Publication](publication_bt.md) -- [Monitoring threats](monitor_threats_bt.md) -- [Assigning CVE IDs](id_assignment_bt.md) -- [Acquiring exploits](acquire_exploit_bt.md) +- [Deployment](deployment_bt.md) +- [Developing a fix](fix_dev_bt.md) +- [Reporting to others](reporting_bt.md) +- [Publication](publication_bt.md) +- [Monitoring threats](monitor_threats_bt.md) +- [Assigning CVE IDs](id_assignment_bt.md) +- [Acquiring exploits](acquire_exploit_bt.md) The *other work* task is included as a placeholder for any Participant-specific tasks not represented here. - - - - diff --git a/docs/topics/behavior_logic/em_bt.md b/docs/topics/behavior_logic/em_bt.md index d396a82d..c9ea1238 100644 --- a/docs/topics/behavior_logic/em_bt.md +++ b/docs/topics/behavior_logic/em_bt.md @@ -5,9 +5,9 @@ It follows the state transition function in the [Embargo Management Process Model](../process_models/em/index.md#em-state-transitions). Recall that the EM process begins in the $q^{em} \in N$ state and ends in one of two states: -- in the *eXited* ($q^{em} \in X$) state after having established an +- in the *eXited* ($q^{em} \in X$) state after having established an *Active* embargo, or -- in the *None* ($q^{em} \in N$) state after having exhausted all +- in the *None* ($q^{em} \in N$) state after having exhausted all attempts to reach an agreement ```mermaid @@ -106,7 +106,7 @@ terminates, consistent with - [Terminate Embargo Behavior](em_terminate_bt.md) - [Evaluate Embargo Behavior](em_eval_bt.md) -Otherwise, we continue through each remaining EM state. +Otherwise, we continue through each remaining EM state. (D) When there is no embargo and there are no outstanding proposals ($q^{em} \in N$), the only options are to either stop trying or [propose](em_propose_bt.md) a new embargo. @@ -131,8 +131,7 @@ Otherwise, either the current embargo terms are acceptable, or a new embargo sho The structure of this branch mirrors that of the *Proposed* state discussed above. Again, we check to see if there is cause to [terminate](em_terminate_bt.md) doing so, if needed. If termination is not indicated, we proceed once again to [evaluate the proposed revision](em_eval_bt.md), either accepting -or countering the proposal. +or countering the proposal. When neither of these succeed, the revision is rejected and the EM state returns to $q^{em} \in A$ with the original embargo terms intact. An $EJ$ message conveys this information to the other Participants. - diff --git a/docs/topics/behavior_logic/em_eval_bt.md b/docs/topics/behavior_logic/em_eval_bt.md index edcba2a7..b82ee9fc 100644 --- a/docs/topics/behavior_logic/em_eval_bt.md +++ b/docs/topics/behavior_logic/em_eval_bt.md @@ -37,6 +37,3 @@ In both cases, acceptance leads to an EM state transition to $q^{em} \in A$ and (B) On the other hand, the proposed terms may not be acceptable. In this case, the Participant might be willing to offer a counterproposal. The counterproposal is covered by the [propose](em_propose_bt.md) behavior. - - - diff --git a/docs/topics/behavior_logic/em_propose_bt.md b/docs/topics/behavior_logic/em_propose_bt.md index fe774933..60b8731c 100644 --- a/docs/topics/behavior_logic/em_propose_bt.md +++ b/docs/topics/behavior_logic/em_propose_bt.md @@ -1,6 +1,6 @@ # Propose Embargo Behavior -The Propose Embargo Behavior Tree is shown in the figure below. +The Propose Embargo Behavior Tree is shown in the figure below. ```mermaid --- @@ -49,7 +49,7 @@ It consists of a sequence that begins with (A,B) a check for embargo viability a [Negotiating Embargoes](../process_models/em/negotiating.md). Once the checks succeed, it proceeds to (C) selecting embargo terms to propose. -Implementations of this task might simply draw from a default policy, as in +Implementations of this task might simply draw from a default policy, as in [Default Embargoes](../process_models/em/defaults.md), or it might be a case-specific decision made by a Participant. (D) Embargo terms can be proposed from any of the non-*eXited* states ($q^{em} \in \{N,P,A,R\}$). @@ -57,10 +57,9 @@ Implementations of this task might simply draw from a default policy, as in (D1) If a new or revised embargo has already been proposed ($q^{em} \in \{P,R\}$, the tree then checks whether a counterproposal is desired. Assuming it is not, no proposal is made, and the behavior succeeds. -Otherwise, (D2) proposals from state $q^{em} \in N$ emit $EP$ and transition $q^{em} \xrightarrow{p} P$, +Otherwise, (D2) proposals from state $q^{em} \in N$ emit $EP$ and transition $q^{em} \xrightarrow{p} P$, whereas (D3) those from $q^{em} \in A$ emit $EV$ and move to $q^{em} \xrightarrow{p} R$. Proposals from states $q^{em} \in P$ (D2) or $q^{em} \in R$ (D3) represent counterproposals and, therefore, do not change the EM state. They do, however, emit $EP$ or $EV$ messages as appropriate. - diff --git a/docs/topics/behavior_logic/em_terminate_bt.md b/docs/topics/behavior_logic/em_terminate_bt.md index 4c918502..9dd81cbc 100644 --- a/docs/topics/behavior_logic/em_terminate_bt.md +++ b/docs/topics/behavior_logic/em_terminate_bt.md @@ -63,7 +63,6 @@ Finally, the EM state is updated to *eXited* and an $ET$ message is emitted. - [Threat Monitoring Behavior](monitor_threats_bt.md) - [Message Handling Behavior](msg_intro_bt.md) - The Terminate Embargo Behavior Tree appears in multiple locations in the larger tree. We will encounter it again as a possible response to evidence collected via diff --git a/docs/topics/behavior_logic/fix_dev_bt.md b/docs/topics/behavior_logic/fix_dev_bt.md index 5d3d2880..edd79f10 100644 --- a/docs/topics/behavior_logic/fix_dev_bt.md +++ b/docs/topics/behavior_logic/fix_dev_bt.md @@ -1,6 +1,6 @@ # Fix Development Behavior -The Fix Development Behavior Tree is shown below. +The Fix Development Behavior Tree is shown below. ```mermaid --- @@ -28,8 +28,8 @@ flowchart LR (B) For Vendors, if a fix is ready (i.e., the case is in $q^{cs} \in VF\cdot\cdot\cdot\cdot$), the tree returns *Success*. -(C) Otherwise, engaged Vendors ($q^{rm} \in A$) can +(C) Otherwise, engaged Vendors ($q^{rm} \in A$) can - create fixes -- set $q^{cs} \in Vfd\cdot\cdot\cdot \xrightarrow{\mathbf{F}} VFd\cdot\cdot\cdot$ +- set $q^{cs} \in Vfd\cdot\cdot\cdot \xrightarrow{\mathbf{F}} VFd\cdot\cdot\cdot$ - emit $CF$ upon completion diff --git a/docs/topics/behavior_logic/id_assignment_bt.md b/docs/topics/behavior_logic/id_assignment_bt.md index 32e58638..b27f58f6 100644 --- a/docs/topics/behavior_logic/id_assignment_bt.md +++ b/docs/topics/behavior_logic/id_assignment_bt.md @@ -40,6 +40,5 @@ for assigning an ID](https://www.cve.org/ResourcesSupport/AllResources/CNARules# Otherwise, if the Participant is not a CNA, they will have to [request an ID from a CNA](https://www.cve.org/About/Process). -Should both assignment branches fail, the behavior fails. +Should both assignment branches fail, the behavior fails. Otherwise, as long as one of them succeeds, the behavior succeeds. - diff --git a/docs/topics/behavior_logic/index.md b/docs/topics/behavior_logic/index.md index 10c4f0f0..06cf9ff4 100644 --- a/docs/topics/behavior_logic/index.md +++ b/docs/topics/behavior_logic/index.md @@ -63,7 +63,6 @@ Introduction*](https://arxiv.org/abs/1709.00084). | Loop | ↺ | repeatedly ticks child nodes until an exit condition is met. | | Parallel | ⇉ | ticks all child nodes simultaneously, and returns *Success* when $m$ of $n$ children have returned *Success*. | - A basic Behavior Tree is shown below. When a tree is presented in the vertical orientation, each node's children should be read left to right. In the example below, we see two motifs that come up through the remainder of this section. @@ -71,7 +70,6 @@ On the left side is a Fallback node ($\boxed{?}$), which short-circuits to *Succ Otherwise, some activity will occur in $task_a$ and, assuming that it succeeds, the $postcondition$ is set. As a result, the fallback node ensures that *Success* means that the $postcondition$ is met. - ```mermaid --- title: A Basic Behavior Tree @@ -146,8 +144,6 @@ flowchart LR r2 --> r21 ``` - Behavior Trees are composable—that is, a task node in one tree can be replaced with a more refined Behavior Tree in another. We leverage this feature throughout the remainder of this chapter to describe an agent model for an MPCVD Participant as a set of nested Behavior Trees that reflect the protocol described in the previous chapters. - diff --git a/docs/topics/behavior_logic/monitor_threats_bt.md b/docs/topics/behavior_logic/monitor_threats_bt.md index 24fe5232..d8850c82 100644 --- a/docs/topics/behavior_logic/monitor_threats_bt.md +++ b/docs/topics/behavior_logic/monitor_threats_bt.md @@ -42,17 +42,16 @@ flowchart LR fb --> cs_unchanged ``` - For our purposes, monitoring consists of a set of parallel tasks, any one of which can lead to embargo termination. The three conditions of interest are taken straight from the [embargo exit criteria](../process_models/em/early_termination.md). -- (A) If attacks are observed, the $q^{cs} \xrightarrow{\mathbf{A}} A$ transition occurs, and a $CA$ message is emitted. +- (A) If attacks are observed, the $q^{cs} \xrightarrow{\mathbf{A}} A$ transition occurs, and a $CA$ message is emitted. -- (B) If a public exploit is observed, the $q^{cs} \xrightarrow{\mathbf{X}} X$ transition occurs, and a $CX$ message is emitted. +- (B) If a public exploit is observed, the $q^{cs} \xrightarrow{\mathbf{X}} X$ transition occurs, and a $CX$ message is emitted. In the special case where the exploit is made public prior to the vulnerability itself being made public,[^1] there is an additional $q^{cs} \xrightarrow{\mathbf{P}} P$ transition and $CP$ emission. -- (C) Finally, if the vulnerability information has been made public, then the $q^{cs} \xrightarrow{\mathbf{P}} P$ and emits $CP$. +- (C) Finally, if the vulnerability information has been made public, then the $q^{cs} \xrightarrow{\mathbf{P}} P$ and emits $CP$. In the event that one or more of these events is detected, the [Terminate Embargo Behavior Tree](em_terminate_bt.md) is triggered. diff --git a/docs/topics/behavior_logic/msg_cs_bt.md b/docs/topics/behavior_logic/msg_cs_bt.md index 07ebce92..2a217161 100644 --- a/docs/topics/behavior_logic/msg_cs_bt.md +++ b/docs/topics/behavior_logic/msg_cs_bt.md @@ -36,9 +36,9 @@ flowchart LR We are still working through the children of [Receive Messages](msg_intro_bt.md) behavior tree. And as we've come to expect, a precondition check leads to a fallback node in which CS acknowledgement -messages (_CK_) receive no further attention and return *Success*. +messages (_CK_) receive no further attention and return _Success_. -The main CS message-handling sequence comes next, with all matching incoming messages resulting in emission of an +The main CS message-handling sequence comes next, with all matching incoming messages resulting in emission of an acknowledgment message (_CK_). These messages are presented as sub-trees below: @@ -51,7 +51,6 @@ of an error (_CE_) triggering a general inquiry (_GI_) to seek resolution. Finally, the tree has handled all expected messages, so anything else would result in an error condition and emission of a _CE_ message accordingly. - ## Participant-agnostic CS Status Messages The tree first handles messages indicating a Participant-agnostic CS change. @@ -110,10 +109,9 @@ flowchart LR global_seq -->|A2| terminate ``` - (A1a) Information that the vulnerability has been made public (_CP_) is met -with a transition to the *Public Aware* state in the CS model when -necessary. +with a transition to the _Public Aware_ state in the CS model when +necessary. (A1b) Similarly, information that an exploit has been made public forces both the __X__ and __P__ transitions, as necessary. @@ -133,10 +131,10 @@ termination tree](em_terminate_bt.md). ## Participant-Specific CS Status Messages -Next, we see that messages indicating *Vendor Awareness* (_CV_), *Fix -Readiness* (_CF_), and *Fix Deployed* (_CD_) are treated as mere status +Next, we see that messages indicating _Vendor Awareness_ (_CV_), _Fix +Readiness_ (_CF_), and _Fix Deployed_ (_CD_) are treated as mere status updates for the Participant because they are participant-specific. -They are recognized and acknowledged but trigger no further action directly. +They are recognized and acknowledged but trigger no further action directly. ```mermaid --- @@ -150,10 +148,9 @@ flowchart LR seq --> update_status ``` - Recall from [Model Interactions](../process_models/model_interactions/index.md) and -the [Formal Protocol](../../reference/formal_protocol/index.md) that the +the [Formal Protocol](../../reference/formal_protocol/index.md) that the $vfd\cdot\cdot\cdot \rightarrow \dots \rightarrow VFD\cdot\cdot\cdot$ portion of the CS model is unique to each Vendor Participant, and similarly that the $\cdot\cdot d \cdot\cdot\cdot \rightarrow \cdot\cdot D \cdot\cdot\cdot$ portion is unique to @@ -161,7 +158,5 @@ each Participant in the Deployer role. Therefore, messages representing another Participant's status change for this portion of the CS do not directly affect the receiving Participant's status. This is not to say that the Participant might not choose to take some action based on their knowledge of a -Vendor's (or Deployer's) status. -Rather, such follow-up would be expected to occur as part of the Participant's [*do work* process](do_work_bt.md). - - +Vendor's (or Deployer's) status. +Rather, such follow-up would be expected to occur as part of the Participant's [_do work_ process](do_work_bt.md). diff --git a/docs/topics/behavior_logic/msg_em_bt.md b/docs/topics/behavior_logic/msg_em_bt.md index 8c4a534b..7f84adb6 100644 --- a/docs/topics/behavior_logic/msg_em_bt.md +++ b/docs/topics/behavior_logic/msg_em_bt.md @@ -70,12 +70,11 @@ flowchart LR fb --> emit_ee ``` - It is a child of the fallback node started in [Receiving Messages Behavior](msg_intro_bt.md). -A precondition check for EM message types is followed by a fallback node. -EM acknowledgment messages (_EK_) receive no further attention and return *Success*. +A precondition check for EM message types is followed by a fallback node. +EM acknowledgment messages (_EK_) receive no further attention and return _Success_. -## Messages That Lead to a Simple Acknowledgment. +## Messages That Lead to a Simple Acknowledgment Next is a branch handling all the messages that will result in a simple acknowledgment (_EK_). @@ -83,11 +82,11 @@ Next is a branch handling all the messages that will result in a simple acknowle to resolve the problem. (B) Second are embargo termination messages (_ET_). -If the Participant is already in the EM *eXited* state (_X_), no further action is taken (aside from the _EK_). -Otherwise, if the Participant is in either *Active* or *Revise* EM states, the _ET_ message triggers a state +If the Participant is already in the EM _eXited_ state (_X_), no further action is taken (aside from the _EK_). +Otherwise, if the Participant is in either _Active_ or _Revise_ EM states, the _ET_ message triggers a state transition $q^{em} \xrightarrow{t} X$. -(C) Embargo rejections are handled next in a simple sequence that returns the state from *Proposed* to *None*. +(C) Embargo rejections are handled next in a simple sequence that returns the state from _Proposed_ to _None_. ### Handling Viable Embargo Messages @@ -172,25 +171,25 @@ flowchart LR ``` (D2a) An embargo proposal (_EP_) -results in either a move from *None* to *Proposed* or stays in +results in either a move from _None_ to _Proposed_ or stays in *Proposed*, if that was already the case. (D2b) An embargo acceptance (_EA_) -transitions from *Proposed* to *Active*. +transitions from _Proposed_ to _Active_. (D2c) Similar to the _EP_ behavior, -an embargo revision proposal (_EV_) either moves from *Active* to -*Revise* or stays in *Revise*, as appropriate. +an embargo revision proposal (_EV_) either moves from _Active_ to +*Revise* or stays in _Revise_, as appropriate. (D2d) Finally, we deal with revision rejection (_EJ_) or acceptance (_EC_) when in the *Revise* state. -Climbing back up the tree, we see that *Success* in any of the +Climbing back up the tree, we see that _Success_ in any of the branches in this or the previous paragraph results in an acknowledgment message _EK_. -## Messages That Require More than a Simple Acknowledgment. +## Messages That Require More than a Simple Acknowledgment (E) Returning to the the tree at the top of the page, we come to a branch focused on handling EM messages when an embargo is no longer viable---in other words, when the case has @@ -201,4 +200,3 @@ other messages being emitted. Finally, back at the end of the tree at the top of the page, when no other branch has succeeded, we emit an embargo error (_EE_) message to relay the failure. - diff --git a/docs/topics/behavior_logic/msg_intro_bt.md b/docs/topics/behavior_logic/msg_intro_bt.md index 75009ec2..948768ae 100644 --- a/docs/topics/behavior_logic/msg_intro_bt.md +++ b/docs/topics/behavior_logic/msg_intro_bt.md @@ -61,4 +61,3 @@ process-specific Behavior Tree, which we discuss in the following sections. Although each process-specific behavior is described in a subsection and shown in its own figure, they are all part of the same fallback node shown here. - diff --git a/docs/topics/behavior_logic/msg_other_bt.md b/docs/topics/behavior_logic/msg_other_bt.md index e198d498..b873cfe0 100644 --- a/docs/topics/behavior_logic/msg_other_bt.md +++ b/docs/topics/behavior_logic/msg_other_bt.md @@ -30,9 +30,8 @@ flowchart LR seq2 --> gi_emit_GK ``` -This tree represents the final chunk of the fallback node in the [Receive Messages Behavior](msg_intro_bt.md). +This tree represents the final chunk of the fallback node in the [Receive Messages Behavior](msg_intro_bt.md). And here, for the final time, we see a message type check and that general acknowledgment messages (_GK_) -receive no further attention and return *Success*. -General inquiries (_GI_) get at least an acknowledgment, with any follow-up to be handled by [*do work*](do_work_bt.md). +receive no further attention and return _Success_. +General inquiries (_GI_) get at least an acknowledgment, with any follow-up to be handled by [_do work_](do_work_bt.md). As usual, errors (_GE_) also trigger follow-up inquiries (_GI_) in the interest of resolution. - diff --git a/docs/topics/behavior_logic/msg_rm_bt.md b/docs/topics/behavior_logic/msg_rm_bt.md index e5586856..4d4f3297 100644 --- a/docs/topics/behavior_logic/msg_rm_bt.md +++ b/docs/topics/behavior_logic/msg_rm_bt.md @@ -56,12 +56,12 @@ flowchart LR This tree is a child of the fallback node started in [Receiving Messages Behavior](msg_intro_bt.md). Beginning with a precondition check for any RM message type, the tree proceeds to a fallback node. -RM acknowledgment messages (_RK_) receive no further attention and return *Success*. +RM acknowledgment messages (_RK_) receive no further attention and return _Success_. Next comes the main RM message processing sequence. A fallback node covers three major cases: -- (A) First comes a sequence that handles new reports (_RS_ when +- (A) First comes a sequence that handles new reports (_RS_ when $q^{rm} \in S$). This branch changes the recipient's RM state regardless of the Participant's role. If the Participant happens to @@ -71,11 +71,11 @@ A fallback node covers three major cases: transition from $q^{cs} \in vfd \xrightarrow{\mathbf{V}} Vfd$ and emit a corresponding _CV_ message. -- (B) Next, we see that an RM Error (_RE_) results in the emission +- (B) Next, we see that an RM Error (_RE_) results in the emission of a general inquiry (_GI_) for Participants to sort out what the problem is, along with an _RK_ to acknowledge receipt of the error. -- (C) Finally, recall that the RM process is unique to each +- (C) Finally, recall that the RM process is unique to each CVD Participant, so most of the remaining RM messages are simply informational messages about other Participants' statuses that do not directly @@ -86,4 +86,3 @@ A fallback node covers three major cases: For all three cases, an _RK_ message acknowledges receipt of the message. Any unhandled message results in an _RE_ response, indicating an error. - diff --git a/docs/topics/behavior_logic/publication_bt.md b/docs/topics/behavior_logic/publication_bt.md index 13ad3042..fe7c5379 100644 --- a/docs/topics/behavior_logic/publication_bt.md +++ b/docs/topics/behavior_logic/publication_bt.md @@ -104,10 +104,9 @@ There are separate branches for publishing exploits, fixes, and reports. - (B1a) The publish exploit branch succeeds if either no exploit publication is intended, if it is [intended - and ready](acquire_exploit_bt.md), or if it can be acquired and prepared for publication. + and ready](acquire_exploit_bt.md), or if it can be acquired and prepared for publication. - (B1b) The publish fix branch succeeds if the Participant does not intend to publish a fix (e.g., if they are not the Vendor), if a [fix is ready](fix_dev_bt.md), or if it can be developed and prepared for publication. - (B1c) The publish report branch is the simplest and succeeds if either no publication is intended or if the report is ready to go. Once all three branches have completed, the behavior returns *Success*. - diff --git a/docs/topics/behavior_logic/reporting_bt.md b/docs/topics/behavior_logic/reporting_bt.md index b04ac5a7..954eaa50 100644 --- a/docs/topics/behavior_logic/reporting_bt.md +++ b/docs/topics/behavior_logic/reporting_bt.md @@ -4,7 +4,7 @@ The [*CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org describes the reporting phase as the process of identifying parties that need to be informed about the vulnerability and then notifying them. Reporting only works if the intended recipient has the ability to receive reports, as outlined in -our introduction of the [RM _Received_ state](../process_models/rm/index.md#the-received-r-state). +our introduction of the [RM *Received* state](../process_models/rm/index.md#the-received-r-state). The Reporting Behavior Tree is shown in the figure below. @@ -20,19 +20,19 @@ flowchart LR loop --> notify_others ``` -The tree describes a Participant that performs reporting until either their effort limit is met, or they run out of +The tree describes a Participant that performs reporting until either their effort limit is met, or they run out of Participants to notify. ## Identify Participants Behavior !!! tip inline end "Participant Inclusion Choices are left to Participants" - + Note that we are intentionally avoiding setting any requirements about *who* is relevant to a case. We leave that decision to each Participant's judgment. Further discussion of this topic is available in [Adding Participants](../process_models/em/working_with_others.md). -The Identify Participants Behavior Tree, shown in the following diagram, ends when all relevant parties have been -identified. +The Identify Participants Behavior Tree, shown in the following diagram, ends when all relevant parties have been +identified. Until that condition is met, the Participant can proceed with identifying Vendors, Coordinators, or other parties relevant to the coordination of the case. @@ -108,12 +108,12 @@ flowchart LR Participants Behavior. (B1) The method for choosing the recipient is left unspecified since Participants can prioritize recipients how they see fit. -The process proceeds to (B2a) clean up the eligible recipients list when either the recipient is already believed to be in +The process proceeds to (B2a) clean up the eligible recipients list when either the recipient is already believed to be in $q^{rm} \in R$ or if the effort expended in trying to reach the recipient has exceeded the Participant's limit. Such limits are entirely left to the discretion of each Participant. If the chosen recipient is pruned by this branch, the branch returns *Success*. -If the chosen recipient was not pruned, then the cleanup branch fails and execution transfers to the second branch to +If the chosen recipient was not pruned, then the cleanup branch fails and execution transfers to the second branch to notify the recipient. (B2b) The first step in the notification branch is a check for an existing embargo. @@ -122,7 +122,7 @@ can proceed with notification. Otherwise, in the case of an already active embargo (i.e., $q^{em} \in \{A,R\}$), there is an additional check to ensure that the potential recipient's policy is compatible with any existing embargo. -This check allows for a reporting Participant to skip a recipient if they are likely to cause premature termination of +This check allows for a reporting Participant to skip a recipient if they are likely to cause premature termination of an extant embargo. Once at least one of these checks is passed, the notification sequence proceeds through finding the recipient's contact diff --git a/docs/topics/behavior_logic/rm_bt.md b/docs/topics/behavior_logic/rm_bt.md index 5a17972c..a527938a 100644 --- a/docs/topics/behavior_logic/rm_bt.md +++ b/docs/topics/behavior_logic/rm_bt.md @@ -75,7 +75,7 @@ addresses reports in the *Received* state ($q^{rm} \in R$). The only action to be taken from $q^{rm} \in R$ is to validate the report. We address [report validation](rm_validation_bt.md) shortly, but, for now, it is -sufficient to say that the validate report behavior returns *Success* +sufficient to say that the validate report behavior returns *Success* after moving the report to either *Valid* ($q^{rm} \xrightarrow{v} V$) or *Invalid* ($q^{rm} \xrightarrow{i} I$). @@ -101,4 +101,3 @@ We are taking advantage of the composability of Behavior Trees to simplify the presentation. Behaviors that appear in multiple places can be represented as their own trees. We explore the most relevant of these subtrees in the next few subsections. - diff --git a/docs/topics/behavior_logic/rm_closure_bt.md b/docs/topics/behavior_logic/rm_closure_bt.md index 5a49b27b..c8a01650 100644 --- a/docs/topics/behavior_logic/rm_closure_bt.md +++ b/docs/topics/behavior_logic/rm_closure_bt.md @@ -1,6 +1,6 @@ # Report Closure Behavior -The Report Closure Behavior Tree is shown below. +The Report Closure Behavior Tree is shown below. As usual, the post-condition is checked before proceeding. (A) If the case is already *Closed* ($q^{rm} \in C$), we're done. Otherwise, (B) the main close sequence begins with a check for whether the report closure criteria have been met. @@ -25,5 +25,3 @@ flowchart LR close_to_c["RM → C
(emit RC)"] seq --> close_to_c ``` - - diff --git a/docs/topics/behavior_logic/rm_prioritization_bt.md b/docs/topics/behavior_logic/rm_prioritization_bt.md index f51b066f..47cd16c9 100644 --- a/docs/topics/behavior_logic/rm_prioritization_bt.md +++ b/docs/topics/behavior_logic/rm_prioritization_bt.md @@ -3,7 +3,7 @@ The Report Prioritization Behavior Tree is shown in the figure below. It bears some structural similarity to the Report Validation Behavior Tree just described: An initial post-condition check (A) falls back to the main process (B) leading toward -$accept$, which, in turn, falls back to the deferral process (C). +$accept$, which, in turn, falls back to the deferral process (C). In more detail, (A) if the report is already in either the *Accepted* or *Deferred* states and no new information is available to prompt a change, the behavior ends. @@ -58,7 +58,6 @@ flowchart LR defer_seq --> defer_to_d ``` - Failing that, we enter the main prioritization sequence (B). The preconditions of the main sequence are that either the report has not yet been prioritized out of the *Valid* state ($q^{rm} \in V$) or new diff --git a/docs/topics/behavior_logic/rm_validation_bt.md b/docs/topics/behavior_logic/rm_validation_bt.md index d4037042..69d9fb80 100644 --- a/docs/topics/behavior_logic/rm_validation_bt.md +++ b/docs/topics/behavior_logic/rm_validation_bt.md @@ -56,7 +56,7 @@ the report is in *Received* and its validity has never been evaluated or when the report was originally determined to be *Invalid* but new information is available to prompt reconsideration. The validation process shown here is comprised of two main steps: a credibility check -followed by a validity check as outlined in our introduction of +followed by a validity check as outlined in our introduction of the [Received (R) state](../process_models/rm/index.md#the-received-r-state). As a reminder, a report might be in one of three categories: (a) neither diff --git a/docs/topics/behavior_logic/vuldisco_bt.md b/docs/topics/behavior_logic/vuldisco_bt.md index 071a9365..99baf3ad 100644 --- a/docs/topics/behavior_logic/vuldisco_bt.md +++ b/docs/topics/behavior_logic/vuldisco_bt.md @@ -33,7 +33,6 @@ flowchart LR if_vendor --> cs_to_V ``` - The goal of the Discover Vulnerability Behavior is for the Participant to end up outside of the *Start* state of the Report Management process ($q^{rm} \not \in S$, branch A). @@ -48,6 +47,3 @@ Participant, so the $RS$ message in this situation might be an internal message Should no discovery occur (branch C), the branch returns *Success* so that the parent process in [CVD Behavior Tree](cvd_bt.md) can proceed to receive messages from others. - - - diff --git a/docs/topics/formal_protocol/worked_example.md b/docs/topics/formal_protocol/worked_example.md index 97c59ac2..ce51074a 100644 --- a/docs/topics/formal_protocol/worked_example.md +++ b/docs/topics/formal_protocol/worked_example.md @@ -45,9 +45,11 @@ sequenceDiagram ``` ### Vendor Evaluates Embargo {#sec:vendor_eval_embargo_seq} + In this section, we show a variety of responses a Vendor might have to an embargo proposal. -#### Vendor Accepts Embargo +#### Vendor Accepts Embargo + First is a basic accept sequence in which the Vendor accepts the proposed embargo and tells the Reporter this through an _EA_ message. The Reporter acknowledges this with an _EK_ in response. @@ -69,6 +71,7 @@ sequenceDiagram ``` #### Vendor Rejects Embargo + Next we show a rejected proposal. As above, this is a simple sequence where the Vendor indicates their rejection of the proposal with an _ER_ message, and the Reporter acknowledges this with an _EK_ message. @@ -123,16 +126,14 @@ sequenceDiagram It serves as a good model for cooperation among parties who share an interest in a positive outcome. Finally, the following diagram offers what we think is a better approach than a simple counterproposal. -In this "Accept-then-Counter" sequence, we see that the Vendor initially accepts the Reporter's proposed embargo and -immediately follows up with a revision proposal of their own. +In this "Accept-then-Counter" sequence, we see that the Vendor initially accepts the Reporter's proposed embargo and +immediately follows up with a revision proposal of their own. The difference is that by initially accepting the proposal, the Vendor ensures that they are in an active embargo state before attempting to renegotiate. The sequence shown here is intended to be consistent with the previous discussion surrounding [default embargo strategies](../process_models/em/defaults.md). One might think of this as the "Yes-And" rule for embargo negotiations. - - ```mermaid sequenceDiagram actor Reporter @@ -157,10 +158,12 @@ sequenceDiagram ``` ### Vendor Sets Priority + Here we show two responses from a Vendor in the course of prioritizing a report. #### Vendor Accepts Report -This figure shows a Vendor accepting the report for further work (presumably to develop a patch) with an _RA_ message. + +This figure shows a Vendor accepting the report for further work (presumably to develop a patch) with an _RA_ message. ```mermaid sequenceDiagram @@ -175,7 +178,7 @@ sequenceDiagram #### Vendor Defers Report -On the contrary, this figure shows the Vendor deferring the report with an _RD_ message. +On the contrary, this figure shows the Vendor deferring the report with an _RD_ message. In both cases, the Reporter acknowledges the Vendor's messages with an _RK_ message. ```mermaid @@ -191,7 +194,7 @@ sequenceDiagram ### Coordination With a Coordinator {#sec:coordinating_with_coordinator} -The next two diagrams show the process of a Reporter engaging a Coordinator, who, in turn, engages a Vendor. +The next two diagrams show the process of a Reporter engaging a Coordinator, who, in turn, engages a Vendor. The process begins in the first diagram with the Reporter sending a report along with an embargo proposal to the Coordinator ($RS,EP$). The Coordinator acknowledges receipt with an $RK,EK$ response. After evaluating the proposed embargo, the Coordinator accepts it with an _EA_ message. @@ -229,7 +232,7 @@ sequenceDiagram into a shared space can make the process more efficient. In the next diagram, the Coordinator now acts as a proxy for the Reporter, notifying the Vendor and passing along -the embargo information through an $RS,EP$ message of its own. +the embargo information through an $RS,EP$ message of its own. The Vendor accepts the existing embargo (_EA_) and proceeds to validate (_RV_) and prioritize (_RA_) the report. Relevant responses from the Vendor are passed through to the Reporter. Having accepted the report for further work, the Vendor continues with creating a fix for the reported vulnerability. @@ -278,7 +281,6 @@ sequenceDiagram deactivate Reporter ``` - ### Embargo Teardown, Publish, and Close Any Participant can initiate an embargo teardown. @@ -292,7 +294,6 @@ Recipients of the _ET_ message acknowledge receipt and update their EM state acc We could just as easily have shown the Reporter initiating an embargo teardown because of a leaked media report or the Vendor exiting an embargo early because they had their fix ready sooner than expected. - ```mermaid sequenceDiagram actor Reporter @@ -314,14 +315,13 @@ sequenceDiagram With the recognition that more concise publication scheduling might be needed in some situations, we revisit this concern in [Process Implementation Notes](../../howto/process_implementation.md). - #### Publishing After Embargo Teardown Once the embargo has been exited, any Participant may now publish. In the following figure, we show the Vendor publishing first. They notify the Coordinator that they have published using a _CP_ message to convey that information about the vulnerability -is now public. -The Coordinator relays this information to the Reporter. +is now public. +The Coordinator relays this information to the Reporter. Both the Reporter and the Coordinator publish their own reports shortly thereafter. ```mermaid @@ -354,7 +354,6 @@ sequenceDiagram that there was nothing further to be done. This will not always be the case, nor is it necessary. - #### Closing the Case Having no further work to be done on the case, the Reporter closes their @@ -379,8 +378,3 @@ sequenceDiagram Vendor ->> Coordinator: RC Coordinator -->> Vendor: RK ``` - - - - - diff --git a/docs/topics/future_work/cvd_directory.md b/docs/topics/future_work/cvd_directory.md index a7fd071e..40c10bec 100644 --- a/docs/topics/future_work/cvd_directory.md +++ b/docs/topics/future_work/cvd_directory.md @@ -2,17 +2,17 @@ {% include-markdown "../../includes/not_normative.md" %} -The idea of CVD embargoes implies a means of dividing the world into +The idea of CVD embargoes implies a means of dividing the world into -1. those who belong in the embargo +1. those who belong in the embargo 2. those who do not Because _authentication_ is not the same as _authorization_, we cannot simply rely on knowing who a Participant -is; we also have to be able to identify *why* they are *relevant* to a particular case. +is; we also have to be able to identify _why_ they are _relevant_ to a particular case. -Thus, we must ask: +Thus, we must ask: -!!! question +!!! question How do Participants find other relevant potential Participants to invite to a case? @@ -31,10 +31,10 @@ individual Vendor contact. But in larger MPCVD cases, there are a few entangled problems: -1. It can be difficult and inefficient to collect contact information +1. It can be difficult and inefficient to collect contact information for all possibly relevant parties. -2. Even if contact information is widely available using searchable +2. Even if contact information is widely available using searchable resources, many Vendors' preferred contact methods might preclude automation of mass notification (or require customized integration to ensure interoperability between report senders and receivers). @@ -43,17 +43,17 @@ problems: Others ask for submissions via a customized web form. These and [other examples](https://vuls.cert.org/confluence/display/CVD/4.2+Reporting) hinder the interoperability of MPCVD processes. -3. It is not always clear which *other* Vendors' products contain the +3. It is not always clear which _other_ Vendors' products contain the affected product, which limits the ability for an MPCVD cases to follow the software supply chain. -4. Sometimes vulnerabilities arise in protocols or specifications where +4. Sometimes vulnerabilities arise in protocols or specifications where multiple implementations are affected. It can be difficult to identify Vendors whose products implement specific technologies. Software reverse engineering methods can be used to identify affected products in some cases. -5. At the same time, some Vendors treat their product's subcomponents +5. At the same time, some Vendors treat their product's subcomponents as proprietary close-hold information for competitive advantage; this might happen, for example, with OEM or white label licensing agreements. While it is certainly their prerogative to do so, this desire to @@ -61,7 +61,6 @@ problems: discovery---and therefore disclosure to the Vendor---that a vulnerability affects a product. - !!! tip inline end "For more information" - [FIRST Teams](https://www.first.org/members/teams/) @@ -79,15 +78,15 @@ solicits contributions from the community. But further improvements to MPCVD contact management could be made by standardizing the following: -- contact information records and the APIs to access them +- contact information records and the APIs to access them -- contact methods, including common protocols such as the one we just +- contact methods, including common protocols such as the one we just proposed, in conjunction with common data object models and vocabularies or ontologies -- SBOM publication and aggregation services +- SBOM publication and aggregation services -- mechanisms for Vendors to register their interest in specific +- mechanisms for Vendors to register their interest in specific technologies The last of these suggested improvements is not without its challenges. diff --git a/docs/topics/future_work/index.md b/docs/topics/future_work/index.md index 2a2a20cf..c7be0279 100644 --- a/docs/topics/future_work/index.md +++ b/docs/topics/future_work/index.md @@ -5,9 +5,6 @@ In the following pages you'll find: - A discussion of the need for a [CVD Directory](cvd_directory.md) and some of the difficulties it might pose -- A few ideas to [reward efficient behavior](reward_functions.md) elaborating on the concept of churn in the RM and EM processes -- Brief thoughts on the potential [use of ontologies](ontology.md) for process interoperability +- A few ideas to [reward efficient behavior](reward_functions.md) elaborating on the concept of churn in the RM and EM processes +- Brief thoughts on the potential [use of ontologies](ontology.md) for process interoperability - Ideas for future [modeling and simulation](mod_sim.md) to further improve the MPCVD process - - - diff --git a/docs/topics/future_work/mod_sim.md b/docs/topics/future_work/mod_sim.md index f51f8163..0c4d2612 100644 --- a/docs/topics/future_work/mod_sim.md +++ b/docs/topics/future_work/mod_sim.md @@ -3,17 +3,16 @@ {% include-markdown "../../includes/not_normative.md" %} The [protocol formalisms](../../reference/formal_protocol/index.md) and [Behavior Trees](../behavior_logic/index.md) -provided in this documentation combined with the [CS model](../process_models/cs/index.md) described in +provided in this documentation combined with the [CS model](../process_models/cs/index.md) described in [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) point the way toward improvements in MPCVD modeling and simulation. Given the complexity of the protocol state interactions described in -the [formal protocol](../../reference/formal_protocol/index.md) +the [formal protocol](../../reference/formal_protocol/index.md) and the corresponding behaviors described in [CVD Behaviors](../behavior_logic/cvd_bt.md), we anticipate that modeling and simulation work will continue progressing toward a reference implementation of the protocol we describe here. Furthermore, the [reward functions](reward_functions.md) we outlined can—once fully realized—be used to -evaluate the efficacy of future modifications to the protocol. +evaluate the efficacy of future modifications to the protocol. This effort could, in turn, lead to future improvements and optimizations of the MPCVD process. -The modularity of [Behavior Trees](../behavior_logic/index.md) provides ready ground for simulated experiments to determine what additional +The modularity of [Behavior Trees](../behavior_logic/index.md) provides ready ground for simulated experiments to determine what additional optimizations to the MPCVD process might be made in the future. - diff --git a/docs/topics/future_work/ontology.md b/docs/topics/future_work/ontology.md index cd7a4bde..eaa90bd2 100644 --- a/docs/topics/future_work/ontology.md +++ b/docs/topics/future_work/ontology.md @@ -9,9 +9,9 @@ perform MPCVD around the world every day. Thus, for adoption to occur, it will be necessary to map existing systems and processes into the semantics (and eventually, the syntax) of whatever protocol emerges as a descendant of our proposal. -Combined with the abstract [case class model](../../howto/case_object.md), an ontology (e.g., using +Combined with the abstract [case class model](../../howto/case_object.md), an ontology (e.g., using [OWL](https://www.w3.org/OWL/)) could accelerate -the semantic interoperability between independent Participant processes and tools that we set out to improve at the +the semantic interoperability between independent Participant processes and tools that we set out to improve at the beginning of this effort. ## Related Ontology and Data Definition Work @@ -21,4 +21,4 @@ It is currently unclear how this work might intersect with the NIST opportunity for further collaboration. Also, we recognize that the OASIS [Common Security Advisory Framework](https://oasis-open.github.io/csaf-documentation/) is addressing a different abstraction of a closely related problem (representing vulnerability reports and advisories), -so we believe that there may be some opportunity for collaboration there as well. \ No newline at end of file +so we believe that there may be some opportunity for collaboration there as well. diff --git a/docs/topics/future_work/reward_functions.md b/docs/topics/future_work/reward_functions.md index c388a839..8acf4be5 100644 --- a/docs/topics/future_work/reward_functions.md +++ b/docs/topics/future_work/reward_functions.md @@ -17,22 +17,22 @@ The following sections describe two additional reward functions. ## A Reward Function for Minimizing RM Strings In [RM State Transitions](../process_models/rm/index.md#rm-state-transitions), we described a grammar that generates -RM histories. -The state machine can generate arbitrarily long histories because of the cycles in the state machine graph; +RM histories. +The state machine can generate arbitrarily long histories because of the cycles in the state machine graph; however, we observed that human Participants in any real CVD case would likely check the amount of churn. That sort of reliance on human intervention will not scale as well as a more automatable solution might. As a result, we suggest that future work might produce a reward function that can be used to optimize RM histories. Such a function would need to include the following: -- a preference for shorter paths over longer ones +- a preference for shorter paths over longer ones -- a preference for paths that traverse through $q^{rm} \in A$ over +- a preference for paths that traverse through $q^{rm} \in A$ over ones that do not -- a preference for Vendor attentiveness. +- a preference for Vendor attentiveness. -- a preference for validation accuracy +- a preference for validation accuracy !!! tip "Notes on Vendor attentiveness" @@ -47,7 +47,7 @@ Such a function would need to include the following: $\mathbf{D} \prec \mathbf{A}$ are impossible when the Vendor ignores the report. No reward function should provide incentive for willful Vendor ignorance. - + !!! tip "Notes on validation accuracy" Real vulnerabilities should pass through $q^{rm} \in V$, while bogus reports should pass through $q^{rm} \in I$. @@ -76,22 +76,20 @@ quorum of Participants agree that a Vendor's products are affected even if the Vendor denies it, an opportunity exists to capture this information as part of the case. - - ## A Reward Function for Minimizing EM Strings Similarly, the EM process also has the potential to generate arbitrarily long histories, -as shown in [A Regular Grammar for EM](../process_models/em/index.md#sec:em_grammar). +as shown in [A Regular Grammar for EM](../process_models/em/index.md#sec:em_grammar). Again, reliance on humans to resolve this shortcoming may be acceptable for now; -however, looking to the future, we can imagine a reward function to be optimized. +however, looking to the future, we can imagine a reward function to be optimized. The EM reward function might include the following: -- a preference for short paths +- a preference for short paths -- a preference for quick agreement (i.e., the $a$ transition appearing +- a preference for quick agreement (i.e., the $a$ transition appearing early in the EM history) -- a limit on how long an EM history can get without reaching +- a limit on how long an EM history can get without reaching $q^{em} \in A$ at all (i.e., How many proposal-rejection cycles are tolerable before giving up?) diff --git a/docs/topics/index.md b/docs/topics/index.md index 8fef7950..7fd2144f 100644 --- a/docs/topics/index.md +++ b/docs/topics/index.md @@ -12,7 +12,6 @@ For technical reference, see [Reference](../reference/index.md). If you're just trying to understand the CVD process, we recommend that you start with the [CERT Guide to Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD/). - This section provides an overview of the Vultron Protocol, including: - [Background](background/index.md) @@ -20,4 +19,4 @@ This section provides an overview of the Vultron Protocol, including: - [Formal Protocol overview](formal_protocol/index.md) - [Future Work](future_work/index.md) - [Process Models](process_models/index.md) -- [User Stories](user_stories/index.md) \ No newline at end of file +- [User Stories](user_stories/index.md) diff --git a/docs/topics/process_models/cs/cs_model.md b/docs/topics/process_models/cs/cs_model.md index 2cbc39ac..cbe653f2 100644 --- a/docs/topics/process_models/cs/cs_model.md +++ b/docs/topics/process_models/cs/cs_model.md @@ -3,7 +3,7 @@ {% include-markdown "../../../includes/normative.md" %} Here we complete the definition of the CVD Case State (CS) model begun in the [previous page](index.md). -As a reminder, this model provides a high-level view of the state of a CVD case and is +As a reminder, this model provides a high-level view of the state of a CVD case and is derived from [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513). --- @@ -42,20 +42,18 @@ in the table below. $$D \implies F \implies V$$ CS states can be any combination of statuses, provided that a number of caveats elaborated in -[CS Transitions](#cs-transitions) are met. +[CS Transitions](#cs-transitions) are met. One such caveat worth noting here is that valid states must follow what we call the *Vendor fix path*. - -The reason is causal: For a fix to be deployed (_D_), it must have been ready (_F_) for deployment. -And for it to be ready, the Vendor must have already known (_V_) about the vulnerability. -As a result, valid states must begin with one of the following strings: _vfd_, _Vfd_, _VFd_, or _VFD_. +The reason is causal: For a fix to be deployed (*D*), it must have been ready (*F*) for deployment. +And for it to be ready, the Vendor must have already known (*V*) about the vulnerability. +As a result, valid states must begin with one of the following strings: *vfd*, *Vfd*, *VFd*, or *VFD*. !!! tip inline end "See also" See §2.4 of [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) for an expanded explanation of the *Vendor fix path*. - ```mermaid --- title: Vendor Fix Path @@ -70,7 +68,6 @@ stateDiagram-v2 VFd --> VFD : fix is deployed ``` - The CS model is thus composed of 32 possible states, which we define as $\mathcal{Q}^{cs}$. @@ -97,11 +94,10 @@ composed of 32 possible states, which we define as $\mathcal{Q}^{cs}$. ## CS Start and End States -All vulnerability cases start in the base state _vfdpxa_ in which no +All vulnerability cases start in the base state *vfdpxa* in which no events have occurred. -The lone final state in which all events have occurred is _VFDPXA_. - +The lone final state in which all events have occurred is *VFDPXA*. !!! tip "The Map is not the Territory" @@ -128,12 +124,11 @@ The lone final state in which all events have occurred is _VFDPXA_. words, it remains possible for exploits to be published or attacks to be observed long after the [RM](../rm/index.md) process has closed a case. - We frequently need to refer to subsets of $\mathcal{Q}^{cs}$. To do so, we will use a dot ($\cdot$) to represent a single character wildcard. !!! example "CS Model Wildcard Notation Example" - + For example, $VFdP \cdot \cdot$ refers to the subset of $\mathcal{Q}^{cs}$ in which the Vendor is aware, a fix is ready but not yet deployed, and the public is aware of the vulnerability, yet we are indifferent to whether @@ -157,7 +152,6 @@ implies a set of events corresponding to each specific substate change, which we | **X** | An exploit for a vulnerability is made public | $\cdot\cdot\cdot\cdot x \cdot \xrightarrow{\mathbf{X}} \cdot\cdot\cdot\cdot X \cdot$ | | **A** | Attacks exploiting a vulnerability are observed | $\cdot\cdot\cdot\cdot\cdot a \xrightarrow{\mathbf{A}} \cdot\cdot\cdot\cdot\cdot A$ | - ???+ note inline end "CS Model Input Symbols ($\Sigma^{cs}$) Defined" $$\Sigma^{cs} = \{\mathbf{V},\mathbf{F},\mathbf{D},\mathbf{P},\mathbf{X},\mathbf{A}\}$$ @@ -171,7 +165,6 @@ implies a set of events corresponding to each specific substate change, which we We define the set of symbols for our CS DFA as $\Sigma^{cs}$ at right. - For the CS model, an input symbol $\sigma^{cs} \in \Sigma^{cs}$ is "read" when a Participant observes a change in status (a Vendor is notified and exploit code has been published, etc.). @@ -183,24 +176,24 @@ is poised to ensure eventual consistency with this assumption through the communication of perceived case state across coordinating parties. -### CS Transitions Defined +### CS Transitions Defined Here we define the allowable transitions between states in the CS model. Transitions in the CS model follow a few rules described in detail in §2.4 of [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) which we summarize here: -- Because states correspond to the status of events that have or have +- Because states correspond to the status of events that have or have not occurred, and all state transitions are irreversible (i.e., we assume history is immutable), the result will be an acyclic directed graph of states beginning at $q^{cs}_0={vfdpxa}$ and ending at $\mathcal{F}^{cs}=\{VFDPXA\}$ with allowed transitions as the edges. In practical terms for the CS model, this means there is an arrow - of time from _vfdpxa_ through _VFDPXA_ in which each individual + of time from *vfdpxa* through *VFDPXA* in which each individual state transition changes exactly one letter from lowercase to uppercase. -- The *Vendor fix path* +- The *Vendor fix path* ($vfd \cdot\cdot\cdot \xrightarrow{\mathbf{V}} Vfd \cdot\cdot\cdot \xrightarrow{\mathbf{F}} VFd \cdot\cdot\cdot \xrightarrow{\mathbf{D}} VFD \cdot\cdot\cdot$) is a causal requirement as outlined in [substates](cs_model.md). @@ -219,8 +212,7 @@ stateDiagram-v2 VFD --> [*] ``` - -- Vendors are presumed to know at least as much as the public does; +- Vendors are presumed to know at least as much as the public does; therefore, $v\cdot\cdot P \cdot\cdot$ can only lead to $V\cdot\cdot P \cdot\cdot$. ```mermaid @@ -231,7 +223,6 @@ stateDiagram-v2 vP --> VP ``` - #### Exploit Publication Causes Public Awareness Exploit publication is tantamount to public awareness; therefore, @@ -247,14 +238,12 @@ stateDiagram-v2 Therefore, for all practical purposes, we can simplify the full $pxa \rightarrow PXA$ diagram: - {% include-markdown "./pxa_diagram.md" %} -down to the following: +down to the following: {% include-markdown "./pxa_diagram_simple.md" %} - #### Attacks Do Not Necessarily Cause Public Awareness In this model, attacks observed when a vulnerability is unknown to the @@ -274,12 +263,11 @@ twofold: available to all possible adversaries. Publication, in that case, might assist other adversaries more than it helps defenders. - In other words, although $\cdot\cdot\cdot p \cdot A$ does not require an immediate transition to $\cdot\cdot\cdot P \cdot A$ the way $\cdot\cdot\cdot pX \cdot \xrightarrow{\mathbf{P}} \cdot\cdot\cdot PX \cdot$ does, it does seem plausible that the likelihood of **P** occurring -increases when attacks are occurring. +increases when attacks are occurring. ???+ note "Formalism" @@ -290,7 +278,7 @@ increases when attacks are occurring. P(\mathbf{P} \mid \cdot\cdot\cdot p \cdot A) > P(\mathbf{P} \mid \cdot\cdot\cdot p \cdot a) $$ -Logically, this is a result of there being more ways for the public to discover the vulnerability when attacks are +Logically, this is a result of there being more ways for the public to discover the vulnerability when attacks are happening than when they are not: - For states in $\cdot\cdot\cdot p \cdot a$, public awareness depends on the normal vulnerability discovery and reporting @@ -306,7 +294,6 @@ Hence, the embargo teardown process SHOULD begin, and publication and deployment SHOULD follow as soon as is practical. - ## A Regular Grammar for the CS model Following the complete state machine diagram in above, we can summarize the transition functions of the CS model as a @@ -362,10 +349,9 @@ A diagram of the CS process, including its states and transitions, is shown belo {% include-markdown "./vfdpxa_diagram.md" %} - ## CS Model Fully Defined -In combination, the full definition of the Case State DFA $(\mathcal{Q},q_0,\mathcal{F},\Sigma,\delta)^{cs}$ is shown +In combination, the full definition of the Case State DFA $(\mathcal{Q},q_0,\mathcal{F},\Sigma,\delta)^{cs}$ is shown below. ???+ note "Case State Model $(\mathcal{Q},q_0,\mathcal{F},\Sigma,\delta)^{cs}$ Fully Defined" diff --git a/docs/topics/process_models/cs/index.md b/docs/topics/process_models/cs/index.md index f65633b4..c9c65cbb 100644 --- a/docs/topics/process_models/cs/index.md +++ b/docs/topics/process_models/cs/index.md @@ -2,7 +2,7 @@ {% include-markdown "../../../includes/normative.md" %} -Here we revisit the CS model from [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513). +Here we revisit the CS model from [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513). 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: @@ -26,7 +26,7 @@ prior to defining the Case States in In our model, the state of the world is a specification of the current status of all the events in the vulnerability lifecycle model described in [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513). -We describe the relevant factors as substates below. +We describe the relevant factors as substates below. For notational purposes, each substate status is represented by a letter for that part of the state of the world. For example, _v_ means no Vendor awareness and _V_ means the Vendor is aware. The complete set of status labels is @@ -44,14 +44,14 @@ shown in the table below. ### The _Vendor Awareness_ Substate (_v_, _V_) -The *Vendor Awareness* substate corresponds to *Disclosure* in the +The _Vendor Awareness_ substate corresponds to _Disclosure_ in the Arbaugh, Fithen, and McHugh article, [Windows of Vulnerability: A Case -Study analysis](https://doi.org/10.1109/2.889093) and *vulnerability discovered by -Vendor* in Bilge and Dumitraş's article, [Before we knew it: an +Study analysis](https://doi.org/10.1109/2.889093) and _vulnerability discovered by +Vendor_ in Bilge and Dumitraş's article, [Before we knew it: an empirical study of zero-day attacks in the real world](https://doi.org/10.1145/2382196.2382284). In the interest of model simplicity, we are -not concerned with *how* the Vendor finds out about the vulnerability's +not concerned with _how_ the Vendor finds out about the vulnerability's existence—whether it was found via internal testing, reported within a CVD process, or noticed as the result of incident or malware analysis. @@ -84,14 +84,14 @@ stateDiagram-v2 before *Fix Deployed* in the SAAS mode as well. ### The _Fix Readiness_ Substate (_f_, _F_) - -The *Fix Readiness* substate refers to the Vendor's creation and possession of a fix that *could* be deployed to a -vulnerable system *if* the system owner knew of its existence. + +The _Fix Readiness_ substate refers to the Vendor's creation and possession of a fix that _could_ be deployed to a +vulnerable system _if_ the system owner knew of its existence. Here we differ somewhat from previous models ([1](https://doi.org/10.1109/2.889093), [2](https://doi.org/10.1007/978-1-4419-6967-5_6), and [3](https://doi.org/10.1145/2382196.2382284))—their -models address the *release* of the fix rather than its *readiness* for release. +models address the _release_ of the fix rather than its _readiness_ for release. This distinction is necessary because we are interested in modeling the activities and states leading up to disclosure. -Fix *release* is a goal of the CVD process, whereas fix *readiness* is a significant process milestone along the way. +Fix _release_ is a goal of the CVD process, whereas fix _readiness_ is a significant process milestone along the way. ```mermaid stateDiagram-v2 @@ -101,9 +101,9 @@ stateDiagram-v2 f --> F : fix is ready ``` -### The _Fix Deployed_ Substate (_d_, _D_) +### The _Fix Deployed_ Substate (_d_, _D_) -The *Fix Deployed* substate reflects the deployment status of an +The _Fix Deployed_ substate reflects the deployment status of an existing fix. The model in [A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513) was initially designed to treat this substate as a singular binary state for a case, but we intend to relax that here to reflect a more realistic perspective in which each Deployer maintains @@ -118,17 +118,16 @@ stateDiagram-v2 d --> D : fix is deployed ``` +### The _Public Awareness_ Substate (_p_, _P_) -### The _Public Awareness_ Substate (_p_, _P_) - -The *Public Awareness* substate corresponds to *Publication* in the -Arbaugh, Fithen, and McHugh [article](https://doi.org/10.1109/2.889093), *time of -public disclosure* in Frei et al.'s article [Modeling the Security +The _Public Awareness_ substate corresponds to _Publication_ in the +Arbaugh, Fithen, and McHugh [article](https://doi.org/10.1109/2.889093), _time of +public disclosure_ in Frei et al.'s article [Modeling the Security Ecosystem—The Dynamics of (In)Security](https://doi.org/10.1007/978-1-4419-6967-5_6) and *vulnerability disclosed publicly* in Bilge and Dumitraş's [article](https://doi.org/10.1145/2382196.2382284). The public might find out about a vulnerability through the Vendor's announcement of a fix, a news report about a security breach, a conference presentation by a researcher, or a variety of other means. -As above, we are primarily concerned with the occurrence of the event itself rather than the details of *how* the public +As above, we are primarily concerned with the occurrence of the event itself rather than the details of _how_ the public awareness event arises. ```mermaid @@ -139,9 +138,9 @@ stateDiagram-v2 p --> P : public becomes aware ``` -### The _Exploit Public_ Substate (_x_, _X_) +### The _Exploit Public_ Substate (_x_, _X_) -The *Exploit Public* substate reflects whether the method of exploiting +The _Exploit Public_ substate reflects whether the method of exploiting a vulnerability has been made public in sufficient detail to be reproduced by others. Posting PoC code to a widely available site or including the exploit code in a commonly available exploit tool meets @@ -155,9 +154,9 @@ stateDiagram-v2 x --> X : exploit is public ``` -### The _Attacks Observed_ Substate (_a_, _A_) +### The _Attacks Observed_ Substate (_a_, _A_) -The *Attacks Observed* substate reflects whether attacks have been +The _Attacks Observed_ substate reflects whether attacks have been observed in which the vulnerability was exploited. This substate requires evidence that the vulnerability was exploited; we can then presume the existence of exploit code regardless of its availability to @@ -173,4 +172,3 @@ stateDiagram-v2 A : Attacks Observed (A) a --> A : attacks are observed ``` - diff --git a/docs/topics/process_models/cs/vfdpxa_diagram.md b/docs/topics/process_models/cs/vfdpxa_diagram.md index dc1eeeb4..58a0a697 100644 --- a/docs/topics/process_models/cs/vfdpxa_diagram.md +++ b/docs/topics/process_models/cs/vfdpxa_diagram.md @@ -12,12 +12,12 @@ stateDiagram-v2 vfdpxA --> vfdPxA : P vfdpxA --> vfdpXA : X vfdpXA --> vfdPXA : P - vfdpxa --> Vfdpxa : V - vfdpxA --> VfdpxA : V - vfdPxa --> VfdPxa : V - vfdPXa --> VfdPXa : V - vfdPxA --> VfdPxA : V - vfdPXA --> VfdPXA : V + vfdpxa --> Vfdpxa : V + vfdpxA --> VfdpxA : V + vfdPxa --> VfdPxa : V + vfdPXa --> VfdPXa : V + vfdPxA --> VfdPxA : V + vfdPXA --> VfdPXA : V Vfdpxa --> VfdPxa : P Vfdpxa --> VfdpXa : X VfdpXa --> VfdPXa : P @@ -29,12 +29,12 @@ stateDiagram-v2 VfdPxa --> VfdPXa : X VfdPXa --> VfdPXA : A VfdPxA --> VfdPXA : X - Vfdpxa --> VFdpxa : F - VfdpxA --> VFdpxA : F - VfdPxa --> VFdPxa : F - VfdPXa --> VFdPXa : F - VfdPxA --> VFdPxA : F - VfdPXA --> VFdPXA : F + Vfdpxa --> VFdpxa : F + VfdpxA --> VFdpxA : F + VfdPxa --> VFdPxa : F + VfdPXa --> VFdPXa : F + VfdPxA --> VFdPxA : F + VfdPXA --> VFdPXA : F VFdpxa --> VFdPxa : P VFdpxa --> VFdpXa : X VFdpXa --> VFdPXa : P @@ -46,12 +46,12 @@ stateDiagram-v2 VFdPxa --> VFdPXa : X VFdPXa --> VFdPXA : A VFdPxA --> VFdPXA : X - VFdpxa --> VFDpxa : D - VFdpxA --> VFDpxA : D - VFdPxa --> VFDPxa : D - VFdPXa --> VFDPXa : D - VFdPxA --> VFDPxA : D - VFdPXA --> VFDPXA : D + VFdpxa --> VFDpxa : D + VFdpxA --> VFDpxA : D + VFdPxa --> VFDPxa : D + VFdPXa --> VFDPXa : D + VFdPxA --> VFDPxA : D + VFdPXA --> VFDPXA : D VFDpxa --> VFDPxa : P VFDpxa --> VFDpXa : X VFDpXa --> VFDPXa : P diff --git a/docs/topics/process_models/dfa_notation_definition.md b/docs/topics/process_models/dfa_notation_definition.md index fb02bd1e..6bd4daa4 100644 --- a/docs/topics/process_models/dfa_notation_definition.md +++ b/docs/topics/process_models/dfa_notation_definition.md @@ -1,5 +1,5 @@ ???+ note inline end "DFA Notation Defined" - + A [Deterministic Finite Automaton](https://en.wikipedia.org/wiki/Deterministic_finite_automaton) is defined as a 5-tuple $(\mathcal{Q},q_0,\mathcal{F},\Sigma,\delta)$ where @@ -9,4 +9,3 @@ states. - $\Sigma$ is a finite set of input symbols. - $\delta$ is a transition function of the form $\delta: \mathcal{Q} \times \Sigma \xrightarrow{} \mathcal{Q}$. - diff --git a/docs/topics/process_models/em/defaults.md b/docs/topics/process_models/em/defaults.md index 10cf5aa4..ee3685ab 100644 --- a/docs/topics/process_models/em/defaults.md +++ b/docs/topics/process_models/em/defaults.md @@ -61,7 +61,6 @@ stateDiagram-v2 If neither Sender nor Receiver proposes an embargo, _and_ no policy defaults apply, no embargo SHALL exist. - ### Sender Proposes When Receiver Has No Default Embargo Next, we consider the case where the Sender has a default embargo or otherwise proposes an embargo @@ -86,7 +85,6 @@ stateDiagram-v2 embargo specified by policy, the Receiver SHOULD accept the Sender's proposal. - !!! note "" ???+ note inline end "Formalism" @@ -95,7 +93,6 @@ stateDiagram-v2 The Receiver MAY then propose a revision. - ### Receiver Has Default Embargo, Sender Implies Acceptance The next scenario is where the Receiver has a default embargo specified by @@ -109,7 +106,6 @@ stateDiagram-v2 P --> A : sender accepts ``` - !!! note "" ???+ note inline end "Formalism" @@ -119,7 +115,6 @@ stateDiagram-v2 A Receiver's default embargo specified in its vulnerability disclosure policy SHALL be treated as an initial embargo proposal. - !!! note "" ???+ note inline end "Formalism" @@ -131,8 +126,6 @@ stateDiagram-v2 the Receiver's default embargo SHALL be considered as an accepted proposal. - - ### Sender Proposes an Embargo Longer than the Receiver Default Now we consider the case where the Sender proposes an embargo longer @@ -159,7 +152,6 @@ stateDiagram-v2 $$q^{em} \in N \xrightarrow{p_{receiver}} P \xrightarrow{p_{sender}} P \xrightarrow{a_{receiver}} A \xrightarrow{r_{sender}} R$$ - !!! note "" ???+ note inline end "Formalism" @@ -171,7 +163,6 @@ stateDiagram-v2 The Receiver MAY then *accept* or *reject* the proposed extension. - ### Sender Proposes an Embargo Shorter than the Receiver Default Finally, we reach a common scenario in which the Sender proposes an @@ -198,7 +189,6 @@ stateDiagram-v2 $$q^{em} \in N \xrightarrow{p_{receiver}} P \xrightarrow{p_{sender}} P \xrightarrow{a_{sender}} A \xrightarrow{r_{receiver}} R$$ - !!! note "" ???+ note inline end "Formalism" @@ -242,8 +232,6 @@ to lengthen it. acknowledges the time-dependent informational asymmetry inherent to the CVD process. - - !!! info "A Logical Argument for Accepting the Shortest Proposed Embargo" Perhaps the above reasoning comes across as too Machiavellian for some @@ -335,7 +323,6 @@ to lengthen it. $$\Sigma ( \mathbf{z} ) = min(n,m)$$ - As an example: !!! example "The Shortest Proposed Embargo Wins" diff --git a/docs/topics/process_models/em/early_termination.md b/docs/topics/process_models/em/early_termination.md index 93e53361..cb201b54 100644 --- a/docs/topics/process_models/em/early_termination.md +++ b/docs/topics/process_models/em/early_termination.md @@ -1,16 +1,16 @@ -# Early Termination +# Early Termination {% include-markdown "../../../includes/normative.md" %} Embargoes sometimes terminate prior to the agreed date and time. This is an unavoidable, if inconvenient, fact arising from three main causes: -1. Vulnerability discovery capability is widely distributed across the +1. Vulnerability discovery capability is widely distributed across the world, and not all Finders become cooperative Reporters. -2. Even among otherwise cooperative CVD Participants, leaks sometimes happen. +2. Even among otherwise cooperative CVD Participants, leaks sometimes happen. -3. Adversaries are unconstrained by CVD in their vulnerability discovery, +3. Adversaries are unconstrained by CVD in their vulnerability discovery, exploit code development, and use of exploit code in attacks. ## Be Prepared for Embargo Termination @@ -28,7 +28,6 @@ the same regardless of the cause. As a result, Some reasons to terminate an embargo before the agreed date include the following: - !!! note "" ???+ note inline end "Formalism" @@ -38,7 +37,6 @@ following: Embargoes SHALL terminate immediately when information about the vulnerability becomes public. Public information may include reports of the vulnerability or exploit code. - !!! note "" @@ -66,19 +64,19 @@ given in the [CS model](../cs/cs_model.md#cs-transitions) , where we describe the CS model's transition function. Embargo termination is the set of transitions described in the [EM model](index.md#terminate-embargo). -## Waiting for All Vendors to Reach _Fix Ready_ May Be Impractical. +## Waiting for All Vendors to Reach *Fix Ready* May Be Impractical ???+ note inline end "Fix Ready Definition" $$q^{cs} \in VF\cdot\cdot\cdot\cdot$$ -It is not necessary for all Vendor Participants to reach _Fix Ready_ before publication or embargo termination. +It is not necessary for all Vendor Participants to reach *Fix Ready* before publication or embargo termination. Especially in larger MPCVD cases, there comes a point where the net benefit of waiting for every Vendor to be ready is outweighed by the benefit of delivering a fix to the population that can deploy it. No solid formula for this exists, but factors to consider include -- the market share of the Vendors in _Fix Ready_ ($q^{cs} \in VF \cdot \cdot \cdot \cdot$) compared to +- the market share of the Vendors in *Fix Ready* ($q^{cs} \in VF \cdot \cdot \cdot \cdot$) compared to those that are not ($q^{cs} \in \cdot f \cdot \cdot \cdot \cdot$) - the software supply chain for fix delivery to Deployers - the potential impact to critical infrastructure, public safety/health, or national security @@ -95,4 +93,3 @@ those that are not ($q^{cs} \in \cdot f \cdot \cdot \cdot \cdot$) Participants SHOULD consider the software supply chain for the vulnerability in question when determining an appropriate quorum for release. - diff --git a/docs/topics/process_models/em/index.md b/docs/topics/process_models/em/index.md index 159a56cb..e22ede0a 100644 --- a/docs/topics/process_models/em/index.md +++ b/docs/topics/process_models/em/index.md @@ -10,24 +10,22 @@ relative to the report at hand. Once an embargo has expired, there is no further about the vulnerability. - !!! tip inline end "Reminder" Exploits are information about vulnerabilities too. - CVD case Participants must be able to propose, accept, and reject embargo timing proposals according to their individual needs. Additionally, Participants may want to attempt to gain agreement that enables specific -details about a vulnerability to be shared with other Participants or +details about a vulnerability to be shared with other Participants or made public. Such content considerations are outside the scope of this proposal. We focus our discussion on the *when* of an embargo, not the *what*. {% include-markdown "./embargo_defn.md" %} - + Unlike the [RM](../rm/index.md) model, in which each Participant has their own instance of the -[RM](../rm/index.md) DFA, EM states are a global property of a CVD case. +[RM](../rm/index.md) DFA, EM states are a global property of a CVD case. !!! note "" A CVD case SHALL NOT have more than one active embargo at a time. @@ -60,7 +58,6 @@ stateDiagram-v2 v5 --> v6 ``` - {% include-markdown "./nda-sidebar.md" %} ## EM State Machine @@ -72,7 +69,7 @@ EM model using DFA notation. ### EM States -CVD cases are either subject to an active embargo or they are not. +CVD cases are either subject to an active embargo or they are not. We begin with a simple two-state model for the embargo state: ```mermaid @@ -84,10 +81,10 @@ stateDiagram-v2 ``` However, because embargo management is a process of coordinating across -Participants, it will be useful to distinguish between the _None_ state +Participants, it will be useful to distinguish between the *None* state and an intermediate state in which an embargo has been proposed but not -yet accepted or rejected. We might call this the _None + Proposed_ -state, but we shortened it to _Proposed_. +yet accepted or rejected. We might call this the *None + Proposed* +state, but we shortened it to *Proposed*. ???+ note inline end "EM States ($\mathcal{Q}^{em}$) Defined" @@ -99,12 +96,12 @@ state, but we shortened it to _Proposed_. & e\underline{X}ited \} \end{split}$ -Similarly, we want to be able to discriminate between an _Active_ +Similarly, we want to be able to discriminate between an *Active* embargo state and one in which a revision has been proposed but is not -yet accepted or rejected, which we will denote as the _Active + Revise_ -state, shortened to _Revise_. Finally, we wish to distinguish between -the state in which no embargo has ever been established (_None_), and -the final state after an active embargo has ended (_eXited_). Combining +yet accepted or rejected, which we will denote as the *Active + Revise* +state, shortened to *Revise*. Finally, we wish to distinguish between +the state in which no embargo has ever been established (*None*), and +the final state after an active embargo has ended (*eXited*). Combining these, we get the following set of EM states, which we denote as $\mathcal{Q}^{em}$. @@ -125,7 +122,7 @@ stateDiagram-v2 eXited --> [*] ``` -We address the [state transitions](#em-state-transitions) in detail below. +We address the [state transitions](#em-state-transitions) in detail below. As a reminder, we use the underlined capital letters as shorthand for EM state names later in this documentation. @@ -137,20 +134,18 @@ EM state names later in this documentation. [_Accepted_](../rm/index.md#the-accepted-a-state), and these are independent states. Be sure to check which model a state's shorthand notation is referring to. - -#### Start and Final States. +#### Start and Final States ???+ note inline end "EM Start and Final States Defined" $q^{em}_0 = None$ - + $\mathcal{F}^{em} = \{None,~eXited\}$ -The EM process starts in the _None_ state. The process ends in one of two states: If an -embargo agreement is eventually reached, the EM process ends in the _eXited_ state. -Otherwise, if no agreement is ever reached, the EM process ends in the _None_ state. Formal +The EM process starts in the *None* state. The process ends in one of two states: If an +embargo agreement is eventually reached, the EM process ends in the *eXited* state. +Otherwise, if no agreement is ever reached, the EM process ends in the *None* state. Formal definitions of each are shown in the box at right. - ### EM State Transitions {% include-markdown "./em_dfa_diagram.md" %} @@ -158,22 +153,22 @@ definitions of each are shown in the box at right. The symbols of our EM DFA correspond to the actions that cause transitions between the states: !!! note "" - An embargo MAY be _proposed_. + An embargo MAY be *proposed*. !!! note "" - Once proposed, it MAY be _accepted_ or _rejected_. + Once proposed, it MAY be *accepted* or *rejected*. !!! note "" - Once accepted, revisions MAY be _proposed_, which MAY, in turn, be - _accepted_ or _rejected_. + Once accepted, revisions MAY be *proposed*, which MAY, in turn, be + *accepted* or *rejected*. !!! note "" - Finally, accepted embargoes MUST eventually _terminate_. + Finally, accepted embargoes MUST eventually *terminate*. A summary of the available actions is shown as $\Sigma^{em}$ below. ???+ note "EM Symbols ($\Sigma^{em}$) Defined" - + $$ \begin{split} \Sigma^{em} = \{ ~\underline{p}ropose, @@ -210,7 +205,6 @@ stateDiagram-v2 dots --> [*] ``` - ##### Accept or Reject Embargo Proposal Once proposed, Participants can accept or reject the proposed embargo. @@ -242,7 +236,6 @@ If the newly proposed embargo is accepted, then the old one is abandoned. On the other hand, if the newly proposed embargo is rejected, the old one remains accepted. - ```mermaid stateDiagram-v2 direction LR @@ -266,7 +259,6 @@ stateDiagram-v2 The revision process laid out here ensures that there is no break in active embargo coverage. The existing active embargo remains in effect until it is replaced by an accepted revision proposal. - ##### Terminate Embargo Existing embargoes can terminate due to timer expiration or other reasons discussed in [Early Termination](early_termination.md). @@ -322,22 +314,22 @@ stateDiagram-v2 ``` Due to the numerous loops in the DFA shown in the state machine diagram above, -the EM grammar is capable of generating arbitrarily long strings of _propose_-_propose_ and _propose_-_reject_ +the EM grammar is capable of generating arbitrarily long strings of *propose*-*propose* and *propose*-*reject* histories matching the regular expression `(p*r)*(pa(p*r)*(pa)?t)?`. As an example, here is an exhaustive list of all the possible traces of length seven or fewer: -> _pr_, _pat_, _ppr_, _ppat_, _papt_, _prpr_, _pppr_, _ppppr_, _pprpr_, -> _prppr_, _pappt_, _ppapt_, _pppat_, _papat_, _paprt_, _prpat_, -> _pppppr_, _papppt_, _prpppr_, _ppprpr_, _ppappt_, _pppapt_, _prprpr_, -> _papapt_, _pprppr_, _pappat_, _paprpt_, _prppat_, _prpapt_, _ppaprt_, -> _pprpat_, _ppapat_, _papprt_, _ppppat_, _pprprpr_, _prprppr_, -> _paprppt_, _prpprpr_, _pappprt_, _papppat_, _ppppapt_, _prpaprt_, -> _papappt_, _pappapt_, _pppappt_, _pprpppr_, _pppprpr_, _prppppr_, -> _ppprppr_, _ppapppt_, _ppaprpt_, _papprpt_, _ppapprt_, _ppappat_, -> _prpppat_, _prpapat_, _ppprpat_, _ppppppr_, _pprppat_, _papapat_, -> _paprpat_, _ppapapt_, _prprpat_, _paprprt_, _prppapt_, _pppapat_, -> _pprpapt_, _pppaprt_, _pppppat_, _prpappt_, _papaprt_, _pappppt_ +> *pr*, *pat*, *ppr*, *ppat*, *papt*, *prpr*, *pppr*, *ppppr*, *pprpr*, +> *prppr*, *pappt*, *ppapt*, *pppat*, *papat*, *paprt*, *prpat*, +> *pppppr*, *papppt*, *prpppr*, *ppprpr*, *ppappt*, *pppapt*, *prprpr*, +> *papapt*, *pprppr*, *pappat*, *paprpt*, *prppat*, *prpapt*, *ppaprt*, +> *pprpat*, *ppapat*, *papprt*, *ppppat*, *pprprpr*, *prprppr*, +> *paprppt*, *prpprpr*, *pappprt*, *papppat*, *ppppapt*, *prpaprt*, +> *papappt*, *pappapt*, *pppappt*, *pprpppr*, *pppprpr*, *prppppr*, +> *ppprppr*, *ppapppt*, *ppaprpt*, *papprpt*, *ppapprt*, *ppappat*, +> *prpppat*, *prpapat*, *ppprpat*, *ppppppr*, *pprppat*, *papapat*, +> *paprpat*, *ppapapt*, *prprpat*, *paprprt*, *prppapt*, *pppapat*, +> *pprpapt*, *pppaprt*, *pppppat*, *prpappt*, *papaprt*, *pappppt* However, because EM is a human-oriented scheduling process, our experience suggests that we @@ -348,10 +340,10 @@ potential reward function over EM DFA strings in [Future Work](../../future_work For example, it is often preferable for a Vendor to accept whatever embargo the Reporter initially proposes followed closely by proposing a revision to their preferred timeline than it is for the Vendor and Reporter to ping-pong -proposals and rejections without ever establishing an embargo in the first place. +proposals and rejections without ever establishing an embargo in the first place. In the worst case (i.e., where the Reporter declines to extend their embargo), a short embargo is usually preferable to none at all. -This implies a preference for strings starting with _par_ over strings starting with _ppa_ or _prpa_, among others. +This implies a preference for strings starting with *par* over strings starting with *ppa* or *prpa*, among others. We will come back to this idea in [Default Embargoes](#default-embargoes) and in the [worked protocol example](../../formal_protocol/worked_example.md#vendor-accepts-then-proposes-revision). @@ -378,6 +370,3 @@ Taken together, the complete DFA specification for the EM process is shown below \end{cases} \end{aligned} \end{pmatrix}$ - - - diff --git a/docs/topics/process_models/em/negotiating.md b/docs/topics/process_models/em/negotiating.md index 1af78701..531e82fc 100644 --- a/docs/topics/process_models/em/negotiating.md +++ b/docs/topics/process_models/em/negotiating.md @@ -36,7 +36,7 @@ Counterexamples include their fix delivery or deployment - when a Vendor has deployed a fix but wants to complete their root cause analysis prior to releasing information about the vulnerability. - + !!! note "" CVD Participants MAY *propose* or *accept* a new embargo when the fix @@ -50,7 +50,6 @@ releasing information about the vulnerability. CVD Participants MAY *propose* or *accept* an embargo in all other case states (${q^{cs} \in \cdot\cdot\cdot pxa}$). - ## Asymmetry in Embargo Negotiation Asymmetry is inherent in the CVD process because those who currently have the vulnerability information get to decide @@ -61,12 +60,12 @@ We discuss some ways to improve (but not fully remove) this asymmetry in [Defaul but for now we just need to acknowledge that it exists. !!! note "" - + Participants MAY *accept* or *reject* any proposed embargo as they see fit. !!! note "" - + Receivers SHOULD *accept* any embargo proposed by Reporters. !!! note "" @@ -75,7 +74,7 @@ but for now we just need to acknowledge that it exists. they see fit. !!! note "" - + Participants MAY withdraw (*reject*) their own unaccepted *Proposed* embargo. @@ -98,7 +97,7 @@ is expected. !!! note "" In the absence of an explicit *accept* or *reject* response from a Receiver in a timely manner, the Sender MAY proceed in a manner - consistent with an EM state of _None_ ($q^{em} \in N$). + consistent with an EM state of *None* ($q^{em} \in N$). ## No Embargo means No Embargo @@ -124,8 +123,8 @@ no further obligations. ## Don't Give Up Too Soon -The above notwithstanding, Participants are encouraged to try again, especially when no explicit rejection has been -communicated (i.e., in the _tacitly rejected_ scenario described above). +The above notwithstanding, Participants are encouraged to try again, especially when no explicit rejection has been +communicated (i.e., in the *tacitly rejected* scenario described above). !!! note "" @@ -133,7 +132,6 @@ communicated (i.e., in the _tacitly rejected_ scenario described above). negotiations when prior proposals have been *reject*ed or otherwise failed to achieve *accept*ance. - ## Submitting a Report Before Embargo Negotiations Conclude Participants need not wait for embargo negotiations to conclude before @@ -173,4 +171,3 @@ point, it can be extended with a revision. Participants SHOULD remain flexible in adjusting embargo terms as the case evolves. - diff --git a/docs/topics/process_models/em/principles.md b/docs/topics/process_models/em/principles.md index 7561b548..381da0b1 100644 --- a/docs/topics/process_models/em/principles.md +++ b/docs/topics/process_models/em/principles.md @@ -60,7 +60,6 @@ See [Adding Participants](working_with_others.md) for more information. ## Embargoes are Limited Short-Term Agreements - Given all other facts about a vulnerability report being equal, there are two factors that contribute significantly to the success or failure of an embargo: scale and duration. The more people involved in an @@ -110,7 +109,7 @@ any embargo at all. However, regardless of their choices, Participants should be clear about their status and intentions with other Participants. There are a few good reasons to exit an embargo early. (See [Early Termination](early_termination.md) for more information.) - + !!! note "" Participants MAY propose a new embargo or revision to an existing embargo at any time within the constraints outlined in [Negotiating Embargoes](negotiating.md). @@ -124,7 +123,7 @@ Participants. There are a few good reasons to exit an embargo early. ### Leaving an Embargo is Not Embargo Termination Note that a Participant leaving an embargo is not necessarily the same -as the embargo itself terminating. +as the embargo itself terminating. Embargo termination corresponds to the $q^{em} \in \{A,R\} \xrightarrow{t} X$ transition in the [EM model](index.md) and reflects a consensus among case Participants that the embargo no longer applies. A Participant leaving an *Active* embargo means that the @@ -151,8 +150,7 @@ the leaving Participant is no longer involved in the case. These points imply a need for Participants to track the status of other Participants with respect to their adherence to the embargo and -engagement with the case. - +engagement with the case. ### Leaving an Embargo May Have Consequences @@ -170,8 +168,8 @@ Leaving an embargo early in one case may have repercussions to Participants' wil ## Embargo Termination is Not the Same as Publication -Finally, embargo termination _removes a constraint_ rather than _adding an -obligation_. +Finally, embargo termination *removes a constraint* rather than *adding an +obligation*. !!! note "" Participants SHOULD not publish information about the vulnerability diff --git a/docs/topics/process_models/em/split_merge.md b/docs/topics/process_models/em/split_merge.md index d5574cfa..6c2b83c0 100644 --- a/docs/topics/process_models/em/split_merge.md +++ b/docs/topics/process_models/em/split_merge.md @@ -9,7 +9,7 @@ We discuss the impact of these events on embargoes below. ## Impact of Case Mergers on Embargoes -While relatively rare, it is sometimes necessary for two independent CVD cases to be merged into a single case. +While relatively rare, it is sometimes necessary for two independent CVD cases to be merged into a single case. !!! example "Case Merge Example" @@ -50,7 +50,7 @@ It is also possible that a single case needs to be split into multiple cases aft longer to work through the logistics of delivering deployable fixes to their customers. In such a case, the case Participants might choose to split the case into its respective supply chain cohorts to better coordinate within each group. - + Unlike the relatively simple situation of merging two cases, splitting a case into multiple cases is more complex. Case splits impose a dependency between the new case embargoes because the earlier embargo on one case might reveal the existence of a vulnerability in the products allocated to the later case. @@ -92,4 +92,3 @@ Note that it may not always be possible for the split cases to have different embargo dates without the earlier case revealing the existence of a vulnerability in the products allocated to the later case. For this reason, it is often preferable to avoid case splits entirely. - diff --git a/docs/topics/process_models/em/working_with_others.md b/docs/topics/process_models/em/working_with_others.md index 328a7461..7dc06010 100644 --- a/docs/topics/process_models/em/working_with_others.md +++ b/docs/topics/process_models/em/working_with_others.md @@ -8,15 +8,14 @@ an embargoed case. As anyone who has tried to schedule a meeting with multiple attendees can attest, multi-party scheduling can be difficult. When that schedule must also accommodate work completion schedules for an -MPCVD case, it becomes even harder. In [Default Embargoes](#default-embargoes), +MPCVD case, it becomes even harder. In [Default Embargoes](#default-embargoes), we laid out a heuristic for resolving multiple embargo proposals, _The Shortest Embargo Proposed Wins_. -More specifically, we recommended that Participants *accept* the +More specifically, we recommended that Participants _accept_ the earliest proposed end date and immediately propose and evaluate the rest as potential revisions. This principle applies to any MPCVD case, even at its outset. - ## Start Early, Start Small Embargo negotiations can become contentious in larger cases. Many @@ -131,25 +130,25 @@ the new Participant to accept the embargo prior to receiving the report. In MPCVD there are practical considerations to be made regarding the timing of *when* to notify individual Participants. The primary factor in these decisions -stems from the interaction of the *Active* embargo with the potential +stems from the interaction of the _Active_ embargo with the potential Participant's existing (explicit or implicit) disclosure policy. -### Participants with Disclosure Policies Shorter Than an Existing Embargo. +### Participants with Disclosure Policies Shorter Than an Existing Embargo Adding a potential Participant with a known default disclosure policy *shorter* than an extant embargo leaves Participants with these options to choose from: -1. Shorten the existing embargo to match the potential Participant's +1. Shorten the existing embargo to match the potential Participant's policy. -2. Propose the existing embargo to the potential Participant, and, upon +2. Propose the existing embargo to the potential Participant, and, upon acceptance, share the report with them. -3. Delay notifying the potential Participant until their default policy +3. Delay notifying the potential Participant until their default policy aligns with the existing embargo. -4. Avoid including the potential Participant in the embargo entirely. +4. Avoid including the potential Participant in the embargo entirely. !!! example "Example: A Vendor with a short default embargo" @@ -168,27 +167,27 @@ to choose from: Participants with short default embargo policies until their policy aligns with the agreed embargo. -### Participants with Disclosure Policies Longer Than an Existing Embargo. +### Participants with Disclosure Policies Longer Than an Existing Embargo Similarly, adding a Participant with a known default disclosure policy *longer* than an extant embargo leaves Participants with the following options to choose from: -1. Lengthen the existing embargo to match the potential Participant's +1. Lengthen the existing embargo to match the potential Participant's policy. -2. Propose the existing embargo to the potential Participant, and, upon +2. Propose the existing embargo to the potential Participant, and, upon acceptance, share the report with them. -3. Avoid including the potential Participant in the embargo entirely. +3. Avoid including the potential Participant in the embargo entirely. -In the case of a Vendor with a *longer* default policy than the existing +In the case of a Vendor with a _longer_ default policy than the existing embargo, it is still preferable to give them as much lead time as -possible *even* if it is not possible to extend the embargo to their +possible _even_ if it is not possible to extend the embargo to their preferred timing. !!! note "" - + In the interest of receiving the report in the first place, potential Participants with a longer default policy than an existing case SHOULD accept the embargo terms offered. @@ -215,10 +214,10 @@ preferred timing. Participants in a case with an existing embargo MAY choose to extend the embargo to accommodate a newly added Participant. -### Untrustworthy Participants. +### Untrustworthy Participants Unfortunately, not all potential CVD Participants are equally trustworthy with -vulnerability information. +vulnerability information. !!! example "Examples of Untrustworthy Participants" @@ -233,7 +232,6 @@ vulnerability information. trustworthy with non-public vulnerability information. In these or similar scenarios, these concerns might lead to the exclusion of otherwise trustworthy Participants from an embargo. - !!! note "" @@ -254,7 +252,7 @@ Participants are left to be notified by the publication of the vulnerability report. This is the equivalent of treating them like a Participant with a default zero-day maximum embargo policy. -### Coordinators. +### Coordinators Third-party Coordinators, as Participants who are neither Finders nor Vendors, often play an important role in MPCVD cases, especially those with broad impact @@ -267,7 +265,7 @@ make the argument for including third-party Coordinators in CVD cases of sufficient complexity, impact, or importance. -### Other Parties. +### Other Parties Some Participants in CVD have their own policies that prohibit notification of any parties unable to directly contribute to the development of a fix for a particular vulnerability. @@ -279,22 +277,22 @@ coordinate the response within that community. However, it falls short in some cases, such as the following: -- Vulnerabilities are found to affect a broad spectrum of Vendors and +- Vulnerabilities are found to affect a broad spectrum of Vendors and products, especially when cases cross industry sectors or otherwise include Participants having widely divergent operational tempos or software delivery models. -- Vulnerabilities affect systems deployed in high-impact niches, such +- Vulnerabilities affect systems deployed in high-impact niches, such as critical infrastructure, public safety, and national security. -- Outside expertise is needed to understand the implications or impact +- Outside expertise is needed to understand the implications or impact of a vulnerability beyond the participating Vendors; sometimes the most knowledgeable parties work for someone else. ## Consequences of Non-Compliance Considering multiple cases over time, MPCVD can be thought of as an [iterated game](https://vuls.cert.org/confluence/display/CVD/5.5+Response+Pacing+and+Synchronization) analogous to the Prisoner's Dilemma. -One notable strategy for the Prisoner's Dilemma is *tit for tat* in which non-cooperation from one party in one round +One notable strategy for the Prisoner's Dilemma is _tit for tat_ in which non-cooperation from one party in one round can be met with non-cooperation from the opposite party in the next. While MPCVD is usually much bigger than a toy two-player game, we feel it is necessary to encode the possibility that non-cooperation will have downstream consequences. @@ -303,4 +301,3 @@ non-cooperation will have downstream consequences. Participants MAY decline to participate in future CVD cases involving parties with a history of violating previous embargoes. - diff --git a/docs/topics/process_models/index.md b/docs/topics/process_models/index.md index 8df56b06..b154f4eb 100644 --- a/docs/topics/process_models/index.md +++ b/docs/topics/process_models/index.md @@ -57,8 +57,6 @@ graph LR Agent2 --> Agent1 ``` - - ## [Report Management process](rm/index.md) {% include-markdown "./rm/index.md" start="" end="" %} @@ -81,4 +79,4 @@ graph LR {% include-markdown "./model_interactions/cs_global_local.md" %} -[Read More...](cs/index.md) \ No newline at end of file +[Read More...](cs/index.md) diff --git a/docs/topics/process_models/model_interactions/index.md b/docs/topics/process_models/model_interactions/index.md index 3d941a06..fce82ab6 100644 --- a/docs/topics/process_models/model_interactions/index.md +++ b/docs/topics/process_models/model_interactions/index.md @@ -21,8 +21,7 @@ Specifically, the [RM](../rm/index.md) process is unique to each Participant, wh The [CS](../cs/index.md) process is a hybrid: some aspects are Participant-agnostic, while others are Participant-specific, which we will discuss in more detail below. - -Interactions between all these processes affect the overall MPCVD process for a case. +Interactions between all these processes affect the overall MPCVD process for a case. The following diagram illustrates this distinction. ```mermaid @@ -46,7 +45,7 @@ stateDiagram-v2 PS --> PA ``` -### Global vs. Participant-Specific Aspects of the CS Model. +### Global vs. Participant-Specific Aspects of the CS Model The [CS model](../cs/index.md) encompasses both Participant-specific and Participant-agnostic aspects of a CVD case. In particular, the Vendor fix path substates—Vendor unaware (_vfd_), @@ -65,7 +64,7 @@ important in the [Formal Protocol](../../formal_protocol/index.md) definition. Participant-agnostic aspects of the MPCVD process are those that represent facts about the world with respect to a case. - + !!! example "Participant-Agnostic Examples" - The [Embargo Management](../em/index.md) process is global to all Participants in a case @@ -80,4 +79,3 @@ important in the [Formal Protocol](../../formal_protocol/index.md) definition. - The [Report Management](../rm/index.md) process is unique to each Participant. - So is the Vendor Fix Path portion of the [Case State](../cs/index.md) process. - diff --git a/docs/topics/process_models/model_interactions/rm_em.md b/docs/topics/process_models/model_interactions/rm_em.md index 5f614b67..47c0355e 100644 --- a/docs/topics/process_models/model_interactions/rm_em.md +++ b/docs/topics/process_models/model_interactions/rm_em.md @@ -45,7 +45,6 @@ stateDiagram-v2 If it has not already begun, the [EM](../em/index.md) process SHOULD begin when a recipient is in RM _Received_ ($q^{rm} \in R$) whenever possible. - ```mermaid stateDiagram-v2 direction LR @@ -98,7 +97,6 @@ stateDiagram-v2 RM --> EM : avoid ``` - ## Negotiate Embargoes Through Validation and Prioritization !!! note "" @@ -108,7 +106,6 @@ stateDiagram-v2 prioritization ($q^{rm} \in V \xrightarrow{\{a,d\}} \{A,D\}$) activities. - ## Renegotiate Embargoes While Reports Are Valid Yet Unclosed !!! note "" @@ -134,7 +131,7 @@ stateDiagram-v2 RM --> EM : ok to
proceed ``` -## Avoid Embargoes for Invalid Reports... +## Avoid Embargoes for Invalid Reports !!! note "" @@ -281,11 +278,10 @@ Notwithstanding the above, in force ($q^{em} \in \{A,R\}$) SHOULD communicate their intent to either continue to adhere to the embargo or terminate their compliance with it. - Report closure or deferral alone does not terminate an embargo. !!! note "" - + A Participant's closure or deferral ($q^{rm} \in \{C,D\}$) of a report while an embargo remains active ($q^{em} \in \{A,R\}$) and while other Participants remain engaged ($q^{rm} \in \{R,V,A\}$) SHALL NOT @@ -305,9 +301,9 @@ state RM { } RM --> EM : does not imply ``` - + It is expected that Participants will continue to adhere to the embargo until it is explicitly terminated. -However, +However, !!! note "" @@ -325,4 +321,4 @@ so that they can make informed decisions about the viability of the extant embar !!! note "" Upon receipt of a Participant's notification of intent to end their compliance with an embargo, - other Participants MAY choose to terminate the embargo. \ No newline at end of file + other Participants MAY choose to terminate the embargo. diff --git a/docs/topics/process_models/model_interactions/rm_em_cs.md b/docs/topics/process_models/model_interactions/rm_em_cs.md index 2d64b58c..b2f81e03 100644 --- a/docs/topics/process_models/model_interactions/rm_em_cs.md +++ b/docs/topics/process_models/model_interactions/rm_em_cs.md @@ -2,22 +2,19 @@ {% include-markdown "../../../includes/normative.md" %} - The [RM](../rm/index.md) and [EM](../em/index.md) models interact with the [Case State Model](../cs/index.md). -Here we will review the constraints arising from the interaction of the [RM](../rm/index.md) and [EM](../em/index.md) +Here we will review the constraints arising from the interaction of the [RM](../rm/index.md) and [EM](../em/index.md) models with each of the CS transition events represented by its symbols. We have organized this page according to how each CS model [substate](../cs/index.md) interacts with the [RM](../rm/index.md) and [EM](../em/index.md) models. - ???+ note inline end "CS Transition Symbols Defined" $\Sigma^{cs} = \{ \mathbf{V},~\mathbf{F},~\mathbf{D},~\mathbf{P},~\mathbf{X},~\mathbf{A} \}$ As a reminder, a list of the CS model transition symbols is reproduced in the inset at right. - ## Vendor Notification ???+ note inline end "Vendor Notification Formalized" @@ -26,7 +23,6 @@ As a reminder, a list of the CS model transition symbols is reproduced in the in $$q^{cs} \in vfd\cdot\cdot\cdot \xrightarrow{\mathbf{V}} Vfd\cdot\cdot\cdot$$ - Vendor Awareness (**V**) occurs when a Participant—typically a Finder, Coordinator, or another Vendor—is in RM _Accepted_ and notifies the Vendor. In turn, the Vendor starts in $q^{rm} = Received$ and proceeds to follow their validation and prioritization routines. @@ -72,7 +68,6 @@ need to engage with a new Vendor on the case. The latter example is consistent with [public narratives](https://www.techtarget.com/searchsecurity/news/252446638/Meltdown-and-Spectre-disclosure-suffered-extraordinary-miscommunication) about the Meltdown/Spectre vulnerabilities. - !!! note "" Once a case has reached $q^{cs} \in Vfdpxa$ for at least one Vendor, @@ -110,7 +105,7 @@ stateDiagram-v2 ``` ???+ note "Embargo Effects of Vendor Awareness Formalized" - + $$q^{cs} \in Vfdpxa \implies q^{em} \in \begin{cases} None \xrightarrow{propose} Proposed \\ @@ -168,7 +163,7 @@ stateDiagram-v2 CS --> EM: implies ``` -???+ note "Embargo Effects of Fix Readiness Formalized" +???+ note "Embargo Effects of Fix Readiness Formalized" $$q^{cs} \in VF\cdot pxa \implies q^{em} \in \begin{cases} @@ -179,7 +174,7 @@ stateDiagram-v2 \end{cases}$$ !!! note "" - + In MPCVD cases, where some Vendors are likely to reach $q^{cs} \in VF\cdot\cdot\cdot\cdot$ before others, @@ -214,7 +209,7 @@ stateDiagram-v2 ``` For vulnerabilities in systems whose software delivery model dictates that Public Awareness must precede -Deployment ($\mathbf{P} \prec \mathbf{D}$), the Vendor status at the time of deployment might be +Deployment ($\mathbf{P} \prec \mathbf{D}$), the Vendor status at the time of deployment might be irrelevant—assuming, of course, that they at least passed through $q^{rm} = Accepted$ at some point as is required for Fix Ready (**F**), which, in turn, is a prerequisite for deployment (**D**). @@ -263,8 +258,8 @@ stateDiagram-v2 Revise \xrightarrow{terminate} eXited \\ \end{cases}$$ -As with the *Fix Ready* scenario [above](#sec:cs_f_em), MPCVD cases may have Vendors in varying states of *Fix Deployment*. -Therefore the embargo extension caveats from that section apply to the *Fix Deployed* state as well. +As with the _Fix Ready_ scenario [above](#sec:cs_f_em), MPCVD cases may have Vendors in varying states of _Fix Deployment_. +Therefore the embargo extension caveats from that section apply to the _Fix Deployed_ state as well. ## Public Awareness @@ -272,10 +267,10 @@ Within the context of a coordinated publication process, (**P**) requires at least one Participant to be in the $q^{rm} = Accepted$ state because Participants are presumed to publish only on cases they have accepted. Ideally, the Vendor is among those Participants, but as -outlined in the [*CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD), +outlined in the [_CERT Guide to Coordinated Vulnerability Disclosure_](https://vuls.cert.org/confluence/display/CVD), that is not strictly necessary. -That said, the publishing party might be outside of *any* existing +That said, the publishing party might be outside of _any_ existing coordination process. For example, this is the situation when a report is already in the midst of a CVD process and a party outside the CVD case reveals the vulnerability publicly (e.g., parallel discovery, embargo leaks). @@ -340,8 +335,8 @@ That said, SHOULD comply with the protocol described here, especially when they also fulfill other roles (e.g., Finder, Reporter, Coordinator, Vendor) in the process. -For example, as described in -[A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513), +For example, as described in +[A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=735513), the preference for $\mathbf{P} \prec \mathbf{X}$ dictates that !!! note "" @@ -433,7 +428,7 @@ not imply widespread adversary knowledge of the vulnerability. In such scenarios, it is possible that early embargo termination—leading to publication—might be of more assistance to other adversaries than it is to defenders. Thus, we need to allow room for Participant judgment based on their case-specific situation awareness. -Formally, +Formally, !!! note "" @@ -442,7 +437,6 @@ Formally, - New embargoes SHALL NOT be sought. - Any existing embargo SHOULD terminate. - ```mermaid --- title: Attacks Observed CS-EM Interactions diff --git a/docs/topics/process_models/rm/index.md b/docs/topics/process_models/rm/index.md index 45e3e6b8..cd1780a0 100644 --- a/docs/topics/process_models/rm/index.md +++ b/docs/topics/process_models/rm/index.md @@ -4,7 +4,7 @@ Here we describe a high-level workflow for the CVD Report Management (RM) process. -The RM process should be reasonably familiar to anyone familiar with [IT Service Management](https://en.wikipedia.org/wiki/IT_service_management) (ITSM) workflows such as problem, change, +The RM process should be reasonably familiar to anyone familiar with [IT Service Management](https://en.wikipedia.org/wiki/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. @@ -24,7 +24,7 @@ completed, should map onto the RM process outlined here. {% include-markdown "../dfa_notation_definition.md" %} In this section, we first cover the states themselves before proceeding -to a discussion of the transitions between them. +to a discussion of the transitions between them. [Elsewhere](rm_interactions.md) , we provide a discussion of the Participant-specific semantics of the state transitions. We use Deterministic Finite Automata (DFA) notation to describe our @@ -36,8 +36,7 @@ Our proposed RM DFA models a report lifecycle containing seven states, defined b {% include-markdown "./rm_state_machine_diagram.md" %} - -???+ note inline end "RM States $\mathcal{Q}^{rm}$ Defined" +???+ note inline end "RM States $\mathcal{Q}^{rm}$ Defined" $\begin{split} \mathcal{Q}^{rm} = \{ & \underline{S}tart, \\ @@ -63,7 +62,7 @@ the state names. Each Participant in a CVD case will have their own RM state. The _Start_ state is a simple placeholder state for reports that have yet to be received. It is, in effect, a null state that no CVD Participant would be expected to reflect in their report tracking system. We include -it here because it is useful when modeling coordination +it here because it is useful when modeling coordination that spans multiple Participants in the [formal protocol](../../formal_protocol/index.md). Otherwise, the discussion until then will mostly ignore it. @@ -106,8 +105,8 @@ Exiting the _Received_ state requires a Participant to assess the validity of a report. Note that validation is distinct from prioritization, as covered in our description of the [_Valid_](#the-valid-v-state) state. In other words, the _Received_ state corresponds to the -[Validation phase](https://vuls.cert.org/confluence/display/CVD/4.3+Validation+and+Triage) -of the [*CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD). +[Validation phase](https://vuls.cert.org/confluence/display/CVD/4.3+Validation+and+Triage) +of the [_CERT Guide to Coordinated Vulnerability Disclosure_](https://vuls.cert.org/confluence/display/CVD). !!! note "" @@ -176,7 +175,6 @@ stateDiagram-v2 Received --> Invalid ``` - The reasons for a report to be put in this state will vary based on each recipient's validation criteria, and their technical capability and available resources. The _Invalid_ state is intended to be used as a @@ -203,10 +201,10 @@ contradict that conclusion. Reports in the _Valid_ state are ready to be prioritized for possible future work. The result of this prioritization process will be to either -accept the report for follow-up or defer further effort. +accept the report for follow-up or defer further effort. The _Valid_ state is equivalent to the [Prioritization -(Triage)](https://vuls.cert.org/confluence/display/CVD/4.3+Validation+and+Triage) phase -of the [*CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD). +(Triage)](https://vuls.cert.org/confluence/display/CVD/4.3+Validation+and+Triage) phase +of the [_CERT Guide to Coordinated Vulnerability Disclosure_](https://vuls.cert.org/confluence/display/CVD). As an example, a Vendor might later choose to _defer_ further response on a _Valid_ report due to other priorities. ```mermaid @@ -219,7 +217,6 @@ stateDiagram-v2 Invalid --> Valid ``` - !!! note "" For _Valid_ reports, the Participant SHOULD perform a prioritization @@ -246,8 +243,6 @@ In other words, prioritization is only necessary if the workload represented by active valid reports exceeds the organization's capacity to process those reports. - - Prioritization schemes, such as [SSVC](https://github.com/CERTCC/SSVC) or the [CVSS](https://first.org/cvss), are commonly used to prioritize work within the CVD process; however, specific details are @@ -279,17 +274,16 @@ stateDiagram-v2 Valid --> Accepted ``` - -- For our purposes, Finders/Reporters enter the _Accepted_ state only +- For our purposes, Finders/Reporters enter the _Accepted_ state only for reports that they intend to put through the CVD process. If they have no intention of pursuing CVD, there is no need for them to track their actions using this protocol. See [the secret lives of finders](rm_interactions.md#the-secret-lives-of-finders) for more. -- Vendors usually do root cause analysis, understand the problem, and +- Vendors usually do root cause analysis, understand the problem, and produce a fix or mitigation. -- Coordinators typically identify potentially affected Vendors, notify +- Coordinators typically identify potentially affected Vendors, notify them, and possibly negotiate embargoes. We provide additional elaboration on the sorts of activities that might @@ -323,7 +317,6 @@ stateDiagram-v2 Deferred --> Accepted ``` - For example, a Participant might use the _Deferred_ state when a valid report fails to meet their [prioritization criteria](#prioritize-report), or when a higher priority task takes precedence over an active case. @@ -370,7 +363,6 @@ stateDiagram-v2 Closed --> [*] ``` - !!! note "" Reports SHOULD be moved to the _Closed_ state once a Participant has @@ -382,7 +374,7 @@ stateDiagram-v2 - cases in _Accepted_ where all necessary tasks are complete. ???+ note "RM Start and End States ($q^{rm}_0, \mathcal{F}^{rm}$) Defined" - + The RM process starts in the _Start_ state. @@ -393,7 +385,6 @@ stateDiagram-v2 $$\mathcal{F}^{rm} = \{Closed\}$$ - ### RM State Transitions A Participant's RM process begins when the Participant receives a report. @@ -402,7 +393,7 @@ transitions in the corresponding DFA. ???+ note inline end "RM Symbols ($\Sigma^{rm}$) Defined" These actions constitute the set of symbols for the - RM DFA. + RM DFA. $\begin{align*} \Sigma^{rm} = \{ & \underline{r}eceive, \\ @@ -433,7 +424,7 @@ protocol. Every state transition implies a different message type. To begin, a Participant must receive a report. Recall that the _Start_ state is a placeholder, so this action simply puts the receiving Participant into the _Received_ state at the beginning of their -involvement in the case. +involvement in the case. ```mermaid --- @@ -457,7 +448,7 @@ periodically revalidate them to see if they have become _Valid_. !!! note "" Participants SHOULD create a case for all _Valid_ reports. - + !!! note "" Paricipants MAY create a case for _Invalid_ reports. @@ -496,7 +487,7 @@ stateDiagram-v2 Once a report has been validated (i.e., it is in the RM _Valid_ state, $q^{rm} \in V$), the Participant must prioritize it to determine what -further effort, if any, is necessary. +further effort, if any, is necessary. !!! note "" @@ -516,8 +507,6 @@ moving it to the _Accepted_ state. Participants MAY re-prioritize _Accepted_ or _Deferred_ cases. - - ```mermaid --- title: Prioritize Report @@ -555,7 +544,6 @@ stateDiagram-v2 reprioritize2 --> Deferred: defer ``` - ##### Participants Interact from the Accepted State Some Participants (e.g., Finders and Coordinators) need to engage @@ -622,7 +610,6 @@ to _Deferred_ to _Closed_ in rapid (even immediate) succession. Participants MUST NOT close cases or reports from the _Valid_ state. - #### Possible Report Management Histories ???+ note inline end "RM Transition Function ($\delta^{rm}$) Defined" @@ -691,7 +678,7 @@ The full definition of the RM DFA is given below. \end{pmatrix}$$ ???+ note "RM State Subsets Defined" - + Before proceeding, we pause to define a few useful subsets of RM states ($\dots \subset \mathcal{Q}^{rm}$) for future use: @@ -703,4 +690,3 @@ The full definition of the RM DFA is given below. Active &= \{ R,V,A \} \\ Inactive &= \{ I,D,C \} \end{align}$$ - diff --git a/docs/topics/process_models/rm/rm_interactions.md b/docs/topics/process_models/rm/rm_interactions.md index 978206ef..61020904 100644 --- a/docs/topics/process_models/rm/rm_interactions.md +++ b/docs/topics/process_models/rm/rm_interactions.md @@ -5,7 +5,7 @@ Participants can change their local state independent of the state of other Part Events within a CVD case may trigger a state transition in one Participant while no transition occurs in another. For example, in [particpants interact from the accepted state](#participants-interact-from-the-accepted-state) we showed that even though the _sender_ is the one taking the action, it is the _recipient_'s state that changes. -The table below lists role-based actions. +The table below lists role-based actions. | Finder/Reporter | Vendor | Coordinator | Action | RM Transition | |:----------------:|:----------------:|:----------------:|-----------------------------------------|:----------------------------------------------------------------------------------------------:| @@ -31,9 +31,9 @@ of a potential CVD protocol. Why? Because for anyone else to know about the vuln (and as a prerequisite to CVD happening at all), the Finder must have already validated the report and prioritized it as worthy of further effort to have any reason to attempt to coordinate its disclosure. In -other words, CVD only starts *after* the Finder has already reached the +other words, CVD only starts _after_ the Finder has already reached the _Accepted_ state for any given vulnerability to be reported. -Correspondingly, this also represents their transition from *Finder* to +Correspondingly, this also represents their transition from _Finder_ to *Reporter*. Nevertheless, for now, we retain these states for completeness. We revisit this topic in our [formal derivation](../../../reference/formal_protocol/states.md#finder-reporters) @@ -76,8 +76,7 @@ stateDiagram-v2 } ``` - -## Finder-Vendor CVD. +## Finder-Vendor CVD A simple Finder-Vendor CVD scenario is shown below. As explained [above](#the-secret-lives-of-finders), many of the Finder's states would be @@ -132,7 +131,7 @@ stateDiagram-v2 A --> RV: r ``` -## Finder-Coordinator-Vendor CVD. +## Finder-Coordinator-Vendor CVD A slightly more complicated scenario in which a Finder engages a Coordinator after failing to engage a Vendor is shown in the next diagram. @@ -142,13 +141,13 @@ considering our role as a Coordinator means that we do not participate in cases following the previous example. Here we see three notification actions corresponding to [participants interacting from the accepted state](#participants-interact-from-the-accepted-state): -- First, $A_f \xrightarrow{r_0} R_v$ represents the Finder's initial +- First, $A_f \xrightarrow{r_0} R_v$ represents the Finder's initial attempt to reach the Vendor. -- Next, $A_f \xrightarrow{r_1} R_c$ is the Finder's subsequent attempt +- Next, $A_f \xrightarrow{r_1} R_c$ is the Finder's subsequent attempt to engage with the Coordinator. -- Finally, the Coordinator contacts the Vendor in +- Finally, the Coordinator contacts the Vendor in $A_c \xrightarrow{r_2} R_v$. ```mermaid @@ -220,21 +219,20 @@ stateDiagram-v2 AC --> RV: r2 ``` - -## MPCVD with a Coordinator and Multiple Vendors. +## MPCVD with a Coordinator and Multiple Vendors A small MPCVD scenario is shown below. As with the other examples, each notification shown is an instance of [participants interacting from the accepted state](#participants-interact-from-the-accepted-state). Contrary to the previous example, this scenario starts with the Finder contacting a Coordinator, perhaps because they recognize the increased complexity of coordinating multiple Vendors' responses. -- First, $A_f \xrightarrow{r_0} R_c$ represents the Finder's initial +- First, $A_f \xrightarrow{r_0} R_c$ represents the Finder's initial report to the Coordinator. -- Next, $A_c \xrightarrow{r_1} R_{v_1}$ shows the Coordinator +- Next, $A_c \xrightarrow{r_1} R_{v_1}$ shows the Coordinator contacting the first Vendor. -- Finally, the Coordinator contacts a second Vendor in +- Finally, the Coordinator contacts a second Vendor in $A_c \xrightarrow{r_2} R_{v_2}$. ```mermaid @@ -324,8 +322,7 @@ stateDiagram-v2 AC --> RV2: r2 ``` - -## A Menagerie of MPCVD Scenarios. +## A Menagerie of MPCVD Scenarios Other MPCVD RM interaction configurations are possible, of course. We demonstrate a few such scenarios in the following figures. @@ -333,7 +330,6 @@ This time each node represents a Participant's entire RM model. We have observed following interactions at the CERT/CC. We intend the RM model to be sufficiently composable to accommodate all such permutations. - ### Finder coordinates MPCVD with Multiple Vendors A Finder notifies multiple Vendors without engaging a Coordinator. @@ -349,7 +345,7 @@ stateDiagram-v2 Finder --> Vendor3: r2 ``` -### Vendor coordinates MPCVD +### Vendor coordinates MPCVD A Finder notifies a Vendor, who, in turn, notifies other Vendors. @@ -382,7 +378,7 @@ stateDiagram-v2 Coordinator --> Vendor4: r4 ``` -### Supply-chain oriented MPCVD. +### Supply-chain oriented MPCVD Supply-chain oriented MPCVD often has two or more tiers of Vendors being notified by their upstream component suppliers, with @@ -405,4 +401,3 @@ stateDiagram-v2 Vendor7 --> Vendor8: r8 Vendor7 --> Vendor9: r9 ``` - diff --git a/docs/topics/user_stories/index.md b/docs/topics/user_stories/index.md index e59c2376..2a02b37a 100644 --- a/docs/topics/user_stories/index.md +++ b/docs/topics/user_stories/index.md @@ -27,11 +27,9 @@ Where appropriate, we intend to provide a reference implementation for each appl ## Support Levels - Each story page indicates a categorization according to the level of support provided by the originally published Vultron Protocol (version 0.4.0): - - _Provided_ - Stories in this category are directly supported by the Vultron Protocol v0.4.0. - _Allowed_ - Stories in this category are indirectly supported by the Vultron Protocol v0.4.0. - _Unsupported_ - Stories in this category are not supported by the Vultron Protocol v0.4.0. @@ -41,7 +39,6 @@ In the future, we expect these categories will change toward simply _Supported_, We also anticipate that as we learn more about ActivityPub and make progress on the protocol development, some of the stories in the _Unsupported_ category could move to _Supported_. - ## User Stories Table {% include-markdown "./table.md" %} diff --git a/docs/topics/user_stories/story_2022_002.md b/docs/topics/user_stories/story_2022_002.md index d79cbf1a..a156ad9e 100644 --- a/docs/topics/user_stories/story_2022_002.md +++ b/docs/topics/user_stories/story_2022_002.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Provided by RS message type - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Reporting -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_003.md b/docs/topics/user_stories/story_2022_003.md index fe2e47ab..54db306c 100644 --- a/docs/topics/user_stories/story_2022_003.md +++ b/docs/topics/user_stories/story_2022_003.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Use search engines. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_004.md b/docs/topics/user_stories/story_2022_004.md index 68c7c00d..face3ae9 100644 --- a/docs/topics/user_stories/story_2022_004.md +++ b/docs/topics/user_stories/story_2022_004.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not provide a policy publication or consumption mechanism. No formal policy specification language exists. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_005.md b/docs/topics/user_stories/story_2022_005.md index afe28bb7..6c405bd9 100644 --- a/docs/topics/user_stories/story_2022_005.md +++ b/docs/topics/user_stories/story_2022_005.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Unclear what to optimize for, also, no formal policy specification language exists - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_006.md b/docs/topics/user_stories/story_2022_006.md index 993b50dd..3c2013b7 100644 --- a/docs/topics/user_stories/story_2022_006.md +++ b/docs/topics/user_stories/story_2022_006.md @@ -6,8 +6,7 @@ ## Notes ## *(as of v0.4.0)* -Participation decisions are Participant-specific. - +Participation decisions are Participant-specific. ## Metadata ## diff --git a/docs/topics/user_stories/story_2022_007.md b/docs/topics/user_stories/story_2022_007.md index c51a32f4..0e779a44 100644 --- a/docs/topics/user_stories/story_2022_007.md +++ b/docs/topics/user_stories/story_2022_007.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* EE (embargo error) message type is available. Unclear what kind of policy troubles would need to be detected, if a formal policy specification language were to exist. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_008.md b/docs/topics/user_stories/story_2022_008.md index f97fa167..d54aeb6e 100644 --- a/docs/topics/user_stories/story_2022_008.md +++ b/docs/topics/user_stories/story_2022_008.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Warn them about what? This story is inadequate. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_009.md b/docs/topics/user_stories/story_2022_009.md index e1522224..9545eea9 100644 --- a/docs/topics/user_stories/story_2022_009.md +++ b/docs/topics/user_stories/story_2022_009.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Policy can be posted online, but not via the protocol. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_010.md b/docs/topics/user_stories/story_2022_010.md index ff79fd69..1af1951a 100644 --- a/docs/topics/user_stories/story_2022_010.md +++ b/docs/topics/user_stories/story_2022_010.md @@ -6,8 +6,7 @@ ## Notes ## *(as of v0.4.0)* -The EM process provides all of these except for hard limits, which it allows for. - +The EM process provides all of these except for hard limits, which it allows for. ## Metadata ## diff --git a/docs/topics/user_stories/story_2022_011.md b/docs/topics/user_stories/story_2022_011.md index 5ef9a800..815956b8 100644 --- a/docs/topics/user_stories/story_2022_011.md +++ b/docs/topics/user_stories/story_2022_011.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol is focused on coordinating cases that exist. Advertising bounties would be outside the protocol. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_012.md b/docs/topics/user_stories/story_2022_012.md index 47696b0f..bcc5fcba 100644 --- a/docs/topics/user_stories/story_2022_012.md +++ b/docs/topics/user_stories/story_2022_012.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Provided by the RS message type. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Reporting -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_013.md b/docs/topics/user_stories/story_2022_013.md index 53886ba9..d249f456 100644 --- a/docs/topics/user_stories/story_2022_013.md +++ b/docs/topics/user_stories/story_2022_013.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Adding a Participant equates to sending them a report using the RS message type. There is no special process to add a Participant aside from notifying them and engaging them in the RM and EM processes. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_014.md b/docs/topics/user_stories/story_2022_014.md index 4e1d501d..9258db0b 100644 --- a/docs/topics/user_stories/story_2022_014.md +++ b/docs/topics/user_stories/story_2022_014.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Embargo negotiation is provided by the EM process and its accompanying message types. Publication notification is covered by the CP message type. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_015.md b/docs/topics/user_stories/story_2022_015.md index 50249d25..e40d5684 100644 --- a/docs/topics/user_stories/story_2022_015.md +++ b/docs/topics/user_stories/story_2022_015.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* An EV message may be appropriate to shorten any existing embargo. Any Participant can send a GI message at any time for any reason. The protocol does not provide a publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_016.md b/docs/topics/user_stories/story_2022_016.md index 5c3af77f..9e1a02ce 100644 --- a/docs/topics/user_stories/story_2022_016.md +++ b/docs/topics/user_stories/story_2022_016.md @@ -6,8 +6,7 @@ ## Notes ## *(as of v0.4.0)* -Unclear what "limited/ACK" means. Unclear what "full/proper advisory" means. The protocol does not provide an advisory publication mechanism. RK message provides ack of RS receipt. - +Unclear what "limited/ACK" means. Unclear what "full/proper advisory" means. The protocol does not provide an advisory publication mechanism. RK message provides ack of RS receipt. ## Metadata ## @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_017.md b/docs/topics/user_stories/story_2022_017.md index 14c86dce..417b617f 100644 --- a/docs/topics/user_stories/story_2022_017.md +++ b/docs/topics/user_stories/story_2022_017.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_018.md b/docs/topics/user_stories/story_2022_018.md index d64460d2..f5e33894 100644 --- a/docs/topics/user_stories/story_2022_018.md +++ b/docs/topics/user_stories/story_2022_018.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Provided by the CX message type. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_019.md b/docs/topics/user_stories/story_2022_019.md index 01d018d8..03f92fb4 100644 --- a/docs/topics/user_stories/story_2022_019.md +++ b/docs/topics/user_stories/story_2022_019.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Provided by the CA message type. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_020.md b/docs/topics/user_stories/story_2022_020.md index 95a57544..332790f5 100644 --- a/docs/topics/user_stories/story_2022_020.md +++ b/docs/topics/user_stories/story_2022_020.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not provide a report or advisory publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_021.md b/docs/topics/user_stories/story_2022_021.md index eb7afc94..42bb500d 100644 --- a/docs/topics/user_stories/story_2022_021.md +++ b/docs/topics/user_stories/story_2022_021.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not provide a policy publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_022.md b/docs/topics/user_stories/story_2022_022.md index 3d551f96..b5511423 100644 --- a/docs/topics/user_stories/story_2022_022.md +++ b/docs/topics/user_stories/story_2022_022.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol is focused on coordinating cases that exist. Advertising CVD scope is outside the protocol. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_023.md b/docs/topics/user_stories/story_2022_023.md index 3ad2ec53..eb07ca2f 100644 --- a/docs/topics/user_stories/story_2022_023.md +++ b/docs/topics/user_stories/story_2022_023.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_024.md b/docs/topics/user_stories/story_2022_024.md index 2a5cbcda..9caf90df 100644 --- a/docs/topics/user_stories/story_2022_024.md +++ b/docs/topics/user_stories/story_2022_024.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate how RS messages are delivered. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Case participant management; Participant identity management - **Roles:** Finder, Reporter - **Phases:** Reporting, Analysis and Remediation -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_025.md b/docs/topics/user_stories/story_2022_025.md index a012041f..f3290390 100644 --- a/docs/topics/user_stories/story_2022_025.md +++ b/docs/topics/user_stories/story_2022_025.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The EM process provides the mechanism for establishing, extending, and terminating embargoes. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Case participant management - **Roles:** Vendor, Deployer - **Phases:** Validation and Prioritization, Analysis and Remediation -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_026.md b/docs/topics/user_stories/story_2022_026.md index 50da679b..ca5122ad 100644 --- a/docs/topics/user_stories/story_2022_026.md +++ b/docs/topics/user_stories/story_2022_026.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The EM process provides the mechanism for establishing, extending, and terminating embargoes. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Case participant management - **Roles:** Coordinator - **Phases:** Reporting, Validation and Prioritization, Analysis and Remediation -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_027.md b/docs/topics/user_stories/story_2022_027.md index 506b9551..0381c704 100644 --- a/docs/topics/user_stories/story_2022_027.md +++ b/docs/topics/user_stories/story_2022_027.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_028.md b/docs/topics/user_stories/story_2022_028.md index 240028df..18467f1d 100644 --- a/docs/topics/user_stories/story_2022_028.md +++ b/docs/topics/user_stories/story_2022_028.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol is focused on coordinating cases that exist. CVD Endpoint discovery is not provided. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_029.md b/docs/topics/user_stories/story_2022_029.md index c7e196c3..912459c9 100644 --- a/docs/topics/user_stories/story_2022_029.md +++ b/docs/topics/user_stories/story_2022_029.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RM process assumes each Participant is managing their own report handling. This presumes a means of identifying reports. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_030.md b/docs/topics/user_stories/story_2022_030.md index 3361d723..996bdb92 100644 --- a/docs/topics/user_stories/story_2022_030.md +++ b/docs/topics/user_stories/story_2022_030.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not address global IDs. But it could be overlayed onto the existing RM process. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_031.md b/docs/topics/user_stories/story_2022_031.md index bfde9c85..7855f47d 100644 --- a/docs/topics/user_stories/story_2022_031.md +++ b/docs/topics/user_stories/story_2022_031.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_032.md b/docs/topics/user_stories/story_2022_032.md index ec6f74df..1372a986 100644 --- a/docs/topics/user_stories/story_2022_032.md +++ b/docs/topics/user_stories/story_2022_032.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_033.md b/docs/topics/user_stories/story_2022_033.md index c0897bba..56700200 100644 --- a/docs/topics/user_stories/story_2022_033.md +++ b/docs/topics/user_stories/story_2022_033.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Message content is unrestricted by the protocol. Participant policy for such requests is out-of-scope for the protocol. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_034.md b/docs/topics/user_stories/story_2022_034.md index e070bb23..aac6ce08 100644 --- a/docs/topics/user_stories/story_2022_034.md +++ b/docs/topics/user_stories/story_2022_034.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not specify Participant identification, authentication, or authorization mechanisms. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_035.md b/docs/topics/user_stories/story_2022_035.md index ce802103..0de35900 100644 --- a/docs/topics/user_stories/story_2022_035.md +++ b/docs/topics/user_stories/story_2022_035.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not specify Participant identification, authentication, or authorization mechanisms. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_036.md b/docs/topics/user_stories/story_2022_036.md index 0358a5a1..4a95c2aa 100644 --- a/docs/topics/user_stories/story_2022_036.md +++ b/docs/topics/user_stories/story_2022_036.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not specify Participant identification, authentication, or authorization mechanisms. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_037.md b/docs/topics/user_stories/story_2022_037.md index 2fca0f12..a1a8ff76 100644 --- a/docs/topics/user_stories/story_2022_037.md +++ b/docs/topics/user_stories/story_2022_037.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not provide a report or advisory publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -18,8 +17,8 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Vendor -- **Phases:** -- **Categories:** +- **Phases:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_038.md b/docs/topics/user_stories/story_2022_038.md index 88aa529e..fa262adc 100644 --- a/docs/topics/user_stories/story_2022_038.md +++ b/docs/topics/user_stories/story_2022_038.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RS message type provides this. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Vendor, Coordinator - **Phases:** Reporting -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_039.md b/docs/topics/user_stories/story_2022_039.md index 5c64c21a..15e4ff44 100644 --- a/docs/topics/user_stories/story_2022_039.md +++ b/docs/topics/user_stories/story_2022_039.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_040.md b/docs/topics/user_stories/story_2022_040.md index 67bf0711..9542fd94 100644 --- a/docs/topics/user_stories/story_2022_040.md +++ b/docs/topics/user_stories/story_2022_040.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Reporting, Validation and Prioritization, Analysis and Remediation -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_041.md b/docs/topics/user_stories/story_2022_041.md index 4864e367..3da1f970 100644 --- a/docs/topics/user_stories/story_2022_041.md +++ b/docs/topics/user_stories/story_2022_041.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_042.md b/docs/topics/user_stories/story_2022_042.md index ba23ed4c..0a323dd4 100644 --- a/docs/topics/user_stories/story_2022_042.md +++ b/docs/topics/user_stories/story_2022_042.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_043.md b/docs/topics/user_stories/story_2022_043.md index 14389266..326f9dd1 100644 --- a/docs/topics/user_stories/story_2022_043.md +++ b/docs/topics/user_stories/story_2022_043.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_044.md b/docs/topics/user_stories/story_2022_044.md index bd7a8160..10975f24 100644 --- a/docs/topics/user_stories/story_2022_044.md +++ b/docs/topics/user_stories/story_2022_044.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_045.md b/docs/topics/user_stories/story_2022_045.md index f927b169..38cfdbd8 100644 --- a/docs/topics/user_stories/story_2022_045.md +++ b/docs/topics/user_stories/story_2022_045.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* A log of RM, EM, and CS state transitions can provide the data for such a record. Verification/Auditing is not addressed at this time. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_046.md b/docs/topics/user_stories/story_2022_046.md index d1724baf..57df74e5 100644 --- a/docs/topics/user_stories/story_2022_046.md +++ b/docs/topics/user_stories/story_2022_046.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The Protocol does not provide any mechanism for case leadership to be managed, but such a process could be overlaid onto the existing mechanisms using GI messages if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_047.md b/docs/topics/user_stories/story_2022_047.md index c9b250e8..d9fc669e 100644 --- a/docs/topics/user_stories/story_2022_047.md +++ b/docs/topics/user_stories/story_2022_047.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The Protocol does not provide any mechanism for case leadership to be managed, but such a process could be overlaid onto the existing mechanisms using GI messages if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_048.md b/docs/topics/user_stories/story_2022_048.md index 6938525a..2736f4b9 100644 --- a/docs/topics/user_stories/story_2022_048.md +++ b/docs/topics/user_stories/story_2022_048.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The Protocol does not provide any mechanism for case leadership to be managed, but such a process could be overlaid onto the existing mechanisms using GI messages if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_049.md b/docs/topics/user_stories/story_2022_049.md index 1b6fa858..165d7926 100644 --- a/docs/topics/user_stories/story_2022_049.md +++ b/docs/topics/user_stories/story_2022_049.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The Protocol does not provide any mechanism for case leadership to be managed, but such a process could be overlaid onto the existing mechanisms using GI messages if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_050.md b/docs/topics/user_stories/story_2022_050.md index 32c0051a..35f687d5 100644 --- a/docs/topics/user_stories/story_2022_050.md +++ b/docs/topics/user_stories/story_2022_050.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The Protocol does not provide any mechanism for case leadership to be managed, but such a process could be overlaid onto the existing mechanisms using GI messages if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_051.md b/docs/topics/user_stories/story_2022_051.md index bae475da..ab9b50d0 100644 --- a/docs/topics/user_stories/story_2022_051.md +++ b/docs/topics/user_stories/story_2022_051.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The Protocol does not provide any mechanism for case leadership to be managed, but such a process could be overlaid onto the existing mechanisms using GI messages if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_052.md b/docs/topics/user_stories/story_2022_052.md index 548547eb..e9eeb1f0 100644 --- a/docs/topics/user_stories/story_2022_052.md +++ b/docs/topics/user_stories/story_2022_052.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RM process provides the RS message type for notifying others. Participants are free to announce their additions to the case using a GI message if desired. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_053.md b/docs/topics/user_stories/story_2022_053.md index ca22f15a..6d791dd3 100644 --- a/docs/topics/user_stories/story_2022_053.md +++ b/docs/topics/user_stories/story_2022_053.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_054.md b/docs/topics/user_stories/story_2022_054.md index 559de3d9..c40f2488 100644 --- a/docs/topics/user_stories/story_2022_054.md +++ b/docs/topics/user_stories/story_2022_054.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* No voting mechanisms are included in the protocol at this time. This function could be implemented using GI messages, but enforcement would be via social convention not technical protocol. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_055.md b/docs/topics/user_stories/story_2022_055.md index 727ba35e..37f6545d 100644 --- a/docs/topics/user_stories/story_2022_055.md +++ b/docs/topics/user_stories/story_2022_055.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_056.md b/docs/topics/user_stories/story_2022_056.md index 36ab750d..e8880fa8 100644 --- a/docs/topics/user_stories/story_2022_056.md +++ b/docs/topics/user_stories/story_2022_056.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_057.md b/docs/topics/user_stories/story_2022_057.md index eca554d0..1063e9b9 100644 --- a/docs/topics/user_stories/story_2022_057.md +++ b/docs/topics/user_stories/story_2022_057.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_058.md b/docs/topics/user_stories/story_2022_058.md index ed42a439..b1ad5a4d 100644 --- a/docs/topics/user_stories/story_2022_058.md +++ b/docs/topics/user_stories/story_2022_058.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_059.md b/docs/topics/user_stories/story_2022_059.md index 20ed807a..e01ece9c 100644 --- a/docs/topics/user_stories/story_2022_059.md +++ b/docs/topics/user_stories/story_2022_059.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_060.md b/docs/topics/user_stories/story_2022_060.md index bb499730..a40000a3 100644 --- a/docs/topics/user_stories/story_2022_060.md +++ b/docs/topics/user_stories/story_2022_060.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_061.md b/docs/topics/user_stories/story_2022_061.md index dfdbbabb..d1542a9b 100644 --- a/docs/topics/user_stories/story_2022_061.md +++ b/docs/topics/user_stories/story_2022_061.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* In general, an engaged Participant should be able to track state change messages received from other Participants rather than by polling. However, should that fail to maintain state sync across Participants, any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_062.md b/docs/topics/user_stories/story_2022_062.md index 7ee473c3..08d14552 100644 --- a/docs/topics/user_stories/story_2022_062.md +++ b/docs/topics/user_stories/story_2022_062.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* State change messages form the core of the protocol. The content of those messages is unspecified, and can include any additional information the sender thinks is relevant. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Participant - **Phases:** Reporting, Validation and Prioritization, Analysis and Remediation, Deployment -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_063.md b/docs/topics/user_stories/story_2022_063.md index d80bc85b..cd83e0a1 100644 --- a/docs/topics/user_stories/story_2022_063.md +++ b/docs/topics/user_stories/story_2022_063.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_064.md b/docs/topics/user_stories/story_2022_064.md index 0d432d1f..d92cf206 100644 --- a/docs/topics/user_stories/story_2022_064.md +++ b/docs/topics/user_stories/story_2022_064.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_065.md b/docs/topics/user_stories/story_2022_065.md index 7208bfde..f7fe6e1b 100644 --- a/docs/topics/user_stories/story_2022_065.md +++ b/docs/topics/user_stories/story_2022_065.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_066.md b/docs/topics/user_stories/story_2022_066.md index b7314828..b69bce73 100644 --- a/docs/topics/user_stories/story_2022_066.md +++ b/docs/topics/user_stories/story_2022_066.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol assumes that any Participant may exit a case at any time for any reason. An RI, RD, or RC message should be emitted as appropriate, noting intentions for embargo compliance. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_067.md b/docs/topics/user_stories/story_2022_067.md index 2d2be61c..604ea3f4 100644 --- a/docs/topics/user_stories/story_2022_067.md +++ b/docs/topics/user_stories/story_2022_067.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol assumes that any Participant may exit a case at any time for any reason. An RI, RD, or RC message should be emitted as appropriate, noting intentions for embargo compliance. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_068.md b/docs/topics/user_stories/story_2022_068.md index 73b4764c..f4abefea 100644 --- a/docs/topics/user_stories/story_2022_068.md +++ b/docs/topics/user_stories/story_2022_068.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol assumes that any Participant may exit a case at any time for any reason. An RC message should be emitted as appropriate, noting intentions for embargo compliance. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_069.md b/docs/topics/user_stories/story_2022_069.md index fbef5269..5bdf4580 100644 --- a/docs/topics/user_stories/story_2022_069.md +++ b/docs/topics/user_stories/story_2022_069.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The CP message type provides this. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_070.md b/docs/topics/user_stories/story_2022_070.md index 005a5634..ddbdb5da 100644 --- a/docs/topics/user_stories/story_2022_070.md +++ b/docs/topics/user_stories/story_2022_070.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_071.md b/docs/topics/user_stories/story_2022_071.md index c8c325df..acafd247 100644 --- a/docs/topics/user_stories/story_2022_071.md +++ b/docs/topics/user_stories/story_2022_071.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not address sharing rules explicitly. There is nothing precluding this information from being conveyed in the content of messages. Participants need to decide for themselves their adherence policy. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_072.md b/docs/topics/user_stories/story_2022_072.md index a6365e2b..8af8c72c 100644 --- a/docs/topics/user_stories/story_2022_072.md +++ b/docs/topics/user_stories/story_2022_072.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not address sharing rules explicitly. There is nothing precluding this information from being conveyed in the content of messages. Participants need to decide for themselves their adherence policy. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_073.md b/docs/topics/user_stories/story_2022_073.md index 57f44340..b02b574b 100644 --- a/docs/topics/user_stories/story_2022_073.md +++ b/docs/topics/user_stories/story_2022_073.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not address sharing rules explicitly. There is nothing precluding this information from being conveyed in the content of messages. Participants need to decide for themselves their adherence policy. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_074.md b/docs/topics/user_stories/story_2022_074.md index 951b011f..05f19c02 100644 --- a/docs/topics/user_stories/story_2022_074.md +++ b/docs/topics/user_stories/story_2022_074.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RM, EM, and CS processes and their corresponding messages provide these abilities. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_075.md b/docs/topics/user_stories/story_2022_075.md index 69f5a765..f393a2bf 100644 --- a/docs/topics/user_stories/story_2022_075.md +++ b/docs/topics/user_stories/story_2022_075.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol recommends that Participants keep track of other Participants' state as the case progresses. It does not, however, require that any Participant do so. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_076.md b/docs/topics/user_stories/story_2022_076.md index cdbbc824..00fbe810 100644 --- a/docs/topics/user_stories/story_2022_076.md +++ b/docs/topics/user_stories/story_2022_076.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RM, EM, and CS processes are common to both CVD and VDP processes. It is somewhat unclear what specifically the difference is that this story is meant to address. The protocol notes that embargoes are not NDAs, and is mute on bounty payment mechanisms. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_077.md b/docs/topics/user_stories/story_2022_077.md index af9e4b01..8d357f90 100644 --- a/docs/topics/user_stories/story_2022_077.md +++ b/docs/topics/user_stories/story_2022_077.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_078.md b/docs/topics/user_stories/story_2022_078.md index c33f7a36..cec4c3f3 100644 --- a/docs/topics/user_stories/story_2022_078.md +++ b/docs/topics/user_stories/story_2022_078.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The EM process describes a tendency toward shorter embargoes, but does not require it. Individual Participants are free to negotiate embargoes according to their own policy and values. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_079.md b/docs/topics/user_stories/story_2022_079.md index ca393b11..42eac607 100644 --- a/docs/topics/user_stories/story_2022_079.md +++ b/docs/topics/user_stories/story_2022_079.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The EM process recommends a few heuristics for resolving embargo proposals. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_080.md b/docs/topics/user_stories/story_2022_080.md index 1df20d6e..8dc55b3c 100644 --- a/docs/topics/user_stories/story_2022_080.md +++ b/docs/topics/user_stories/story_2022_080.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol allows for any Participant to exit an embargo or case at any time. An ET message should be emitted as appropriate to signal the immediate termination of an embargo. An EV message may be emitted to provide advance warning of an intent to end an embargo early. The EM process recommends a few heuristics for resolving embargo proposals. The protocol does not provide a publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_081.md b/docs/topics/user_stories/story_2022_081.md index 92b724df..8ac2a793 100644 --- a/docs/topics/user_stories/story_2022_081.md +++ b/docs/topics/user_stories/story_2022_081.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Notify-on-state-change is a core design principle of the protocol. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_082.md b/docs/topics/user_stories/story_2022_082.md index ba6b6ead..fbfa166d 100644 --- a/docs/topics/user_stories/story_2022_082.md +++ b/docs/topics/user_stories/story_2022_082.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_083.md b/docs/topics/user_stories/story_2022_083.md index 57eb2488..34815030 100644 --- a/docs/topics/user_stories/story_2022_083.md +++ b/docs/topics/user_stories/story_2022_083.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. The protocol does not provide a publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_084.md b/docs/topics/user_stories/story_2022_084.md index 25a04a99..019c5023 100644 --- a/docs/topics/user_stories/story_2022_084.md +++ b/docs/topics/user_stories/story_2022_084.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol is mute on bounty payments. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Vendor - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_085.md b/docs/topics/user_stories/story_2022_085.md index 2930fd93..4d829bae 100644 --- a/docs/topics/user_stories/story_2022_085.md +++ b/docs/topics/user_stories/story_2022_085.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol is mute on bounty payments. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Reporter - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_086.md b/docs/topics/user_stories/story_2022_086.md index d24728ab..157bdb7c 100644 --- a/docs/topics/user_stories/story_2022_086.md +++ b/docs/topics/user_stories/story_2022_086.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RM process requires that Participants prioritize valid cases. The protocol does not dictate what prioritization scheme is used. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_087.md b/docs/topics/user_stories/story_2022_087.md index 0954e49b..02c3e213 100644 --- a/docs/topics/user_stories/story_2022_087.md +++ b/docs/topics/user_stories/story_2022_087.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_088.md b/docs/topics/user_stories/story_2022_088.md index e3dcf8cf..4cc65eb5 100644 --- a/docs/topics/user_stories/story_2022_088.md +++ b/docs/topics/user_stories/story_2022_088.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The state-change messaging orientation of the protocol provides Participants the opportunity to track the changes as they happen. The GI message type permits Participants to inquire about and resolve loss-of-sync issues. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_089.md b/docs/topics/user_stories/story_2022_089.md index 1b434678..4871f3a3 100644 --- a/docs/topics/user_stories/story_2022_089.md +++ b/docs/topics/user_stories/story_2022_089.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not address message integrity. It will need to be addressed by implementation-specific choices. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_090.md b/docs/topics/user_stories/story_2022_090.md index 303ef8ac..0a48ebca 100644 --- a/docs/topics/user_stories/story_2022_090.md +++ b/docs/topics/user_stories/story_2022_090.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not specify Participant identification, authentication, or authorization mechanisms. It will need to be addressed by implementation-specific choices. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_091.md b/docs/topics/user_stories/story_2022_091.md index 367b0957..94ea3ccd 100644 --- a/docs/topics/user_stories/story_2022_091.md +++ b/docs/topics/user_stories/story_2022_091.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not specify message confidentiality mechanisms. It will need to be addressed by implementation-specific choices. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_092.md b/docs/topics/user_stories/story_2022_092.md index 78abb9c8..64423bd6 100644 --- a/docs/topics/user_stories/story_2022_092.md +++ b/docs/topics/user_stories/story_2022_092.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_093.md b/docs/topics/user_stories/story_2022_093.md index f154552f..f21d82f2 100644 --- a/docs/topics/user_stories/story_2022_093.md +++ b/docs/topics/user_stories/story_2022_093.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_094.md b/docs/topics/user_stories/story_2022_094.md index d6d30d75..cdd29d34 100644 --- a/docs/topics/user_stories/story_2022_094.md +++ b/docs/topics/user_stories/story_2022_094.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* There is no Participant reputation management mechanism provided. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_095.md b/docs/topics/user_stories/story_2022_095.md index 7b05508f..2cb790ee 100644 --- a/docs/topics/user_stories/story_2022_095.md +++ b/docs/topics/user_stories/story_2022_095.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* There is no Participant reputation management mechanism provided. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_096.md b/docs/topics/user_stories/story_2022_096.md index 71f5f995..9e626b28 100644 --- a/docs/topics/user_stories/story_2022_096.md +++ b/docs/topics/user_stories/story_2022_096.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* There is no Participant reputation management mechanism provided. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_097.md b/docs/topics/user_stories/story_2022_097.md index 181458a1..cf89c10d 100644 --- a/docs/topics/user_stories/story_2022_097.md +++ b/docs/topics/user_stories/story_2022_097.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* There is no Participant directory service provided. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_098.md b/docs/topics/user_stories/story_2022_098.md index 4e557d6b..574f4e03 100644 --- a/docs/topics/user_stories/story_2022_098.md +++ b/docs/topics/user_stories/story_2022_098.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The default assumption is that all case communications are sent to all Participants, but that is not a strict requirement. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_099.md b/docs/topics/user_stories/story_2022_099.md index cb84485e..ad6bf122 100644 --- a/docs/topics/user_stories/story_2022_099.md +++ b/docs/topics/user_stories/story_2022_099.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not dictate who gets to be a case Participant. That needs to be decided on a per-case, per-Participant level. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_100.md b/docs/topics/user_stories/story_2022_100.md index 3e55558f..50e40480 100644 --- a/docs/topics/user_stories/story_2022_100.md +++ b/docs/topics/user_stories/story_2022_100.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Group/community management is outside the protocol scope. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -18,12 +17,12 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Contact directory - **Roles:** Vendor, Coordinator, Other -- **Phases:** +- **Phases:** - **Categories:** Community, Infrastructure --- - **File:** `story_2022_100.md` - **Original ID:** `124.0` -- **2022 Whitepaper ID:** `CVD-API-055-124 ` +- **2022 Whitepaper ID:** `CVD-API-055-124` - **Support Level:** *(as of v0.4.0)* Unsupported diff --git a/docs/topics/user_stories/story_2022_101.md b/docs/topics/user_stories/story_2022_101.md index 781f82ed..102075a4 100644 --- a/docs/topics/user_stories/story_2022_101.md +++ b/docs/topics/user_stories/story_2022_101.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The RM process requires that Participants validate received cases. It does not however dictate the validation criteria, which is left as a per-Participant implementation choice. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Coordinator - **Phases:** Reporting, Validation and Prioritization -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_102.md b/docs/topics/user_stories/story_2022_102.md index 178ed76f..c01c55cb 100644 --- a/docs/topics/user_stories/story_2022_102.md +++ b/docs/topics/user_stories/story_2022_102.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Participants can collect whatever information they choose to make the decisions they need to make. Any Participant can send a GI message at any time for any reason. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** nan - **Roles:** Coordinator - **Phases:** Reporting, Validation and Prioritization -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_103.md b/docs/topics/user_stories/story_2022_103.md index 535adea2..2daecd02 100644 --- a/docs/topics/user_stories/story_2022_103.md +++ b/docs/topics/user_stories/story_2022_103.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* Although no explicit mechanism is provided, this can be achieved using GI messages. Explicitly supporting this story would likely entail going deeper into modeling the substates of RM:Accepted, which is beyond our scope at present. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_104.md b/docs/topics/user_stories/story_2022_104.md index d3bca8c4..edb20d22 100644 --- a/docs/topics/user_stories/story_2022_104.md +++ b/docs/topics/user_stories/story_2022_104.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* This story represents MPCVD in hard mode. But there are two ways to approach it: As a single case, or as individual cases with correlated states. The latter is essentially a post-split version of the former. Either way should work, but the Participants will need to maintain a degree of sync across cases if the case is split. GI messages carry most of the burden here. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_105.md b/docs/topics/user_stories/story_2022_105.md index c5e6cd00..575070df 100644 --- a/docs/topics/user_stories/story_2022_105.md +++ b/docs/topics/user_stories/story_2022_105.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The vendor treating the case as multiple reports is doable within the current protocol. It makes the embargo negotiation a bit more complex, but we address that in the case split/merger discussion in the embargo chapter. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_106.md b/docs/topics/user_stories/story_2022_106.md index 3bcfd822..c4a4022d 100644 --- a/docs/topics/user_stories/story_2022_106.md +++ b/docs/topics/user_stories/story_2022_106.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not impose a structure to its implementation aside from the assumption that case participants are in a shared broadcast domain. This should work equally well whether individual participants follow a "copy all" approach using any communication channel or if they agree to use a centrally located resource following a blackboard pattern. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/story_2022_107.md b/docs/topics/user_stories/story_2022_107.md index 580d4961..2b405155 100644 --- a/docs/topics/user_stories/story_2022_107.md +++ b/docs/topics/user_stories/story_2022_107.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol doesn't directly reflect a Vendor or product's vulnerability status. Instead, it reflects the Vendor's status with respect to the Report. We expect that each RM message type will be accompanied by content that indicates any reasons or necessary explanation for why a particular state change occurred. E.g., "RI: report is invalid because none of our products are affected." Or "RV: This report affects the following of our products..." - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Product vulnerability status - **Roles:** Vendor - **Phases:** Validation and Prioritization, Analysis and Remediation -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_108.md b/docs/topics/user_stories/story_2022_108.md index 5558fb69..802ee957 100644 --- a/docs/topics/user_stories/story_2022_108.md +++ b/docs/topics/user_stories/story_2022_108.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not provide a report or advisory publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Product vulnerability status - **Roles:** Vendor - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_109.md b/docs/topics/user_stories/story_2022_109.md index 8f44d279..6e9fa372 100644 --- a/docs/topics/user_stories/story_2022_109.md +++ b/docs/topics/user_stories/story_2022_109.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol doesn't directly reflect a Vendor or product's vulnerability status. Instead, it reflects the Vendor's status with respect to the Report. We expect that each RM message type will be accompanied by content that indicates any reasons or necessary explanation for why a particular state change occurred. E.g., "RI: report is invalid because none of our products are affected." Or "RV: This report affects the following of our products..." - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Product vulnerability status - **Roles:** Vendor - **Phases:** Validation and Prioritization, Analysis and Remediation -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_110.md b/docs/topics/user_stories/story_2022_110.md index 80973013..a25946b0 100644 --- a/docs/topics/user_stories/story_2022_110.md +++ b/docs/topics/user_stories/story_2022_110.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* The protocol does not provide a report or advisory publication mechanism. - ## Metadata ## Following is additional information compiled from our original design materials. @@ -19,7 +18,7 @@ We are including it here for future reference and traceability. - **Potential future process or service:** Product vulnerability status - **Roles:** Vendor - **Phases:** Public Awareness -- **Categories:** +- **Categories:** --- diff --git a/docs/topics/user_stories/story_2022_111.md b/docs/topics/user_stories/story_2022_111.md index 78737592..38e7f3f3 100644 --- a/docs/topics/user_stories/story_2022_111.md +++ b/docs/topics/user_stories/story_2022_111.md @@ -8,7 +8,6 @@ *(as of v0.4.0)* You probably want SBOM, this protocol isn't going to help you with that problem. - ## Metadata ## Following is additional information compiled from our original design materials. diff --git a/docs/topics/user_stories/table.md b/docs/topics/user_stories/table.md index 9de788c7..65cf9950 100644 --- a/docs/topics/user_stories/table.md +++ b/docs/topics/user_stories/table.md @@ -5,9 +5,8 @@ - :material-close: - Unsupported - :material-block-helper: - Out-of-scope - -| ID | Title | Status | -|-------------------------------|--------------------------------------------------------------------------------------------------------------------------|:-----------------------:| +| ID | Title | Status | +|-------------------------------|--------------------------------------------------------------------------------------------------------------------------|:-----------------------:| | [2022_001](story_2022_001.md) | {% include-markdown "./story_2022_001.md" start="" end="" trailing-newlines=false %} | :material-check: | | [2022_002](story_2022_002.md) | {% include-markdown "./story_2022_002.md" start="" end="" trailing-newlines=false %} | :material-check-all: | | [2022_003](story_2022_003.md) | {% include-markdown "./story_2022_003.md" start="" end="" trailing-newlines=false %} | :material-check: | diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index 3a16e9c8..d257beef 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -6,7 +6,6 @@ We will add tutorials here as we develop them. If you have a suggestion for a tutorial, please [open an issue](https://github.com/CERTCC/Vultron/issues) to let us know. - In the mean time: - If you are unfamiliar with the Vultron Protocol, we recommend that you start with [Understanding Vultron](../topics/index.md). From 056ac5978dba347eab7b040272c0e76381593d2e Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 27 Oct 2023 11:12:56 -0400 Subject: [PATCH 2/6] Update lint_md_changes.yml --- .github/workflows/lint_md_changes.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/workflows/lint_md_changes.yml b/.github/workflows/lint_md_changes.yml index 5c85b77d..2000bb03 100644 --- a/.github/workflows/lint_md_changes.yml +++ b/.github/workflows/lint_md_changes.yml @@ -18,3 +18,5 @@ jobs: with: globs: ${{ steps.changed-files.outputs.all_changed_files }} separator: "," + config: .markdownlint-cli2.yaml + From 10c9398b92539db0c9370dadac27efb23238ab6c Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 27 Oct 2023 11:13:37 -0400 Subject: [PATCH 3/6] Create .markdownlint-cli2.yaml --- .markdownlint-cli2.yaml | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 .markdownlint-cli2.yaml diff --git a/.markdownlint-cli2.yaml b/.markdownlint-cli2.yaml new file mode 100644 index 00000000..1402a240 --- /dev/null +++ b/.markdownlint-cli2.yaml @@ -0,0 +1,5 @@ +config: + "MD013": false + "MD033": false + "MD041": false + "MD051": false From bfde358b716c3dbae9466f8ed4c026abccb69019 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 27 Oct 2023 11:17:02 -0400 Subject: [PATCH 4/6] Update .markdownlint-cli2.yaml ignore MD046 --- .markdownlint-cli2.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/.markdownlint-cli2.yaml b/.markdownlint-cli2.yaml index 1402a240..a13b06dc 100644 --- a/.markdownlint-cli2.yaml +++ b/.markdownlint-cli2.yaml @@ -2,4 +2,5 @@ config: "MD013": false "MD033": false "MD041": false + "MD046": false "MD051": false From f6f8b586f8a5fed8ad6620d54cbe7457fb696fe1 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 27 Oct 2023 11:20:44 -0400 Subject: [PATCH 5/6] fix readme.md linter errors --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index a9ad54ae..c2446afd 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ together to coordinate appropriate responses to vulnerabilities. Vultron is a collection of ideas, models, code, and work in progress, and is not yet ready for production use. -# Background and related work +## Background and related work Vultron is a continuation of the [CERT/CC](https://www.sei.cmu.edu/about/divisions/cert/index.cfm)'s work on improving the coordination of vulnerability disclosure and response. Our previous work in this area includes: @@ -42,7 +42,7 @@ derived from both our process modeling work and from the experience of building That same year, we published [Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198), which serves as the basis for the work contained in this repository. -# So what _is_ Vultron? +## So what _is_ Vultron? Vultron is: @@ -62,7 +62,7 @@ Currently, the work is focused on mapping the formal protocol onto the syntax an protocol. Examples of our first steps in that direction can be found in [doc/examples](doc/examples) -# What is Vultron _not_? +## What is Vultron _not_? Vultron is **not** a drop-in replacement for any particular @@ -80,7 +80,7 @@ prioritization schemes like [SSVC](https://github.com/CERTCC/SSVC) and [CVSS](ht Vultron is not intended to be a product, rather it's meant to be a feature set that can be implemented in a variety of CVD-related products and services to enable interoperability between them. -# Other CERT CVD Resources +## Other CERT CVD Resources For more about our work in modeling, formalizing, and describing the CVD process, see: @@ -97,7 +97,7 @@ For more about our work in modeling, formalizing, and describing the CVD process is an older talk which looks at a number of prior models of the CVD process, and shows some of our early attempts to formally describe the concurrency aspects of the CVD process. -# License and Copyright +## License and Copyright We are still working out the correct licensing model for this effort, but for now, this repository is covered by the included [copyright statement](COPYRIGHT.md). From fafed868a286fc2c904a64e605cd730409bf6813 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 27 Oct 2023 11:24:21 -0400 Subject: [PATCH 6/6] fix markdownlint-cli2 errors --- .../pull_request_template.md | 5 ++- docs/adr/adr-template.md | 41 ++++++++++--------- docs/howto/case_object.md | 2 +- docs/topics/background/index.md | 6 +-- docs/topics/formal_protocol/worked_example.md | 26 ++++++------ 5 files changed, 42 insertions(+), 38 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md b/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md index 098c42e9..d60c63ce 100644 --- a/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md +++ b/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md @@ -1 +1,4 @@ -Please note: Pull request submissions are subject to our [Contribution Instructions](https://github.com/CERTCC/Vultron/blob/main/ContributionInstructions.md). \ No newline at end of file + +--- +Please note: Pull request submissions are subject to our +[Contribution Instructions](https://github.com/CERTCC/Vultron/blob/main/ContributionInstructions.md) diff --git a/docs/adr/adr-template.md b/docs/adr/adr-template.md index 054289ad..336b4775 100644 --- a/docs/adr/adr-template.md +++ b/docs/adr/adr-template.md @@ -6,6 +6,7 @@ deciders: {list everyone involved in the decision} consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication} informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication} --- + # {short title of solved problem and solution} ## Context and Problem Statement @@ -16,16 +17,16 @@ informed: {list everyone who is kept up-to-date on progress; and with whom there ## Decision Drivers -* {decision driver 1, e.g., a force, facing concern, …} -* {decision driver 2, e.g., a force, facing concern, …} -* … +- {decision driver 1, e.g., a force, facing concern, …} +- {decision driver 2, e.g., a force, facing concern, …} +- … ## Considered Options -* {title of option 1} -* {title of option 2} -* {title of option 3} -* … +- {title of option 1} +- {title of option 2} +- {title of option 3} +- … ## Decision Outcome @@ -35,9 +36,9 @@ Chosen option: "{title of option 1}", because ### Consequences -* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} -* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} -* … +- Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} +- Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} +- … ## Validation @@ -52,22 +53,22 @@ Chosen option: "{title of option 1}", because {example | description | pointer to more information | …} -* Good, because {argument a} -* Good, because {argument b} +- Good, because {argument a} +- Good, because {argument b} -* Neutral, because {argument c} -* Bad, because {argument d} -* … +- Neutral, because {argument c} +- Bad, because {argument d} +- … ### {title of other option} {example | description | pointer to more information | …} -* Good, because {argument a} -* Good, because {argument b} -* Neutral, because {argument c} -* Bad, because {argument d} -* … +- Good, because {argument a} +- Good, because {argument b} +- Neutral, because {argument c} +- Bad, because {argument d} +- … ## More Information diff --git a/docs/howto/case_object.md b/docs/howto/case_object.md index 651595ae..3cf79e50 100644 --- a/docs/howto/case_object.md +++ b/docs/howto/case_object.md @@ -228,7 +228,7 @@ teardown procedure as a consequence. On the contrary the `-` on `emit_message` conveys that this capability is only accessible to the `Participant` class itself (i.e., each `Participant` gets to decide if, when, and what messages to send). -#### `Vendor` and `Deployer` `Participant` Classes +### `Vendor` and `Deployer` `Participant` Classes The presence of the `VendorParticipant` and `DeployerParticipant` classes---depicted as implementations of the `Participant` class---is diff --git a/docs/topics/background/index.md b/docs/topics/background/index.md index 1667b820..6c77b2c0 100644 --- a/docs/topics/background/index.md +++ b/docs/topics/background/index.md @@ -28,7 +28,7 @@ Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD): The CVD process continues until the answers to these questions are "nothing," and "nobody." -### CVD *Is* MPCVD, and MPCVD *Is* CVD +## CVD *Is* MPCVD, and MPCVD *Is* CVD Any given CVD case is made up of many individual disclosure events, for example, @@ -51,7 +51,7 @@ $N_{vendors} \geq 1$ and for which the "traditional" CVD case is merely a special (and often simpler) case where $N_{vendors} = 1$. -### Context of Our Recent Work +## Context of Our Recent Work This documentation, in the context of recent CVD work at the [CERT/CC](https://www.sei.cmu.edu/about/divisions/cert/index.cfm), @@ -80,7 +80,7 @@ Whereas the [*CVD Guide*](https://vuls.cert.org/confluence/display/CVD) offers a process and the many scenarios one can expect to encounter as a Participant therein, in this documentation we provide an additional layer of formality in the form of a *protocol* for MPCVD. -### What We Mean by *Protocol* +## What We Mean by *Protocol* We first define what we mean by our use of the term *protocol* by providing a few common usages from the [Oxford English Dictionary](https://www.oed.com/). diff --git a/docs/topics/formal_protocol/worked_example.md b/docs/topics/formal_protocol/worked_example.md index ce51074a..fe20f79b 100644 --- a/docs/topics/formal_protocol/worked_example.md +++ b/docs/topics/formal_protocol/worked_example.md @@ -5,7 +5,7 @@ Here we give a brief worked example showing a few usage scenarios of the [protocol](../../reference/formal_protocol/index.md). We use UML Sequence Diagrams to show the interaction between Participant roles. -### A Finder Becomes a Reporter +## A Finder Becomes a Reporter As mentioned in [RM Interactions](../process_models/rm/rm_interactions.md#the-secret-lives-of-finders), Finders have a few hidden state @@ -44,11 +44,11 @@ sequenceDiagram Vendor -->> Finder: RK, EK, CV ``` -### Vendor Evaluates Embargo {#sec:vendor_eval_embargo_seq} +## Vendor Evaluates Embargo {#sec:vendor_eval_embargo_seq} In this section, we show a variety of responses a Vendor might have to an embargo proposal. -#### Vendor Accepts Embargo +### Vendor Accepts Embargo First is a basic accept sequence in which the Vendor accepts the proposed embargo and tells the Reporter this through an _EA_ message. The Reporter acknowledges this with an _EK_ in response. @@ -70,7 +70,7 @@ sequenceDiagram deactivate Vendor ``` -#### Vendor Rejects Embargo +### Vendor Rejects Embargo Next we show a rejected proposal. As above, this is a simple sequence where the Vendor indicates their rejection of the proposal with an _ER_ message, and the Reporter acknowledges this with an _EK_ message. @@ -88,7 +88,7 @@ sequenceDiagram Reporter -->> Vendor: EK ``` -#### Vendor Counterproposal +### Vendor Counterproposal Here we demonstrate a Vendor embargo counterproposal. The Vendor responds to the Reporter's prior _EP_ message with an _EP_ message of their own. The Reporter initially @@ -117,7 +117,7 @@ sequenceDiagram deactivate Reporter ``` -#### Vendor Accepts then Proposes Revision +### Vendor Accepts then Proposes Revision !!! tip inline end "Yes, And..." @@ -157,11 +157,11 @@ sequenceDiagram deactivate Reporter ``` -### Vendor Sets Priority +## Vendor Sets Priority Here we show two responses from a Vendor in the course of prioritizing a report. -#### Vendor Accepts Report +### Vendor Accepts Report This figure shows a Vendor accepting the report for further work (presumably to develop a patch) with an _RA_ message. @@ -176,7 +176,7 @@ sequenceDiagram Reporter -->> Vendor: RK ``` -#### Vendor Defers Report +### Vendor Defers Report On the contrary, this figure shows the Vendor deferring the report with an _RD_ message. In both cases, the Reporter acknowledges the Vendor's messages with an _RK_ message. @@ -192,7 +192,7 @@ sequenceDiagram Reporter -->> Vendor: RK ``` -### Coordination With a Coordinator {#sec:coordinating_with_coordinator} +## Coordination With a Coordinator {#sec:coordinating_with_coordinator} The next two diagrams show the process of a Reporter engaging a Coordinator, who, in turn, engages a Vendor. The process begins in the first diagram with the Reporter sending a report along with an embargo proposal to the Coordinator @@ -281,7 +281,7 @@ sequenceDiagram deactivate Reporter ``` -### Embargo Teardown, Publish, and Close +## Embargo Teardown, Publish, and Close Any Participant can initiate an embargo teardown. We happened to show the case where the Coordinator initiates it in the following diagram, sending an embargo @@ -315,7 +315,7 @@ sequenceDiagram With the recognition that more concise publication scheduling might be needed in some situations, we revisit this concern in [Process Implementation Notes](../../howto/process_implementation.md). -#### Publishing After Embargo Teardown +### Publishing After Embargo Teardown Once the embargo has been exited, any Participant may now publish. In the following figure, we show the Vendor publishing first. @@ -354,7 +354,7 @@ sequenceDiagram that there was nothing further to be done. This will not always be the case, nor is it necessary. -#### Closing the Case +### Closing the Case Having no further work to be done on the case, the Reporter closes their report and tells the Coordinator using an _RC_ message in the next diagram.