Build Security Threat Analysis

Change-Id: I764f492e762901e1ed9889924645acf1f0bca241
This commit is contained in:
KATO Tomoyuki 2016-05-03 10:00:58 +09:00
parent d4507a9cec
commit 0ee1347bf9
7 changed files with 26 additions and 13 deletions

View File

@ -10,6 +10,7 @@ It includes these manuals:
* Security Guide
* Security Notes
* Security Threat Analysis
The Security Notes are published by the OpenStack Security Project (OSSP) to
advise users of security related issues. For more information refer
@ -22,9 +23,13 @@ https://security.openstack.org/vmt-process.html.
Directory Structure
-------------------
Security Guide is in the directory ``security-guide``, which source files in
RST format in the directory ``security-guide/source``.
Security Threat Analysis is in the directory ``security-guide``, which source
files in RST format in the directory ``security-threat-analysis/source``.
The security notes are in the directory ``security-notes``.

View File

@ -30,5 +30,6 @@ SPECIAL_BOOKS=(
# These are translated in openstack-manuals
["common"]="skip"
# Not translated
["security-threat-analysis"]="skip"
["security-notes"]="skip"
)

View File

@ -20,7 +20,6 @@ Contents
todo.rst
Search in this guide
~~~~~~~~~~~~~~~~~~~~

View File

@ -41,8 +41,8 @@ Preparing artifacts for review
Before the review
~~~~~~~~~~~~~~~~~
- Verify that the services architecture page contains all the sections listed
in the Architecture Page Template <link>.
- Verify that the services architecture page contains all the sections
listed in the Architecture Page Template <link>.
- The architecture page should include diagrams as specified in the
Architecture Diagram guidance <link>.
- Send an email to the openstack-dev@lists.openstack.org mailing list with a
@ -54,10 +54,12 @@ Before the review
Running the threat analysis review
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Identify the “scribe” role, who will record the discussion and any findings
in the etherpad.
- Identify the “scribe” role, who will record the discussion and any
findings in the etherpad.
- Ask the project architect to briefly describe the purpose of the service,
typical uses cases, who will use it and how it will be deployed. Identify the data assets that might be at risk, eg peoples photos, cat videos, databases. Assets in flight and at rest.
typical uses cases, who will use it and how it will be deployed.
Identify the data assets that might be at risk, eg peoples photos, cat
videos, databases. Assets in flight and at rest.
- Briefly consider potential abuse cases, what might an attacker want to use
this service for? Could an attacker use this service as a stepping stone to
attack other services? Do not spend too long on this section, as abuse cases
@ -79,16 +81,16 @@ Running the threat analysis review
vulnerabilities, is the implementation in use maintained? Is this protocol
used as a security control to provide confidentiality, integrity or
availability?
#. Can this interface be used as an entry point to the system, can an attacker
use it to attack a potentially vulnerable service? If so, consider what
additional controls should be applied to limit the exposure.
#. Can this interface be used as an entry point to the system, can an
attacker use it to attack a potentially vulnerable service? If so,
consider what additional controls should be applied to limit the exposure.
#. If an attacker was able to compromise a given component, what would that
enable them to do? Could they stepping-stone through the OpenStack cloud?
#. How is the service administered? Is this a secure path, with appropriate
authentication and authorization controls?
- Once the reviewers are familiar with the service, re-consider abuse cases, are
there any other cases which should be considered and mitigated?
- Once the reviewers are familiar with the service, re-consider abuse cases,
are there any other cases which should be considered and mitigated?
- Step through typical use-case diagrams. Again consider if sensitive data is
appropriately protected. Where an entry point is identified, consider how
risks of malicious input data can be mitigated.

View File

@ -11,7 +11,10 @@
Project Description and Purpose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Brief description of the purpose of the project; about a paragraph, can be cut/paste from wiki or other documentation. Include links to relevant presentations if available. Remove this comment>.
<Brief description of the purpose of the project; about a paragraph,
can be cut/paste from wiki or other documentation. Include links to
relevant presentations if available. Remove this comment>.
Primary Users

View File

@ -4,3 +4,5 @@ mkdir -p publish-docs
doc-tools-build-rst security-guide --build build \
--target security-guide
doc-tools-build-rst security-threat-analysis --build build \
--target security-threat-analysis

View File

@ -22,6 +22,7 @@ commands = {posargs}
commands =
doc8 -e '' security-notes
doc8 -e '' security-guide
doc8 -e '' security-threat-analysis
[testenv:checkbuild]
commands =
@ -68,7 +69,7 @@ commands = {toxinidir}/tools/generatepot-rst.sh {posargs}
[doc8]
# Settings for doc8:
# This file has extra long lines that cannot be avoided, let's white list it.
ignore-path = security-notes/OSSN-0047,common,security-guide/build
ignore-path = security-notes/OSSN-0047,common,security-guide/build,security-threat-analysis/build
# File extensions to use
extensions = .rst,.txt
# Disable some doc8 checks: