Add content from State paper (#102)

* pandoc techreport.tex -o test.md

* add notes for repro

* split big file by h1

* rename files

* strip acronym junk (+1 squashed commit)
Squashed commits:
[85d0d19] strip acronym junk

* add ascii flag to bt tree output

* merging in the state based paper part 1 of ?

* turn refs into todos

* show parallelism

* split model and transitions

* refs -> todo

* merge in content

* update nav

* make eqrefs into todos

* keep expanding measuring cvd section

* remove superfluous files

* define 0day

* vep definitions

* cvd stakeholder roles

* policy formalization

* situation awareness

* add todo to possibly merge

* fix broken refs

* relocate file

* add action rules

* remove file after refactor

* reorganize nav

* Run markdownlint on content

markdownlint-cli2 --config .markdownlint-cli2.yaml --fix "**/*.md" "#node_modules"

* global replace format cruft

* mdlint

* link fixes

* mdlint

* reorder nav

* clean up events.md

* replacing references with links

* fix up cvd guide links

* sec:desirability

* catch up to cvd guide

* refactor table to include

* clean up discriminating_skill_and_luck.md

* fix link warnings

* wip cleanup

* event frequency table

* add images from paper

* continue refining measuring section

* continue refining measuring section

* continue refining measuring section

* fixup observing_skill.md

* finish up measuring_cvd section

* clean up roles_influence.md

* clean up zero_day.md

* clean up situation_awareness.md

* clean up policy_formalization.md

* clean up vep.md

* clean up action_rules.md

* mdlint

* wrapping up

* clean up cruft

* clean up cruft

* remove superfluous line

* remove environment dependency

* black python

* update requirements.txt

* restore env check

Acknowledgements.md

@@ -4,7 +4,7 @@ This work builds upon the following prior works:
 
 | Work                                                                                            | Authors | URL                                                                                                       |
 |-------------------------------------------------------------------------------------------------| ------- |-----------------------------------------------------------------------------------------------------------|
-| The CERT Guide to Coordinated Vulnerability Disclosure                                          | Allen D. Householder, Garret Wassermann, Art Manion, Christopher King | <https://doi.org/10.1184/R1/12367340.v1><br/>2019 Update: <https://vuls.cert.org/confluence/display/CVD>  |
+| The CERT Guide to Coordinated Vulnerability Disclosure                                          | Allen D. Householder, Garret Wassermann, Art Manion, Christopher King | <https://doi.org/10.1184/R1/12367340.v1><br/>2019 Update: <https://certcc.github.io/CERT-Guide-to-CVD>  |
 | A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)                | Allen D. Householder and Jonathan Spring | <https://doi.org/10.1184/R1/16416771>                                                                     |
 | Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures | Allen D. Householder and Jonathan Spring | <https://doi.org/10.1145/3477431>                                                                         |
 | Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)      | Allen D. Householder | <https://doi.org/10.1184/R1/19852798>                                                                     |

README.md

