Skip to content
Permalink
Browse files
Incorporated appropriate sections from Issue #176 as well as consiste…
…ncy in font/language usage.
  • Loading branch information
Emily Fox committed May 29, 2019
1 parent 6e30370 commit 8563a0142b4cd480a20ffc2cd547628d2c10fb39
Showing 1 changed file with 26 additions and 15 deletions.
@@ -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

0 comments on commit 8563a01

Please sign in to comment.