Move assessments to community/assessments

Signed-off-by: Andrés Vega <[email protected]>

assessments/README.md → community/assessments/README.md

@@ -1,62 +1,64 @@
-# TAG-Security Security Assessment (TSSA) Process 
+# TAG-Security Security Assessment (TSSA) Process
 
 ## Goals
 
-The [TAG-Security Security Assessment Process](guide) (formerly the security 
-review process) is designed to accelerate the adoption of cloud native 
+The [TAG-Security Security Assessment Process](guide) (formerly the security
+review process) is designed to accelerate the adoption of cloud native
 technologies based on the below goals and assumptions:
 
 ### 1) Reduce risk across the ecosystem
 
 The primary goal is to minimize the risk of malicious attacks and accidental privacy
 breaches. This process achieves this in two ways:
 
-   * Improve detection and resolution of vulnerabilities through a clear communication
+* Improve detection and resolution of vulnerabilities through a clear communication
      process.
-   * Enhance domain expertise in participating projects via collaborative assessments.
+* Enhance domain expertise in participating projects via collaborative assessments.
 
 ### 2) Accelerate adoption of cloud native technologies
 
-Security assessments are essential but time-intensive processes that each company, 
-organization, and project must perform to meet their unique commitments to users and 
-stakeholders. In open source, finding security-related information can be overwhelmingly 
-difficult and time-consuming. The CNCF TAG-Security Security Assessment Process, hereafter 
-“TSSA” Process, aims to enhance the discovery of security information and streamline 
+Security assessments are essential but time-intensive processes that each company,
+organization, and project must perform to meet their unique commitments to users and
+stakeholders. In open source, finding security-related information can be overwhelmingly
+difficult and time-consuming. The CNCF TAG-Security Security Assessment Process, hereafter
+“TSSA” Process, aims to enhance the discovery of security information and streamline
 internal and external assessments in multiple ways:
 
-   * Consistent documentation to reduce assessment time.
-   * Baseline of security information to minimize Q&A.
-   * A clear security profile rubric for organizations to align their risk profiles with
+* Consistent documentation to reduce assessment time.
+* Baseline of security information to minimize Q&A.
+* A clear security profile rubric for organizations to align their risk profiles with
      the project’s and allocate resources effectively (for assessment and needed project
      contribution).
-   * Structured metadata for navigation, grouping, and cross-linking.
+* Structured metadata for navigation, grouping, and cross-linking.
 
-This process is expected to raise awareness of how open source projects impact cloud native security; 
+This process is expected to raise awareness of how open source projects impact cloud native security;
 however, separate activities may be needed to achieve that purpose using materials generated by
 the TSSA, known as artifacts or the TSSA package.
 
 ## Outcome
 
 Each project's TSSA package shall include a description of the project's:
+
 1. Security design goals.
 2. Potential risks in design and configuration implementations.
 3. Known limitations including expectations that certain security aspects are managed by
    upstream or downstream dependencies or complementary software.
-5. Next steps to enhance the project's security and/or its contributions to a more secure
+4. Next steps to enhance the project's security and/or its contributions to a more secure
    cloud native ecosystem.
 
-Due to the nature and time frame of the analysis, *the TSSA package is not 
-meant to subsume the need for a professional security audit of the code*. Implementation-specific 
-vulnerabilities or improper deployment configurations are not in the scope of a TSSA. 
-Instead, the TSSA aims to uncover design flaws, enhance the project's security mindset, 
+Due to the nature and time frame of the analysis, *the TSSA package is not
+meant to subsume the need for a professional security audit of the code*. Implementation-specific
+vulnerabilities or improper deployment configurations are not in the scope of a TSSA.
+Instead, the TSSA aims to uncover design flaws, enhance the project's security mindset,
 and clearly document its design goals and intended security properties.
 
 ### Benefits of a TSSA
 
