Build Security Threat Analysis

Change-Id: I764f492e762901e1ed9889924645acf1f0bca241

README.rst

@@ -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``.
 
 

doc-tools-check-languages.conf

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

security-threat-analysis/source/index.rst

@@ -18,7 +18,6 @@ Contents
    templates/architecture-page.rst
    architecture-diagram-guidance.rst
    todo.rst
-   
 
 
 Search in this guide

security-threat-analysis/source/threat-analysis-process.rst

@@ -41,8 +41,8 @@ Preparing artifacts for review
 Before the review
 ~~~~~~~~~~~~~~~~~
 
-- Verify that the service’s architecture page contains all the sections listed
-  in the Architecture Page Template <link>.
+- Verify that the service’s 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.

security-threat-analysis/templates/architecture-page.rst

@@ -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

tools/build-all-rst.sh

@@ -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

tox.ini

@@ -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: