-
Notifications
You must be signed in to change notification settings - Fork 65
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
823962f
commit 8f4c2a3
Showing
12 changed files
with
682 additions
and
21 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
Capability,Description,Tags | ||
(network)Session lifetime is limited,Session lifetime is limited.,Security | ||
A test specification for the system must be available,A test specification for the system must be available in order to perform test of the created system.,"Documentation, NFR" | ||
Clock Identity Authentication and Authorization,"Authentication refers to verifying the identity of the peer clock. Authorization, on the other hand, refers to verifying that the peer clock is permitted to play the role that it plays in the protocol. For example, some nodes may be permitted to be masters,while other nodes are only permitted to be slaves or TCs. Authentication is typically implemented by means of a cryptographic signature, allowing the verification of the identity of the sender. Authorization requires clocks to maintain a list of authorized clocks, or a ""black list"" of clocks that should be denied service or revoked.",Security | ||
Data logging:Sensitive data is not logged in clear text by the application.,Sensitive data is not logged in clear text by the application.,"NFR, Security" | ||
"Database connections, passwords, keys, or other secrets are not stored in plain text.","Database connections, passwords, keys, or other secrets are not stored in plain text.","NFR, Security" | ||
Disaster Recovery,"The solution will be configured to be split across the minimal two data centers where possible with failover from data center to data center in the event of a disaster, In addition, each data center needs to be able to run in a self sufficient manner should it become isolated from the other.",NFR | ||
Documentation must be available in an open document format,"All system documentation must be made available in open document format. System documentation is (not exhausted) operational manuals, code documentation, test specs and test reports, installation manuals.","Documentation, NFR" | ||
Encryption keys must be secured,Encryption keys must be secured.,Security | ||
High Availability,"All components should be configured in a high availability configuration to eliminate single points of failure, and minimize solution outages.",Availability | ||
Maintainability,"The system should allow for easy software upgrades with minimal outage. The outage should be restricted to no longer than one day, and allow for the use of a back up system for service continuity while the upgrade the taking place.",NFR | ||
Maintainability,"Any solution must be maintainable by the affected maintenance team, both initially and throughout its lifecycle. | ||
Unnecessary complexity in maintenance, such as by requiring additional / unusual skills or tools or having a complex solution design, adds risk to the solution’s supportability and must be justified.","maintainability, NFR" | ||
Manageability,"All solutions must be managed throughout their lifecycle, including startup, shutdown, backup, updates, security / permission changes, etc. Administrators and support personnel must be able to conduct such routine activities effectively in order to ensure that the solution does not incur excessive cost or experience unnecessary outages.","manageability, NFR" | ||
Minimize Footprint,Stack multiple components within single operating system instances where possible to minimize both the number of physical and virtual servers required to run the solution.,NFR | ||
Privileged Accounts must not be used for non-administrator activities,"Privileged and super-user accounts (Administrator, root, etc.) must not be used for non-administrator activities. A secure mechanism to escalate privileges (e.g., via User Account Control or via sudo) with a standard account is acceptable to meet this requirement. Network services must run under accounts assigned the minimum necessary privileges.",Security | ||
Requirements for Evidence,"Requirements for Evidence:The strength of mechanisms analysis shall show that all critical mechanisms satisfy the claimed minimum strength of mechanisms rating in the case of cryptographic mechanisms, this shall take the form of a statement of confirmation from the appropriate national body.",Security | ||
Secure Hash Standard (SHS) –,"This Standard specifies secure hash algorithms, SHA -1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA- | ||
512/256. All of the algorithms are iterative, one-way hash functions that can process a message to produce a condensed representation called a message digest. These algorithms enable the determination of a message’s integrity: any change to the message will, with a very high probability, result in a different message digest. | ||
The digests are used to detect whether messages have been changed since the digests were generated. | ||
See: http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf",Security | ||
SecureBoot,The system where software is deployed supports SecureBoot (also known as Trusted Boot).,Security | ||
Sensitive data is not stored in persistent cookies,Sensitive data is not stored in persistent cookies.,Security | ||
Sensitive data is transmitted with the HTML POST protocol.,Sensitive data is transmitted with the HTML POST protocol. So GET is NOT used for sensitive data.,Security | ||
Service levels,"The required service level(s) for any solution affect its design, cost, maintenance and support. As such, these must be known.","NFR, service levels" | ||
SSL is used to protect authentication cookies,SSL is used to protect authentication cookies.,Security | ||
Supportability,"Any solution must be supportable by the affected operations and maintenance teams, both initially and throughout its lifecycle. | ||
Unnecessary complexity in support, such as by requiring additional / unusual skills or tools, adds risk to the solution’s supportability and must be justified. | ||
The maintenance support team will be responsible for the success of the solution during its production life. As such, they require training, mentoring and appropriate transition measures to ensure they are able to successfully support the new component in the production environment.","NFR, supportability" | ||
The certificate must be an X.509v3 certificate,"The certificate must be an X.509v3 certificate. | ||
The certificate must be within the valid period. The certificate must be verified and validated through authentication. | ||
The system will not issue digital certificates. Users will present trusted third party-issued certificates that are valid and verifiable by the system.","NFR, Security" | ||
The contents of authentication cookies are encrypted,The contents of authentication cookies are encrypted.,Security | ||
User ID must be unique and passwords must be stored in irreversible encrypted form,User ID must be unique.,Security |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
APPENDIX: NFR Capabilities | ||
=========================== | ||
|
||
This appendix provides some a very few examples of NFRs. | ||
Having good NFRs is crucial for your solution. Asking users to provide NFRs is not the best way to success. More productive is to discuss NFRs with your users that you think are worth discussing. Some NFRs, e.g. for availability, MUST BE discussed since this has severe consequence for the solution and maintenance costs. Some NFRs e.g. for security MUST BE implemented and are not really suited for users discussions. Most of the time you will be confronted with bad NFRs for your architecture after realization. So you better do it right from the start. | ||
|
||
|
||
.. csv-table:: NFR Capabilities | ||
:file: NFRcapabilities.csv | ||
:widths: 20, 60 , 20 | ||
:header-rows: 1 | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,197 @@ | ||
#!/usr/bin/env python3 | ||
# -*- coding: utf-8 -*- | ||
# | ||
# ArchitecturePLAYBOOK documentation build configuration file, created by | ||
# sphinx-quickstart on Sat Jun 2 15:11:46 2018. | ||
# | ||
# This file is execfile()d with the current directory set to its | ||
# containing dir. | ||
# | ||
# Note that not all possible configuration values are present in this | ||
# autogenerated file. | ||
# | ||
# All configuration values have a default; values that are commented out | ||
# serve to show the default. | ||
|
||
# If extensions (or modules to document with autodoc) are in another directory, | ||
# add these directories to sys.path here. If the directory is relative to the | ||
# documentation root, use os.path.abspath to make it absolute, like shown here. | ||
# | ||
# import os | ||
# import sys | ||
# sys.path.insert(0, os.path.abspath('.')) | ||
|
||
|
||
# -- General configuration ------------------------------------------------ | ||
|
||
# If your documentation needs a minimal Sphinx version, state it here. | ||
# | ||
# needs_sphinx = '1.0' | ||
|
||
# Add any Sphinx extension module names here, as strings. They can be | ||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom | ||
# ones. | ||
extensions = ['sphinx.ext.autodoc'] | ||
|
||
# Add any paths that contain templates here, relative to this directory. | ||
templates_path = ['_templates'] | ||
|
||
# The suffix(es) of source filenames. | ||
# You can specify multiple suffix as a list of string: | ||
# | ||
from recommonmark.parser import CommonMarkParser | ||
source_parsers = { | ||
'.md': CommonMarkParser, | ||
} | ||
source_suffix = ['.rst', '.md'] | ||
#source_suffix = '.rst' | ||
|
||
# The master toctree document. | ||
master_doc = 'index' | ||
|
||
# General information about the project. | ||
project = 'ArchitecturePLAYBOOK' | ||
copyright = '2018, Maikel Mardjan' | ||
author = 'Maikel Mardjan' | ||
|
||
# The version info for the project you're documenting, acts as replacement for | ||
# |version| and |release|, also used in various other places throughout the | ||
# built documents. | ||
# | ||
# The short X.Y version. | ||
version = '1.01' | ||
# The full version, including alpha/beta/rc tags. | ||
release = '1.01' | ||
|
||
# The language for content autogenerated by Sphinx. Refer to documentation | ||
# for a list of supported languages. | ||
# | ||
# This is also used if you do content translation via gettext catalogs. | ||
# Usually you set "language" from the command line for these cases. | ||
language = None | ||
|
||
# List of patterns, relative to source directory, that match files and | ||
# directories to ignore when looking for source files. | ||
# This patterns also effect to html_static_path and html_extra_path | ||
exclude_patterns = [] | ||
|
||
# The name of the Pygments (syntax highlighting) style to use. | ||
pygments_style = 'sphinx' | ||
|
||
# If true, `todo` and `todoList` produce output, else they produce nothing. | ||
todo_include_todos = False | ||
|
||
|
||
# -- Options for HTML output ---------------------------------------------- | ||
|
||
# The theme to use for HTML and HTML Help pages. See the documentation for | ||
# a list of builtin themes. | ||
# | ||
html_theme = 'alabaster' | ||
|
||
# Theme options are theme-specific and customize the look and feel of a theme | ||
# further. For a list of options available for each theme, see the | ||
# documentation. | ||
# | ||
# html_theme_options = {} | ||
|
||
# Add any paths that contain custom static files (such as style sheets) here, | ||
# relative to this directory. They are copied after the builtin static files, | ||
# so a file named "default.css" will overwrite the builtin "default.css". | ||
html_static_path = ['_static'] | ||
|
||
# Custom sidebar templates, must be a dictionary that maps document names | ||
# to template names. | ||
# | ||
# This is required for the alabaster theme | ||
# refs: http://alabaster.readthedocs.io/en/latest/installation.html#sidebars | ||
html_sidebars = { | ||
'**': [ | ||
'about.html', | ||
'navigation.html', | ||
'relations.html', # needs 'show_related': True theme option to display | ||
'searchbox.html', | ||
'donate.html', | ||
] | ||
} | ||
|
||
|
||
# -- Options for HTMLHelp output ------------------------------------------ | ||
|
||
# Output file base name for HTML help builder. | ||
htmlhelp_basename = 'ArchitecturePLAYBOOKdoc' | ||
|
||
|
||
# -- Options for LaTeX output --------------------------------------------- | ||
|
||
latex_elements = { | ||
# The paper size ('letterpaper' or 'a4paper'). | ||
# | ||
# 'papersize': 'letterpaper', | ||
|
||
# The font size ('10pt', '11pt' or '12pt'). | ||
# | ||
# 'pointsize': '10pt', | ||
|
||
# Additional stuff for the LaTeX preamble. | ||
# | ||
# 'preamble': '', | ||
|
||
# Latex figure (float) alignment | ||
# | ||
# 'figure_align': 'htbp', | ||
} | ||
|
||
# Grouping the document tree into LaTeX files. List of tuples | ||
# (source start file, target name, title, | ||
# author, documentclass [howto, manual, or own class]). | ||
latex_documents = [ | ||
(master_doc, 'ArchitecturePLAYBOOK.tex', 'ArchitecturePLAYBOOK Documentation', | ||
'Maikel Mardjan', 'manual'), | ||
] | ||
|
||
|
||
# -- Options for manual page output --------------------------------------- | ||
|
||
# One entry per manual page. List of tuples | ||
# (source start file, name, description, authors, manual section). | ||
man_pages = [ | ||
(master_doc, 'architectureplaybook', 'ArchitecturePLAYBOOK Documentation', | ||
[author], 1) | ||
] | ||
|
||
|
||
# -- Options for Texinfo output ------------------------------------------- | ||
|
||
# Grouping the document tree into Texinfo files. List of tuples | ||
# (source start file, target name, title, author, | ||
# dir menu entry, description, category) | ||
texinfo_documents = [ | ||
(master_doc, 'ArchitecturePLAYBOOK', 'ArchitecturePLAYBOOK Documentation', | ||
author, 'ArchitecturePLAYBOOK', 'One line description of project.', | ||
'Miscellaneous'), | ||
] | ||
|
||
|
||
|
||
# -- Options for Epub output ---------------------------------------------- | ||
|
||
# Bibliographic Dublin Core info. | ||
epub_title = project | ||
epub_author = author | ||
epub_publisher = author | ||
epub_copyright = copyright | ||
|
||
# The unique identifier of the text. This can be a ISBN number | ||
# or the project homepage. | ||
# | ||
# epub_identifier = '' | ||
|
||
# A unique identification for the text. | ||
# | ||
# epub_uid = '' | ||
|
||
# A list of files that should not be packed into the epub file. | ||
epub_exclude_files = ['search.html'] | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
.. ArchitecturePLAYBOOK documentation master file, created by | ||
sphinx-quickstart on Sat Jun 2 15:11:46 2018. | ||
You can adapt this file completely to your liking, but it should at least | ||
contain the root `toctree` directive. | ||
Business IT Architecture PLAYBOOK | ||
=================================== | ||
|
||
.. toctree:: | ||
:numbered: | ||
:maxdepth: 2 | ||
:caption: Contents: | ||
|
||
introduction | ||
business-architecture | ||
data-architecture | ||
application-architecture | ||
ti-architecture | ||
quality | ||
capabilities | ||
|
||
|
||
|
||
Indices and tables | ||
================== | ||
|
||
* :ref:`genindex` | ||
* :ref:`modindex` | ||
* :ref:`search` |
Oops, something went wrong.