openstack/security-analysis
Code Issues Proposed changes

Updated security review template

Browse Source 
Updated security review template to suit asset based security
review.

Change-Id: Ifcc8cb3fcd289b35b243947e90a9a59d4da71b0e
This commit is contained in:
Doug Chivers 2016-12-11 14:34:06 +00:00
parent f31be8a32d
commit 128588c2a4
1 changed files with 48 additions and 127 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

175
doc/source/templates/architecture-page.rst
View File

@ -4,7 +4,6 @@ Architecture page template
Project name architecture - version/release
-------------------------------------------
**Status**: Draft/Ready for Review/Reviewed
**Release**: Juno/Kilo/Liberty if applicable
@ -17,11 +16,11 @@ Project name architecture - version/release
- Architect: name - irc handle
- Security Reviewer: 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.
@ -29,7 +28,6 @@ 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.
@ -41,19 +39,8 @@ For example:
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
@ -68,66 +55,20 @@ For example:
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
A list of the components of the deployed project excluding external entities.
Each component should be named and have a brief description of its purpose, and
be labeled with the primary technology used (e.g. Python, MySQL, RabbitMQ).
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".
- keystone listener process (Python): Python process that consumes keystone
events published by the keystone service.
- Database (MySQL): MySQL database to store barbican state data related to its
managed entities and their metadata.
Service architecture diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Insert Service Architecture diagram here. For diagram requirements see
Architecture Diagram guidance in the OpenStack Security Guide.
@ -136,75 +77,56 @@ Architecture Diagram guidance in the OpenStack Security Guide.
Data assets
~~~~~~~~~~~
Data assets are user data, high-value data, configuration items, authorization
tokens or other items that an attacker may target. Data assets should include a
statement of where that asset is persisted.
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"
For example:
- *ACL rules* - persisted in database
- *DB Credentials* - persisted in barbican.conf
- *Middleware configuration* - persisted in paste.ini
- *[PKCS#11] HSM HMAC Key* - persisted in HSM
"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 asset impact analysis
~~~~~~~~~~~~~~~~~~~~~~~~~~
List all data assets listed above, briefly describe the impact to the system
that an integrity failure, loss of confidentiality or loss of availability
would have to the system. Project architects should attempt to complete this
prior to the review to minimise the time required.
For example:
Data Assets:
- *RBAC/ACL rulesets*:
- Integrity Failure Impact: Attacker with valid AuthN could be granted access
to any secret.
- Confidentiality Failure Impact: Mappings between users and secrets are
exposed.
- Availability Failure Impact: barbican will not start if the file is not
readable.
Interfaces
~~~~~~~~~~
List interfaces within the scope of the review: connections that cross a trust
boundary, connections that do not use a industry standard encryption protocol
such as TLS or SSH. Capture the following information for each interface:
Data flow diagram(s)
~~~~~~~~~~~~~~~~~~~~
Number. From -> To *[Transport Protocol]*
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.
- Assets in flight: List all data assets traveling across the interface.
- Brief description of the impact of a successful attack on this interface.
An example of a data flow diagram is shown below:
For example:
.. image:: figures/template_dfd.png
1. Administrator->API Process *[TLS]*:
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 service’s 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.
- Assets in flight: barbican admin keystone Credentials
- An attacker with access to the admin credentials can modify quotas,
expanding or reducing them for any user. This has potential availability
impact. Denial of Service.
Resources
@ -213,4 +135,3 @@ Resources
- URL related to this project
- URL related to this project
- URL related to this project
- URL related to this project