-Undergoing the TSSA Process is a key step toward eliminating security risks and integrating 
+Undergoing the TSSA Process is a key step toward eliminating security risks and integrating
 security as a fundamental aspect of your system over time.
 
 Key benefits of TSSA include:
+
 * Establishing a measurable security baseline.
 * Identifying and analyzing security issues and their risks.
 * Integrating a culture of security awareness among developers.
@@ -66,6 +68,7 @@ Key benefits of TSSA include:
 
 A complete TSSA package primarily consists of the following
 items:
+
 * [Self-assessment](guide/self-assessment.md): A written assessment by the project
 of the project's current security status.
 * [Joint-assessment](guide/joint-assessment.md): A hands-on assessment by both the [security
@@ -79,15 +82,15 @@ It is considered when performing due diligence.
 
 ### Use of a completed TSSA package
 
-A finalized TSSA package may assist the community in contextual project reviews, but 
-it is not an endorsement or audit of the project’s security. It does not exempt individuals 
-or organizations from conducting their own due diligence and complying with laws, regulations, 
+A finalized TSSA package may assist the community in contextual project reviews, but
+it is not an endorsement or audit of the project’s security. It does not exempt individuals
+or organizations from conducting their own due diligence and complying with laws, regulations,
 and policies.
 
-Draft assessments contain *unconfirmed* content and require peer review before being 
-committed to the repository. Draft documents may also contain *speculative* content as 
+Draft assessments contain *unconfirmed* content and require peer review before being
+committed to the repository. Draft documents may also contain *speculative* content as
 the project lead or security reviewer is performing an assessment.  
-Draft assessments are *only* for the purpose of preparing final artifacts and are **not** 
+Draft assessments are *only* for the purpose of preparing final artifacts and are **not**
 to be used in any other capacity by the community.
 
 Final presentation slides and the project's joint assessment
@@ -97,8 +100,8 @@ documentation and artifacts from the TSSA.  These folders can be found under
 
 ## Process
 
-Creating the TSSA package is a collaborative process that benefits both the project 
-and the community. The primary content is generated by the [project lead](guide/project-lead.md) 
+Creating the TSSA package is a collaborative process that benefits both the project
+and the community. The primary content is generated by the [project lead](guide/project-lead.md)
 and revised based on feedback from [security reviewers](guide/security-reviewer.md)
 and other members of the TAG.
 

assessments/guide/joint-assessment.md → community/assessments/guide/joint-assessment.md

@@ -244,12 +244,12 @@ section).
 
 ### Identity Theft
 
