Merge "Adding templates for security review artifacts"

This commit is contained in:
Jenkins 2016-08-17 22:15:40 +00:00 committed by Gerrit Code Review
commit ee91b2dae1
6 changed files with 352 additions and 0 deletions

View File

@ -0,0 +1,216 @@
=============================
Architecture page template
=============================
Project name architecture - version/release
-------------------------------------------
**Status**: Draft/Ready for Review/Reviewed
**Release**: Juno/Kilo/Liberty if applicable
**Version**: 0.01 if applicable
**Contacts**:
- PTL: name - irc handle
- Architect: name - irc handle
- Security Reviewer: name - irc handle
Project description and purpose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A brief description of the purpose of the project. This should be a paragraph
or two and can be cut/paste from wiki or other documentation. Include links
to relevant presentations and further documentation if available.
Primary users and use-cases
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A short statement about the expected primary users of the implemented
architecture, 'users' can either be actors or other services within OpenStack.
For example:
#. Administrators will use this tool to manage storage quotas
#. Nova will fetch TLS certificates for nova-migrate
#. IaaS services e.g cinder, neutron-lbaas and nova for encryption key
generation and storage.
Differences from previous architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If this is a revision of a prior architecture, briefly list the new components
and interfaces. If this is a new architecture that replaces a prior service,
briefly describe how this service differs from its ancestor. If this is an
entirely new service with no precedent or one that has not been reviewed
previously, then remove this section.
External dependencies & associated security assumptions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
External dependencies are items outside of the control of the service that are
required for its operation, and may impact the service if they were compromised
or became unavailable. These items are usually outside the control of the
developer but within the control of the deployer, but may be operated by a
third party.
For example:
- Nova compute service is configured in accordance with security best practice.
- AWS object storage.
Components
~~~~~~~~~~
In the component descriptions that follow, I-C means that in a typical
deployment, they reside in hosted instances on the cloud, and U-C means they
are likely to be in the under cloud infrastructure. O-C means they are outside
of the cloud.
- component-1 (optional product/technology name)[I-C or U-C]: Describe
component
- component-2 [I-C]: Describe component
- component-3 [U-C]: Describe component
- component-3 [O-C]: Describe component or service
For Example:
- Worker Queue (rabbitmq) [U-C]: This queue is used to process new order
requests. Other systems involved submit and receive data via this queue.
- Database (MySQL) [I-C or U-C]: Open-source sql database to store Barbican
state data related to its managed entities and their metadata.
Interfaces
~~~~~~~~~~
.. csv-table::
:header: "Interface","Network name","Network protocol","Requestor","Request","Request credentials","Request authorization","Listener","Response","Response credentials","Description of operation"
"1"
"2"
"3"
Guidance:
- Enter a component name in the Requestor and Listener columns.
- Enter a data asset name in the Request and Response columns.
- Do not use an interface to show a function call within the same process.
- It is appropriate to show calls or effects which a process or library
makes outside of the process. For example, if the project is responsible for
part of a process, such as a library, do not list intra-process calls to that
library as separate interfaces. On the service architecture diagram you can
show the process and the library and color-code them to show the part(s) for
which the project has responsibility.
- If a request uses mutual TLS authentication (using both a client and server
certificate) then it may be appropriate to list 'TLS Certificate' in the
'Request credentials field' for that interface, but otherwise TLS should not
be regarded as a credential. The following examples attempt to clarify this
for common situations:
- Over an HTTPS session a service sends a Keystone token to authenticate
itself. In this case the Request credential is the Keystone token and the
Network protocol is HTTPS.
- A service connects to a database using SQL with a username and password.
Customers have the option at installation time to set up TLS for this
connection but are not required to do so. In this case list the most
secure available option in the interfaces table: the Network protocol is
"SQL with TLS" and the Request credentials are "username/password".
Service architecture diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Insert Service Architecture diagram here. For diagram requirements see
Architecture Diagram guidance in the OpenStack Security Guide.
.. image:: figures/template_architecture-diagram.png
Data assets
~~~~~~~~~~~
The following is the description of data assets used by this service. See the
TODO Information Classification Handling Policy for an explanation of
requirements associated with the Confidentiality and Availability labels.
.. csv-table::
:header: "Data name","Confidentiality","Integrity","Availability","Description"
"System request","Confidential","High","Medium","Requests between OpenStack services"
"System reply","Confidential","High","Medium","Replies to System requests"
"Data type X","Confidential","High","High","Data in motion, not stored"
"Data type Y","Confidential","High","Medium","Parameters in config file."
"MySQL database","Confidential","High","High","Contains user preferences. Backup to Swift daily."
Data flow diagram(s)
~~~~~~~~~~~~~~~~~~~~
Insert DFDs here. If you prefer to use sequence diagrams, then delete this
section. Architecture documentation should have at least one DFD or sequence
diagram.
An example of a data flow diagram is shown below:
.. image:: figures/template_dfd.png
Sequence diagram(s)
~~~~~~~~~~~~~~~~~~~
Insert sequence diagrams here. If you prefer to use DFDs, then delete this
section. Architecture documentation should have at least one DFD or sequence
diagram.
An example of a sequence diagram is shown below:
.. image:: figures/template_sequence-diagram.png
Summary of controls **Delete this section??**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Summary of controls spanning multiple components and interfaces:
- **Audit**: for example: SERVICENAME performs logging. Logs are
collected by the centralized logging service.
- **Authentication**: for example: authentication via Keystone tokens
at APIs. Password authentication to MQ and DB.
- **Authorization**: for example: OpenStack provides admin and
non-admin roles that are indicated in session tokens. Processes run
at minimum privilege. Processes run as unique user/group definitions
(servicename/servicename). Appropriate filesystem controls prevent
other processes from accessing services files. Security Groups
(or IPtables) ensure that no unneeded ports are open. Security Groups
provide authorization controls between in-cloud components. IPtables
and ACLs at the network perimeter and VLAN boundaries ensure that no
unneeded ports are open.
- **Availability**: for example: redundant hosts, clustered DB,
fail-over or—This is not an HA process. Throttle to prevent API
flooding. Monitoring via centralized monitoring service.
- **Confidentiality**: for example: Network connections over TLS.
Network separation via VLANs. Data and config files protected via
filesystem controls. Unencrypted local traffic is bound to localhost.
- **Integrity**: for example: Network connections over TLS. Network
separation via VLANs. DB API integrity protected by SQL Alchemy. Data
and config files are protected by filesystem controls. Unencrypted
local traffic is bound to localhost.
Resources
~~~~~~~~~
- URL related to this project
- URL related to this project
- URL related to this project
- URL related to this project