@@ -16,7 +16,7 @@ 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 2.0](https://vuls.cert.org/confluence/display/CVD)
+[Version 2.0](https://certcc.github.io/CERT-Guide-to-CVD)
 )
 - Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC)
 ([Version 1.0](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=636379),
@@ -87,7 +87,7 @@ For more about our work in modeling, formalizing, and describing the CVD process
 - [Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=887198) (2022) is the initial Vultron report.
   - [SEI Blog post on Vultron](https://insights.sei.cmu.edu/blog/vultron-a-protocol-for-coordinated-vulnerability-disclosure/) (2022-09-26)
   - [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)
+- [CERT Guide to Coordinated Vulnerabilty Disclosure](https://certcc.github.io/CERT-Guide-to-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)
 - [Coordinated Vulnerability Disclosure User Stories](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=886543) (2022)

docs/_acronyms/index.md

@@ -0,0 +1,193 @@
+<!-- 
+Try to keep these alphabetized.
+However, if you add an acronym that is a subset of another acronym,
+add the longer string first. (E.g., CERT/CC before CERT.) The matching
+stops after the first match is found.
+-->
+*[ACM]: Association for Computing Machinery
+*[AFB]: Air Force Base
+*[AFLCMC]: Air Force Life Cycle Management Center
+*[AI]: Artificial Intelligence
+*[AMA]: Ask Me Anything
+*[API]: Application Programming Interface
+*[ASCII]: American Standard Code for Information Interchange
+*[ATMs]: Automated Teller Machines
+*[ATM]: Automated Teller Machine
+
+*[BCP]: Best Current Practice
+*[BFF]: CERT Basic Fuzzing Framework
+*[BGP]: Border Gateway Protocol
+*[BIND]: Berkeley Internet Name Domain
+*[BOD]: Binding Operational Directive
+
+*[CAPEC]: Common Attack Pattern Enumeration and Classification
+*[CA]: Certificate Authority
+*[CERT/CC]: CERT Coordination Center, a part of the Software Engineering Institute at Carnegie Mellon University
+*[CERT]: The CERT Division of the Software Engineering Institute
+*[CISA]: Cybersecurity and Infrastructure Security Agency, a part of the U.S. Department of Homeland Security
+*[CI]: Continuous Integration
+*[CD]: Continuous Deployment
+*[CMU]: Carnegie Mellon University
+*[CNAs]: CVE Numbering Authorities
+*[CNA]: CVE Numbering Authority
+*[COPPA]: Children's Online Privacy Protection Act
+*[CPE]: Common Platform Enumeration
+*[CSAF]: Common Security Advisory Framework
+*[CSIRTs]: Computer Security Incident Response Teams
+*[CSIRT]: Computer Security Incident Response Team
+*[CS]: Case State
+*[MPCVD]: Multi-Party Coordinated Vulnerability Disclosure
+*[CVD]: Coordinated Vulnerability Disclosure
+*[CVE]: Common Vulnerabilities and Exposures
+*[CVRF]: Common Vulnerability Reporting Format, superseded by the Common Security Advisory Framework (CSAF)
+*[CVSS]: Common Vulnerability Scoring System
+*[CWE]: Common Weakness Enumeration
+*[CWSS]: Common Weakness Scoring System
+
+*[DFAs]: Deterministic Finite Automata
+*[DFA]: Deterministic Finite Automaton
+*[DFIR]: Digital Forensics and Incident Response
+*[DHS]: U.S. Department of Homeland Security
+*[DNS]: Domain Name System
+*[DoD]: U.S. Department of Defense
+*[DoJ]: U.S. Department of Justice
+*[DDoS]: Distributed Denial of Service
+*[DoS]: Denial of Service
+
+*[EFF]: Electronic Frontier Foundation
+*[EM]: Embargo Management
+*[ENISA]: European Union Agency for Cybersecurity
+*[EoL]: End of Life
+*[EOL]: End of Life
+*[EO]: Executive Order
+*[EU]: European Union
+
+*[FAQ]: Frequently Asked Questions
+*[FCC]: U.S. Federal Communications Commission
+*[FBI]: U.S. Federal Bureau of Investigation
+*[FDA]: U.S. Food and Drug Administration
+*[FERPA]: Family Educational Rights and Privacy Act
+*[FIRST]: Forum of Incident Response and Security Teams
+*[FI]: Finland
+*[FTC]: U.S. Federal Trade Commission
+*[FTP]: File Transfer Protocol
+
+*[GnuPG]: GNU Privacy Guard, an implementation of the OpenPGP standard
+*[GPG]: GNU Privacy Guard, an implementation of the OpenPGP standard
+
+*[HIPPA]: Health Insurance Portability and Accountability Act
+*[HTML]: Hyper Text Markup Language
+*[HTTP]: Hyper Text Transfer Protocol
+*[HTTPS]: Hyper Text Transfer Protocol Secure
+*[HVAC]: Heating, Ventilation, and Air Conditioning
+
+*[IEC]: International Electrotechnical Commission
+*[IEEE]: Institute of Electrical and Electronics Engineers
+*[IETF]: Internet Engineering Task Force
+*[IoT]: Internet of Things
+*[IP]: Internet Protocol
+*[ISACs]: Information Sharing and Analysis Centers
+*[ISAC]: Information Sharing and Analysis Center
+*[ISAOs]: Information Sharing and Analysis Organizations
+*[ISAO]: Information Sharing and Analysis Organization
+*[ISO]: International Organization for Standardization
+*[ISPs]: Internet Service Providers
+*[ISP]: Internet Service Provider
+
+*[JPCERT/CC]: Japan Computer Emergency Response Team Coordination Center
+*[JSON]: JavaScript Object Notation
+*[JTAG]: Joint Test Action Group
+*[JVN]: Japan Vulnerability Notes
+
+*[ML]: Machine Learning
+*[MON]: The Monitoring Process Area of the CERT Resilience Management Model
+*[MPLS]: Multiprotocol Label Switching
+
+*[NCSC]: National Cyber Security Centre
+*[NDAs]: Non-Disclosure Agreements
+*[NDA]: Non-Disclosure Agreement
+*[NHTSA]: National Highway Traffic Safety Administration
+*[NIAC]: National Infrastructure Advisory Council
+*[NIST]: National Institute of Standards and Technology
+*[NL]: The Netherlands
+*[NTIA]: National Telecommunications and Information Administration
+*[NTP]: Network Time Protocol
+*[NVD]: National Vulnerability Database
+
+*[OASIS]: Organization for the Advancement of Structured Information Standards
+*[OCTAVE]: Operationally Critical Threat, Asset, and Vulnerability Evaluation
+*[OpSec]: Operational Security
+*[OS]: Operating System
+*[OUSPG]: Oulu University Secure Programming Group
+
+*[PCI DSS]: Payment Card Industry Data Security Standard
+*[PGP]: Pretty Good Privacy
+*[PoC]: Proof of Concept Exploit
+*[PSIRTs]: Product Security Incident Response Teams
+*[PSIRT]: Product Security Incident Response Team
+
+*[REST]: Representational State Transfer
+*[RE]: Reverse Engineering
+*[RFCs]: Requests for Comments
+*[RFC]: Request for Comments
+*[RFID]: Radio Frequency Identification
+*[RMM]: The CERT Resilience Management Model
+*[RM]: Report Management
+
+*[SAAS]: Software as a Service
+*[SaaS]: Software as a Service
+*[SBOM]: Software Bill of Materials
+*[SCAP]: Security Content Automation Protocol
+*[SDLC]: Secure Development Lifecycle
+*[SDL]: Software Development Lifecycle
+*[SDR]: Software Defined Radio
+*[SEC]: U.S. Securities and Exchange Commission
+*[SEI]: Software Engineering Institute
+*[SERA]: Security Engineering Risk Analysis
+*[SIG]: Special Interest Group
+*[SLAs]: Service Level Agreements
+*[SLA]: Service Level Agreement
+*[SLEs]: Service Level Expectations
+*[SLE]: Service Level Expectation
+*[SMEs]: Subject Matter Experts
+*[SME]: Subject Matter Expert
+*[SMTP]: Simple Mail Transfer Protocol
+*[SNMP]: Simple Network Management Protocol
+*[SPDX]: Software Package Data Exchange
+*[SP]: Special Publication
+*[SR]: Special Report
+*[SSL]: Secure Sockets Layer
+*[SSVC]: Stakeholder-Specific Vulnerability Categorization
+*[STARTTLS]: Start Transport Layer Security, a protocol extension for upgrading a plaintext connection to a secure connection
+*[StartTLS]: Start Transport Layer Security, a protocol extension for upgrading a plaintext connection to a secure connection
+
+*[TCP]: Transmission Control Protocol
+*[TF-IDF]: Term Frequency-Inverse Document Frequency
+*[TLP]: Traffic Light Protocol
+*[TTPs]: Tactics, Techniques, and Procedures
+*[TTP]: Tactics, Techniques, and Procedures
+*[TLS]: Transport Layer Security
+*[TSIG]: Transaction Signature
+*[TVs]: Televisions
+*[TV]: Television
+
+*[UK]: United Kingdom
+*[URLs]: Uniform Resource Locators
+*[URL]: Uniform Resource Locator
+*[US]: United States
+
+*[VAR]: Vulnerability Analysis and Resolution, a process area of the CERT RMM
+*[VDBs]: Vulnerability Databases
+*[VDB]: Vulnerability Database
+*[VDPs]: Vulnerability Disclosure Programs
+*[VDP]: Vulnerability Disclosure Program
+*[VEP]: Vulnerability Equities Process
+*[VINCE]: Vulnerability Information and Coordination Environment
+*[VMs]: Virtual Machines
+*[VM]: Vulnerability Management
+*[VRF]: Vulnerability Reporting Form
+*[VR]: Vulnerability Response
+*[VU#]: CERT Vulnerability Note
+*[VXREF]: Vulnerability Cross-Reference
+
+*[W3C]: World Wide Web Consortium

docs/howto/case_object.md

@@ -268,7 +268,7 @@ One might reasonably expect `Contacts` to have names, email addresses, phone num
 
 The remainder of the class diagram above consists of classes representing the Role and Message Type flags and various enumerations.
 
-- 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).
+- 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://certcc.github.io/CERT-Guide-to-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.

docs/howto/index.md

@@ -22,7 +22,7 @@ suggestions for potential implementers.
 
     If you are unfamiliar with the Vultron Protocol, we recommend that you start with [Understanding Vultron](../topics/index.md).
     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/).
+    If you're just trying to understand the CVD process, we recommend that you start with the [CERT Guide to Coordinated Vulnerability Disclosure](https://certcc.github.io/CERT-Guide-to-CVD).
 
 In this section, you will find:
 

docs/includes/tab_exp_freq.md

@@ -0,0 +1,10 @@
+!!! info "Expected Frequency of ${row} \prec {col}$ when events are chosen uniformly from possible transitions in each state"
+
+    | | $\mathbf{V}$ | $\mathbf{F}$ | $\mathbf{D}$ | $\mathbf{P}$ | $\mathbf{X}$ | $\mathbf{A}$ |
+    |---|---|---|---|---|---|---|
+    | $\mathbf{V}$ | 0 | 1 | 1 | 0.333 | 0.667 | 0.750 |
+    | $\mathbf{F}$ | 0 | 0 | 1 | 0.111 | 0.333 | 0.375 |
+    | $\mathbf{D}$ | 0 | 0 | 0 | 0.037 | 0.167 | 0.187 |
+    | $\mathbf{P}$ | 0.667 | 0.889 | 0.963 | 0 | 0.500 | 0.667 |
+    | $\mathbf{X}$ | 0.333 | 0.667 | 0.833 | 0.500 | 0 | 0.500 |
+    | $\mathbf{A}$ | 0.250 | 0.625 | 0.812 | 0.333 | 0.500 | 0 |

docs/index.md

@@ -84,7 +84,7 @@ in detail.
 The Vultron Protocol is a continuation of the CERT/CC'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](https://vuls.cert.org/confluence/display/CVD)
+- [The CERT Guide to Coordinated Vulnerability Disclosure](https://certcc.github.io/CERT-Guide-to-CVD)
 - 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](https://kb.cert.org/vince/)

docs/reference/formal_protocol/messages.md

@@ -20,7 +20,7 @@ Revisiting the definitions from the [Formal Protocol Introduction](index.md):
     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
-[CVD Guide](https://vuls.cert.org/confluence/display/CVD/2.3.+Avoid+Surprise):
+[CVD Guide](https://certcc.github.io/CERT-Guide-to-CVD/topics/principles/avoid_surprise/):
 
 !!! quote "Avoid Surprise"
 

docs/reference/formal_protocol/states.md

@@ -623,7 +623,7 @@ states, as we show next.
 
 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://certcc.github.io/CERT-Guide-to-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.

docs/reference/index.md

@@ -10,7 +10,7 @@
      
     If you are unfamiliar with the Vultron Protocol, we recommend that you start with [Understanding Vultron](../topics/index.md).
     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/).
+    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://certcc.github.io/CERT-Guide-to-CVD).
 
 The Vultron Protocol Reference includes the formal Vultron Protocol specification, and crosswalks the
 protocol with other related standards and protocols, including:

docs/reference/ssvc_crosswalk.md

@@ -7,6 +7,8 @@ In the context of the Vultron Protocol, once a report has been validated
 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.
 
+{== TODO merge with SSVC section of [Situation Awareness](../topics/other_uses/situation_awareness.md) ==}
+
 ## SSVC Supplier and Deployer Trees
 
 The default outcomes for both the SSVC [*Supplier*](https://github.com/CERTCC/SSVC/blob/v2.1/doc/graphics/ssvc_2_supplier.pdf)
@@ -148,12 +150,14 @@ otherwise it should be *No*.
 
 !!! note "SSVC *Supplier Contacted* Decision Point Mapped to RM States"
 
-    $$SSVC(supp.~contacted) = 
+    $$
+    SSVC(supp.~contacted) = 
     \begin{cases}
         Yes & \iff q^{rm}_{Vendor} \not \in S \text{ or } q^{cs}_{Vendor} \in V\cdot\cdot\cdot\cdot\cdot \\
         \\
         No & \iff q^{rm}_{Vendor} \in S \text{ or } q^{cs}_{Vendor} \in vfd \cdot\cdot\cdot \\
-    \end{cases}$$
+    \end{cases}
+    $$
 
 ### Report Credibility
 
@@ -169,11 +173,30 @@ because "Valid-but-not-Credible" is a contradiction.
 
 !!! note "SSVC *Report Credibility* Decision Point Mapped to RM States"
 
-    $$SSVC(report~cred.) = 
+    $$
+    SSVC(report~cred.) = 
     \begin{cases}
         Credible & \text{implies }q^{rm} \xrightarrow{v} V \textrm{ (if validation also passes)}\\
         Not~Credible & \text{implies } q^{rm} \xrightarrow{i} I \\
-    \end{cases}$$
+    \end{cases}
+    $$
+
+### Public Value Added
+
+The SSVC *Public Value Added* decision point can take on the values *Precedence*, *Ampliative*, or *Limited*.
+*Precedence* means that publication adds value by providing information that is not widely known.
+*Ampliative* means that publication might providing additional information or reach to information that may or may not
+already be public.
+*Limited* means that publication impact might be limited because the information is already widely known.
+
+!!! note "SSVC *Public Value Added Decision Point Mapped to CS States"
+
+        $$ SSVC(pva) = 
+        \begin{cases}
+            Precedence & \iff q^{cs} \in \cdot\cdot\cdot p\cdot\cdot \\
+            Ampliative & \iff q^{cs} \in VFdp\cdot\cdot \textrm{ or } q^{cs} \in \cdot\cdot dP\cdot\cdot \\
+            Limited & \iff q^{cs} \in VF\cdot P\cdot \\
+        \end{cases}$$
 
 ### Supplier Engagement
 
@@ -319,3 +342,14 @@ 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_.
+
+!!! example "SSVC Decision Points and Anticipated Transitions"
+
+    Other SSVC decision points may be informative about which transitions to
+    expect in a case. Two examples apply here:
+
+    1. *Supplier Engagement*
+    acts to gauge the likelihood of the **F** transitions.
+    Coordination becomes more necessary the lower that likelihood is.
+    2. *Utility* (the usefulness of the exploit to the adversary) acts
+    to gauge the likelihood of the **A** transition.