-|Victim Components | Server | Agent | Container on node | Container separate node |
-|--|--|--|--|--|
-| Victim Server | N/A | Score .11 : Mitigated, server has... | Score .11 : Mitigated,
-node has... | Score .11 : Mitigated, node has... |
-| Victim Agent | Score 57.5  None, significant issue... | Score. 11 : Mitigated, server
-has... | Score .11 : Mitigated, node has... | Score .11 : Mitigated, node has... |
+| Victim Components                | Server                                                                                                                                                              | Agent                                                                                                                                                                                                                     | Container (same node)                                                                                                                                                                                                                                                                           | Container (diff node)                                                                                                                                                                                                                                                              |
+|----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Victim Server                    | N/A: There is only one server                                                                                                                                        | "Mitigated: The server has validation in place to prevent it from signing CSRs for SPIFFE IDs that are not registered to a particular agent. Furthermore, there is validation to prevent an operator from erroneously registering the server's SPIFFE ID. Agents always validate the server's SPIFFE ID when connecting to it. Score: 0.11" | "Mitigated: There is validation to prevent an operator from erroneously registering the server's SPIFFE ID. Score: 0.11"                                                                                                                                                                        | "Mitigated: There is validation to prevent an operator from erroneously registering the server's SPIFFE ID. Score: 0.11"                                                                                                                                                                        |
+| Victim Agent                     | "NONE: The server has the signing keys and can issue new identities at will. Score: 57.5"                                                                            | "Mitigated: The server has validation in place to prevent it from signing CSRs for SPIFFE IDs that are not registered to a particular agent. Furthermore, there is validation to prevent an operator from erroneously registering a SPIFFE ID representing an agent. Score: 0.115"                       | "ESCAPE: If a container escape and privilege escalation can be performed, it is possible to read the agent's key from memory. Score: 0.63"                                                                                                                                                       | "Mitigated: There is validation to prevent an operator from erroneously registering the agent's SPIFFE ID. Score: 0.115"                                                                                                                                                                       |
+| Victim Container (same node)     | "NONE: The server has the signing keys and can issue new identities at will. Score: 5.5"                                                                             | "NONE: Agent controls the keys and certificates for all containers authorized to run on it. Score: 5.5"                                                                                                                                                          | "ESCAPE: If a container escape and privilege escalation can be performed, it is possible to read neighboring container's keys from memory. Score: 0.231"                                                                                                                                         | "ESCAPE: A container can be authorized to run on multiple nodes. If the container in question is authorized to run on the node with the evil container, then the evil container can obtain a certificate representing the victim container by reading keys from the memory of the local agent. Score: 0.525"                      |
+| Victim Container (diff node)     | "NONE: The server has the signing keys and can issue new identities at will. Score: 12.5"                                                                            | "NONE: A container can be authorized to run on multiple nodes. If the container in question is authorized to run on the node with the evil agent, then the evil agent can obtain a certificate representing the container. Score: 12.5 NOTE: This condition only occurs under certain configurations" | "ESCAPE: A container can be authorized to run on multiple nodes. If the container in question is authorized to run on the node with the evil container, then the evil container can obtain a certificate representing the victim container by reading keys from the memory of the local agent. Score: 0.525" | "ESCAPE: A container can be authorized to run on multiple nodes. If the container in question is authorized to run on the node with the evil container, then the evil container can obtain a certificate representing the victim container by reading keys from the memory of the local agent. Score: 0.525" |
 
 ### Compromise
 
@@ -289,14 +289,18 @@ formal assessment and are no guarantee of the actual security of the project.
 *If a hands-on assessment was performed, the below format should be used for
 reporting details*
 
-| | |
-| -- | -- |
-| Date of assessment | mmddyyyy-mmddyyyy |
-| Hands-on reviewers | name, github handle |
+### Assessment Details
+
+| Field               | Description               |
+|---------------------|---------------------------|
+| Date of assessment  | mmddyyyy-mmddyyyy         |
+| Hands-on reviewers  | name, github handle       |
+
+### Findings
 
-| Finding Number | Finding name | Finding Notes | Reviewer |
-| -- | -- | -- | -- |
-| | | |
+| Finding Number | Finding name | Finding Notes | Reviewer           |
+|----------------|--------------|---------------|--------------------|
+|                |              |               |                    |
 
 ### Hands-on assessment result
 

assessments/guide/joint-readme-template.md → community/assessments/guide/joint-readme-template.md

@@ -13,11 +13,11 @@ Project team:  _list name and github handle as appropriate_
 
 ## Background
 
-*Brief synopsys of the project, problem space, how the project solves the problem, can be pulled from the joint assessment.*
+_Brief synopsys of the project, problem space, how the project solves the problem, can be pulled from the joint assessment._
 
 ### Maturity
 
-*Use cases, integrations, etc. bulleted, should be available in the joint assessment.*
+_Use cases, integrations, etc. bulleted, should be available in the joint assessment._
 
 ## Summary
 
