Incorporated appropriate sections from Issue #176 as well as consiste…

…ncy in font/language usage.
cncf · May 29, 2019 · 8563a01 · 8563a01
1 parent 6e30370
commit 8563a01
Showing 1 changed file with 26 additions and 15 deletions.
diff --git a/assessments/guide/outline.md b/assessments/guide/outline.md
@@ -36,11 +36,11 @@ could believe may be in scope (e.g., Flibble does not intend to stop a
 party with a key from storing an arbitrarily large amount of data, possibly
 incurring financial cost or overwhelming the servers)
 
-## Intended use
+## Intended Use
 
-* Target users and use cases. Provide a mapping from [standard personas](../../usecases.md) to the
+* Target Users and Use Cases. Provide a mapping from [standard personas](../../usecases.md) to the
 nomenclature used in your project docs (which you should then use consistently
-for the remaider of this document). Describe the scenarios in which the project is expected to be used. This must be specific enough to provide context for analysis. For example:
+for the remainder of this document). Describe the scenarios in which the project is expected to be used. This must be specific enough to provide context for analysis. For example:
 
     Flibble can be used in any cloud environment.  Three diverse examples are
     as follows:
@@ -52,35 +52,46 @@ for the remaider of this document). Describe the scenarios in which the project
 * Operation.  A description of the operational aspects of the system, such as
 how keys are likely to be managed and stored.
 
-## Project design
+## Project Design
 * Design.  A description of the system design that discusses how it works.
 This is especially critical for any mechanisms that relate to the security
-of the system.
+of the system.  Include architecture and network (if applicable) information such as encryption of traffic between services, access control types (RBAC, etc.) and enforcement, or security logging, etc.
 
-## Security analysis
-* Attacker motivations.  A discussion about the likely goals of an attacker.
+## Configuration and Set-Up
+* Default.  Documentation describing the default configuration of the project with initial set-up instructions (link to docs is acceptable). Documentation should identify potential security risks/trade-offs of the default config.
+* Secure. Documentation describing recommended secure configuration and set-up instructions, beyond defaults with justification for selection and trade-offs (link to docs is acceptable).
+* Advanced Secure. If applicable, documentation describing advanced settings for most hardened configuration of the project to include justification for selection and trade-offs (link to docs is acceptable).
+
+## Project Compliance
+* Compliance.  List any security standards or sub-sections the project is already documented as meeting (PCI-DSS, COBIT, ISO, GDPR, etc.).
+
+
+## Security Analysis
+* Attacker Motivations.  A discussion about the likely goals of an attacker as well as the kind of attacker (do not forget to invlude discussion of insider threat with trusted access to the project)
 This likely relates closely to the impact of different attacks in the
 scenarios.  (e.g., In the password hash case, the attacker wants to expose
 those hashes on the Flibble server.  However, a Flibble cloudlet attacker
 may find it more interesting to bring down the service.)
-* Expected attacker capabilities.  A description of likely capabilities that
+* Predisposing Conditions. A listing of potential vulnerabilities and configurations of the project that could potentially be exploited or used correctly to result in an increased likelihood of attack success. Include any established trusts with other projects as a potential vulnerable point from a pivoted attack (i.e. compromise of the LDAP results in loss of access control integrity for the project)
+* Expected Attacker Capabilities.  A description of likely capabilities that
 the attacker has in these scenarios should be described.  Both assumptions
 about the strength and limitations of attackers should be described.
 (e.g., We assume that an attacker may be able to exploit implementation
 errors in some set of the servers to take control of them.  However, we
 assume the attacker cannot break AES or SHA256.)
-* Attack risks and effects.  A rough estimation of the risk posed by different attacks, and potential negative consequences.
+* Attack Risks and Effects.  A rough estimation of the risk posed by different attacks, and potential negative consequences.
 (e.g., The master Flibble server only communicates with Flibble servers
 using a minimalistic API that is formally verified and written in Rust.)
-* Security degradation.  A discussion about the resulting security when
+* Security Degradation.  A discussion about the resulting security when
 various attacks are launched.  Note, that no system is secure in all
 scenarios, hence it is expected that this will include areas where attacks
 compromise all meaningful security.  (e.g., If an attacker is able to
 compromise the “master” Flibble server, they may read, write, or delete any
 content stored on any system)
+* Compensating Mechanisms.  Additional architectural decisions, configuration settings, options, etc. designed to reduce overall attack vector and success (minimize impact)
 
-## Secure development practices
-* Development pipeline.  A description of the testing and review processes
+## Secure Development Practices
+* Development Pipeline.  A description of the testing and review processes
 that the software undergoes as it is developed and built.
 * Communication Channels. Reference where you document how to reach your
 team or describe in corresponding section.
@@ -94,15 +105,15 @@ encryption by default.)
 
 ## Roadmap
 
-* Project next steps. Link to your general roadmap, if available, then list
+* Project Next Steps. Link to your general roadmap, if available, then list
 prioritized next steps that may have an impact on the risk profile of your
 project, including anything that was identified as part of this review.
-* CNCF requests. In the initial draft, please include whatever you believe
+* CNCF Requests. In the initial draft, please include whatever you believe
 the CNCF could assist with that would increase security of the ecosystem.
 
 ## Appendix
 
-* Known Issues over time. List or sumarize statistics of past vulerabilities
+* Known Issues Over Time. List or sumarize statistics of past vulerabilities
 with links. If none have been reported, provide data, if any, about your
 track record in catching issues in code review or automated testing.
 * CII Best Practices. A brief discussion of where the project is at with