Binary file not shown.

After

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

View File

@ -0,0 +1,75 @@
=================================
Security review findings template
=================================
<Project name> security review findings - version/release
---------------------------------------------------------
**Status**: Draft/Completed
**Release**: Juno/Kilo/Liberty/Newton
**Version**: 0.01 if applicable
**Review Date**: mm/dd/yyyy
**Review Body**: <OpenStack Security Project/Name of Third Party Organisation >
**Contacts**:
- PTL: name - irc handle
- Architect: name - irc handle
- Security Reviewer: name - irc handle
- OpenStack Security Project Reviewer: <name> (only applicable for third party
security reviews)
1. Finding title
~~~~~~~~~~~~~~~~
- Risk: <Description of the Risk of this Finding>
- Impact: <Description of the Impact of this risk>
- Likelihood: <Low/Medium/High>
- Impact: <Low/Medium/High>
- Overall Risk Rating: <Low/Medium/High>
- Bug: <link to launchpad bug for this finding>
- Recommendation: <Description of the recommended resolution for this finding>
- Investigation Results: <Results of any investigation into this finding, such
as investigating and discovering this is a weakness in the core technology,
find that there is already a blueprint or patch in to fix it, or that a bug
should be opened for this>
2. Finding title
~~~~~~~~~~~~~~~~
- Risk: <Description of the Risk of this Finding>
- Impact: <Description of the Impact of this risk>
- Likelihood: <Low/Medium/High>
- Impact: <Low/Medium/High>
- Overall Risk Rating: <Low/Medium/High>
- Bug: <link to launchpad bug for this finding>
- Recommendation: <Description of the recommended resolution for this finding>
- Investigation Results: <Results of any investigation into this finding, such
as investigating and discovering this is a weakness in the core technology,
find that there is already a blueprint or patch in to fix it, or that a bug
should be opened for this>
3. Finding title
~~~~~~~~~~~~~~~~
- Risk: <Description of the Risk of this Finding>
- Impact: <Description of the Impact of this risk>
- Likelihood: <Low/Medium/High>
- Impact: <Low/Medium/High>
- Overall Risk Rating: <Low/Medium/High>
- Bug: <link to launchpad bug for this finding>
- Recommendation: <Description of the recommended resolution for this finding>
- Investigation Results: <Results of any investigation into this finding, such
as investigating and discovering this is a weakness in the core technology,
find that there is already a blueprint or patch in to fix it, or that a bug
should be opened for this>

View File

@ -0,0 +1,61 @@
==============================
Security review notes template
==============================
<Project name> security review notes - <version/release>
========================================================
**Status**: Draft/Completed
**Release**: Juno/Kilo/Liberty/Newton
**Version**: 0.01 if applicable
**Review Date**: mm/dd/yyyy
**Review Body**: <OpenStack Security Project/Name of Third Party Organisation >
**Contacts**:
- PTL: name - irc handle
- Architect: name - irc handle
- Security Reviewer: name - irc handle
**Reviewers**:
- <Project>: <reviewer names/handles>
- <Security Review Body>: <reviewer names/handles>
- OpenStack Security Project: <reviewer names/handles> (only applicable for
third party reviews)
Review
~~~~~~
Abuse cases
-----------
- <abuse case>
- <abuse case>
Architectural diagram walkthrough
---------------------------------
- notes
Sequence/DFD diagram walkthrough
--------------------------------
- notes
Actions
-------
1. action 1
2. action 2