@@ -31,17 +31,17 @@ _refer to the existing readmes for other projects, such as [SPIFFE/SPIRE](https:
 
 ### CNCF recommendations
 
-* 
-* 
+*
+*
 
 ### Project recommendations
 
-* 
-* 
+*
+*
 
 ### Additional recommendations
 
-* 
-* 
+*
+*
 
-Tracking issue: *link to issue for assessment*
+Tracking issue: _link to issue for assessment_

assessments/guide/project-lead.md → community/assessments/guide/project-lead.md

@@ -8,8 +8,8 @@ interest in security.
 
 ## Time and effort
 
-The level of effort for the team providing the information is expected to be 
-around **80 hours** of work.  Note, projects that have already performed a 
+The level of effort for the team providing the information is expected to be
+around **80 hours** of work.  Note, projects that have already performed a
 security analysis internally are expected to have much lower requirements.
 
 ## Conflict of interest

assessments/guide/security-reviewer.md → community/assessments/guide/security-reviewer.md

@@ -93,6 +93,7 @@ or other details in the ticketed request for a project's joint assessment may
 require additional time. However, analysis is expected to be concluded in a
 few weeks -- usually 3 weeks.  Effort is expected to include and may not be
 limited to:
+
 * reviewing existing security documentation
 * reviewing ticketed request for project assessment
 * analysis of security assertions and assumptions
@@ -112,38 +113,40 @@ There is a possibility of a conflict of interest that can arise between a
 security reviewer and the project being assessed due to the closely-knit nature
 of the community. Having clear guidelines for conflict of interest situations
 are important to prevent:
-- Individuals from intentionally or unintentionally promoting their own
+
+* Individuals from intentionally or unintentionally promoting their own
 company's project
-- TAG-Security chairs and review leads intentionally or
+* TAG-Security chairs and review leads intentionally or
 unintentionally limiting the participation of an individual unfairly by
 asserting conflict of interest
-- Security reviews being stalled while groups belabor on who should be allowed
+* Security reviews being stalled while groups belabor on who should be allowed
 to participate
 
 The conflicts of interest lie on a spectrum, and are classified into hard and
 soft conflicts:
+
 * A hard conflict makes a reviewer ineligible to assess a project.
 * A soft conflict allows a reviewer to assess a project, but not as a
 [project lead](./project-lead.md).
 * It is not unusual for reviewers to have soft conflicts. The diversity of
 reviewers that are familiar with a project can provide a deeper insight
-together with a fresh set of eyes and is beneficial to the success of a 
+together with a fresh set of eyes and is beneficial to the success of a
 TAG-Security Security Assessment.
 
 All reviewers must provide a conflict declaration on the tracking issue to
 indicate which hard or soft conflicts do, or do not exist when they volunteer
 to be a reviewer.  This is done by placing a comment on the issue associated
 with the joint assessment using the table provided below.
 
-#### Conflict of interest statement template:
+### Conflict of interest statement template
+
 | Hard Conflicts | Y/N |
 | :------------- | :-: |
 | Reviewer is a currently a maintainer of the project |  |
 | Reviewer is direct report of/to a current maintainer of the project |  |
 | Reviewer is paid to work on the project |  |
 | Reviewer has significant financial interest directly ties to the success of the project |  |
 
-
 | Soft Conflicts | Y/N |
 | :------------- | :-: |
 | Reviewer belongs to the same company/organization of the project, but does not work on the project |  |
@@ -155,13 +158,14 @@ with the joint assessment using the table provided below.
 
 Should a conflict arise during the time of the assessment, reviewers should notify
 the lead security reviewer when they become aware of the potential conflict,
-so the new conflict may be consulted with the Security Assessment Facilitator 
+so the new conflict may be consulted with the Security Assessment Facilitator
 and/or chairs.
 
 ## Asserting team readiness to conduct a balanced assessment
 
 The lead security reviewer has the responsibility of ensuring a balanced assessment,
 and as part of that before kicking off the assessment must:
+
 * Check that all reviewers have conflict-of-interest declarations,
 * Provide their own declaration of any potential conflict-of-interest
 (or lack thereof),
@@ -188,4 +192,3 @@ participating in the assessment for which their hard conflict exists. Depending
  two chairs and the Security Assessment Facilitator may determine if the hard conflict
 may be waived.  Should this occur, the decision's justification will be documented
  to ensure it clearly depicts the circumstances for granting the waiver.
-