├── .readthedocs.yml
├── README.md
├── _config.yml
├── _static
├── cover_osa.jpg
└── nocxstyle.css
├── _toc.yml
├── about.md
├── aboutthisguide.md
├── architecture
├── NCSC-designprinciples.md
├── NCSC-securecommunication.md
├── NCSC-zerotrustprinciples.md
├── attack-vectors.md
├── common-attackvectors.md
├── frameworks.md
├── mozilla-dataprivacy-principles.md
├── mozilla_securityprinciples.md
├── ms-zt-principles.md
├── ncsc-zero-trust-architecture
│ ├── 01-Know-your-architecture-including-users-devices-and-services.md
│ ├── 02-Know-your-User-Service-and-Device-identities.md
│ ├── 03-Assess-your-users-behaviour-devices-and-services-health.md
│ ├── 04-Use-policies-to-authorise-requests.md
│ ├── 05-Authenticate-everywhere.md
│ ├── 06-focus-your-monitoring-on-devices-and-services.md
│ ├── 07-Don't-trust-any-network-including-your-own.md
│ ├── 08-Choose-services-designed-for-zero-trust.md
│ └── Diagrams
│ │ ├── User_token_Service_3.png
│ │ ├── User_token_Service_4.png
│ │ └── ZT-2.png
├── reference-architecture.md
├── saltzer_designprinciples.md
├── securitymodels.md
├── securityprinciples.md
├── stride.md
├── supplychainattacks.md
└── threadmodels.md
├── bio.md
├── contributing.md
├── generatedfiles
├── attacks.md
├── courses.md
├── foundations.md
├── framework.md
├── frameworks.md
├── governmentsecurityorganizations.md
├── overview.md
├── publicsecurityagencies.md
├── securitybydesign.md
└── standards.md
├── help.md
├── images
├── OO.png
├── ROI_logo.png
├── User_token_Service_3.png
├── User_token_Service_4.png
├── YourLogoHere.png
├── ZT-2.png
├── ddos-model.png
├── essence-of-infosec.png
├── image_10_SDLC.png
├── image_11_IoT.png
├── image_12_Nist_CloudSecurityREFmodel.png
├── image_8_OSA.png
├── image_9_SAMM.png
├── jericho.png
├── ml-system.png
├── mobile-threads.png
├── nist.png
├── nocxbanner.png
├── oath2.png
├── opentitan.png
├── principles.png
├── security-abbs.png
├── securitybydesign.png
└── what_is_security.png
├── introduction.md
├── learning
├── books.md
├── cryptography.md
├── foundations.md
├── researchlabs.md
├── secure-coding.md
├── security-references.md
├── securitycourses.md
├── softwaretesting.md
├── trustedcomputing.md
├── vulnerabilitydatabases.md
└── vulnerabilitymanagement.md
├── license.md
├── open.md
├── prevention
├── api-security-checklist.md
├── architecturesteps.md
├── conciseguidefordeveloping.md
├── cors.md
├── csp-checklist.md
├── evalFOSS.md
├── foss-securitycriteria.md
├── hardening.md
├── linux-securitychecklist.md
├── mvsp.md
├── ncp-checklists.md
├── nocx-security-checklist.md
├── openSSF-scorecard.md
├── owasp-top10-checklist.md
├── prevention.md
├── ransomware.md
├── reproduciblebuilds.md
├── simple-checklists.md
└── simplesolutions.md
├── protection
├── dataclassification-example1.md
├── iso27001.md
├── mattermost-security-policy.md
├── security-classifications.md
├── security-guidelines.md
├── security-management.md
├── security-policies.md
└── vulnerabilities-search.md
├── references
├── governments.md
├── securitystandards.md
└── specialattacks.md
├── requirements.txt
└── sponsors.md
/.readthedocs.yml:
--------------------------------------------------------------------------------
1 | # .readthedocs.yml
2 | # Read the Docs configuration file
3 | # See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
4 |
5 | version: 2
6 |
7 | build:
8 | image: latest
9 |
10 | sphinx:
11 | configuration: conf.py
12 |
13 | formats: []
14 |
15 | python:
16 | install:
17 | - requirements: requirements.txt
18 |
19 | formats:
20 | - epub
21 | - pdf
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 | # Open Security Reference Architecture
3 |
4 | IT Security is a complex field. People, processes and technology are crucial parts of an architecture to reduce risks. Our certified experts love to solve your cyber security challenges. Detecting what is not good with your current security is the simple work. You can find many companies that launch automated test suites based on open source tools that tell you that you are not secure enough. However the real challenge is designing solutions that are secure.
5 |
6 |
7 | Good Open publications for cyber security are hard to find.
8 |
9 | This [Security Reference Architecture](https://nocomplexity.com/documents/securityarchitecture/introduction.html) aims to enable you to create better and faster security solutions. You SHOULD use and reuse content that is provided in this reference architecture to prevent reinventing the wheel.
10 |
11 | To encourage collaboration for this project this reference architecture is of course free and open (cc-by-sa).
12 |
13 | This project is supported by the [BM-Support Foundation](https://www.bm-support.org/).
14 |
15 |
16 | The initial version (2015) of this project was called the 'Open Reference Architecture for Security and Privacy'. However we decided to split this project in a pure security reference architecture Guide and a [privacy playbook](https://nocomplexity.com/documents/simplifyprivacy/intro.html).
17 |
18 |
19 | # Contributing
20 |
21 | You don’t have to be a security expert to contribute, every contribution is welcome!
22 |
23 | We encourage all security professionals to improve this reference architecture. You can help by:
24 | * Add security principles.
25 | * Add security models.
26 | * Add threat models that can be easily reused.
27 | * Add links towards open (cc-by) solutions created by government’s or foundations.
28 | * Provide an URL to enhance the collection of open access resources that helps creating a security architecture faster and better!
29 |
30 | Your contributions to this Guide are greatly appreciated as long as contributions fit within the scope and goal of this security reference architecture. As an open project, this Security Architecture shall always remain vendor-neutral and freely available for all to use. If you contribute you will of course get credit (mentioned in upcoming publications).
31 |
32 | * This reference architecture is intended to be a helpful resource aimed at professional security architects and engineers.
33 | * Contributions must fit within the scope and goal of this security reference architecture.
34 | * All contributions to resources must be open. E.g. cc-by licensed or equivalent.
35 |
36 | > [!TIP]
37 | > The simplest way to make a comment for a specific page is to use the Github icon in the top right.
38 |
39 |
40 | # Licensing
41 |
42 | When you submit text to which you hold the copyright, you agree to license it under:
43 |
44 | * Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0).
45 |
46 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | #######################################################################################
2 | # The NO Complexity default configuration configuration making jupyter books
3 | # Override these values in their own `_config.yml` file.
4 | # Created by Maikel Mardjan (nocomplexity.com)
5 | #######################################################################################
6 | # Book settings
7 | title : 'Security Reference Architecture' # The title of the book. Will be placed in the left navbar.
8 | author : 'Maikel Mardjan (nocomplexity.com) & Asim Jahan and all contributors.' # The author of the book
9 | copyright : '2025 Business Management Support Foundation (bm-support.org)' # Copyright year to be placed in the footer
10 | logo : "images/nocxbanner.png" # A path to the book logo
11 | # Patterns to skip when building the book. Can be glob-style (e.g. "*skip.ipynb")
12 | exclude_patterns : [_build, Thumbs.db, .DS_Store, "**.ipynb_checkpoints",README.md]
13 | # Auto-exclude files not in the toc
14 | only_build_toc_files : false
15 |
16 | #######################################################################################
17 | # Execution settings
18 | execute:
19 | execute_notebooks : auto # Whether to execute notebooks at build time. Must be one of ("auto", "force", "cache", "off")
20 | cache : "" # A path to the jupyter cache that will be used to store execution artifacs. Defaults to `_build/.jupyter_cache/`
21 | exclude_patterns : [] # A list of patterns to *skip* in execution (e.g. a notebook that takes a really long time)
22 | timeout : 30 # The maximum time (in seconds) each notebook cell is allowed to run.
23 | run_in_temp : false # If `True`, then a temporary directory will be created and used as the command working directory (cwd),
24 | # otherwise the notebook's parent directory will be the cwd.
25 | allow_errors : false # If `False`, when a code cell raises an error the execution is stopped, otherwise all cells are always run.
26 | stderr_output : show # One of 'show', 'remove', 'remove-warn', 'warn', 'error', 'severe'
27 |
28 | #######################################################################################
29 | # Parse and render settings
30 | parse:
31 | myst_enable_extensions: # default extensions to enable in the myst parser. See https://myst-parser.readthedocs.io/en/latest/using/syntax-optional.html
32 | - amsmath
33 | - colon_fence
34 | - deflist
35 | - dollarmath
36 | - html_admonition
37 | - html_image
38 | - linkify
39 | - replacements
40 | - smartquotes
41 | - substitution
42 |
43 | myst_url_schemes : [mailto, http, https] # URI schemes that will be recognised as external URLs in Markdown links
44 | #######################################################################################
45 | # HTML-specific settings
46 | html:
47 | favicon : "" # A path to a favicon image
48 | # use_edit_page_button : true # Whether to add an "edit this page" button to pages. If `true`, repository information in repository: must be filled in
49 | # use_repository_button : true # Whether to add a link to your repository button
50 | # use_issues_button : true # Whether to add an "open an issue" button
51 |
52 | extra_footer : '
© Copyright 2025, BM-Support.org & Maikel Mardjan. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
'
53 | extra_navbar : 'ROI Now!'
54 |
55 |
56 | home_page_in_navbar : true # Whether to include your home page in the left Navigation Bar
57 | baseurl : "" # The base URL where your book will be hosted. Used for creating image previews and social links. e.g.: https://mypage.com/mybook/
58 | comments:
59 | hypothesis : false
60 | utterances : false
61 |
62 | #######################################################################################
63 | # LaTeX-specific settings
64 | latex:
65 | latex_engine : pdflatex # one of 'pdflatex', 'xelatex' (recommended for unicode), 'luatex', 'platex', 'uplatex'
66 |
67 | #######################################################################################
68 | # Launch button settings
69 | # launch_buttons:
70 | # notebook_interface : jupyterlab # The interface interactive links will activate ["classic", "jupyterlab"]
71 | # binderhub_url : https://mybinder.org # The URL of the BinderHub (e.g., https://mybinder.org)
72 | # jupyterhub_url : "" # The URL of the JupyterHub (e.g., https://datahub.berkeley.edu)
73 | # thebe : false # Add a thebe button to pages (requires the repository to run on Binder)
74 | # colab_url : "" # The URL of Google Colab (https://colab.research.google.com)
75 |
76 | #repository:
77 | # url : https://github.com/nocomplexity/SecurityArchitecture # The URL to your book's repository
78 | # path_to_book : "" # A path to your book's folder, relative to the repository root.
79 | # branch : master # Which branch of the repository should be used when creating links
80 |
81 | # repository:
82 | # github_url: https://github.com/nocomplexity/SecurityArchitecture
83 | # html:
84 | # use_repository_button: true
85 | # github_url: https://github.com/
86 | # github_repo: SecurityArchitecture
87 | # #######################################################################################
88 | # Advanced and power-user settings
89 | sphinx:
90 | extra_extensions :
91 | - sphinx_design
92 | #- sphinx_click.ext
93 | #- sphinx.ext.autodoc
94 | #- sphinx.ext.viewcode
95 | #- sphinx.ext.napoleon
96 | #- sphinx.ext.todo
97 | local_extensions : # A list of local extensions to load by sphinx specified by "name: path" items
98 | # gitinfo : '/home/maikel/projects/pythondev/simple-ml-qacheck'
99 | config:
100 | html_last_updated_fmt: ""
101 | html_theme_options:
102 | repository_url: "https://github.com/nocomplexity/SecurityArchitecture"
103 | repository_branch: "master"
104 | use_repository_button: True
105 | use_edit_page_button: True
106 | use_issues_button: True
107 | # home_page_in_toc: False,
108 | logo:
109 | text: 'Open Security Reference Architecture'
110 | extra_footer: '
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
'
111 |
112 |
113 | parse:
114 | myst_enable_extensions:
115 | - html_admonition
116 |
117 |
--------------------------------------------------------------------------------
/_static/cover_osa.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/_static/cover_osa.jpg
--------------------------------------------------------------------------------
/_static/nocxstyle.css:
--------------------------------------------------------------------------------
1 | .caption-text {
2 | color: #FF0000;
3 | }
4 |
5 | /* for the danger color (button!) to be NOCX red instead of the default*/
6 | html[data-theme="light"] {
7 | --pst-color-danger: red;
8 | }
9 |
10 | @page {
11 | size: 6.5in 9.2in;
12 | margin: 2cm; /* Set margin on each page */
13 | }
14 |
--------------------------------------------------------------------------------
/_toc.yml:
--------------------------------------------------------------------------------
1 | format: jb-book
2 |
3 | root: introduction
4 |
5 | parts:
6 | - caption: Prevention
7 | chapters:
8 | - file: prevention/prevention
9 | - file: prevention/architecturesteps
10 | - file: prevention/simple-checklists
11 | sections:
12 | - file: prevention/nocx-security-checklist
13 | - file: prevention/foss-securitycriteria
14 | - file: prevention/reproduciblebuilds
15 | - file: prevention/owasp-top10-checklist
16 | - file: prevention/openSSF-scorecard
17 | - file: prevention/linux-securitychecklist
18 | - file: prevention/mvsp
19 | - file: prevention/api-security-checklist
20 | - file: prevention/csp-checklist
21 | - file: prevention/ncp-checklists
22 | - file: prevention/evalFOSS
23 | - file: prevention/conciseguidefordeveloping
24 | - file: prevention/ransomware
25 | - file: prevention/simplesolutions
26 | - file: prevention/hardening
27 | - file: prevention/securitystandards
28 | sections:
29 | - file: prevention/cors
30 |
31 |
32 | - caption: Protection
33 | chapters:
34 | - file: protection/security-policies
35 | sections:
36 | - file: protection/security-guidelines
37 | - file: protection/iso27001
38 | - file: protection/mattermost-security-policy
39 | - url: https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=2810&s=1A
40 | title: Example of NASA
41 | - url: https://www.vupune.ac.in/images/IT-Policies/VU_HR-IS_Policy_Ver_10.pdf
42 | title: Example of an university
43 | - url: https://www2.gov.bc.ca/assets/gov/british-columbians-our-governments/services-policies-for-government/information-management-technology/information-security/isp_v4.pdf
44 | title: Example of a government
45 | - url: https://www.etsi.org/deliver/etsi_tr/103300_103399/10330501/04.01.02_60/tr_10330501v040102p.pdf
46 | title: ETSI Critical Security Controls for Effective Cyber Defence
47 | - url: https://canso.org/publication/air-traffic-management-cybersecurity-policy-template/
48 | title: Air Traffic Management Cybersecurity Policy Template
49 | - file: protection/security-classifications
50 | sections:
51 | - url: https://security.berkeley.edu/data-classification-standard
52 | title: Data Classification Standard (Berkeley)
53 | - file: protection/dataclassification-example1
54 | - file: protection/vulnerabilities-search
55 | - file: protection/security-management
56 | - url: https://nocomplexity.com/documents/securitysolutions
57 | title: Security Solutions
58 |
59 | - caption: Architecture
60 | chapters:
61 | - file: architecture/frameworks
62 | - file: architecture/reference-architecture
63 | - file: architecture/securitymodels
64 | - file: architecture/attack-vectors
65 | sections:
66 | - file: architecture/common-attackvectors
67 | - file: architecture/supplychainattacks
68 | - url: https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html
69 | title: CWE Top 25 Most Dangerous Software Weaknesses
70 | - url: https://cwe.mitre.org/scoring/lists/2021_CWE_MIHW.html
71 | title: CWE Most Important Hardware Weaknesses
72 | - file: architecture/threadmodels
73 | sections:
74 | - file: architecture/stride
75 | - url: https://www.first.org/cvss/specification-document
76 | title: CVSS
77 | - url: http://securitycards.cs.washington.edu/index.html
78 | title: Security Cards
79 | - url: https://resources.sei.cmu.edu/library/Asset-view.cfm?assetid=51546
80 | title: OCTAVE Approach
81 | - url: https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2019/findings/Kubernetes%20Threat%20Model.pdf
82 | title: Kubernetes Threat Model
83 | - url: https://github.com/a13xp0p0v/linux-kernel-defence-map
84 | title: Linux Kernel Defence Map
85 | - file: architecture/securityprinciples
86 | sections:
87 | - file: architecture/mozilla_securityprinciples
88 | - file: architecture/mozilla-dataprivacy-principles
89 | - file: architecture/NCSC-designprinciples
90 | - file: architecture/NCSC-zerotrustprinciples
91 | - file: architecture/NCSC-securecommunication
92 | - file: architecture/saltzer_designprinciples
93 | - file: architecture/ms-zt-principles
94 | - url: https://www.ncsc.gov.uk/whitepaper/security-architecture-anti-patterns
95 | title: Security architecture anti-patterns
96 |
97 |
98 | - caption: Learning
99 | chapters:
100 | - file: learning/securitycourses
101 | - file: learning/books
102 | - file: learning/secure-coding
103 | - file: learning/softwaretesting
104 | - file: learning/trustedcomputing
105 | - file: learning/security-references
106 | sections:
107 | - file: learning/cryptography
108 | - file: learning/researchlabs
109 | - file: learning/vulnerabilitymanagement
110 | - file: learning/vulnerabilitydatabases
111 | - url: https://nocomplexity.com/cybersecurity-conferences/
112 | title: Security Conferences
113 |
114 | - caption: Key Resources
115 | chapters:
116 | - file: generatedfiles/foundations
117 | - file: references/goverments
118 | - file: references/securitystandards
119 | - file: generatedfiles/securitybydesign
120 | - file: references/specialattacks
121 |
122 |
123 | - caption: About
124 | chapters:
125 | - file: help
126 | - file: open
127 | - file: contributing
128 | - file: aboutthisguide
129 | - file: bio
130 | - file: license
131 | - file: sponsors
132 | - file: about
133 |
--------------------------------------------------------------------------------
/about.md:
--------------------------------------------------------------------------------
1 | # About NO|Complexity
2 |
3 | ## Who is Behind NO|Complexity?
4 |
5 | [NO|Complexity.com](https://nocomplexity.com/) is dedicated to solve business IT challenges in a rapidly evolving world. I’m Maikel Mardjan, and I believe that many business IT solutions are overly complex. Simple solutions have many advantages. But creating simple solutions is not simple. Tackling complexity challenges requires an unique combination of expertise, skills and people.
6 |
7 |
8 | With experience across a range of architecture roles—including IT Architect, Security Architect, Business Architect, and Enterprise Architect—I have worked with various organizations to design IT systems that prioritize simplicity. I hold a Master’s degree (MSc) in Business Studies from the University of Groningen and a Master’s degree (MSc) in Electrical Engineering from Delft University of Technology. Additionally, I am TOGAF 9 Certified and hold CISSP (Certified Information Systems Security Professional) certification.
9 |
10 | Currently, I lead initiatives at NoComplexity.com, an innovative IT company focused on straightforward solutions. For more insights and updates, you can find me on X (despite my privacy and other concerns with BigTech...) at [@maikelmardjan](https://X.com/maikelmardjan).
11 |
12 | ## Other NO|Complexity Publications
13 |
14 | ### Cyber Security
15 |
16 | % Start cards grid
17 | ::::{grid} 3
18 | :class-container: text-center
19 | :gutter: 3
20 |
21 | :::{grid-item-card}
22 | :link: https://nocomplexity.com/documents/securityarchitecture/introduction.html
23 | :link-type: url
24 | {octicon}`book;2em;caption-text` **Open Security Reference Architecture**
25 | ^^^
26 | Cyber security can still be simple and effective.
27 | Use this Playbook to create better and faster security solutions for your security use case.
28 | :::
29 |
30 | :::{grid-item-card}
31 | :link: https://nocomplexity.com/documents/securitybydesign/intro.html
32 | :link-type: url
33 | {octicon}`book;2em;caption-text` **Security By Design**
34 | ^^^
35 | Security by design is a proven method to develop products that are less vulnerable for cyber security threats.
36 | Master the topic quickly with this eBook.
37 | :::
38 |
39 | :::{grid-item-card}
40 | :link: https://nocomplexity.com/documents/securitysolutions/intro.html
41 | :link-type: url
42 | {octicon}`book;2em;caption-text` **Open Security Solutions**
43 | ^^^
44 | Given the vast array of FOSS cybersecurity products available, this publication offers a handcrafted curated selection.
45 | :::
46 |
47 | :::{grid-item-card}
48 | :link: https://nocomplexity.com/documents/reports/SimplifySecurity.pdf
49 | :link-type: url
50 | {octicon}`book;2em;caption-text` **Simplify Cyber Manifest**
51 | ^^^
52 | A manifesto to revolutionize cybersecurity through simplification.
53 | :::
54 |
55 |
56 | :::{grid-item-card}
57 | :link: https://nocomplexity.com/documents/simplifysecurity/intro.html#
58 | :link-type: url
59 | {octicon}`book;2em;caption-text` **Simplify Security**
60 | ^^^
61 | Find open simple cyber solutions that work. Simplify cyber security to accelerate its effectiveness.
62 | :::
63 |
64 |
65 | :::{grid-item-card}
66 | :link: https://nocomplexity.com/documents/simplifyprivacy/intro.html
67 | :link-type: url
68 | {octicon}`book;2em;caption-text` **Simplify Digital Privacy**
69 | ^^^
70 | This digital Playbook is all about protecting *your* digital privacy.
71 | :::
72 |
73 |
74 | ::::
75 | % End of Cards grid
76 |
77 | ### Machine Learning - AI and Tools
78 |
79 | % Start cards grid
80 | ::::{grid} 3
81 | :class-container: text-center
82 | :gutter: 3
83 |
84 | :::{grid-item-card}
85 | :link: https://nocomplexity.com/documents/fossml/abstract.html
86 | :link-type: url
87 | {octicon}`book;2em;caption-text` **Free and Open Machine Learning**
88 | ^^^
89 | Freedom to control machine learning and AI technology is not self-evident. This Playbook gives you full control.
90 | :::
91 |
92 |
93 |
94 | :::{grid-item-card}
95 | :link: https://nocomplexity.com/documents/jupyterlab/intro.html
96 | :link-type: url
97 | {octicon}`book;2em;caption-text` **Mastering JupyterLab**
98 | ^^^
99 | Supercharge your data science journey with Mastering JupyterLab. Use this Playbook to streamline your workflow and boost productivity.
100 | :::
101 |
102 |
103 | :::{grid-item-card}
104 | :link: https://nocomplexity.com/documents/pythonbook/introduction.html
105 | :link-type: url
106 | {octicon}`book;2em;caption-text` **Master Python for AI/ML**
107 | ^^^
108 | Python programming skills are essential for architects, engineers, and even managers in the IT industry.
109 | Become a Python master to do more with AI/ML applications.
110 | :::
111 |
112 |
113 | ::::
114 | % End of Cards grid
115 |
116 |
117 | ### General
118 |
119 |
120 | % Start cards grid
121 | ::::{grid} 3
122 | :class-container: text-center
123 | :gutter: 3
124 |
125 | :::{grid-item-card}
126 | :link: https://nocomplexity.com/documents/arplaybook/introduction.html
127 | :link-type: url
128 | {octicon}`book;2em;caption-text` **Architecture Playbook**
129 | ^^^
130 | A playbook providing practical tools to help create architectures and designs more quickly and effectively.
131 | :::
132 |
133 | :::{grid-item-card}
134 | :link: https://nocomplexity.com/simplifyit/
135 | :link-type: url
136 | {octicon}`book;2em;caption-text` **Simplify IT**
137 | ^^^
138 | This is an eBook with proven scientific tools and frameworks to help you effectively solve complex IT problems and gain a comprehensive understanding of IT systems in a business context.
139 | :::
140 |
141 |
142 |
143 | ::::
144 | % End of Cards grid
--------------------------------------------------------------------------------
/aboutthisguide.md:
--------------------------------------------------------------------------------
1 | # About this guide
2 |
3 | This open security reference architecture is created to be used and reused.
4 |
5 | We use only FOSS tools to create content, images and publications (web version, PDF, ePUB).
6 |
7 |
8 | * The latest version of this guide is made using [Jupyter Book](https://jupyterbook.org/intro.html). Jupyter Book is an open source project for building beautiful, publication-quality books and documents from computational material.
9 |
10 |
11 | On the background we simple Python tools to keep things organized and maintainable.
--------------------------------------------------------------------------------
/architecture/NCSC-designprinciples.md:
--------------------------------------------------------------------------------
1 | # NCSC:Secure design principles
2 |
3 | The UK National Cyber Security Centre provides solid information to simplify cyber security for small and large organisations. All material is [open](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/).
4 |
5 | ## Five principles for the design of cyber secure systems
6 |
7 | 1. Establish the context before designing a system
8 | Before you can create a secure system design, you need to have a good understanding of the fundamentals and take action to address any identified short-comings.
9 |
10 | 2. Make compromise difficult
11 | Designing with security in mind means applying concepts and using techniques which make it harder for attackers to compromise your data or systems.
12 |
13 | 3. Make disruption difficult
14 | When high-value or critical services rely on technology for delivery, it becomes essential that the technology is always available. In these cases the acceptable percentage of ‘down time’ can be effectively zero.
15 |
16 | 4. Make compromise detection easier
17 | Even if you take all available precautions, there’s still a chance your system will be compromised by a new or unknown attack. To give yourself the best chance of spotting these attacks, you should be well positioned to detect compromise.
18 |
19 | 5. Reduce the impact of compromise
20 | Design to naturally minimise the severity of any compromise.
21 |
22 | See the NCSC site with these [principles](https://www.ncsc.gov.uk/collection/cyber-security-design-principles/cyber-security-design-principles) for more helpful information on each principle.
23 |
24 | source:https://www.ncsc.gov.uk/
25 |
26 | ## Attribution
27 |
28 | Minor textual corrections in the NCSC security principles are made before incorporating these principles in this publication. Original NCSC material is [open-government version 3](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/) licensed.
29 |
--------------------------------------------------------------------------------
/architecture/attack-vectors.md:
--------------------------------------------------------------------------------
1 | # Attack vectors
2 |
3 | Good security is goal oriented. Good security architecture is tailored to your situation. When defining a product or new (IT) service one of the key activities is to define your specific security requirements. Defining requirements is known to be hard, time consuming and complex. Especially when you have iterative development cycles and you do not have a clearly defined view of your final product or service that is to be created.
4 |
5 | Defining attack vectors within your security requirements documentation is proven to be helpful from the start. Attack vectors give more focus on expected threats so you can start developing security measures that really matter in your situation from the start.
6 |
7 | Attack vectors are routes or methods used to get into information systems. Attacks are the techniques that attackers use to exploit the vulnerabilities in applications. Many attack vectors take advantage of the human element in the system or one of the maintenance activities defined for the system, because that’s often defined as the weakest link.
8 |
9 | Within the IT cyber security world many terms and definitions are used. Attack vectors usually require detailed knowledge to judge whether the vector is relevant in a specific situation.
10 |
11 | Some attack vectors apply to critical infrastructure components, like NTP or DNS. E.g. in a rogue master attack, an attacker causes other nodes in the network to believe it is a legitimate master. Contrary to spoofing attacks in the Rogue Master attack the attacker does not fake its identity, but rather manipulates the master election process using malicious control packets.
12 |
13 | The good news is: The number of possible attack vectors is limited. The bad news is: The ways an attack vector can be exploited is endless. Unless decent security measures are taken to minimise attacks using this specific attack vector. Good designed security solutions are not that complicated and complex after all.
14 |
15 | ## Attack vectors and Weaknesses
16 |
17 | * A good reference for attack vectors is to use the [ATT&CK model](https://attack.mitre.org/).
18 | See the section on models for the reference and more info.
19 |
20 | And check the subsections:
21 |
22 | ```{tableofcontents}
23 | ```
24 |
25 |
--------------------------------------------------------------------------------
/architecture/common-attackvectors.md:
--------------------------------------------------------------------------------
1 | # Common Attack vectors
2 |
3 | Common attack vectors are:
4 |
5 | * Analysis of vulnerabilities in compiled software without source code
6 |
7 | * Anti-forensic techniques
8 |
9 | * Automated probes and scans
10 |
11 | * Automated widespread attacks
12 |
13 | * Client validation in AJAX routines
14 |
15 | * Cross-site scripting in AJAX
16 |
17 | * Cryptographic Performance Attacks
18 |
19 | * Cyber-threats & bullying (not illegal in all jurisdictions)
20 |
21 | * DoS Attacks
22 |
23 | * Email propagation of malicious code
24 |
25 | * Executable code attacks (against browsers)
26 |
27 | * Exploiting Vulnerabilities
28 |
29 | * GUI intrusion tools
30 |
31 | * HTTPS Interception
32 |
33 | * Industrial espionage
34 |
35 | * Internet social engineering attacks
36 |
37 | * Malicious AJAX code execution
38 |
39 | * Network sniffers
40 |
41 | * Packet Manipulation
42 |
43 | * Packet spoofing
44 |
45 | * Parameter manipulation with SOAP
46 |
47 | * Replay Attack
48 |
49 | * RIA thick client binary vector
50 |
51 | * Rogue Master Attack
52 |
53 | * RSS Atom Injection
54 |
55 | * Session-hijacking
56 |
57 | * Side-channel attack
58 |
59 | * Sophisticated botnet command and control attacks
60 |
61 | * Spoofing
62 |
63 | * Stealth and other advanced scanning techniques
64 |
65 | * Targeting of specific users
66 |
67 | * Web service routing issues
68 |
69 | * Wide-scale trojan distribution
70 |
71 | * Wide-scale use of worms
72 |
73 | * Widespread attacks on DNS infrastructure
74 |
75 | * Widespread attacks using NNTP to distribute attack
76 |
77 | * Widespread, distributed denial-of-service attacks
78 |
79 | * Windows-based remote access trojans (Back Orifice)
80 |
81 | * WSDL scanning and enumeration
82 |
83 | * XML Poisoning
84 |
85 | * XPATH injection in SOAP message
86 |
87 | It is recommended that you specify in your solution architecture the attack vectors that apply to your use case. Remember to put the explanation of the attack vectors used in an appendix, since not all your stakeholders know what e.g. ‘Spoofing’ is.
88 |
--------------------------------------------------------------------------------
/architecture/frameworks.md:
--------------------------------------------------------------------------------
1 | # Frameworks
2 |
3 | ## Cyber SecurityFramework (Saudi Arabian Monetary Authority)
4 |
5 | To improve cyber resilience, the Saudi Arabian government created mandatory guidelines to strengthen their constituents’ security postures and provide prescriptive measures to defend against today’s cyber threats.
6 |
7 | SAMA established a Cyber Security Framework (“the Framework”) to enable Financial Institutions to effectively identify and address risks related to cyber security.
8 |
9 | See: https://www.sama.gov.sa/en-US/Laws/BankingRules/SAMA%20Cyber%20Security%20Framework.pdf
10 |
11 | ## In-toto
12 |
13 | [In-toto](https://in-toto.io/): A framework to secure the integrity of software supply chains.
14 |
15 |
16 | ```{admonition} What is in-toto?
17 | :class: tip
18 |
19 | in-toto is designed to ensure the integrity of a software product from initiation to end-user installation. It does so by making it transparent to the user what steps were performed, by whom and in what order. As a result, with some guidance from the group creating the software, in-toto allows the user to verify if a step in the supply chain was intended to be performed, and if the step was performed by the right actor.
20 |
21 | Check: [https://in-toto.io/](https://in-toto.io/)
22 |
23 | ```
24 |
25 | Check [here for the github](https://github.com/in-toto/in-toto) repository.
26 |
27 |
28 | ## NIST Security framework
29 |
30 | Whenever you feel the need to draw a process regarding security or risk
31 | processes: resist the temptation! The US based NIST organization is a
32 | well-known governmental organization that offers great publications on
33 | all thinkable subjects regarding security.
34 |
35 | One of the simplest, yet most frequently model is displayed here below.
36 |
37 | 
38 |
39 | On the NIST site (see references) you can find in-depth information
40 | regarding all sub functions of this security framework. The experience
41 | is, is that it is far better to check what in your use case needs
42 | special attention. If you ever feel the need to create your own security
43 | framework, think again. In essence all come down to the high level
44 | framework described by the NIST organization. Using a broad used
45 | security framework has a number of advantages:
46 |
47 | - Easier communication with stakeholders;
48 | - Easier knowledge and experience transfer between security experts of
49 | different organization;
50 | - Saves time, time you can use to solve the real context specific
51 | issues regarding practice use and implementation of the security
52 | functions.
53 |
54 |
55 | ## NIST Risk Management Framework RMF
56 |
57 | The NIST Risk Management Framework (RMF) provides a comprehensive, flexible, repeatable, and measurable 7-step process that any organization can use to manage information security and privacy risk for organizations and systems and links to a suite of NIST standards and guidelines to support implementation of risk management programs to meet the requirements of the Federal Information Security Modernization Act (FISMA).
58 |
59 |
60 | Risk management overview:
61 |
62 | https://csrc.nist.gov/projects/risk-management
63 |
64 | Search for RMF controls (checklist):
65 |
66 | https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#!/search?version=5.1
67 |
68 |
69 | Good overview on of all controls:
70 |
71 | https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#!/controls?version=5.1
72 |
73 | ## Open Software Supply Chain Attack Reference (OSC&R)
74 |
75 | A great framework for Releasing Secure Products.
76 |
77 | ```{admonition} Open Software Supply Chain Attack Reference (OSC&R)
78 | :class: tip
79 |
80 | Make security a part of product development.
81 |
82 | Check: [https://pbom.dev/](https://pbom.dev/)
83 | ```
84 |
85 |
86 |
87 | ## The Update Framework
88 |
89 | The Update Framework (TUF) helps developers maintain the security of software update systems, providing protection even against attackers that compromise the repository or signing keys. TUF provides a flexible framework and specification that developers can adopt into any software update system.
90 |
91 | TUF is hosted by the Linux Foundation as part of the Cloud Native Computing Foundation (CNCF) and is used in production by various tech companies and open source organizations.
92 |
93 | Check: https://theupdateframework.io/
94 |
95 | This project is a Linux Foundation project under the Cloud Native Computing Foundation.
96 |
97 | ## Supply-chain Levels for Software Artifacts (SLSA)
98 |
99 |
100 | Supply-chain Levels for Software Artifacts, or SLSA ("salsa"). It’s a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It’s how you get from "safe enough" to being as resilient as possible, at any link in the chain.
101 |
102 |
103 | ```{hint} More information:
104 | [Check the SLSA security framework](https://slsa.dev/)
105 |
106 | ```
107 |
108 | ## Secure Software Development Framework (SSDF)
109 |
110 | Few software development life cycle (SDLC) models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model to ensure that the software being developed is well-secured. This document recommends the Secure Software Development Framework (SSDF) – a core set of high-level secure software development practices that can be integrated into each SDLC implementation.
111 |
112 | Check [ NIST SP 800-218 Secure Software Development Framework (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)
113 |
114 | ## Open Cybersecurity Schema Framework (OCSF)
115 |
116 | The Open Cybersecurity Schema Framework is an open-source project, delivering an extensible framework for developing schemas, along with a vendor-agnostic core security schema.
117 | The framework is made up of a set of data types, an attribute dictionary, and the taxonomy. It is not restricted to the cybersecurity domain nor to events, however the initial focus of the framework has been a schema for cybersecurity events.
118 | Check and use: [Cybersecurity Schema Framework](https://schema.ocsf.io/)
119 |
120 | :::{note}
121 | OCSF is licensed under the Apache License 2.0. The repository home is: [https://github.com/ocsf/](https://github.com/ocsf/)
122 | :::
123 |
124 |
125 | ## VERIS Framework
126 |
127 | The Vocabulary for Event Recording and Incident Sharing (VERIS) is a set of metrics designed to provide a common language for describing security incidents in a structured and repeatable manner. VERIS is a response to one of the most critical and persistent challenges in the security industry - a lack of quality information. VERIS targets this problem by helping organizations to collect useful incident-related information and to share that information - anonymously and responsibly - with others.
128 |
129 | Check: [https://verisframework.org/](https://verisframework.org/)
130 |
131 | Repository: [https://github.com/vz-risk/veris](https://github.com/vz-risk/veris)
132 |
133 |
134 | ```{include} ../generatedfiles/frameworks.md
135 | ```
--------------------------------------------------------------------------------
/architecture/mozilla-dataprivacy-principles.md:
--------------------------------------------------------------------------------
1 | # Mozilla Data Privacy Principles
2 |
3 |
4 |
5 | 1. No surprises
6 |
7 | Use and share information in a way that is transparent and benefits the user.
8 |
9 | 2. User control
10 |
11 | Develop products and advocate for best practices that put users in control of their data and online experiences.
12 |
13 | 3. Limited data
14 |
15 | Collect what we need, de-identify where we can and delete when no longer necessary.
16 |
17 | 4. Sensible settings
18 |
19 | Design for a thoughtful balance of safety and user experience.
20 |
21 | 5. Defense in depth
22 |
23 | Maintain multi-layered security controls and practices, many of which are publicly verifiable.
24 |
25 |
26 |
27 | [Source](https://www.mozilla.org/en-US/privacy/principles/)
--------------------------------------------------------------------------------
/architecture/ms-zt-principles.md:
--------------------------------------------------------------------------------
1 | # Zero Trust principles (Microsoft)
2 |
3 |
4 | ## Verify explicitly
5 |
6 | Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.
7 |
8 |
9 | ## Use least privileged access
10 |
11 | Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive polices, and data protection to help secure both data and productivity.
12 |
13 |
14 | ## Assume breach
15 |
16 | Minimize blast radius for breaches and prevent lateral movement by segmenting access by network, user, devices, and app awareness. Verify all sessions are encrypted end to end. Use analytics to get visibility, drive threat detection, and improve defenses.
17 |
18 | *([source](https://www.microsoft.com/en-us/security/business/zero-trust))*
19 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/01-Know-your-architecture-including-users-devices-and-services.md:
--------------------------------------------------------------------------------
1 | # 1. Know your architecture including users, devices, services and data
2 |
3 | In the zero trust network model it's more important than ever to know your assets. This will most likely involve undertaking an asset discovery phase to understand what you have. In some environments this can be challenging and it might involve using an automated tool to discover assets on the network. It might not always be a technology problem, it could be the case you can determine your assets by querying procurement records. In a micro service architecture it would be advantageous to know the data flows between services before you start to implement zero trust.
4 |
5 | In order to get the benefits from zero trust you need to know about each component of your architecture, from users and their devices (including external users), through to the services and data they are accessing.
6 |
7 | Your attention should be focused on the components of the system which use the network. The network itself should be considered untrusted and hostile
8 |
9 | **Transitioning to zero trust**
10 |
11 | This principle is particularly important if transitioning to a zero trust architecture for an established system, with many pre-existing services. If a zero trust architecture is implemented without considering existing services, they may be at higher risk. These services may not be designed for a hostile, untrusted scenario and therefore will be unable to defend themselves against attack.
12 |
13 | **Conduct a risk assessment**
14 |
15 | Once you know your architecture it puts you in a better position to carry out an exercise to understand the risks to your new network design and the assets in the network and ensure they are being mitigated. It would be sensible to start with a risk assessment. This can be used to help you understand if all risks have been mitigated using the zero trust components under consideration. Degree of risk mitigation may depend on criticality of assets. It is imperative to evaluate the importance of the assets and provide the safeguards commensurate to them.
16 |
17 | If all the risks cannot be mitigated using a zero trust approach, the existing security controls from your current network architecture will need to stay in place until this is resolved.
18 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/03-Assess-your-users-behaviour-devices-and-services-health.md:
--------------------------------------------------------------------------------
1 | # 3. Assess your user's behaviour, devices and services health
2 |
3 | You should monitor health signals from your users and devices (including IoT) continuously, to evaluate confidence in their trustworthiness. For example, you may want to know where your users are trying to access services from and have confidence in the health of your devices.
4 |
5 | ## Device health
6 |
7 | You need to have confidence that the devices accessing your services and data are healthy. The health of these devices represents some of the most important signals used to control access to your data and services. Device health consists of compliance with device configuration policies and device state.
8 |
9 | First, define policies which configure devices to be secure - the [NCSC's mobile device guidance](https://www.ncsc.gov.uk/collection/mobile-device-guidance) can help with this. Using a device management service, apply these policies to devices and enforce them, then continuously check that devices are compliant. Is the device compliant with the policies that you set?
10 |
11 | Device health can be determined based on the state of security features on the platform. For example, is secure boot enabled? [Are the latest operating system updates installed](https://www.ncsc.gov.uk/collection/mobile-device-guidance/keeping-devices-and-software-up-to-date)? [Is virtualisation-based security](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs) or [system integrity protection enabled](https://support.apple.com/en-us/HT204899)?
12 |
13 | Going further, determining the underlying state of a devices' firmware, boot process, endpoint security suite and operating system kernel are strong signals which help to the determination its overall health. Attestation is a way of achieving this, taking a snapshot of the state of a device with claims about different components of the hardware and operating system. The endpoint security suite can inform whether the device is compromised. This information can be used as a signal that can be used to determine access to a service or data.
14 |
15 | ## Services
16 |
17 | Service health should also be considered, not only when end user devices are accessing them, but also when services are talking to other services. Zero trust infrastructure, such as the policy engine and policy enforcement points should also be considered as services, when reading this principle.
18 |
19 | Services should be configured to satisfy the principles of zero trust using their native security functions, as per documentation. For instance, by enforcing strong authentication mechanisms and disabling legacy protocols that don\'t support modern authentication.
20 |
21 | Services must be kept up to date with the latest software patches and you should be able to determine the version and patch level of the service you are using. [Patches fixing vulnerabilities should be applied at the earliest opportunity.](https://www.ncsc.gov.uk/guidance/vulnerability-management)
22 |
23 | The health of your services needs to be monitored. An unexpected change in state may indicate an unauthorised change, or malicious activity. How this is achieved will depend on the type of service, but ideally this would be carried out programmatically, by interrogating an API provided by the service.
24 |
25 | ## Users
26 |
27 | The behaviour of the users accessing services, devices and data should be carefully considered. Service and data access decisions need to be based on signals of the user and devices being used for the access.
28 |
29 | Define policies that check the state of users\' connections. For example, a user connecting in from a different geographical region to where they are normally based, or activity in the middle of the night may be unexpected. Further signals can be requested to improve the integrity of the user action, by asking for another factor of authentication.
30 |
31 | Passwordless authentication (e.g. FIDO2) is an ideal solution which provides strong security with an excellent user experience. Consider implementing passwordless authentication for a strong, consistent, and simple authentication experience across all of your services.
32 |
33 | Multi-factor Authentication (MFA) is a requirement of zero trust architecture, but with modern devices and platforms, this doesn't mean the user experience has to be poor. The key to preserving the user experience is triggering MFA only when required. For example, when confidence of the user and his or her devices degrades, trigger the MFA. Signals of the users and devices are used to evaluate the confidence.
34 |
35 |
36 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/04-Use-policies-to-authorise-requests.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | # 4. Use policies to authorise requests
4 |
5 | Each request for data or a service should be authorised against a policy. The power of a zero-trust architecture comes from the access policies you define.
6 |
7 | Use products and protocols that support a continuous authentication and authorisation process, whilst protecting your data at rest and in transit with encryption. How you achieve this depends on the of zero trust technologies you deploy.
8 |
9 | For example, in a cloud environment, access may be controlled using an authentication and authorisation broker to provide Single sign-on (SSO) functionality to a variety of applications, with enforcement usually being session-based. Policies will be assessed as a connection is established, and if approved, the broker will provide a short-lived session token allowing access to the service requested by the user.
10 |
11 | Continuous Authentication and Authorisation is supported by monitoring signals from users and devices and evaluating their confidence level continually. When the confidence degrades, re-authentication may be triggered by applying the access policies dynamically before authorising access requests from the users and devices.
12 |
13 | Regardless of how you design your zero trust architecture, a component that enforces access policy should only allow connections if the strict policies you define are satisfied. It\'s important that you trust a product or service that enforces access policy and ensure it has been designed with zero trust in mind. If this component was compromised, it would give the attacker control over who has access to data or services.
14 |
15 | **Use signals to make access decisions**
16 |
17 | Policy decisions should consider several signals, taken from a signals database and real-time connection information. Together, these enable you to build context, so you can decide if an access request can be trusted enough to continue.
18 |
19 | Signals from sources such as the user's identity, their devices and user behaviour can be used to make access decisions. For example, a high-impact action, such as creating a new admin-level user, would have to meet stringent policy requirements to be trusted. Whereas, a relatively low-impact action, such as checking the online lunch menu, would have to meet more lenient policy requirements to be trusted. Stringent and lenient degrees may be adjusted according to confidence level of users and devices.
20 |
21 | 
22 |
23 | **Buying zero trust technology**
24 |
25 | When choosing technologies for your zero-trust architecture, evaluate the signal types they support, as well as other applicable capabilities, for compatibility with your policy engine. Some examples signals that the policy engine could evaluate are the user's role, physical location, authentication factor ,device state, value of the service they are accessing, and risk of the action they are performing.
26 |
27 | Some policy engines will allow you to create risk-based access policies, perhaps prompting for additional signals to gain more confidence in the connection. The risk-based policy engines consider confidence level of the users and devices, and dynamically adjust the access policies. For example, if a user tries to access a high-value service for the first time outside of normal working hours. In this case, the policy engine may ask a user to present a 2nd factor for authentication.
28 |
29 | ## Other considerations
30 |
31 | **Access denied**
32 |
33 | When an access request is denied, consider how the user will be informed. Too much information may facilitate an attacker, too little may frustrate a legitimate user. For example, you may indicate that there has been an authentication error, but not detail what has failed, for example, 'the account does not exist.' This makes life difficult for an attacker trying to enumerate authentication information.
34 |
35 | **Break glass**
36 |
37 | Should an emergency arise where access to data is critical, you may need to have a process in place which allows a connection to be established even if an access policy can\'t be satisfied.
38 |
39 | In such a scenario, the risk needs to be managed carefully to prevent this feature being abused. For example, limit the risk associated with emergency access by only allowing such access, from an individual user account, on a specific device, from a specified location, for a limited time, with minimum privilege required.
40 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/05-Authenticate-everywhere.md:
--------------------------------------------------------------------------------
1 | # 5. Authenticate and Authorise everywhere
2 |
3 | In a zero trust architecture, we assume the network is hostile and authenticate *all* connections that access data or services.
4 |
5 | Services may be available directly over the Internet, so authentication of user requests requires a stronger mechanism than a simple username and password combination.
6 |
7 | Authentication and authorisation decision should consider multiple signals, such as device health, device location and user identity and status, and evaluate risk associated with the access requests.
8 |
9 | **Multi-factor**
10 |
11 | [MFA](https://www.ncsc.gov.uk/guidance/multi-factor-authentication-online-services) is a requirement for a zero trust architecture. This doesn't mean that the user experience has to be poor. On modern devices and platforms, strong MFA can be achieved with a good user experience.
12 |
13 | For higher-impact requests, consider adding additional factors such as: hardware tokens or one-time passwords, device type, and user behaviour analytics
14 |
15 | **Usability**
16 |
17 | It's important that strong authentication doesn't hinder the usability of a service. So, only prompt for additional authentication factors when requests have a higher impact. For example, when accessing sensitive data or requesting privileged actions, such as creating users. SSO should be considered, to mitigate the friction of using MFA.
18 |
19 | A risk-based approach should be considered to mitigate the higher impact caused by the additional authentication factors. In the example above, if the confidence level of the user is sufficiently high, additional factors may be avoided.
20 |
21 | Passwordless authentication (e.g. FIDO2) is an ideal solution, as it provides strong security, and an excellent user experience. Consider implementing passwordless authentication for a strong, consistent, and positive user experience across all of your services.
22 |
23 | **Service to service authentication**
24 |
25 | Requests between services also need to be authenticated. This is normally achieved using API tokens, frameworks such as OAuth or Public Key Infrastructure (PKI). Use mutual authentication wherever possible.
26 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/06-focus-your-monitoring-on-devices-and-services.md:
--------------------------------------------------------------------------------
1 | # 6. Focus your monitoring on users, devices and services
2 |
3 | Given that devices and services are more exposed to network attacks than in traditional architectures, it's important that comprehensive and continuous monitoring is carried out.
4 |
5 | You should know what actions that devices, users and services are performing and what data they are accessing. Your monitoring should link back to the policies that you set, verifying they are being enforced as you expect. Zero trust architecture should be able to adjust the policy dynamically according to the confidence level evaluated based on the signals from the user and the device.
6 |
7 | **No choke points**
8 |
9 | User devices within a traditional walled garden network architecture should use a VPN to send all traffic through a controlled path. This enables traffic to be inspected. In a zero trust architecture, this choke point isn't available and protective monitoring has to be moved onto each device.
10 |
11 | It's important that you are confident in the device health as a compromised, 'unhealthy' device cannot be trusted to provide reliable monitoring, as logs could have been tampered with.
12 |
13 | Endpoint security suite provides features to detect threats, predict and prevent attacks from impersonating the user, compromising the device and exfiltrating your confidential information.
14 |
15 | **Network monitoring**
16 |
17 | Although the network is untrusted and assumed hostile, network monitoring is still important to ensure good performance and cyber hygiene. Monitoring should be carried out on your networks to measure performance, identify all devices attached to your network, detect rogue devices, and malicious activity, especially if you're hosting on-premise services.
18 |
19 | Coupled with device monitoring, network monitoring can help improve visibility and correlation. For example, you could trace network connections to the process on the device that generated them.
20 |
21 | Further advice and guidance can be found with in the NCSC [Logging and protective monitoring](https://www.ncsc.gov.uk/collection/mobile-device-guidance/logging-and-protective-monitoring) page.
22 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/07-Don't-trust-any-network-including-your-own.md:
--------------------------------------------------------------------------------
1 | # 7. Don't trust any network, including your own
2 |
3 | In zero trust the network is considered hostile, therefore you need to build trust into users, devices and services rather than the network.
4 |
5 | Don't trust any network between the device and the service it's accessing, this includes the local network. The device should be configured to prevent attacks that are present on a local network. This would include DNS spoofing, man in the middle attacks and unsolicited inbound connections.
6 |
7 | Attacks targeted at foundational network services, such as DNS, can often only be mitigated at higher layers in the stack. For example, you should ensure that the services your users are accessing are protected with authenticated and encrypted protocols, such as TLS.
8 |
9 | Whatever solution you choose to protect foundation network protocols, we recommend that organisations maintain control of their services. For example, your DNS servers should remain in your control so that you can conduct monitoring and filtering.
10 |
11 | **Enforcing device usage policy**
12 |
13 | In a zero trust architecture, some network traffic is no longer tunnelled back to a central point, so Internet traffic cannot be inspected and monitored. Therefore, the traditional method of enforcing an Internet browsing policy; the blocking of malicious domains and unauthorised use of network protocols, will need to be enforced on the device.
14 |
15 | It could be possible another hop in the network might be required e.g a hosted cloud proxy to provide this functionality. If you do need to hop though a remote service, this could affect the performance and user experience.
16 |
17 | Protective monitoring of network connections should also be moved onto the device. Safe messaging and browsing features such as malicious URL and phishing detection should be considered as device security features.
18 |
19 | **General cyber hygiene**
20 |
21 | While the network should be treated as hostile and untrusted, maintaining cyber hygiene on the network is still important. For example, monitoring of the local network for unauthorised hosts and patching of network components. This will ensure that the network is performant and available. It's especially important in architectures where you are hosting on-premise services.
22 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/08-Choose-services-designed-for-zero-trust.md:
--------------------------------------------------------------------------------
1 | # 8. Choose services designed for zero trust
2 |
3 | Prefer services with built-in support for zero trust.
4 |
5 | Given that in a zero trust architecture, you can't trust the network, services need to be designed to protect themselves. This includes the Internet, to which components could be directly exposed.
6 |
7 | **Legacy services**
8 |
9 | Some services, especially legacy services (services no longer in active development), may need additional components to enable zero trust. This may increase management overhead and cause usability issues, so ensure you have the resources to take this on.
10 |
11 | **Do not reinvent the wheel**
12 |
13 | Creating your own supporting infrastructure should be avoided, due to the cost, complexity and potential for error. In this case, as elsewhere, the general cyber security principle of using products and services that have been designed and built by trained professionals holds true.
14 |
15 | **Look for standards**
16 |
17 | Whenever possible, use standards-based technologies. This allows interoperability between devices and services. A good example is authentication and authorisation, where common standards such as [OpenID Connect](https://openid.net/connect/), OAuth or [SAML](https://wiki.oasis-open.org/security/FrontPage) allow you to use a single directory service to authenticate to many services.
18 |
19 | Unfortunately, there are currently no standards for policies. However, we recommend that you use a single policy engine and apply the full set of features it offers.
20 |
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/Diagrams/User_token_Service_3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/architecture/ncsc-zero-trust-architecture/Diagrams/User_token_Service_3.png
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/Diagrams/User_token_Service_4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/architecture/ncsc-zero-trust-architecture/Diagrams/User_token_Service_4.png
--------------------------------------------------------------------------------
/architecture/ncsc-zero-trust-architecture/Diagrams/ZT-2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/architecture/ncsc-zero-trust-architecture/Diagrams/ZT-2.png
--------------------------------------------------------------------------------
/architecture/reference-architecture.md:
--------------------------------------------------------------------------------
1 | # Reference Architecture
2 |
3 | A reference architecture speeds up creating your solution.
4 | Various good reference architectures exist. The problems arise often when translating an architecture into solutions. Too often no good translation from architecture concepts to a tangible solution is possible.
5 |
6 | The number of security applications available to solve your security problems is overwhelming. But for a good security architecture you should first determine WHAT must be solved before jumping into solutions. Only if you have a good understanding of your problem, an effective selection of security solutions that reduce risks is possible.
7 |
8 | The following conceptual security topology helps with arranging functional to product mapping needs:
9 |
10 | ```{figure} ../images/security-abbs.png
11 | :align: center
12 | ```
13 | *This image is created by (c) nocomplexity.com and is cc-by-sa 4.0 licensed*
14 |
15 | For every security function or service needed you should look serious at using open transparent reusable solutions. So Open Source. Of course many vendors provide good solid security products for specific use cases. But when you feel you need a trivial security service note that there is always a working and maintained FOSS application available. When using a security FOSS solution you have a large choice of companies that deliver maintenance and support on this application on commercial bases.
16 |
--------------------------------------------------------------------------------
/architecture/saltzer_designprinciples.md:
--------------------------------------------------------------------------------
1 | # Saltzer and Schroeder's design principles
2 |
3 | Saltzer and Schroeder's design principles are design principles enumerated by Jerome Saltzer and Michael Schroeder in their 1975 article The Protection of Information in Computer Systems,[1] that from their experience are important for the design of secure software systems.
4 |
5 | The design principles:
6 |
7 | * Economy of mechanism: Keep the design as simple and small as possible.
8 | * Fail-safe defaults: Base access decisions on permission rather than exclusion.
9 | * Complete mediation: Every access to every object must be checked for authority.
10 | * Open design: The design should not be secret.
11 | * Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key.
12 | * Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job.
13 | * Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users.
14 | * Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly.
15 | * Work factor: Compare the cost of circumventing the mechanism with the resources of a potential attacker.
16 | * Compromise recording: It is sometimes suggested that mechanisms that reliably record that a compromise of information has occurred can be used in place of more elaborate mechanisms that completely prevent loss.
17 |
18 | *([source Wikipedia](https://en.wikipedia.org/wiki/Saltzer_and_Schroeder%27s_design_principles) )*
19 |
20 | ## Least privilege
21 |
22 | * Each user and program should operate using fewest privileges possible
23 | * Limits the damage from an accident, error, or attack
24 | * Reduces number of potential interactions among privileged programs
25 | * Unintentional, unwanted, or improper uses of privilege less likely
26 | * Extend to the internals of a program: only smallest portion of program which needs those privileges should have them
27 |
28 | ## Economy of mechanism/Simplicity
29 |
30 | * Protection system's design should be simple and small as possible
31 | * “techniques such as line-by-line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential.‘”
32 | * Aka “KISS” principle (``keep it simple, stupid'')
33 |
34 | ## Open design
35 |
36 | * The protection mechanism must not depend on attacker ignorance
37 | * Instead, the mechanism should be public
38 | Depend on secrecy of relatively few (and easily changeable) items like passwords or private keys
39 | * An open design makes extensive public scrutiny possible
40 | * Makes it possible for users to convince themselves system is adequate
41 | * Not realistic to maintain secrecy for distributed system
42 | * Decompilers/subverted hardware quickly expose implementation “secrets”
43 | * Even if you pretend that source code is necessary to find exploits (it isn't), source code has often been stolen and redistributed
44 |
45 | * Claude Shannon (inventor of information theory) restated Kerckhoff's Law as: “[Assume] the enemy knows the system”
46 |
47 | This is one of the oldest and strongly supported principles, based on many years in cryptography
48 | Kerckhoffs's Law: “A cryptosystem should be designed to be secure if everything is known about it except the key information”
49 |
50 |
51 | ## Complete mediation (“non-bypassable”)
52 |
53 | * Every access attempt must be checked; position the mechanism so it cannot be subverted. For example, in a client-server model, generally the server must do all access checking because users can build or modify their own clients
54 |
55 | ## Fail-safe defaults (e.g., permission-based approach)
56 |
57 | * The default should be denial of service, and the protection scheme should then identify conditions under which access is permitted
58 | * More generally, installation should be secure by default
59 |
60 | ## Separation of privilege
61 |
62 | Ideally, access to objects should depend on more than one condition, so that defeating one protection system won't enable complete access
63 |
64 | ## Least common mechanism
65 |
66 | * Minimize the amount and use of shared mechanisms (e.g. use of the /tmp or /var/tmp directories)
67 | * Shared objects provide potentially dangerous channels for information flow and unintended interactions
68 |
69 | ## Psychological acceptability / Easy to use
70 |
71 | The human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly
72 | Mistakes will be reduced if the security mechanisms closely match the user's mental image of his or her protection goals
73 |
--------------------------------------------------------------------------------
/architecture/securityprinciples.md:
--------------------------------------------------------------------------------
1 | # Security Principles
2 |
3 | Good cyber security principles are simple but crucial for creating a cyber security solution for your context.
4 |
5 | ## What are principles?
6 |
7 | Principles are statements of direction that govern selections and
8 | implementations. That is, principles provide a foundation for decision
9 | making.
10 |
11 | Principles are used within business design and successful IT projects.
12 |
13 |
14 | A definition:
15 |
16 | * A principle is a qualitative statement of intent that should be met by
17 | the architecture.*
18 |
19 | Security architecture principles are used to translate selected
20 | alternatives into basic ideas, standards, and guidelines for simplifying
21 | and organising the construction, operation, and evolution of systems.
22 |
23 | It is important to draw an early differentiation between standards,
24 | requirements, and principles.
25 |
26 | * Standards are “musts”; that is, they require compliance.
27 |
28 | * Requirements articulate specific needs that must be met by a specific
29 | solution.
30 |
31 | * Principles, on the other hand, are more general and serve as a
32 | framework for making choices by providing guidance about the
33 | preferred outcome of a decision in a given context.
34 |
35 | As such, the purpose of our collected principles is to support decision
36 | making with regard to security and privacy design within all
37 | organizations.
38 |
39 | Principles guide architects, consultants and designers with
40 | decision making. Within business design and architecture, you find many
41 | people with strong opinions with what a good and usable principle is or
42 | is not. Discussion is always good to get a better understanding of each
43 | other mental maps. However, discussions on what a good security
44 | principle is, should be target on what you can do with principles. How
45 | principles help you and your company? Can principals help you doing
46 | projects faster and better? Can principles prevent your company
47 | architecture and software systems becoming the next IT over complexity
48 | landscape?
49 |
50 | Having security and privacy principles are a crucial foundation as they
51 | establish the basis for a set of rules and behaviours for any
52 | organization.
53 |
54 | :::{important}
55 | Security principles are statements of direction that govern selections
56 | and implementations.
57 | :::
58 |
59 | :::{note}
60 | **Security principles provide a foundation for decision making and are crucial to have for any new design.**
61 | :::
62 |
63 |
64 | 
65 |
66 | In these sections you find good principles to create your security solution.
67 |
68 | ```{tableofcontents}
69 | ```
70 |
71 |
--------------------------------------------------------------------------------
/architecture/supplychainattacks.md:
--------------------------------------------------------------------------------
1 | # Threat Landscape for Supply Chain Attacks
2 |
3 | With half of the attacks being attributed to Advanced Persistence Threat (APT) actors, their complexity and resources greatly exceed the more common non-targeted attacks, and, therefore, there is an increasing need for new protective methods that incorporate suppliers in order to guarantee that organizations remain secure.
4 |
5 | Supply chain refers to the ecosystem of processes, people, organizations, and distributors involved in the
6 | creation and delivery of a final solution or product5. In cybersecurity, the supply chain involves a wide range of
7 | resources (hardware and software), storage (cloud or local), distribution mechanisms (web applications, online
8 | stores), and management software.
9 | There are four key elements in a supply chain:
10 | * Supplier: is an entity that supplies a product or service to another entity.
11 | * Supplier Assets: are valuable elements used by the supplier to produce the product or service.
12 | * Customer: is the entity that consumes the product or service produced by the supplier.
13 | * Customer Assets: are valuable elements owned by the target.
14 |
15 | An entity can be individuals, groups of individuals, or organizations. Assets can be people, software, documents,
16 | finances, hardware, or others.
17 |
18 | A supply chain attack is a combination of at least two attacks. The first attack is on a supplier that is then used to
19 | attack the target to gain access to its assets. The target can be the final customer or another supplier. Therefore, for
20 | an attack to be classified as a supply chain one, both the supplier and the customer have to be targets.
21 |
22 | Enisa pulished a great report on Supply Chain Attacks. This report aims at mapping and studying the supply chain attacks that were discovered from January 2020 to early July 2021.
23 |
24 | [Download the report](https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks) , published: July 29, 2021
25 |
26 | *Attribution* for the content of this section Enisa: [Enisa](https://www.enisa.europa.eu/) is a the European Union Agency for Cybersecurity.
27 |
28 |
--------------------------------------------------------------------------------
/bio.md:
--------------------------------------------------------------------------------
1 | # Who
2 |
3 | This first release (2016) of the open reference architecture for
4 | security was called open reference architecture for security and privacy.
5 | We have decided to make a separate publication for a privacy playbook. Check bm-support.org for updates on this project.
6 |
7 | ## The initial authors
8 |
9 | The initial authors that started this project in 2015 are:
10 |
11 | **Asim Jahan**
12 |
13 | Asim works as an information security and privacy consultant. As such he
14 | likes to improve or redesign business processes enabling companies and
15 | organisations to perform better with less effort at less costs. He holds
16 | a Bachelor degree in Business IT & Management of The Hague University.
17 | Asim knows the GDPR inside out. He also has all knowledge of CIPP/E and
18 | CIPM. He currently works for the government implementing GDPR together
19 | with a handpicked team. He likes to speak and recently Asim joined a
20 | debating club. blogs and observes developments in cyber realms. Take a
21 | look at his LinkedIn profile: .
22 |
23 | **Maikel Mardjan**
24 |
25 | Maikel works often as IT (security) architect and loves to make designs
26 | for complex IT systems in a simple way. Maikel holds both a Master (Msc)
27 | Business Studies of University of Groningen and a Master degree (Msc)
28 | Electrical Engineering, of Delft University of Technology. Maikel is
29 | TOGAF 9 Certified and CISSP (Certified Information Systems Security
30 | Professional) certified. Maikel currently works for the innovative IT
31 | company [nocomplexity.com](https://nocomplexity.com/). Despite privacy
32 | concerns, Maikel can be found on Twitter
33 | too
34 |
35 |
36 |
37 | ## Contributors
38 |
39 | This guide is the result of the collaboration of people around the
40 | world, and your contributions are welcome!
41 |
42 | The Open Reference Architecture for Security is created with
43 | input of:
44 |
45 | - Alexandre Dulaunoy
46 | - Jens
47 | - Michael Hansen
48 |
--------------------------------------------------------------------------------
/contributing.md:
--------------------------------------------------------------------------------
1 | # Contributing
2 |
3 | Great that you’re here and want to contribute!
4 |
5 | You don’t have to be a security expert to contribute, every contribution is welcome!
6 |
7 | * If you wish to make comments regarding this document, please raise them as [GitHub issues](https://github.com/nocomplexity/SecurityArchitecture). Send comments by email if you are unable to raise issues on GitHub do not want to use Github. All comments are welcome!
8 |
9 |
10 | :::{admonition} This playbook is open source!
11 | :class: tip
12 |
13 | All contributions are welcome!
14 |
15 | The simplest way to make a comment for a specific page is to use the Github icon in the top right.
16 | :::
17 |
18 | We encourage all security professionals to improve this reference architecture. You can help by:
19 |
20 | * Add security principles.
21 |
22 | * Add security models.
23 |
24 | * Add threat models that can be easily reused.
25 |
26 | * Add links towards open (cc-by) solutions created by government's or foundations.
27 |
28 |
29 | Your contributions to this Guide are greatly appreciated as long as contributions fit within the scope and goal of this open security architecture. As an open project, this Open Reference Architecture for Security shall always remain vendor-neutral and freely available for all to use. If you contribute you will of course get credit (mentioned in upcoming publications).
30 |
31 | We have a simple rule for all valuable input:
32 | 1. Input MUST BE open. So cc-by licensed for text links and an OSI approved FOSS licensed for tools.
33 |
34 | The maintainers review your pull request and your patch is merged with the master branch ASAP.
35 |
36 | :::{note}
37 | **Licensing**:
38 |
39 | When you submit text to which you hold the copyright, you agree to license it under:
40 |
41 | * Creative Commons Attribution-ShareAlike 4.0 International License (“CC BY-SA”)
42 | :::
43 |
44 |
--------------------------------------------------------------------------------
/generatedfiles/attacks.md:
--------------------------------------------------------------------------------
1 | ## Attacks
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 3
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance
11 | {octicon}`light-bulb;1em;caption-text` **Apache Log4j Vulnerability Guidance**
12 | ^^^
13 | Log4shell is a critical vulnerability in the widely-used logging tool Log4j, which is used by millions of computers worldwide running online services. A wide range of people, including organisations, governments and individuals are still vulnerable...
14 | +++
15 | [Read more or use this reference »](https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: https://cachewarpattack.com/#home
21 | {octicon}`hubot;1em;caption-text` **CacheWarp**
22 | ^^^
23 | CacheWarp is a software fault attack on AMD SEV-ES and SEV-SNP. It allows attackers to hijack control flow, break into encrypted VMs, and perform privilege escalation inside the VM.
24 | +++
25 | [Read more or use this reference »](https://cachewarpattack.com/#home)
26 | :::
27 |
28 |
29 | :::{grid-item-card}
30 | :link: https://downfall.page/
31 | {octicon}`pencil;1em;caption-text` **Downfall attacks**
32 | ^^^
33 | Downfall attacks target a critical weakness found in billions of modern processors used in personal and cloud computers. This vulnerability, identified as CVE-2022-40982, enables a user to access and steal data from other users who share the same computer.
34 | +++
35 | [Read more or use this reference »](https://downfall.page/)
36 | :::
37 |
38 |
39 | :::{grid-item-card}
40 | :link: https://meltdownattack.com/
41 | {octicon}`note;1em;caption-text` **Meltdown and Spectre**
42 | ^^^
43 | Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware vulnerabilities allow programs to steal data which is currently processed on the computer.
44 | +++
45 | [Read more or use this reference »](https://meltdownattack.com/)
46 | :::
47 |
48 |
49 | :::{grid-item-card}
50 | :link: https://people.redhat.com/~hkario/marvin/
51 | {octicon}`checklist;1em;caption-text` **The Marvin Attack**
52 | ^^^
53 | The Marvin Attack is a return of a 25 year old vulnerability that allows performing RSA decryption and signing operations as an attacker with the ability to observe only the time of the decryption operation performed with the private key.
54 | +++
55 | [Read more or use this reference »](https://people.redhat.com/~hkario/marvin/)
56 | :::
57 |
58 |
59 | ::::
60 | % End of Grid
61 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
62 |
63 |
--------------------------------------------------------------------------------
/generatedfiles/courses.md:
--------------------------------------------------------------------------------
1 | ## Courses
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 3
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://widgets.weforum.org/blockchain-toolkit/data-protection/index.html
11 | {octicon}`project;1em;caption-text` **Data Protection**
12 | ^^^
13 | Course on protecting the confidentiality of sensitive data shared on a blockchain network.
14 | +++
15 | [Read more or use this reference »](https://widgets.weforum.org/blockchain-toolkit/data-protection/index.html)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: https://widgets.weforum.org/blockchain-toolkit/digital-identity/index.html#q01
21 | {octicon}`package;1em;caption-text` **Digital Identity**
22 | ^^^
23 | This module covers considerations and questions to guide the design of a responsible digital identity system as it relates to blockchain for supply chain.
24 | +++
25 | [Read more or use this reference »](https://widgets.weforum.org/blockchain-toolkit/digital-identity/index.html#q01)
26 | :::
27 |
28 |
29 | ::::
30 | % End of Grid
31 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
32 |
33 |
--------------------------------------------------------------------------------
/generatedfiles/framework.md:
--------------------------------------------------------------------------------
1 | ## Framework
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 2
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://www.nist.gov/cyberframework
11 | {octicon}`tools;1em;caption-text` **NIST Cybersecurity Framework**
12 | ^^^
13 | For industry, government, and organizations to reduce cybersecurity risks
14 | +++
15 | [Read more or use this reference »](https://www.nist.gov/cyberframework)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: http://www.opensecurityarchitecture.org/
21 | {octicon}`tag;1em;caption-text` **Open Security Architecture (OSA)**
22 | ^^^
23 | OSA distills the know-how of the security architecture community and provides readily usable patterns for your application. OSA shall be a free framework that is developed and owned by the community.
24 | +++
25 | [Read more or use this reference »](http://www.opensecurityarchitecture.org/)
26 | :::
27 |
28 |
29 | :::{grid-item-card}
30 | :link: https://www.opensamm.org/
31 | {octicon}`briefcase;1em;caption-text` **Software Assurance Maturity Model**
32 | ^^^
33 | The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.
34 | +++
35 | [Read more or use this reference »](https://www.opensamm.org/)
36 | :::
37 |
38 |
39 | ::::
40 | % End of Grid
41 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
42 |
43 |
--------------------------------------------------------------------------------
/generatedfiles/frameworks.md:
--------------------------------------------------------------------------------
1 | ## Frameworks
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 3
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://www.nist.gov/cyberframework
11 | {octicon}`thumbsup;1em;caption-text` **NIST Cybersecurity Framework**
12 | ^^^
13 | For industry, government, and organizations to reduce cybersecurity risks
14 | +++
15 | [Read more or use this reference »](https://www.nist.gov/cyberframework)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: http://www.opensecurityarchitecture.org/
21 | {octicon}`thumbsup;1em;caption-text` **Open Security Architecture (OSA)**
22 | ^^^
23 | OSA distills the know-how of the security architecture community and provides readily usable patterns for your application. OSA shall be a free framework that is developed and owned by the community.
24 | +++
25 | [Read more or use this reference »](http://www.opensecurityarchitecture.org/)
26 | :::
27 |
28 |
29 | :::{grid-item-card}
30 | :link: https://www.opensamm.org/
31 | {octicon}`zap;1em;caption-text` **Software Assurance Maturity Model**
32 | ^^^
33 | The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.
34 | +++
35 | [Read more or use this reference »](https://www.opensamm.org/)
36 | :::
37 |
38 |
39 | ::::
40 | % End of Grid
41 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
42 |
43 |
--------------------------------------------------------------------------------
/generatedfiles/governmentsecurityorganizations.md:
--------------------------------------------------------------------------------
1 | ## GovernmentSecurityOrganizations
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 2
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://www.enisa.europa.eu/
11 | {octicon}`check-circle;1em;caption-text` **ENISA**
12 | ^^^
13 | The European Union Agency for Cybersecurity.
14 | +++
15 | [Read more or use this reference »](https://www.enisa.europa.eu/)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: https://cyber.gouv.fr/
21 | {octicon}`check-circle;1em;caption-text` **French Cybersecurity Agency**
22 | ^^^
23 | French Cybersecurity Agency (ANSSI)
24 | +++
25 | [Read more or use this reference »](https://cyber.gouv.fr/)
26 | :::
27 |
28 |
29 | :::{grid-item-card}
30 | :link: https://www.aspi.org.au/
31 | {octicon}`thumbsup;1em;caption-text` **Australian Strategic Policy Institute (ASPI)**
32 | ^^^
33 | Core aim is to provide the Australian Government with fresh ideas on Australia's defence, security and strategic policy choices. .auCheck provides a series of tests that check whether your internet services follow standards advised by the Australian government and are up to date. .auCheck is a non-commercial, independent and free service. Our mission is to empower users, in particular Australian small businesses, to ask the right questions and request up-to-date services from their providers.
34 | +++
35 | [Read more or use this reference »](https://www.aspi.org.au/)
36 | :::
37 |
38 |
39 | :::{grid-item-card}
40 | :link: https://www.cyber.gov.au/
41 | {octicon}`book;1em;caption-text` **Australian Cyber Security Centre (ACSC)**
42 | ^^^
43 | The Australian Cyber Security Centre (ACSC) leads the Australian Government’s efforts to improve cyber security. Our role is to help make Australia the most secure place to connect online. We monitor cyber threats across the globe 24 hours a day, seven days a week, so we can alert Australians early on what to do.
44 | +++
45 | [Read more or use this reference »](https://www.cyber.gov.au/)
46 | :::
47 |
48 |
49 | :::{grid-item-card}
50 | {octicon}`check-circle;1em;caption-text` **Cybersecurity Library of US DoD**
51 | ^^^
52 | Great collection of links to valuable security resources. Use it and improve it for your context! Also using these resources is good for inspiration when you need to create your own security architecture or how to perform a complex risks analyses in a large environment. Zero Trust is everywhere, but I like the DoD created [Zero Trust reference architecture](https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf)
53 | +++
54 | [Read more or use this reference »](https://dodcio.defense.gov/Library/)
55 | :::
56 |
57 |
58 | :::{grid-item-card}
59 | :link: https://www.nist.gov/
60 | {octicon}`eye;1em;caption-text` **NIST General information**
61 | ^^^
62 | The National Institute of Standards and Technology (NIST) is now part of the U.S. Department of Commerce. It sets standards and guidelines for Cyber Security.
63 | +++
64 | [Read more or use this reference »](https://www.nist.gov/)
65 | :::
66 |
67 |
68 | :::{grid-item-card}
69 | :link: https://www.ncsc.gov.uk/
70 | {octicon}`bookmark;1em;caption-text` **The National Cyber Security Centre(UK)**
71 | ^^^
72 | All standards, information and tips from the UK government. Aim of this initiative is "Making the UK the safest place to live and work online".
73 | +++
74 | [Read more or use this reference »](https://www.ncsc.gov.uk/)
75 | :::
76 |
77 |
78 | :::{grid-item-card}
79 | :link: https://www.nomoreransom.org/en/index.html
80 | {octicon}`verified;1em;caption-text` **No-More-Ransom**
81 | ^^^
82 | The “No-More-Ransom” website is an initiative by the National High Tech Crime Unit of the Netherlands’ police, Europol’s European Cybercrime Centre and two cyber security companies – Kaspersky Lab and Intel Security – with the goal to help victims of ransomware retrieve their encrypted data without having to pay the criminals.
83 | +++
84 | [Read more or use this reference »](https://www.nomoreransom.org/en/index.html)
85 | :::
86 |
87 |
88 | :::{grid-item-card}
89 | :link: https://nzism.gcsb.govt.nz/
90 | {octicon}`pencil;1em;caption-text` **New Zealand Information Security Manual**
91 | ^^^
92 | Great IS manual. The New Zealand Information Security Manual details processes and controls essential for the protection of all New Zealand Government information and systems. Controls and processes representing good practice are also provided to enhance the baseline controls. Use and reuse this manual for your governmental organisation or company.
93 | +++
94 | [Read more or use this reference »](https://nzism.gcsb.govt.nz/)
95 | :::
96 |
97 |
98 | :::{grid-item-card}
99 | {octicon}`book;1em;caption-text` **Luxembourg National Cybersecurity Competence Center (NC3)**
100 | ^^^
101 | The NC3 mission is to support the Luxembourg ecosystem in building cybersecurity competence and capacity. They produce some nice FOSS tools, [check it here](https://github.com/NC3-LU).
102 | +++
103 | [Read more or use this reference »](https://www.nc3.lu/)
104 | :::
105 |
106 |
107 | :::{grid-item-card}
108 | :link: https://lhc.lu/
109 | {octicon}`book;1em;caption-text` **Luxembourg House of Cybersecurity**
110 | ^^^
111 | Luxembourg House of Cybersecurity is the backbone of leading-edge cyber resilience in Luxembourg and aims at capitalising on and further developing innovation, competencies, collaboration and capacity building.
112 | +++
113 | [Read more or use this reference »](https://lhc.lu/)
114 | :::
115 |
116 |
117 | :::{grid-item-card}
118 | :link: https://www.fedramp.gov/
119 | {octicon}`verified;1em;caption-text` **The Federal Risk and Authorization Management Program (FedRAMP)**
120 | ^^^
121 | Provides a standardized approach to security authorizations for Cloud Service Offerings. With many (free)templates!
122 | +++
123 | [Read more or use this reference »](https://www.fedramp.gov/)
124 | :::
125 |
126 |
127 | ::::
128 | % End of Grid
129 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
130 |
131 |
--------------------------------------------------------------------------------
/generatedfiles/publicsecurityagencies.md:
--------------------------------------------------------------------------------
1 | ## Public security agencies
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 3
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://www.cyber.gov.au/
11 | {octicon}`smiley;1em;caption-text` **Australian Cyber Security Centre (ACSC)**
12 | ^^^
13 | The Australian Cyber Security Centre (ACSC) leads the Australian Government’s efforts to improve cyber security. Our role is to help make Australia the most secure place to connect online. We monitor cyber threats across the globe 24 hours a day, seven days a week, so we can alert Australians early on what to do.
14 | +++
15 | [Read more or use this reference »](https://www.cyber.gov.au/)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: https://www.aspi.org.au/
21 | {octicon}`check-circle;1em;caption-text` **Australian Strategic Policy Institute (ASPI)**
22 | ^^^
23 | Core aim is to provide the Australian Government with fresh ideas on Australia's defence, security and strategic policy choices. .auCheck provides a series of tests that check whether your internet services follow standards advised by the Australian government and are up to date. .auCheck is a non-commercial, independent and free service. Our mission is to empower users, in particular Australian small businesses, to ask the right questions and request up-to-date services from their providers.
24 | +++
25 | [Read more or use this reference »](https://www.aspi.org.au/)
26 | :::
27 |
28 |
29 | :::{grid-item-card}
30 | {octicon}`light-bulb;1em;caption-text` **Cybersecurity Library of US DoD**
31 | ^^^
32 | Great collection of links to valuable security resources. Use it and improve it for your context! Also using these resources is good for inspiration when you need to create your own security architecture or how to perform a complex risks analyses in a large environment. Zero Trust is everywhere, but I like the DoD created [Zero Trust reference architecture](https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf)
33 | +++
34 | [Read more or use this reference »](https://dodcio.defense.gov/Library/)
35 | :::
36 |
37 |
38 | :::{grid-item-card}
39 | :link: https://www.enisa.europa.eu/
40 | {octicon}`tag;1em;caption-text` **ENISA**
41 | ^^^
42 | The European Union Agency for Cybersecurity.
43 | +++
44 | [Read more or use this reference »](https://www.enisa.europa.eu/)
45 | :::
46 |
47 |
48 | :::{grid-item-card}
49 | :link: https://cyber.gouv.fr/
50 | {octicon}`thumbsup;1em;caption-text` **French Cybersecurity Agency**
51 | ^^^
52 | French Cybersecurity Agency (ANSSI)
53 | +++
54 | [Read more or use this reference »](https://cyber.gouv.fr/)
55 | :::
56 |
57 |
58 | :::{grid-item-card}
59 | :link: https://lhc.lu/
60 | {octicon}`project;1em;caption-text` **Luxembourg House of Cybersecurity**
61 | ^^^
62 | Luxembourg House of Cybersecurity is the backbone of leading-edge cyber resilience in Luxembourg and aims at capitalising on and further developing innovation, competencies, collaboration and capacity building.
63 | +++
64 | [Read more or use this reference »](https://lhc.lu/)
65 | :::
66 |
67 |
68 | :::{grid-item-card}
69 | {octicon}`cross-reference;1em;caption-text` **Luxembourg National Cybersecurity Competence Center (NC3)**
70 | ^^^
71 | The NC3 mission is to support the Luxembourg ecosystem in building cybersecurity competence and capacity. They produce some nice FOSS tools, [check it here](https://github.com/NC3-LU).
72 | +++
73 | [Read more or use this reference »](https://www.nc3.lu/)
74 | :::
75 |
76 |
77 | :::{grid-item-card}
78 | :link: https://www.nist.gov/
79 | {octicon}`verified;1em;caption-text` **NIST General information**
80 | ^^^
81 | The National Institute of Standards and Technology (NIST) is now part of the U.S. Department of Commerce. It sets standards and guidelines for Cyber Security.
82 | +++
83 | [Read more or use this reference »](https://www.nist.gov/)
84 | :::
85 |
86 |
87 | :::{grid-item-card}
88 | :link: https://nzism.gcsb.govt.nz/
89 | {octicon}`hubot;1em;caption-text` **New Zealand Information Security Manual**
90 | ^^^
91 | Great IS manual. The New Zealand Information Security Manual details processes and controls essential for the protection of all New Zealand Government information and systems. Controls and processes representing good practice are also provided to enhance the baseline controls. Use and reuse this manual for your governmental organisation or company.
92 | +++
93 | [Read more or use this reference »](https://nzism.gcsb.govt.nz/)
94 | :::
95 |
96 |
97 | :::{grid-item-card}
98 | :link: https://www.nomoreransom.org/en/index.html
99 | {octicon}`hubot;1em;caption-text` **No-More-Ransom**
100 | ^^^
101 | The “No-More-Ransom” website is an initiative by the National High Tech Crime Unit of the Netherlands’ police, Europol’s European Cybercrime Centre and two cyber security companies – Kaspersky Lab and Intel Security – with the goal to help victims of ransomware retrieve their encrypted data without having to pay the criminals.
102 | +++
103 | [Read more or use this reference »](https://www.nomoreransom.org/en/index.html)
104 | :::
105 |
106 |
107 | :::{grid-item-card}
108 | :link: https://www.fedramp.gov/
109 | {octicon}`thumbsup;1em;caption-text` **The Federal Risk and Authorization Management Program (FedRAMP)**
110 | ^^^
111 | Provides a standardized approach to security authorizations for Cloud Service Offerings. With many (free)templates!
112 | +++
113 | [Read more or use this reference »](https://www.fedramp.gov/)
114 | :::
115 |
116 |
117 | :::{grid-item-card}
118 | :link: https://www.ncsc.gov.uk/
119 | {octicon}`package;1em;caption-text` **The National Cyber Security Centre(UK)**
120 | ^^^
121 | All standards, information and tips from the UK government. Aim of this initiative is "Making the UK the safest place to live and work online".
122 | +++
123 | [Read more or use this reference »](https://www.ncsc.gov.uk/)
124 | :::
125 |
126 |
127 | :::{grid-item-card}
128 | :link: https://itsecurity.uiowa.edu/
129 | {octicon}`package;1em;caption-text` **The University of Iowa Information Security and Policy Office**
130 | ^^^
131 | Great website from IOWA university with ready to use and REUSE examples of everything you need to set up an security department. Great example. Offers courses, list standards, offerts policies(examples) and more!
132 | +++
133 | [Read more or use this reference »](https://itsecurity.uiowa.edu/)
134 | :::
135 |
136 |
137 | ::::
138 | % End of Grid
139 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
140 |
141 |
--------------------------------------------------------------------------------
/generatedfiles/securitybydesign.md:
--------------------------------------------------------------------------------
1 | ## SecurityByDesign
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 3
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://www.cisa.gov/resources-tools/resources/secure-by-design
11 | {octicon}`eye;1em;caption-text` **Secure-by-Design**
12 | ^^^
13 | Principles and Approaches for Secure by Design Software. At first created for software manufacturers to ship products that are secure by design. But very usefull resource to use, even if you are not creating software!
14 | +++
15 | [Read more or use this reference »](https://www.cisa.gov/resources-tools/resources/secure-by-design)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: https://nocomplexity.com/documents/securitybydesign/intro.html
21 | {octicon}`tag;1em;caption-text` **Security By Design Guide**
22 | ^^^
23 | Security by design is a proven method to develop products that are less vulnerable for cyber security threats. This is the only reference you need.
24 | +++
25 | [Read more or use this reference »](https://nocomplexity.com/documents/securitybydesign/intro.html)
26 | :::
27 |
28 |
29 | ::::
30 | % End of Grid
31 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
32 |
33 |
--------------------------------------------------------------------------------
/generatedfiles/standards.md:
--------------------------------------------------------------------------------
1 | ## Standards
2 |
3 | % This file is GENERATED. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
4 |
5 | ::::{grid} 3
6 | :class-container: text-center
7 | :gutter: 2
8 |
9 | :::{grid-item-card}
10 | :link: https://cyclonedx.org/
11 | {octicon}`smiley;1em;caption-text` **CycloneDX**
12 | ^^^
13 | OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction
14 | +++
15 | [Read more or use this reference »](https://cyclonedx.org/)
16 | :::
17 |
18 |
19 | :::{grid-item-card}
20 | :link: https://objects.monarc.lu/
21 | {octicon}`bookmark;1em;caption-text` **MONARC Objects Sharing Platform**
22 | ^^^
23 | objects.monarc.lu is the MOSP instance for creating and sharing JSON objects related to cybersecurity security, such as vulnerabilities, threats or cybersecurity standards.5112 items are currently available through 19 organizations.
24 | +++
25 | [Read more or use this reference »](https://objects.monarc.lu/)
26 | :::
27 |
28 |
29 | :::{grid-item-card}
30 | {octicon}`verified;1em;caption-text` **OmniBOR**
31 | ^^^
32 | OmniBOR defines two key concepts, Artifact IDs and Input Manifests, that enable anyone to independently produce the same identifier for any software artifact, and to detect any artifact built with vulnerable inputs. See also repo on https://github.com/omnibor
33 | +++
34 | [Read more or use this reference »](https://omnibor.io/)
35 | :::
36 |
37 |
38 | :::{grid-item-card}
39 | {octicon}`stack;1em;caption-text` **Open Common Requirement Enumeration**
40 | ^^^
41 | The Open Source project “OpenCRE “ links all security standards and guidelines together at the level of requirements into one harmonized resource: threats, weaknesses, what to verify, how to program, how to test, which tool settings, in-depth discussion, training material. Everything organized. See also https://github.com/OWASP/OpenCRE
42 | +++
43 | [Read more or use this reference »](https://opencre.org/)
44 | :::
45 |
46 |
47 | :::{grid-item-card}
48 | :link: https://webauthn.guide/
49 | {octicon}`cross-reference;1em;caption-text` **WebAuthn**
50 | ^^^
51 | Public Key Cryptography and Web Authentication (WebAuthn)
52 | +++
53 | [Read more or use this reference »](https://webauthn.guide/)
54 | :::
55 |
56 |
57 | ::::
58 | % End of Grid
59 | % This file is GENERATED using a simple tool. Check the tools on https://nocomplexity.com/ or my github.com/nocomplexity to use it too! Its FOSS.
60 |
61 |
--------------------------------------------------------------------------------
/help.md:
--------------------------------------------------------------------------------
1 | # Help
2 |
3 |
4 | This Playbook is created to simplifying cyber security.
5 |
6 | Helping is possible in multiple ways:
7 | * [Support this work](sponsors)
8 | * [Share this Publication](#share-this-publication) or
9 | * [Contribute](contributing)
10 |
11 |
12 | ## Support this work
13 |
14 | This publication is open-access. So it's free to read, use and reuse as input for other publications.
15 | I believe knowledge should be free and available for everyone on planet earth.
16 |
17 | :::{admonition} Donate
18 | :class: tip
19 |
20 | If you think this PlayBook is worth a few Euros, you can [buy ](https://nocomplexity.gumroad.com/) and receive the PDF version. This will help me to keep this guide maintained. If you are not able to make a small donation, it's fine. Just enjoy this PlayBook and [Share](share-subsection) the word about it.
21 | :::
22 |
23 | :::{admonition} Sponsor
24 | :class: important
25 | As a sponsor you your logo is displayed within our Playbooks and newsletters. This will increase the audience for your products, company or foundation. We’ve got an audience of thousands of adopters that read and use our online Playbooks.
26 |
27 |
28 | Check [this page](https://nocomplexity.com/ads-and-sponsoring/) to increase your audience and discuss options.
29 |
30 |
31 | **Note: We only display ethical ads as static images. So no ad networks or tracking technologies are used.**
32 | :::
33 |
34 | (share-subsection)=
35 | ## Share this publication
36 |
37 | This publication on is created and published on the Internet to be shared as much as possible!
38 |
39 | So Sharing is greatly appreciated!
40 |
41 | :::{tip}
42 | To share this publication , just share the URL:
43 |
44 | [https://simplifysecurity.nocomplexity.com/](https://nocomplexity.com/documents/securityarchitecture/introduction.html)
45 |
46 | Or use copy-paste:
47 | ```
48 | https://simplifysecurity.nocomplexity.com/
49 | ```
50 | :::
51 |
52 |
53 | This Guide is last updated on:
54 | {sub-ref}`today`.
--------------------------------------------------------------------------------
/images/OO.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/OO.png
--------------------------------------------------------------------------------
/images/ROI_logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/ROI_logo.png
--------------------------------------------------------------------------------
/images/User_token_Service_3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/User_token_Service_3.png
--------------------------------------------------------------------------------
/images/User_token_Service_4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/User_token_Service_4.png
--------------------------------------------------------------------------------
/images/YourLogoHere.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/YourLogoHere.png
--------------------------------------------------------------------------------
/images/ZT-2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/ZT-2.png
--------------------------------------------------------------------------------
/images/ddos-model.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/ddos-model.png
--------------------------------------------------------------------------------
/images/essence-of-infosec.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/essence-of-infosec.png
--------------------------------------------------------------------------------
/images/image_10_SDLC.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/image_10_SDLC.png
--------------------------------------------------------------------------------
/images/image_11_IoT.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/image_11_IoT.png
--------------------------------------------------------------------------------
/images/image_12_Nist_CloudSecurityREFmodel.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/image_12_Nist_CloudSecurityREFmodel.png
--------------------------------------------------------------------------------
/images/image_8_OSA.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/image_8_OSA.png
--------------------------------------------------------------------------------
/images/image_9_SAMM.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/image_9_SAMM.png
--------------------------------------------------------------------------------
/images/jericho.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/jericho.png
--------------------------------------------------------------------------------
/images/ml-system.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/ml-system.png
--------------------------------------------------------------------------------
/images/mobile-threads.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/mobile-threads.png
--------------------------------------------------------------------------------
/images/nist.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/nist.png
--------------------------------------------------------------------------------
/images/nocxbanner.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/nocxbanner.png
--------------------------------------------------------------------------------
/images/oath2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/oath2.png
--------------------------------------------------------------------------------
/images/opentitan.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/opentitan.png
--------------------------------------------------------------------------------
/images/principles.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/principles.png
--------------------------------------------------------------------------------
/images/security-abbs.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/security-abbs.png
--------------------------------------------------------------------------------
/images/securitybydesign.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/securitybydesign.png
--------------------------------------------------------------------------------
/images/what_is_security.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nocomplexity/SecurityArchitecture/995617d433230c2cb4ed56f48ed5854ed513ada0/images/what_is_security.png
--------------------------------------------------------------------------------
/introduction.md:
--------------------------------------------------------------------------------
1 | # Introduction
2 |
3 | There are many myths about security, and how difficult it is. Cyber security is a complex domain. There is no perfect solution. Never. But there are simple solutions that do work. Often the best cyber security solutions are open solutions which everyone can use. Good solutions are not subject to a hype. Open solutions are transparent and fully open. So everyone can use and improve it.
4 |
5 | ```{admonition} This Playbook
6 | is created to help you with solving your specific complex security challenges.
7 | ```
8 |
9 |
10 | ## Find security solutions
11 |
12 | Find a proven solution by using this Security Reference Architecture:
13 |
14 | ::::{card-carousel} 2
15 |
16 | :::{card}
17 | :margin: 3
18 | :class-body: text-center
19 | :class-header: bg-light text-center
20 | **[Prevention](prevention/prevention)** 🔐
21 | ^^^
22 | [Simple Checklist](prevention/simple-checklists)
23 |
24 | [Simple Solutions](prevention/simplesolutions)
25 |
26 | [Hardening](prevention/hardening)
27 | :::
28 |
29 |
30 | :::{card}
31 | :margin: 3
32 | :class-body: text-center
33 | :class-header: bg-light text-center
34 | **[Protection](protection/security-management)** ✅
35 | ^^^
36 | [Security Policies](protection/security-policies)
37 |
38 | [Security Classifications](protection/security-classifications)
39 |
40 | [Security Management](protection/security-management)
41 |
42 | [Find vulnerabilities](protection/vulnerabilities-search)
43 | :::
44 | ::::
45 |
46 | ::::{card-carousel} 2
47 |
48 | :::{card}
49 | :margin: 3
50 | :class-body: text-center
51 | :class-header: bg-light text-center
52 | **[Architecture](architecture/reference-architecture)** 📓
53 | ^^^
54 | [Frameworks](architecture/frameworks)
55 |
56 | [Security Principles](architecture/securityprinciples)
57 |
58 | [Security Models](architecture/securitymodels)
59 | :::
60 |
61 | :::{card}
62 | :margin: 3
63 | :class-body: text-center
64 | :class-header: bg-light text-center
65 | **[Learning ](learning/securitycourses)** 📚
66 | ^^^
67 | [Security courses](learning/securitycourses)
68 |
69 | [Open Access Security Books](learning/books)
70 |
71 | [Secure Coding Guidelines](learning/secure-coding)
72 |
73 | [Security References](learning/security-references)
74 | :::
75 |
76 | ::::
77 | % End of card carousel , second row
78 |
79 |
80 |
81 | ## Open and Simple Security Solutions
82 |
83 | This security architecture is not just another security book. We wanted to create an innovative solution that helps you to create better and faster security solutions for your security use case. So we used our many years of experience when dealing with security challenges and created this interactive community driven publication to enable this goal.
84 |
85 | All information within this guide is targeted for reuse to solve your cyber security challenge. This guide is designed so you can make your cyber security designs faster and better. Do not reinvent the wheel. Reuse and improve solid cyber security knowledge and experience that is created to build upon.
86 |
87 |
88 | We believe in open and simple cyber security solutions. Openness and transparency builds trust.
89 |
90 | Open simple solutions are:
91 | * solutions that are easily to understand
92 | * solutions that can be studied
93 | * solutions that can be improved
94 |
95 | Good cyber security solutions are open solutions. Transparency builds trust. Simple solutions that can easily be understood and studied are more transparent than complex proprietary solutions.
96 |
97 | Our mission with this open security reference architecture is to create the best playbook on the internet that continuously helps you with solving your cyber security challenges.
98 |
99 | We believe this is best done together.
100 | ```{tip} Just use the buttons on top of every page. Create an edit suggestion or create an issue.
101 |
102 |
103 | [See Contributing](license)
104 | ```
105 |
106 |
107 | All content in this reference architecture is openly licensed under CC-BY-SA (same as Wikipedia) and everyone can contribute - look for the "Edit" buttons on every page!
108 |
109 | Cyber security is a process, not a destination to arrive at. Designing a cyber security architecture for your use case is the process of choosing between “less safe” and “more safe” and continuing this process until you reach “safe enough” for the information you want to protect.
110 |
111 | Good security design and implementation takes time, patience and hard work.
112 |
113 | Society, companies, and governments are increasingly dependent on IT. Good cyber security is required for safety and privacy.
114 |
115 | There are no silver bullets when it comes to cyber security. Risks will never be zero. Using complex and expensive cyber security solutions are not by definition better.
116 |
117 |
118 | There is no magic tool, method or process that can guarantee that a system (hardware,software, people and processes) will never be compromised.
119 |
120 | ```{warning}
121 | Cyber security is not absolute and can never be guaranteed. Risks will never be zero. It is a journey, not a destination.
122 | ```
123 |
124 |
--------------------------------------------------------------------------------
/learning/books.md:
--------------------------------------------------------------------------------
1 | # Open Access Books
2 |
3 | Continuous learning is key for cyber security.
4 |
5 | Learning (new) Cyber security techniques, vulnerabilities or new protection measures does not have to be boring and expensive.
6 |
7 | The best security professionals share their knowledge under an open access license. So besides checking [OWASP](https://www.owasp.org) use, reuse the quality open access cyber security as provided here.
8 |
9 | ## Cryptography
10 |
11 | * A modern practical book about cryptography for developers with code examples. Practical Cryptography for Developers:
12 |
13 | +++
14 |
15 | * The Joy of Cryptography is a free undergraduate textbook that introduces students to the fundamentals of provable security. A lot of math. But this is crucial to really understand crypto. Created by Mike Rosulek. A cryptographer and associate professor in the School of EECS at Oregon State University. Check: https://joyofcryptography.com/
16 |
17 | +++
18 |
19 | * A Graduate Course in Applied Cryptography, By Dan Boneh and Victor Shoup. [Download in PDF](http://toc.cryptobook.us/)
20 |
21 |
22 | ## DDoS QUICK GUIDE
23 |
24 | Great Guide with a simple but good overview of all DDoS methods and possible protection methods.
25 |
26 | [Download to the DDoS quick guide](https://us-cert.cisa.gov/sites/default/files/publications/DDoS%20Quick%20Guide.pdf)
27 |
28 | ## IoT Security Reference Architecture for the Healthcare Industry
29 |
30 | A growing number of health-related IoT devices are currently available in the marketplace, each incorporating different aspects of the reference architectures explored in this document. Before standard solutions are available, health device developers, OEMs and IT managers should be able to identify the primary IoT and security management needs for their IoT for health solutions by using this reference architecture in conjunction with suitable risk assessment.
31 |
32 | [Read this Reference Architecture](https://www.iotsecurityfoundation.org/wp-content/uploads/2019/05/IoT-Security-Reference-Architecture-For-The-Healthcare-Industry.pdf)
33 |
34 | +++
35 |
36 |
37 | ## Guide to data protection
38 |
39 | This guide is for those who have day-to-day responsibility for data
40 | protection. It explains the purpose and effect of each principle, gives
41 | practical examples and answers frequently asked questions.
42 | Check: [Guide to Data Protection](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/)
43 |
44 |
45 | +++
46 |
47 |
48 | ## Information Security Guide: Effective Practices and Solutions for Higher Education
49 |
50 | Great guide with all topics for IS explained. And with measurements included. Tailored for Education institutes.
51 | The Information Security Guide is mapped to several popular standards, including ISO/IEC 27002:2013, NIST, HIPAA, COBIT, PCI DSS, and the US federal Cybersecurity Frameworks. There are currently 17 chapters on information security, privacy, identity and access management, governance, risk, and compliance.
52 |
53 | Check [https://www.educause.edu/focus-areas-and-initiatives/policy-and-security/cybersecurity-program/resources/information-security-guide](https://www.educause.edu/focus-areas-and-initiatives/policy-and-security/cybersecurity-program/resources/information-security-guide)
54 |
55 |
56 |
57 | +++
58 |
59 | ## Low-Level Software Security for Compiler Developers
60 |
61 | With software security becoming even more important in recent years, it is no surprise to see an ever increasing variety of security hardening features and mitigations against vulnerabilities implemented in compilers. This book aims to help developers of code generation tools such as JITs, compilers, linkers and assemblers to overcome this.
62 |
63 | Link to [Low-Level Software Security for Compiler Developers](https://llsoftsec.github.io/llsoftsecbook/#introduction)
64 |
65 | +++
66 |
67 |
68 | ## Malware Reverse Engineering Handbook
69 |
70 | This handbook by CCDCOE Technology Branch researchers gives an overview of how to analyse malware executables that are targeting the Windows platform. The authors are presenting the most common techniques used in malware investigation including set up of LAB environment, network analysis, behavioural analysis, static and dynamic code analysis. The reader will become familiar with disassemblers, debuggers, sandboxes, system and network monitoring tools. Incident response and collaboration tools are also introduced.
71 |
72 | Book landing page: [https://ccdcoe.org/library/publications/malware-reverse-engineering-handbook/](https://ccdcoe.org/library/publications/malware-reverse-engineering-handbook/)
73 |
74 | Direct PDF link: [https://ccdcoe.org/uploads/2020/07/Malware_Reverse_Engineering_Handbook.pdf](https://ccdcoe.org/uploads/2020/07/Malware_Reverse_Engineering_Handbook.pdf)
75 |
76 |
77 | ## Pentesters Promiscuous Notebook (PPN)
78 |
79 | [A GitBook](https://ppn.snovvcrash.rocks/) for learning to do hands-on things from a practitioner.
80 |
81 | [Repository on Github](https://github.com/snovvcrash/PPN)
82 |
83 |
84 | ## Programming Differential Privacy
85 |
86 | Programming Differential Privacy, A book about differential privacy, for programmers
87 | A great open book on this important security topic. Programming Differential Privacy uses examples and Python code to explain the ideas behind differential privacy! The book is suitable for undergraduate students in computer science, and no theory background is expected.
88 |
89 | Programming Differential Privacy is executable. Using [JupyterBook](https://jupyterbook.org/intro.html), so the same Sphinx based Jupyter tool chain as this Security Architecture book. Each chapter is actually generated from Python code.
90 | Programming Differential Privacy is a living, open-source book. Link to the [GitHub repository](https://github.com/uvm-plaid/programming-dp).
91 |
92 | [Link to the book website](https://programming-dp.com/index.html):https://programming-dp.com/index.html
93 |
94 |
95 | And to read the online html version directly [click here](https://programming-dp.com/index.html).
--------------------------------------------------------------------------------
/learning/cryptography.md:
--------------------------------------------------------------------------------
1 | # Cryptography
2 |
3 | Using cryptographic protection for data in transit or in rest lowers risks.
4 | However using cryptography correct is often not so simple.
5 | This sections is an opinionated collection of open references to help you protect against cryptography attacks.
6 |
7 | - [Timing attacks](https://timing.attacks.cr.yp.to/basics.html) : Timing attacks extract your confidential data from observations of the time used by your computer. Timing attacks have been demonstrated again and again to successfully extract complete cryptographic keys and other secrets. This is aimed at end users, operating-system distributors, CPU manufacturers, and software engineers who would like to know what they can do to protect data against timing attacks. Contains all important papers and work from Billy Bob Brumley and Daniel J. Bernstein.
--------------------------------------------------------------------------------
/learning/foundations.md:
--------------------------------------------------------------------------------
1 | # Open Security Foundations
2 |
3 | * [Center for Internet Security (CIS)](https://www.cisecurity.org/) The Center for Internet Security (CIS) is a 501(c)(3) organization is dedicated to enhancing the cybersecurity readiness and response among public and private sector entities. CIS’s Mission is to: Identify, develop, validate, promote, and sustain best practices in cybersecurity; Deliver world-class security solutions to prevent and rapidly respond to cyber incidents; and Build and lead communities to enable an environment of trust in cyberspace.
4 |
5 |
6 | +++
7 |
8 | * [CA/Browser Forum](https://cabforum.org/) The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).
9 |
10 | +++
11 |
12 | * [Global Encryption Coalition](https://www.globalencryption.org/about/). The Global Encryption Coalition promotes and defends encryption in key countries and multilateral fora where it is under threat. The foundation also provides crucial [resources](https://www.globalencryption.org/resources/) to learn more on encryption.
13 |
14 |
15 | +++
16 |
17 |
18 | * [IDPro Body of Knowledge](https://bok.idpro.org/) The IDPro Body of Knowledge is a compilation of IAM crucial up-to-date knowledge. This content is created and reviewed by the IAM professionals. All articles are peer reviewed.
19 | Within this resource you can find an 'IAM Reference Architecture', articles on 'Authentication and Authorization' and more content regarding IAM (Identity and Access Management).
20 |
21 | +++
22 |
23 |
24 | * [Open Source Technology Improvement Fund](https://ostif.org/)
25 | The Open Source Technology Improvement Fund is a corporate non-profit dedicated to securing open source apps that we all depend on. Securing software isn’t easy, and we know what it takes to succeed. By facilitating security audits and reviews, OSTIF makes it easy for projects to significantly improve security.
26 |
27 | +++
28 |
29 | * [Open Source Security Foundation](https://openssf.org/) Part of the Linux Foundation.
30 | The OpenSSF is the host for several large projects that focus on improving FOSS security.
31 |
32 |
33 | +++
34 |
35 |
36 | * [The Cyber Security Body Of Knowledge](https://www.cybok.org). A comprehensive Body of Knowledge to inform and underpin education and professional training for the cyber security sector. A great collection of resources that cover all aspects of cyber security.
37 |
38 | +++
39 |
40 |
41 |
42 | +++
43 |
44 |
45 |
46 | * [The Shadowserver Foundation](https://www.shadowserver.org/). Since our founding in 2004, The Shadowserver Foundation has become one of the world’s leading resources for Internet security reporting and malicious activity investigation. When we started, we were staffed entirely by volunteers. Today, we employ a full-time team and maintain a global infrastructure spanning 80 countries.
47 | Shadowserver scans the entire IPv4 Internet for over 100 different network protocols every day, and also performs IPv6 scans based on IPv6 hitlists for selected protocols. These are “hello” type port scans that do not exploit any vulnerability.
48 | Check the [daily dashboard](https://dashboard.shadowserver.org/) provided by this foundation.
49 |
50 | +++
51 |
52 | * [Trusted CI](https://www.trustedci.org/): The Trusted CI Framework is a minimum standard for cybersecurity programs. The mission of Trusted CI Foundation is to improve the cybersecurity of NSF computational science and engineering projects, while allowing those projects to focus on their science endeavors. This foundation provides great [templates and tools](https://www.trustedci.org/framework/templates) ready to use!
53 |
54 | +++
55 |
56 | * [ Objective-See Foundation](https://objective-see.org/) Foundation focusses on free, open-source macOS security tools. And is known for organising the macOS security conference, "Objective by the Sea" (#OBTS).
57 |
58 | +++
59 |
60 | * [OpenChain Project](https://www.openchainproject.org/): Linux Foundation project. The OpenChain Project is focused on commercial and non-commercial open source process management in the supply chain. Maintains [OpenChain ISO/IEC 5230](https://www.openchainproject.org/license-compliance) and [OpenChain ISO/IEC DIS 18974](https://www.openchainproject.org/security-assurance) These ISO/IEC standards are at no cost available using this link.
61 |
62 | +++
63 |
64 | * [OpenSCAP](https://www.open-scap.org/). The OpenSCAP project provides tools to improve security of your
65 | infrastructure using open source tools. This project is founded by RedHat and the tools are NIST certified. Use of the tools is encouraged if your systems or infrastructure needs to meet NIST (or other US) security standards.
66 |
67 | +++
68 |
69 | * [Open Source IT Risk Management](https://somap.org/default.html). Focuses on the Security Officers and on helping them in doing their daily business as comfortable as possible. The main goals of SOMAP.org are to develop and maintain:
70 | - Guides and Handbooks explaining and describing Risk Management.
71 | - an open and free 'best practice' Risk Model Repository with security objectives, threats and other risk
72 | related meta-data.
73 |
74 |
75 | +++
76 |
77 | * [The OpenChain Project ](https://www.openchainproject.org/): A Linux Foundation project. The OpenChain Project is solely focused on commercial and non-commercial open source process management in the supply chain. Lots of resources and cc-by or cc0 licensed. Also the ISO/IEC 5230 developed by this project is available.
78 |
79 |
80 | +++
81 |
82 | * [Trusted CI](https://www.trustedci.org/). Trusted CI, the NSF Cybersecurity Center of Excellence is comprised of cybersecurity experts who have spent decades working with science and engineering communities and have an established track record of usable, high-quality solutions suited to the needs of those communities. The team draws from best operational practices and includes leaders in the research and development of new methodologies and high-quality implementations. Trusted CI offers a great collection of valuable resources to help cybersecurity professionals. Almost all content is open and published under a Creative Commons Attribution-NonCommercial 3.0 Unported (CC BYNC 3.0) license.
83 |
--------------------------------------------------------------------------------
/learning/researchlabs.md:
--------------------------------------------------------------------------------
1 | # Cybersecurity Research Labs
2 |
3 | Solving cybersecurity problems is hard. Understanding the problem is a first step towards better solutions.
4 | Every respectable university has a cybersecurity research department. Valorization of research into simple tangible daily cyber solutions is hard. Solving problems means sharing and building upon knowledge of others.
5 |
6 |
7 |
8 | * [The Cybersecurity Research Lab (CRL)](https://www.torontomu.ca/tedrogersschool/cybersecurity-research-lab/)
9 | The Cybersecurity Research Lab (CRL) is an academic research lab at Ted Rogers School of Management at Toronto Metropolitan University.
10 |
11 | +++
12 |
13 | * [International Association for Cryptologic Research](https://iacr.org/)
14 | The International Association for Cryptologic Research (IACR) is a non-profit scientific organization whose purpose is to further research in cryptology and related fields.
15 |
16 | +++
17 |
18 | * [The NYU Center for Cybersecurity (CCS)](https://cyber.nyu.edu/)
19 | The NYU Center for Cybersecurity (CCS) is an interdisciplinary research institute dedicated to training the current and future generations of cybersecurity professionals and to shaping the public discourse and policy, legal, and technological landscape on issues of cybersecurity.
20 |
21 | +++
22 |
23 |
24 | * [COMSEC](https://comsec.ethz.ch/)
25 | COMSEC is the computer security group of the Department of Information Technology and Electrical Engineering (D-ITET) at ETH Zürich. Main research goal is the construction of reliable and secure computing systems.
26 |
27 | +++
28 |
29 | * [The University of Piraeus Cyber Security Research Lab (CSRL)](https://www.torontomu.ca/tedrogersschool/cybersecurity-research-lab/). The Cyber Security Research Lab consists of faculty members, postdoctoral researchers, PhD candidates and other research associates. The vision of the Lab is to reach academic excellence in the areas of cybersecurity, cyber defence and privacy and to advance the skills, knowledge, capabilities and values of our students. Our innovations result from our scientific research activities and relevant publications, our broad collaborations with national/EU/international public/private organizations and SMEs, our participation in numerous R&D cyber security EU projects, as well as in numerous national and international cyber security exercises.
--------------------------------------------------------------------------------
/learning/secure-coding.md:
--------------------------------------------------------------------------------
1 | # Secure Coding Guidelines
2 |
3 |
4 | Creating software is hard. Creating software that meets trivial security
5 | and privacy design rules has proven to be very difficult. Securing
6 | coding is the practice of developing software that prevents security and
7 | privacy risks
8 |
9 | This section gives an opinionated list of good programming standards for
10 | creating software that meets some form of minimal security standards.
11 | When it comes to privacy standards for software it\'s simple: Make sure
12 | the secure coding rules are enforced and no personal data can be exposed
13 | in any way. So start with using the privacy principles before coding.
14 |
15 | Every software engineer should use Secure Coding guidelines and
16 | practices. And every company must check that software used meets minimal
17 | standards regarding mitigating security and privacy risks.
18 |
19 | ## Crypto coding standards
20 |
21 | This reference gives good
22 | \"coding rules\" for implementations of cryptographic operations, and
23 | more generally for operations involving secret or sensitive values.
24 | Created by Jean-Philippe Aumasson ()
25 |
26 | ## Defensive Coding Guide
27 |
28 | A Guide to Improving Software Security,
29 |
30 |
31 | This document provides guidelines for improving software security
32 | through secure coding. It covers common programming languages (C,CPP,
33 | Python, GO) and libraries, and focuses on concrete recommendations. Also
34 | lots of unix \'must do\' and \'never do\' tips from a security
35 | viewpoint.Licensed CC-BY-SA.
36 |
37 | ## GDPR developer's guide
38 |
39 | The Developer's Guide to GDPR provides a first approach to the main principles of GDPR and the different points of attention to consider when developing and deploying applications that respect the privacy of users.
40 |
41 | [GDPR Developer's Guide](https://www.cnil.fr/en/gdpr-developers-guide)
42 |
43 |
44 | ## GOlang programming
45 |
46 | Go Language Web Application Secure Coding Practices,
47 | CC-Licensed so you can edit this
48 | GitBook yourself. Check the repository on
49 | And of course OWASP Secure Coding
50 | Practices are used for this GO specific publication.
51 |
52 | ## Mozilla
53 |
54 | Mozilla is an OSS Foundation that produces a Browser and various other
55 | online communication tools. Security and privacy is a number one
56 | priority for the Mozilla Foundation. Mozilla produces large amount of
57 | code in various programming languages. One of the secure coding
58 | guidelines that is used internal can be found here:
59 |
60 |
61 | ## Reproducible builds
62 |
63 | Reproducible builds are a set of software development practices that
64 | create an independently-verifiable path from source code to the binary
65 | code used by computers. Reproducible Builds project gives rules,
66 | guidelines, tools and more to allow verification that no vulnerabilities
67 | or backdoors have been introduced during the software compilation
68 | process.
69 |
70 |
71 |
72 | ## RUST programming
73 |
74 | Guide to develop secure applications with Rust,
75 |
76 |
77 | The object of this document is to provide hints and recommendations for
78 | secure applications development using the Rust programming language.
79 | This guide also includes a simple checklist. Github repository on:
80 |
81 |
82 | ## Secure Programming HOWTO
83 |
84 | This book provides a set of design and implementation guidelines for
85 | writing secure programs. Such programs include application programs used
86 | as viewers of remote data, web applications (including CGI scripts),
87 | network servers, and setuid/setgid programs. Specific guidelines for C,
88 | C++, Java, Perl, PHP, Python, Tcl, and Ada95 are included. It especially
89 | covers Linux and Unix based systems, but much of its material applies to
90 | any system. For a current version of the [book](https://dwheeler.com/secure-programs/)
91 |
92 | So check:
93 | https://dwheeler.com/secure-programs/
94 |
95 |
96 | ## Web security
97 |
98 | Web Security technologies change continuously. A perfect solution does
99 | not exist. So make sure good practices are combined with good principles
100 | and non technical measurements for minimizing risks.
101 | [Mozilla Web Security Guide](https://developer.mozilla.org/en-US/docs/Web/Security)
102 |
--------------------------------------------------------------------------------
/learning/security-references.md:
--------------------------------------------------------------------------------
1 | # Security References
2 |
3 | Advantage in cybersecurity is gained by harnessing smart ideas. So we collect resources that work and are open to use. So open licensed cybersecurity references are preferred instead of resources that are a fad based on the latest technology buzz.
4 |
5 | Creating a good solid cyber security solution is complicated.
6 | So the most valuable tip is:
7 |
8 |
9 | ```{admonition} Use and reuse good knowledge
10 |
11 | Using and reusing **good** open cyber security references saves you time and improves the quality of your solution.
12 |
13 | ```
14 |
15 |
16 | Good and excellent knowledge for building better security solutions is available under an open access licenses. This is why all references in this section are open access references or available for free under an open liberal license.
17 |
18 | Too often information behind paywall turns out to be a fad or pure marketing information. So be warned!
19 |
20 |
21 | ```{tableofcontents}
22 | ```
23 |
24 |
25 |
26 | ## Attacks methods
27 |
28 | Rowhammer: or
29 |
30 |
31 | DDos:
32 |
33 |
34 |
35 |
36 | ## Learning from attacks
37 |
38 | Key Reinstallation Attacks- Breaking WPA2 by forcing nonce reuse
39 | (KRACK). With hands-on description, check it out:
40 |
41 |
42 |
43 |
44 | ## Thread Models
45 |
46 | The OWASP Automated Threat Handbook provides actionable information and
47 | resources to help defend against automated threats to web applications.
48 |
49 |
50 | ## The Cyber Law Toolkit
51 |
52 | The Cyber Law Toolkit is a dynamic interactive web-based resource for legal professionals who work with matters at the intersection of international law and cyber operations. The Toolkit may be explored and utilized in a number of different ways. At its core, it presently consists of 25 hypothetical scenarios. Each scenario contains a description of cyber incidents inspired by real-world examples, accompanied by detailed legal analysis.
53 |
54 | Great toolkit, with all material available under a nice CC BY-SA 4.0 license.
55 |
56 | Check the toolkit on: [https://cyberlaw.ccdcoe.org/wiki/Main_Page](https://cyberlaw.ccdcoe.org/wiki/Main_Page)
57 |
58 | ## The Common Criteria for Information Technology Security Evaluation (CC)
59 |
60 | If you want to launch a product is many countries and want to make sure you follow all regulations per country: A smart thing is to make use of the common criteria checks.
61 |
62 | The Common Criteria for Information Technology Security Evaluation (CC), and the companion Common Methodology for Information Technology Security Evaluation (CEM) are the technical basis for an international agreement, the Common Criteria Recognition Arrangement (CCRA), which ensures that:
63 |
64 | * Products can be evaluated by competent and independent licensed laboratories so as to determine the fulfilment of particular security properties, to a certain extent or assurance;
65 |
66 | * Supporting documents, are used within the Common Criteria certification process to define how the criteria and evaluation methods are applied when certifying specific technologies;
67 |
68 | * The certification of the security properties of an evaluated product can be issued by a number of Certificate Authorizing Schemes, with this certification being based on the result of their evaluation. These certificates are recognized by all the signatories of the CCRA.
69 |
70 | More information on: https://www.commoncriteriaportal.org/
71 |
72 |
73 |
74 |
75 | ## Web Authorization Protocol (OAuth)
76 | Web Authorization Protocol (OAuth),
77 |
78 |
79 |
80 | ## Mozilla Information Security Guides
81 |
82 | [Security Assurance and Security Operations](https://infosec.mozilla.org/).Technical guidelines, principles and general information as used by the infosec team of Mozilla.
--------------------------------------------------------------------------------
/learning/softwaretesting.md:
--------------------------------------------------------------------------------
1 | # Security Testing Manuals
2 |
3 |
4 | Creating software is hard. Testing security risks even harder. So make
5 | use of good open testing guides.
6 |
7 | ## OWASP Application Security Verification Standard
8 |
9 | The standard provides a basis for designing, building, and testing
10 | technical application security controls, including architectural
11 | concerns, secure development lifecycle, threat modelling, agile security
12 | including continuous integration / deploynent, serverless, and
13 | configuration concerns. See the latest version on the git repository:
14 |
15 |
16 | Or download the PDF from the project main page:
17 |
18 |
19 | ## OWASP Mobile Security Testing Guide
20 |
21 | The Mobile Security Testing Guide (MSTG) is a comprehensive manual for
22 | mobile app security development, testing and reverse engineering. See:
23 |
24 |
25 |
26 | ## OpenSSL: X.509 errors
27 |
28 | A great guide to improve understanding of X.509 errors.
29 |
30 | A must read and must known for everyone who claims to be capable of configuring and maintaining TLS. In reality: Almost no one knowns and understands all aspects of TLS in depth.
31 |
32 | Check the guides: [OpenSSL: X.509 errors](https://x509errors.org/).
33 |
34 | ```{admonition} Mission of this project
35 | :class: note
36 |
37 | Simplify the ecosystem by consolidating the errors and their documentation (similarly to web documentation) and better explaining what the validation errors mean.
38 |
39 | Check also the [code repository and the readme](https://github.com/crocs-muni/usable-cert-validation).
40 | ```
41 |
--------------------------------------------------------------------------------
/learning/trustedcomputing.md:
--------------------------------------------------------------------------------
1 | # Secure Computing
2 |
3 | Secure computing environments aim to created better confidential computing environments. Trusted Execution Environment (TEE) technologies exist on multiple levels (hardware, software, CPU). Open Trusted Environments can provide real improved trust and remove risks that can not be fully eliminated on traditional systems.
4 |
5 | ## Confidential Computing Consortium Projects
6 |
7 | The Linux Foundation [Confidential Computing Consortium](https://confidentialcomputing.io/) is a community focused on projects securing data in use and accelerating the adoption of confidential computing through open collaboration.
8 |
9 | The projects list: [https://confidentialcomputing.io/projects/](https://confidentialcomputing.io/projects/)
10 |
11 |
12 | ## Enarx
13 |
14 | Application deployment system enabling applications to run within Trusted Execution Environments (TEEs).
15 | Enarx is a framework for running applications in TEE instances – which we refer to as “Keeps”–without the need to trust lots of dependencies, without the need to rewrite the application, and without the need to implement attestation separately.
16 |
17 | Enarx aims to minimize the trust relationships required when executing applications, meaning that the only components which need to be trusted are: the CPU and associated firmware, the workload itself, and the Enarx middleware, which is fully open source and auditable. Applications run without any of the layers in the stack (e.g. hypervisor, kernel, user-space) being able to look into or alter the Keep or its contents.
18 |
19 | [http://enarx.io](http://enarx.io)
20 |
21 | ## SeL4
22 |
23 | seL4 is a high-assurance, high-performance operating system microkernel. It is unique because of its comprehensive formal verification, without compromising performance. It is meant to be used as a trustworthy foundation for building safety- and security-critical systems. It is available as open source on GitHub and supported by the seL4 Foundation.
24 |
25 | Github repository: [https://github.com/seL4/](https://github.com/seL4/)
26 | Landing page: [https://sel4.systems/](https://sel4.systems/)
27 |
28 | ## Qubes OS
29 |
30 | Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing. Qubes OS leverages Xen-based virtualization to allow for the creation and management of isolated compartments called qubes.
31 | Recommended by great people and security organisations. Like Edward Snowden and Lets Encrypt.
32 |
33 | Landing page: [https://www.qubes-os.org/](https://www.qubes-os.org/)
34 | Github repository: https://github.com/QubesOS
35 |
36 |
--------------------------------------------------------------------------------
/learning/vulnerabilitydatabases.md:
--------------------------------------------------------------------------------
1 | # Vulnerability Databases
2 |
3 | Security relies on understanding the present and past vulnerabilities within your hardware and software stack. Responsible software and hardware companies publish detailed information about known vulnerabilities. However, remember that the number of reported vulnerabilities for a product does never ever reflect its quality.
4 |
5 | In fact, a lack of openly published vulnerabilities should raise suspicion, as transparency is a hallmark of trustworthy and secure products. The amount of vulnerabilities you can find for a product is not related to the quality. Distrust products that have no open published vulnerabilities.
6 |
7 |
8 | * [Vulnerability Notes Database](https://kb.cert.org/vuls/).The Vulnerability Notes Database provides information about software vulnerabilities. Vulnerability notes include summaries, technical details, remediation information, and lists of affected vendors.
9 |
10 | +++
11 |
12 | * [National Vulnerability Database - US (aka NVD)](https://nvd.nist.gov/) This NVD of the US NIST organization is one of the world largest databases. You should hate it, but there are little alternatives that have the same reach.
13 | The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security-related software flaws, misconfigurations, product names, and impact metrics.
14 |
15 | +++
16 |
17 | * [CWE Vulnerability Databases](http://cwe.mitre.org/) CWE (Common Weakness Enumeration - CWE™) is a community-developed list of common software and hardware security weaknesses. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. Available on:
18 |
19 | +++
20 |
21 | * [GitHub Advisory database](https://github.com/advisories) The GitHub Advisory Database contains a list of known security vulnerabilities and malware, grouped in three categories: GitHub-reviewed advisories, unreviewed advisories, and malware advisories.
22 |
23 | +++
24 |
25 | * [he Open Source Threat Intelligence Sharing Platform](https://www.misp-project.org/) A threat intelligence platform for sharing, storing and correlating Indicators of Compromise of targeted attacks, threat intelligence, financial fraud information, vulnerability information or even counter-terrorism information.
26 |
27 | +++
28 |
29 |
--------------------------------------------------------------------------------
/learning/vulnerabilitymanagement.md:
--------------------------------------------------------------------------------
1 | # Vulnerability management
2 |
3 | - [Stakeholder-Specific Vulnerability Categorization (SSVC)](https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc) A vulnerability analysis methodology that accounts for a vulnerability's exploitation status, impacts to safety, and prevalence of the affected product in a singular system. Check also the [How to Guide](https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf) and try the [online tool](https://www.cisa.gov/ssvc-calculator). The tool is FOSS software and the source repository can be found [here](https://github.com/CERTCC/SSVC)
--------------------------------------------------------------------------------
/license.md:
--------------------------------------------------------------------------------
1 | # License
2 |
3 | This publication is:
4 |
5 | (c) 2025 [BM-Support.org](https://www.bm-support.org/) - Maikel Mardjan and all contributors
6 |
7 | This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Third-party product names may be the trademarks of their respective owners.
8 |
9 | See http://creativecommons.org/licenses/by-sa/4.0/ for the full license text.
10 |
11 |
12 | ## Using and reusing this document
13 |
14 | This Security Reference Architecture is created to be used and improved by you!
15 |
16 | If you do use or reuse content of this Playbook I would appreciate attribution.
17 |
18 | The simplest way to give attribution to this work is by including the following line in your derived publication:
19 |
20 | ```{admonition} Attribution Suggestion
21 | NoComplexity.com, Security Reference Architecture by [Maikel Mardjan](https://nocomplexity.com/), licensed CC BY-SA 4.0.
22 |
23 | ```
24 |
25 | Or use the copy-paste below text this in the document that you create based on this document:
26 |
27 |
28 | ```none
29 | NoComplexity.com, Security Reference Architecture,
30 | by Maikel Mardjan & Asim Jahan and all contributors.
31 | licensed CC BY-SA 4.0.
32 | ```
33 |
34 |
35 |
36 |
37 |
--------------------------------------------------------------------------------
/open.md:
--------------------------------------------------------------------------------
1 | # Openness
2 |
3 | This publication is real open content.
4 |
5 | We believe in [openness](https://www.bm-support.org/open-company-principles/) to simplify cyber security.
6 |
7 | We believe open access is mandatory for simplifying and improving cyber security.
8 |
9 | Open access is the unlimited sharing and reuse of publications and data. Open access for cyber security means knowledge should be freely accessible. So without borders. Applying user tracking or other privacy barriers for publications is not open access.
10 |
11 | Open access improves:
12 | * Sharing cyber solution in an easy way.
13 | * Quality of existing solutions. Improving is often better than to reinvent the wheel.
14 |
15 |
16 |
--------------------------------------------------------------------------------
/prevention/api-security-checklist.md:
--------------------------------------------------------------------------------
1 | # API Security Checklist
2 |
3 | Checklist of the most important security countermeasures when designing, testing, and releasing your API.
4 |
5 |
6 | ## Authentication
7 | - [ ] Don't use `Basic Auth`. Use standard authentication instead (e.g. [JWT](https://jwt.io/), [OAuth](https://oauth.net/)).
8 | - [ ] Don't reinvent the wheel in `Authentication`, `token generation`, `password storage`. Use the standards.
9 | - [ ] Use `Max Retry` and jail features in Login.
10 | - [ ] Use encryption on all sensitive data.
11 |
12 | ### JWT (JSON Web Token)
13 | - [ ] Use a random complicated key (`JWT Secret`) to make brute forcing the token very hard.
14 | - [ ] Don't extract the algorithm from the header. Force the algorithm in the backend (`HS256` or `RS256`).
15 | - [ ] Make token expiration (`TTL`, `RTTL`) as short as possible.
16 | - [ ] Don't store sensitive data in the JWT payload, it can be decoded [easily](https://jwt.io/#debugger-io).
17 |
18 | ### OAuth
19 | - [ ] Always validate `redirect_uri` server-side to allow only whitelisted URLs.
20 | - [ ] Always try to exchange for code and not tokens (don't allow `response_type=token`).
21 | - [ ] Use `state` parameter with a random hash to prevent CSRF on the OAuth authentication process.
22 | - [ ] Define the default scope, and validate scope parameters for each application.
23 |
24 | ## Access
25 | - [ ] Limit requests (Throttling) to avoid DDoS / brute-force attacks.
26 | - [ ] Use HTTPS on server side to avoid MITM (Man in the Middle Attack).
27 | - [ ] Use `HSTS` header with SSL to avoid SSL Strip attack.
28 | - [ ] For private APIs, only allow access from whitelisted IPs/hosts.
29 |
30 | ## Input
31 | - [ ] Use the proper HTTP method according to the operation: `GET (read)`, `POST (create)`, `PUT/PATCH (replace/update)`, and `DELETE (to delete a record)`, and respond with `405 Method Not Allowed` if the requested method isn't appropriate for the requested resource.
32 | - [ ] Validate `content-type` on request Accept header (Content Negotiation) to allow only your supported format (e.g. `application/xml`, `application/json`, etc.) and respond with `406 Not Acceptable` response if not matched.
33 | - [ ] Validate `content-type` of posted data as you accept (e.g. `application/x-www-form-urlencoded`, `multipart/form-data`, `application/json`, etc.).
34 | - [ ] Validate user input to avoid common vulnerabilities (e.g. `XSS`, `SQL-Injection`, `Remote Code Execution`, etc.).
35 | - [ ] Don't use any sensitive data (`credentials`, `Passwords`, `security tokens`, or `API keys`) in the URL, but use standard Authorization header.
36 | - [ ] Use an API Gateway service to enable caching, Rate Limit policies (e.g. `Quota`, `Spike Arrest`, or `Concurrent Rate Limit`) and deploy APIs resources dynamically.
37 |
38 | ## Processing
39 | - [ ] Check if all the endpoints are protected behind authentication to avoid broken authentication process.
40 | - [ ] User own resource ID should be avoided. Use `/me/orders` instead of `/user/654321/orders`.
41 | - [ ] Don't auto-increment IDs. Use `UUID` instead.
42 | - [ ] If you are parsing XML files, make sure entity parsing is not enabled to avoid `XXE` (XML external entity attack).
43 | - [ ] If you are parsing XML files, make sure entity expansion is not enabled to avoid `Billion Laughs/XML bomb` via exponential entity expansion attack.
44 | - [ ] Use a CDN for file uploads.
45 | - [ ] If you are dealing with huge amount of data, use Workers and Queues to process as much as possible in background and return response fast to avoid HTTP Blocking.
46 | - [ ] Do not forget to turn the DEBUG mode OFF.
47 |
48 | ## Output
49 | - [ ] Send `X-Content-Type-Options: nosniff` header.
50 | - [ ] Send `X-Frame-Options: deny` header.
51 | - [ ] Send `Content-Security-Policy: default-src 'none'` header.
52 | - [ ] Remove fingerprinting headers - `X-Powered-By`, `Server`, `X-AspNet-Version`, etc.
53 | - [ ] Force `content-type` for your response. If you return `application/json`, then your `content-type` response is `application/json`.
54 | - [ ] Don't return sensitive data like `credentials`, `Passwords`, or `security tokens`.
55 | - [ ] Return the proper status code according to the operation completed. (e.g. `200 OK`, `400 Bad Request`, `401 Unauthorized`, `405 Method Not Allowed`, etc.).
56 |
57 | ## CI & CD
58 | - [ ] Audit your design and implementation with unit/integration tests coverage.
59 | - [ ] Use a code review process and disregard self-approval.
60 | - [ ] Ensure that all components of your services are statically scanned by AV software before pushing to production, including vendor libraries and other dependencies.
61 | - [ ] Design a rollback solution for deployments.
62 |
63 |
64 | ## Attribution
65 | This section is derived from this [github repostitory](https://github.com/shieldfy/API-Security-Checklist)
66 |
67 | license: MIT License Copyright (c) 2017 Shieldfy
--------------------------------------------------------------------------------
/prevention/architecturesteps.md:
--------------------------------------------------------------------------------
1 | # Create a solution
2 |
3 | This section outlines a clear and simple way to create your security solution.
4 |
5 | To create a sustainable solution to mitigate security risks you must start is by creating a security architecture for your solution.
6 |
7 | An architecture itself does not protect you but a good solution architecture:
8 | * reduces costs
9 | * time and
10 | * lowers risks.
11 | In an architecture the emphasis is not only on the IT (software and hardware) but also on embedding the solutions into your organisation and processes.
12 |
13 | The perfect solution to reduce security risks to zero does not exist. A solution architecture helps in the continuous process of optimizing and controlling your security risks.
14 |
15 | Creating a security architecture can take a lot of time and effort. But a good way to speed up the process of creating your solution is to use this open security reference architecture as the basis.
16 |
17 | This open security reference architecture is created to:
18 | 1. Make security architectures faster and
19 | 2. Improve the quality of your security solution.
20 |
21 | ## Simple steps
22 |
23 | Creating security a security or privacy solution architecture consists of the following high level steps:
24 |
25 | * Dive in the business strategy and organization. Perform a simple risk assessment.
26 |
27 | * Gather security principles and requirements that are relevant for your context.
28 |
29 | * Determine important constraints that apply to your security architecture. There are always constraints, e.g. time, budget, subject matter experts available etc.
30 |
31 | * Derive the architecture building blocks from your architecture or design. Architecture building blocks help you to scope your solution. Using architecture building blocks gives a clear view on (new) integration aspects and where completely new solutions fit in the total IT landscape.
32 |
33 | * Define or reuse the Solution Building Blocks needed to create the design. Prerequisite is that the functionality as specified in the Architecture Building Blocks must be clear.
34 |
35 | * Review and improve your solution.
36 |
37 | 
38 |
39 |
40 |
41 | ## Risk Assessment
42 |
43 | Many great open resources exist that guide you through the process of performing a risk assessment. Creating a risk matrix is not done every day. Use good documentation and proven tools. Make use of the many lessons learned in the field.
44 |
45 |
46 | A number of good open resources that help you with your risk assessment are:
47 | * [Risk Assessment Process Guide](https://www.digital.govt.nz/dmsdocument/3-risk-assessment-process-information-security/html) Based on ISO 3100:2009 Risk Management. Created by the New Zealand Government. Or use the also cc-by licensed [PDF version](https://www.digital.govt.nz/assets/Documents/3Risk-Assessment-Process-Information-Security.pdf). Of [download the MSWord template](https://www.digital.govt.nz/assets/Standards-guidance/Governance/Risk-Assessment-Process-Template.docx)
48 |
49 |
--------------------------------------------------------------------------------
/prevention/conciseguidefordeveloping.md:
--------------------------------------------------------------------------------
1 | # Checklist for Developing More Secure Software
2 |
3 |
4 | Here is a concise guide for all software developers for secure software development, building, and distribution. All tools or services listed are merely examples.
5 |
6 | 1. **Ensure all privileged developers use** [**multi-factor authentication (MFA) tokens**](https://github.com/ossf/great-mfa-project/blob/main/guide/token-usage-guide.md#readme). This includes those with commit or accept privileges. MFA hinders attackers from “taking over” these accounts.
7 | 2. **Learn about secure software development.** Take, e.g., see [Security By Design Playbook](https://nocomplexity.com/documents/securitybydesign/intro.html).
8 | 3. **Use a combination of tools in your CI pipeline to detect vulnerabilities**. See the [OpenSSF guide to security tools](https://github.com/ossf/wg-security-tooling/blob/main/guide.md#readme). Tools shouldn’t be the _only_ mechanism, but they scale.
9 | 4. **Evaluate software before selecting it as a direct dependency**. Only add it if needed, evaluate it (see [Concise Guide for Evaluating Open Source Software](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software), double-check its name (to counter typosquatting), and ensure it’s retrieved from the correct repository.
10 | 5. **Use package managers**. Use package managers (system, language-level, and/or container-level) to automatically manage dependencies and enable rapid updates.
11 | 6. **Implement automated tests**. Include negative tests (tests that what shouldn’t happen doesn’t happen) and ensure the test suite is thorough enough to “ship if it passes the tests”.
12 | 7. **Monitor known vulnerabilities in your software’s direct & indirect dependencies**. E.g., enable basic scanning via GitHub's [dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates) or GitLab [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/). Many other third party Software Composition Analysis (SCA) tools are also available. Quickly update vulnerable dependencies.
13 | 8. **Keep dependencies reasonably up-to-date**. Otherwise, it’s hard to update for vulnerabilities.
14 | 9. **Do not push secrets to a repository**. Use tools to detect pushing secrets to a repository.
15 | 10. **Review before accepting changes**. Enforce it, e.g., [GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) or [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html) protected branches.
16 | 11. **Prominently document how to report vulnerabilities & prepare for them**.
17 | - Use resources like the [Guide to coordinated vulnerability disclosure](https://github.com/ossf/oss-vulnerability-guide).
18 | - [Explicitly disclose security issues affecting vendored dependencies](Vendored-Dependencies-Guide.md).
19 | - Create a [security policy](https://github.com/ossf/oss-vulnerability-guide/tree/main/templates/security_policies). Provide contacts.
20 | 12. **Make it easy for your users to update**. Implement stable APIs, e.g., support old names when new ones are added. Use semantic versioning. Have a deprecation process.
21 | 13. **Sign your project’s important releases**. Use standard tools and signing formats for your distribution. See the [sigstore project](https://www.sigstore.dev/) on how to sign containers and other artifacts.
22 | 14. [**Earn an OpenSSF Best Practices badge**](https://bestpractices.coreinfrastructure.org/) for your open source project. At least earn “passing”. Plan and roadmap to eventually earn silver & gold.
23 | 15. **Improve your** [**OpenSSF Scorecards**](https://github.com/ossf/scorecard) **score (if OSS and on GitHub)**. You can read the [Scorecards checks](https://github.com/ossf/scorecard#scorecard-checks). Use the [Allstar](https://github.com/ossf/allstar) monitor.
24 | 16. **Notify the community of vulnerabilities in your project.** Publish security advisories with accurate & precise information, e.g., what usage & versions are vulnerable, mitigations, and fixed version(s). Get a CVE ID. On GitHub, [create your security advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory#creating-a-security-advisory) & [request a CVE](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#cve-identification-numbers).
25 | 17. **Improve your** [**Supply chain Levels for Software Artifacts (SLSA)**](https://slsa.dev/) **level**. This hardens the integrity of your build and distribution process against attacks.
26 | 18. **Publish and consume a software bill of materials (SBOM)**. This lets users verify inventory, id known vulnerabilities, & id potential legal issues. Consider [**SPDX**](https://spdx.dev/) or [**CycloneDX**](https://cyclonedx.org/).
27 | 19. **Onboard your project into** [**LFX Security**](https://security.lfx.linuxfoundation.org/) **if you manage a Linux Foundation project**.
28 | 20. **Apply the** [**CNCF Security TAG Software Supply Chain Best Practices guide**](https://tag-security.cncf.io/blog/software-supply-chain-security-best-practices-v2/).
29 | 21. **Implement** [**ASVS**](https://owasp.org/www-project-application-security-verification-standard/) **and follow relevant** [**cheatsheets**](https://cheatsheetseries.owasp.org/index.html).
30 | 22. **Apply SAFECode’s** [**Fundamental Practices for Secure Software Development**](https://safecode.org/uncategorized/fundamental-practices-secure-software-development/).
31 | 23. **Complete a third-party security code review/audit**. Expect this to be USD$50K or more.
32 | 24. **Continuously improve**. Improve scores, look for tips, & apply as appropriate.
33 | 25. **Manage succession**. Have clear governance & work to add active, trustworthy maintainer(s).
34 | 26. **Prefer memory-safe languages**. Many vulnerabilities involve memory safety. Where practical, use memory-safe programming languages (most are) and keep memory safety enabled. Otherwise, use mechanisms like extra tools and peer review to reduce risk.
35 |
36 |
37 |
38 | ```{admonition} Attribution
39 | :class: note, dropdown
40 |
41 | Open Source Security Foundation (OpenSSF) Best Practices Working Group, 2023-06-14
42 |
43 | [source](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Developing-More-Secure-Software.md)
44 |
45 | ```
46 |
--------------------------------------------------------------------------------
/prevention/cors.md:
--------------------------------------------------------------------------------
1 | # CORS:Cross-origin resource sharing
2 |
3 | When dealing with internet and APIs you should familiar with Cross-origin resource sharing (CORS).
4 |
5 | This is a mechanism to safely allow a web page or API to access restricted resources from a server on a domain different from the domain that served the web page.
6 |
7 | This CORS specification is written for resource authors and user agents.
8 |
9 |
10 | Solid information on working of CORS and help for implementation can be found on the Mozilla website.
11 |
12 | The main issue when applying CORS is misconfiguration. This happens a lot, mainly caused by implementation without a proper design or implementations that do not follow the design completely. Continuous testing when having configurations with CORS enabled is a must.
13 |
14 |
15 |
16 | ```{admonition} CORS rules are set by the server but enforced (voluntarily) in the client
17 | :class: note, dropdown
18 |
19 | * The server sets the rules: which domains can access their apis and endpoints plus various other rules.
20 |
21 | * The server *does not* enforce these rules. You can easily bypass CORS rules with postman, Curl, etc.
22 |
23 | * Chrome and other good browsers *will* enforce CORS rules (which are set by the server).
24 |
25 | * The purpose of CORS is to protect front end clients (API customers) or ordinary end users (from cross site scripting, CSRF attacks, etc.) . CORS has nothing to do with protecting the server. If browsers did not enforce CORS then CORS would be pointless.
26 |
27 | In short: The purpose of CORS is to protect clients, not servers. Rules that protect clients (or API consumers) are set by the server (and enforced voluntarily in the client.
28 |
29 | ```
30 |
31 |
32 |
33 | Resources for more information:
34 | * [W3.org - Cross-Origin Resource Sharing](https://www.w3.org/TR/2020/SPSD-cors-20200602/)
35 | * [Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)
36 | * [Wikipedia](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing)
37 | * [CORS protocol - Living Standard](https://fetch.spec.whatwg.org/ )
38 |
--------------------------------------------------------------------------------
/prevention/csp-checklist.md:
--------------------------------------------------------------------------------
1 | # Content Security Policy (CSP)
2 |
3 | Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. CSP is should be used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for input validation and output encoding for websites.
4 |
5 | Mozilla Content Security Policy (CSP) Guide: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
6 |
7 | Google CSP tips: https://developers.google.com/web/fundamentals/security/csp
8 |
--------------------------------------------------------------------------------
/prevention/evalFOSS.md:
--------------------------------------------------------------------------------
1 | # Evaluating Open Source Software
2 |
3 | FOSS software is not automatic more secure that commercial software. But having the source code is available means it is easier to evaluate security aspects.
4 |
5 | As a software developer, before using open source software (OSS) dependencies or tools, identify candidates and evaluate the leading ones against your needs. To evaluate a potential OSS dependency for security and sustainability, consider these questions (all tools or services listed are merely examples):
6 |
7 | 1. **Can you avoid adding it?** Can you use an existing (possibly indirect) dependency instead? Every new dependency increases the attack surface (a subversion of the new dependency, or its transitive dependencies, may subvert the system).
8 | 2. **Are you evaluating the intended version?** Ensure you are evaluating the intended version of the software, not a personal fork nor an attacker-controlled fork. These techniques help to counter the common “typosquatting” attack (where an attacker creates an “almost-correct” name).
9 | 1. Check its name and the project website for the link.
10 | 2. Verify the fork relation on GitHub/GitLab.
11 | 3. Check if the project is affiliated with a foundation (in this case, you should be able to access the official source from the foundation’s website).
12 | 4. Check its creation time, and check its popularity.
13 | 3. **Is it maintained?** Unmaintained software is a risk; most software needs continuous maintenance. If it’s unmaintained, it’s also likely to be insecure.
14 | 1. Has significant recent activity (e.g., commits) occurred within the last year?
15 | 2. When was its last release (was it less than a year ago)?
16 | 3. Is there more than one maintainer, ideally from different organizations?
17 | 4. Are there recent releases or announcements from its maintainer(s)?
18 | 5. Does its version string indicate instability (e.g., begin with “0”, include “alpha” or “beta”, etc.)
19 | 4. **Is there evidence that its developers work to make it secure?**
20 | 1. Determine whether the project has earned (or is well on the way to) an [Open Source Security Foundation (OpenSSF) Best Practices badge](https://bestpractices.coreinfrastructure.org/).
21 | 2. Examine information on [https://deps.dev](https://deps.dev/), including its [OpenSSF Scorecards](https://github.com/ossf/scorecard) score and any known vulnerabilities.
22 | 3. Determine whether the package dependencies are (relatively) up to date.
23 | 4. Determine whether there is documentation explaining why it’s secure (aka an “assurance case”).
24 | 5. Are there automated tests included in its CI pipeline? What is its test coverage?
25 | 6. Does the project fix bugs (especially security bugs) in a timely manner? Do they release security fixes for older releases? Do they have an LTS (Long Time Support) version?
26 | 7. Do the developers use code hosting security features where applicable (e.g., if they’re on GitHub or GitLab, do they use branch protection)?
27 | 8. Identify security audits and whether any problems found were fixed. Security audits are relatively uncommon, but see OpenSSF’s “[Security Reviews](https://github.com/ossf/security-reviews)”.
28 | 9. Use [SAFECode’s guide _Principles for Software Assurance Assessment_](https://safecode.org/resource-managing-software-security/principles-of-software-assurance-assessment/) (2019), a multi-tiered approach for examining the software’s security.
29 | 10. Is the current version free of known important vulnerabilities (especially long-known ones)? Organizations may want to implement the [OpenChain](https://www.openchainproject.org/) [Security Assurance Specification 1.1](https://github.com/OpenChain-Project/Security-Assurance-Specification/tree/main/Security-Assurance-Specification/1.1/en) to systemically check for known vulnerabilities on ingest and as new vulnerabilities are publicly revealed.
30 | 11. Do they apply many practices in the [Concise Guide for Developing More Secure Software](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Developing-More-Secure-Software.md)?
31 | 5. **Is it easy to use securely?**
32 |
33 | 1. Are the default configuration and “simple examples” secure (e.g., encryption turned on by default in network protocols)? If not, avoid it.
34 | 2. Is its interface/API designed to be easy to use securely (e.g., if the interface implements a language, does it support parameterized queries)?
35 | 3. Is there guidance on how to use it securely?
36 |
37 | 6. **Are there instructions on how to report vulnerabilities?**
38 | 7. **Does it have significant use?** Software with many users or large users may be inappropriate for your use. However, widely used software is more likely to offer useful information on how to use it securely, and more people will care about its security. Check if a similar name is more popular - that could indicate a typosquatting attack.
39 | 8. **What is the software’s license?** Licenses are technically not security, but licenses can have a significant impact on security and sustainability. Ensure every component has a license, that it’s a widely-used [OSI license](https://opensource.org/licenses) if it’s OSS, and that it’s consistent with your intended use. Projects that won’t provide clear license information are less likely to follow other good practices that lead to secure software.
40 | 9. **What are the results of code evaluation?** Even a brief review of software (by you, someone you hire, or someone else), along with recent changes to it, can give you some insight. Here are things to consider:
41 | 1. When reviewing its source code, is there evidence in the code that the developers were trying to develop secure software (such as rigorous input validation of untrusted input and the use of parameterized statements)?
42 | 2. Is there evidence of insecure/ incomplete software (e.g., many TODO statements)?
43 | 3. What are the “top” problems reported by static analysis tools?
44 | 4. Is there evidence that the software is malicious? Per [_Backstabber’s Knife Collection_](https://arxiv.org/abs/2005.09535), check the installation scripts/routines for maliciousness, check for data exfiltration from **~/.ssh** and environment variables, and look for encoded/ obfuscated values that are executed. Examine the most recent commits for suspicious code (an attacker may have added them recently).
45 | 5. Consider running the software in a sandbox to attempt to trigger and detect malicious code.
46 | 6. Consider running all defined test cases to ensure the software passes them.
47 | 7. See the [OpenSSF's list of security reviews](https://github.com/ossf/security-reviews/blob/main/Overview.md#readme).
48 |
49 | Other resources you may wish to consider include:
50 |
51 | 1. [The Tidelift guide to choosing packages well (February 2021)](https://tidelift.com/subscription/choosing-open-source-packages-well), Tidelift
52 | 2. [How to Evaluate Open Source Software / Free Software (OSS/FS) Programs](https://dwheeler.com/oss_fs_eval.html)
53 |
54 | *Attribution: This text is derived from the this [OSSF repository on github](https://github.com/ossf/wg-best-practices-os-developers/pulls).*
55 |
56 |
--------------------------------------------------------------------------------
/prevention/hardening.md:
--------------------------------------------------------------------------------
1 | # Hardening
2 |
3 | Hardening is a process intended to eliminate a means of attack by patching vulnerabilities and turning off nonessential services.
4 | Using hardening is a great way to make your IT less vulnerable.
5 |
6 | Hardening should be done for every hardware and software object. Hardening can be a lot of work. But more and more good products have good defaults.
7 | Choosing an already hardened software solution, like a hardened Operating System can save you a lot of work and makes you less vulnerable for cyber security risks.
8 |
9 |
10 | ## Kubernetes Hardening Guidance
11 |
12 |
13 | This guidance describes the security challenges associated with setting up and securing
14 | a Kubernetes cluster. It includes hardening strategies to avoid common
15 | misconfigurations and guide system administrators and developers of National Security
16 | Systems on how to deploy Kubernetes with example configurations for the
17 | recommended hardening measures and mitigations. This guidance details the following
18 | mitigations:
19 | - Scan containers and Pods for vulnerabilities or misconfigurations.
20 | - Run containers and Pods with the least privileges possible.
21 | - Use network separation to control the amount of damage a compromise can cause.
22 | - Use firewalls to limit unneeded network connectivity and encryption to protect confidentiality.
23 | - Use strong authentication and authorization to limit user and administrator
24 | access as well as to limit the attack surface.
25 | - Use log auditing so that administrators can monitor activity and be alerted to potential malicious activity.
26 | - Periodically review all Kubernetes settings and use vulnerability scans to help ensure risks are appropriately accounted for and security patches are applied
27 |
28 | This great guide is created by the US National Security Agency (NSA), Cybersecurity Directorate, Endpoint Security and the US Cybersecurity and Infrastructure Security Agency (CISA). This guide is published under a Creative Commons Attribution 4.0 license.
29 |
30 |
31 | Link to the [Kubernetes Hardening Guidance, version august 2022]https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF)
32 |
33 | ## Linux Hardening Guide
34 |
35 | Good hands-on guide creator by the security researcher and developer of [Whonix](https://www.whonix.org/). This guide aims to explain how to harden Linux as much as possible for security and privacy. This guide attempts to be distribution-agnostic and is not tied to any specific one.
36 |
37 | [Link](https://madaidans-insecurities.github.io/guides/linux-hardening.html): https://madaidans-insecurities.github.io/guides/linux-hardening.html
38 |
39 | ## OpenSSH
40 |
41 | Hardening guide and configuration guide of OpenSSH server and client. All Mozilla sites and deployment should follow this mozilla created reference guide.
42 | Most default OpenSSH settings that are security-related already provide good security. But when good is not enough, this guide is a good start to make your configuration better.
43 |
44 | link:[https://infosec.mozilla.org/guidelines/openssh](https://infosec.mozilla.org/guidelines/openssh)
45 |
46 | ## WordPress Hardening
47 |
48 | WordPress is one of the most used FOSS Content Management Systems. Almost 40% of the web is powered by this great FOSS software. But when using third party plugins the risk of security vulnerabilities increased. Security in WordPress is taken very seriously so if you do not mess with the defaults and make sure you apply continuous updates the risks are manageable. However if you have no good process to continuously mitigate the risks of your third party plugins you take a large risk. This guide gives you a head start to prevent security problems when using WordPress!
49 |
50 | ```{note}
51 | This guide created by the developers of WordPress touches the basics. If you are no security experts: Ask help. But keep away from people who frame WordPress as insecure by default. Direct these so called security experts to this guide and look out for security experts who known the value of using FOSS software and have experience of mitigating threads with WordPress.
52 | ```
53 |
54 | This guide is to make sure you have a solid default WordPress configuration.
55 |
56 |
57 | Link: [https://wordpress.org/support/article/hardening-wordpress/](https://wordpress.org/support/article/hardening-wordpress/)
--------------------------------------------------------------------------------
/prevention/ncp-checklists.md:
--------------------------------------------------------------------------------
1 |
2 | # Checklist Repository(NCP)
3 |
4 | The National Checklist Program (NCP), defined by the NIST SP 800-70, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications.
5 |
6 |
7 | Use the NCP Checklist to get a fast and good result on security configuration of operating systems and applications.
8 |
9 | The [link](https://nvd.nist.gov/ncp/repository) to the tool is:https://nvd.nist.gov/ncp/repository
10 |
--------------------------------------------------------------------------------
/prevention/nocx-security-checklist.md:
--------------------------------------------------------------------------------
1 | # Dead simple security checklist
2 |
3 | Simple is hard. Especially to manage and mitigate cyber security risks. The context of cyber security problems consist of a mix of:
4 | * People
5 | * Complicated hardware and software
6 | * Continues changes on all aspects involved
7 | * Organizations
8 | * Internal and external threads
9 | Putting a complex cyber security product in such a context is asking for failures. Stupid simple procedures and awareness trainings are often as good or better than complex and expensive cyber security products to mitigate risks.
10 |
11 |
12 | A good cyber simple solution:
13 | * Does not reinvent the wheel.
14 | * Is open source ([FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software)).
15 | * Ensures that product and process quality aspects can be inspected.
16 | * Follow the principles of reproducible build.
17 | * Meets one or more open security standards that you can verify.
18 |
19 | A simple Cyber security product has:
20 | 1. Zero manual configuration challenges
21 | 2. Zero manual maintenance
22 | 3. Minimal dependencies and
23 | 4. Is created to do one thing, and only one thing, good!
24 |
25 | A good simple cyber security products works without unnecessary additions and modifications in your perimeter.
26 |
27 | ```{attention}
28 | **"The central enemy of reliability is complexity."**
29 | ```
30 |
31 |
32 | Simplicity is the primary cyber security principle. All other principles must be sacrificed in favor of design simplicity.
33 |
34 |
35 | ```{tip} Zero Complexity by design
36 | A nice reference to avoid complexity when designing solutions can be found in the [0Complexity design principles manifest](https://nocomplexity.com/documents/0complexity/0cxdesignprinciples.html)
37 |
38 | ```
39 |
--------------------------------------------------------------------------------
/prevention/owasp-top10-checklist.md:
--------------------------------------------------------------------------------
1 | # OWASP Top 10
2 |
3 |
4 | ```{note}
5 | OWASP is considered to be the gold-standard in computer security information. OWASP maintains an extensive series of cheat sheets which cover all the OWASP Top 10 and more. Below, many of the more relevant cheat sheets have been summarized. To view all the cheat sheets, check out their [Cheat Sheet Index](https://github.com/OWASP/CheatSheetSeries/blob/master/Index.md).
6 | ```
7 | - [Authorization Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authorization_Cheat_Sheet.md)
8 | - [Access Control Basics](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md)
9 | - [Attack Surface Analysis](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md)
10 | - [Content Security Policy (CSP)](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Content_Security_Policy_Cheat_Sheet.md)
11 | - [Cross-Site Request Forgery (CSRF) Prevention](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md)
12 | - [Cross-Site Scripting (XSS) Prevention](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md)
13 | - [Cryptographic Storage](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md)
14 | - [Deserialization](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Deserialization_Cheat_Sheet.md)
15 | - [Docker/Kubernetes (k8s) Security](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Docker_Security_Cheat_Sheet.md)
16 | - [Input Validation](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Input_Validation_Cheat_Sheet.md)
17 | - [Key Management](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Key_Management_Cheat_Sheet.md)
18 | - [OS Command Injection Defense](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.md)
19 | - [Query Parameterization Examples](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Query_Parameterization_Cheat_Sheet.md)
20 | - [Server-Side Request Forgery Prevention](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md)
21 | - [SQL Injection Prevention](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md)
22 | - [Unvalidated Redirects and Forwards](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md)
23 | - [Web Service Security](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Web_Service_Security_Cheat_Sheet.md)
24 | - [XML Security](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_Security_Cheat_Sheet.md)
25 |
26 | ## Attribution
27 | This section is derived from the [owasp.org top 10 project](https://github.com/OWASP/Top10)
28 | Or see https://owasp.org/Top10/
29 |
30 | Copyright 2021 - OWASP Top 10 team - This work is licensed under a Creative Commons Attribution 3.0 Unported License.
31 |
32 | [OWASP 10 top documentation license](https://github.com/OWASP/Top10/blob/master/LICENSE): Creative Commons Attribution-ShareAlike 4.0 International Public License
33 |
--------------------------------------------------------------------------------
/prevention/prevention.md:
--------------------------------------------------------------------------------
1 | # Simplify Prevention
2 |
3 | Investing in prevention measurements is the easiest and simplest way to minimise cyber security risks.
4 |
5 | Good cyber security prevention measurements are simple and cheap. So before investing is expensive cyber security software solution follow these simple prevention rules:
6 |
7 |
8 | ```{admonition} Make a daily-back of important data.
9 | :class: tip, dropdown
10 |
11 | A simple backup that works is cheap, simple and effective against many security threads. Having idiot proof backups is the most valuable weapon against ransomware.
12 |
13 |
14 | Off-line, incorruptible, and disconnected backups – that cannot be encrypted by the malware – is a key corrective control that stops the malware from encrypting your ‘live’ data as well as the backed-up data.
15 | ```
16 |
17 |
18 | ```{admonition} Give only access on a need to know basis to information.
19 | :class: tip, dropdown
20 |
21 | Access control limits the risks of exposure of information. If information is classified make sure that the list of real people whe have access is very limited. Note that information is created to be shared, not to remain secret.
22 |
23 | If you do not understand or trust your access control system: Do not use it!
24 |
25 | If you do not know who (real persons) have access to your classified information: Red flag!
26 |
27 | Make sure you train people regularly on how to handle classified information.
28 |
29 | Information that is vital for your organization should be classified using a rating that makes sense. Also do not forget to classify information like:
30 | - Configuration parameters.
31 | - Software contracts.
32 | - Backup procedures.
33 | Remove sensitive information when it is no longer needed. So keeping logs of all sorts of payment information and details of customers should be limited in time.
34 |
35 | ```
36 |
37 | ```{admonition} Eliminate complicated IT management tasks by automation.
38 | :class: tip, dropdown
39 |
40 | Humans make errors. And often random errors. Software scripts used for automation do not make random errors. If an error is found in a configuration script you can fix it. The same error will never occur again.
41 |
42 | ```
43 |
44 | ```{admonition} Patch applications.
45 | :class: tip, dropdown
46 |
47 | Many applications are regularly updated to address security vulnerabilities as they become apparent – quickly and regularly updating (or ‘patching’) the software will remove a key means by which cyber-security attacks are carried out.
48 |
49 | Avoid discussion if a software update is applicable for your situation. Just update your software since features not used by you can still be used by hackers.
50 |
51 | Since software updates can and will fail: Always make sure that you can roll back.
52 | So before applying software updates:
53 | * Validate that your data is on a safe backup.
54 | * Validate that your roll back procedure is working.
55 | It is common that good software has these features build into their update procedure.
56 |
57 | ```
58 |
59 | ```{admonition} Patch operating systems.
60 | :class: tip, dropdown
61 |
62 | As with applications, security weaknesses are often discovered in operating systems. Again, quickly and regularly updating the operating system defends against most cyber-security attacks. The WannaCry attack in 2017, for example, took advantage of a vulnerability that had been patched for nearly two months.
63 |
64 | ```
65 |
66 | ```{admonition} Restrict administrative privileges.
67 | :class: tip, dropdown
68 |
69 | Microsoft Windows is intended to be easy to use, and often users have free reign of the computer. However, administrator privileges should only be provided on an as-needs basis, as otherwise exploits have the ‘keys to the kingdom’ and can corrupt the computer itself.
70 |
71 | Also on unix based systems, appliances and network devices limiting administrative privileges is a must do.
72 | Software SHOULD never have to use a high privilege account to run.
73 | ```
74 |
75 | ```{admonition} Prevent untrusted code to be run.
76 | :class: tip, dropdown
77 |
78 | So use MAC (mandatory access control). Despite the many technologies like sandboxing, the most important and simple measurement is: to think! Be aware of attachments and downloads of strangers.
79 | ```
--------------------------------------------------------------------------------
/prevention/reproduciblebuilds.md:
--------------------------------------------------------------------------------
1 | # Reproducible builds
2 |
3 | When using FOSS software you have the advantage to inspect the source code on malicious flaws. However almost all software is distributed to end users as pre-compiled binaries. This creates a problem: How do you know if the software is not injected with malicious code?
4 |
5 | Compiling the software yourself is not enough to be sure that no flaws have been introduced.
6 |
7 | ```{attention}
8 | You **should** check if your software has a reproducible build.
9 | ```
10 |
11 |
12 | From a security perspective it is desirable that building a binary the same source code with the same set of tools is reproducible. So that the output is always exactly the same. This makes it possible to verify that the build infrastructure for a binary distribution or embedded system has not been subverted.
13 |
14 |
15 | ```{tip} Simple security tip
16 | For good security you should check if your software has a reproducible build. So validate that the output of your software build matches that of the original build.
17 | ```
18 |
19 | Whilst anyone may inspect the source code of free and open source software for malicious flaws, most software is distributed pre-compiled with no method to confirm whether your received software package matches the software that it is supposed to be.
20 |
21 |
22 | ## What is a reproducible build?
23 | A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
24 |
25 | So a reproducible build is, an approach to determine whether generated binaries correspond
26 | with their original source code.
27 |
28 |
29 | The motivation behind the Reproducible Builds project is to allow verification that no vulnerabilities or backdoors have been introduced during the software compilation process.
30 |
31 | For all software and software build systems in use it is crucial to notice if a developer or build system has been compromised.
32 |
33 | Creating a reproducible build requires some steps. But if you produce software you should do these steps anyway to make sure your software build process is secure.
34 |
35 | Steps to create a reproducible build:
36 | 1. Make your build system entirely deterministic: transforming a given source must always create the same result. For example, the current date and time must not be recorded and output always has to be written in the same order.
37 | 2. The set of tools used to perform the build and more generally the build environment should either be recorded or pre-defined.
38 |
39 |
40 |
41 | More information: [https://reproducible-builds.org/](https://reproducible-builds.org/)
42 |
43 | A nice introduction paper covering the reproducible build project can be found [here](https://arxiv.org/pdf/2104.06020.pdf).
44 |
45 | *(Attribution: Some text in this section is used from https://reproducible-builds.org/ , licence cc-by-sa.)*
46 |
47 |
--------------------------------------------------------------------------------
/prevention/simple-checklists.md:
--------------------------------------------------------------------------------
1 | # Simple Checklists
2 |
3 | The landscape of cyber security solutions is filled with:
4 | * Holy Grails and
5 | * Failures
6 |
7 | We are all humans. So for severe problems like mitigating cyber security risks we fall in love with so-called 'Holy Grail' products. The product capabilities of these products are outlined with vague and difficult marketing buzz. So perfect for managers who lack a solid technical background. Of course you have to trust the vendor since these too-good-to-be-true products are never F/OSS products. This of course to hide the fact that magic solutions do not exist. And security by obscurity is a bad security principle.
8 |
9 | Failed security products are doomed when deployed. These products are characterised by:
10 | * a complex setup
11 | * propriety solution and
12 | * complex mandatory maintenance and update processes.
13 | Too often these products introduce extra risks instead of mitigating risks. Deploying these products can be compared with deliberately installing a large backdoor in your trusted environment.
14 |
15 | Checklists help with improving all security management aspects like:
16 |
17 | * Developing and improving security architectures and designs.
18 | * Communication. E.g. after a security incident.
19 | * Evaluating quality of solutions.
20 |
21 |
22 | ## Collection of Security Checklists
23 |
24 | ```{tableofcontents}
25 | ```
26 |
27 | * Kubernetes Security- Best Practice Guide,
28 |
29 |
--------------------------------------------------------------------------------
/prevention/simplesolutions.md:
--------------------------------------------------------------------------------
1 | # Simple Solutions
2 |
3 |
4 |
5 | ::::{admonition} How to mitigate DDoS attacks - never simple..
6 | :class: tip, dropdown
7 | A Denial of Service (DoS) attack is an attempt to affect the availability of a targeted system. Typically, attackers generate large volumes of packets or requests ultimately overwhelming the target system. In case of a Distributed Denial of Service (DDoS) attack the attacker often uses multiple compromised sources to generate the attack. Like cloud services. Also a DDoS attack can be used as a distraction to get unprivileged access.
8 |
9 | DDoS attacks are most common at the Network (layer 3), Transport (Layer 4), Presentation (Layer 6) and Application (Layer 7) Layers.
10 |
11 | Simple rules for mitigating DDOS attacks:
12 | * Design a good but simple architecture
13 | * Create a static version of your site to be able to inform customers
14 | * Have a response plan
15 | * Have different mitigation scenarios in place
16 | * Make sure to have a direct phone number of a real network security expert that can and will help you! (Without ripping you off)
17 |
18 | :::{tip}
19 | A nie paper for [Responding to Distributed Denial-of-Service Attacks](https://www.cisa.gov/sites/default/files/publications/understanding-and-responding-to-ddos-attacks_508c.pdf)
20 | :::
21 |
22 | [{bdg-primary}`Read this blog for more in depth information`](https://nocomplexity.com/one-more-time/)
23 | ::::
24 |
25 |
26 | ## Prevention
27 |
28 |
29 | :::{admonition} Create a Security Architecture
30 | :class: tip, dropdown
31 |
32 | So follow these simple steps:
33 | * Do a risk analysis. A simple introduction guide is the [CANSO CYBERSECURITY RISK ASSESSMENT GUIDE](https://canso.fra1.digitaloceanspaces.com/uploads/2023/05/CANSO-Safety_Cybersecurity-Risk-Assessment-Guide-2023.pdf). But all [Public security agencies](../references/governments) offer great and simple to use guides, including questionnaires to make this step simpler.
34 | * Develop a security architecture based on your risk profile.
35 | * Always consider real distributed solutions where your security concerns are to spread across several nodes to reduce the impact of a single breach. E.g. spread data and secrets across several independent nodes to be more resilient.
36 | * Develop a thread analyse and improve your architecture.
37 | :::
38 |
39 |
40 |
41 | ```{admonition} Never ever use pirated software
42 | :class: tip, dropdown
43 |
44 | When you download and use pirated software, you will also get a piece of malware as bonus. When using pirated software you can be part of a hacking ecosystem that is used for breaches all over the planet.
45 | ```
46 |
47 |
48 | ## Protection
49 |
50 |
51 | ```{admonition} Implement simple measurements that really help!
52 | :class: tip, dropdown
53 |
54 | Most security protection measurements are very simple and extremely effective.
55 |
56 | So just do:
57 | * Developing awareness within your company and following awareness trainings a continuous process!
58 | * Always implement virus protection on MS Windows based platforms.
59 | * Always implement network segmentation.
60 | * Always implement some simple firewall rules.
61 |
62 |
63 | ```
64 |
65 | ## Detection
66 |
67 | ```{admonition} Implement simple measurements that really help!
68 | :class: tip, dropdown
69 |
70 | Implement some simple but good detection measurements to detect security breaches. Else:everything you do is useless.
71 |
72 | So just do:
73 | * Use audit logging on file systems. Simple is: Use the audit capabilities that are delivered on your operating system. E.g. The FreeBSD audit system for determining read,write,changes on systems is simple but very effective. So use this [FreeBSD Audit Handbook](https://docs.freebsd.org/en/books/handbook/audit/ ).
74 | * Use the default detection system to log and audit all successful and unsuccessful login attempts on your network.
75 |
76 |
77 | ```
78 |
79 | ## Respond
80 |
81 | ```{admonition} Implement some simple procedures to respond to security incidents.
82 | :class: tip, dropdown
83 |
84 | Do not reinvent the wheel. For every simple or complex security incident a good procedure is already invented.
85 |
86 | So just do:
87 | * Use and reuse existing security incident procedures.
88 |
89 | A good collection can be found [here](../protection/security-policies)
90 | ```
91 |
92 | :::{admonition} Mitigating malware and ransomware attacks
93 | :class: tip, dropdown
94 | This guidance helps private and public sector organisations deal with the effects of malware (which includes ransomware). It provides actions to help organisations prevent a malware infection, and also steps to take if you're already infected.
95 | Check this [guide](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks#stepsifinfected).
96 |
97 | :::
98 |
99 | ## Recover
100 |
101 | ```{admonition} Make sure you have a recovery plan.
102 | :class: tip, dropdown
103 |
104 | Do not reinvent the wheel. A good recovery plan is simple:
105 | * Make backups and test recovery procedures.
106 |
107 | Automate making the backups. But make sure that recovery is always manually verified.
108 | Test for disasters. So never ever assume that your backups can not be compromised or stolen.
109 |
110 |
111 | ```
--------------------------------------------------------------------------------
/protection/dataclassification-example1.md:
--------------------------------------------------------------------------------
1 | # Data Classification Policy
2 |
3 | Example from Mitoc Group.
4 |
5 |
6 | ## 1. OVERVIEW
7 |
8 | Information classification is the process of assigning value to information in order to organize it according to its risk to loss or harm from disclosure.
9 | The Mitoc Group Inc (the "Company") information classification and handling standard establishes a baseline derived from federal laws, state laws, regulations, company's policies that govern the privacy and confidentiality of information.
10 |
11 | ## 2. PURPOSE
12 |
13 | The purpose of this policy is to help manage and protect its information assets.
14 |
15 | ## 3. SCOPE
16 |
17 | All employees, contractors, consultants, temporary and other workers at the Company and its subsidiaries must adhere to this policy. All Company's associates share in the responsibility for ensuring that information assets receive an appropriate level of protection by observing this policy. This policy specifies requirements for equipment on the internal Company's network.
18 |
19 |
20 | ## 4. POLICY
21 |
22 | Company Managers or information ‘owners’ shall be responsible for assigning classifications to information assets according to the standard information classification system presented below.
23 | (‘Owners” have approved management responsibility. ‘Owners’ do not have property rights.)
24 |
25 | Where practicable, the information category shall be embedded in the information itself.
26 |
27 | All Company associates shall be guided by the information category in their security-related handling
28 |
29 | All Company information and all information entrusted to Company from third parties falls into one of four classifications in the table below, presented in order of increasing sensitivity.
30 |
31 | ### 4.1 Information Category: Unclassified Public
32 |
33 | Information is not confidential and can be made public without any implications for Company. Loss of availability due to system downtime is an acceptable risk. Integrity is important but not vital.
34 |
35 | Examples:
36 |
37 | * Product brochures widely distributed
38 |
39 | * Information widely available in the public domain, including publicly available Company web site areas
40 |
41 | * Sample downloads of Company software
42 |
43 | * Financial reports required by regulatory authorities
44 |
45 | * Newsletters for external transmission
46 |
47 |
48 | ### 4.2 Information Category: Proprietary
49 |
50 | Information is restricted to management-approved internal access and protected from external access. Unauthorized access could influence Company’s operation effectiveness, cause an important financial loss, provide a significant gain to a competitor, or cause a major drop in consumer confidence. Information integrity is vital.
51 |
52 | Examples:
53 |
54 | * Passwords and information on corporate security procedures
55 |
56 | * Know-how used to process client information
57 |
58 | * Standard Operating Procedures used in all parts of Company’s business
59 |
60 | * All Company-developed software code, whether used internally or provided to clients
61 |
62 |
63 | ### 4.3 Information Category: Client Confidential Data
64 |
65 | Information received from clients in any form for processing in production. The original copy of such information must not be changed in any way without written permission from the client. The highest possible levels of integrity, confidentiality, and restricted availability are vital.
66 |
67 | Examples:
68 |
69 | * Client media
70 |
71 | * Electronic transmissions from clients
72 |
73 | * Client provided customer data
74 |
75 | ### 4.4. Information Category: Company Confidential Data
76 |
77 | Information collected and used by the Company in the conduct of its business to employ people, to log and fulfill client orders, and to manage all aspects of corporate finance. Access to this information is very restricted within the company. The highest possible levels of integrity, confidentiality, and restricted availability are vital.
78 |
79 | Examples:
80 |
81 | * Salaries and other personnel data
82 |
83 | * Accounting data and internal financial reports
84 |
85 | * Confidential customer business data and confidential contracts
86 |
87 | * Non disclosure agreements with clients\vendors
88 |
89 | * Company business plans
90 |
91 |
92 | ## 5. POLICY COMPLIANCE
93 |
94 | ### 5.1 Compliance Measurement
95 |
96 | The Information Security Team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.
97 |
98 | ### 5.2 Exceptions
99 |
100 | Any exception to the policy must be approved by the Information Security Team (security@mitocgroup.com) in advance.
101 |
102 | ### 5.3 Non-Compliance
103 |
104 | An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
105 |
106 | ## Attribution
107 |
108 | This Data Classification Policy is derived Mitoc Group - [source](https://github.com/MitocGroup/www/blob/master/policy/POL-019-data-classification-policy.md)
109 |
110 | This section is licensed: Mozilla Public License 2.0
--------------------------------------------------------------------------------
/protection/iso27001.md:
--------------------------------------------------------------------------------
1 | # ISO/IEC 27001
2 |
3 | ISO/IEC 27001 provides a structured and systematic approach to information security management.
4 |
5 | ISO/IEC 27001 provides guidelines for the best practices to initiate, implement, and improve information security management systems. There are four phases of the ISO/IEC 27001 standards namely plan, do, check, and act (PDCA). ISO 27001 is typically used in Fortune
6 | 5000 organizations.
7 |
8 | The key objectives of ISO/IEC 27001 are to help organizations:
9 |
10 | - Identify and assess their information security risks.
11 | - Implement appropriate security controls and measures to mitigate those risks.
12 | - Establish a framework for managing information security processes.
13 | - Continuously monitor, review, and improve the effectiveness of the ISMS.
14 |
15 |
16 | By achieving certification against ISO/IEC 27001, organizations can demonstrate their commitment to protecting sensitive information, managing risks, and implementing best practices in information security management. It provides assurance to stakeholders, customers, and partners that the organization has implemented a robust and effective information security framework.
17 |
18 | The ISO/IEC 27001 is not an open standard! You have to pay to receive the document and certification means recurring cost since only certified bodies are endorsed to certify organizations.
19 |
20 | There are 114 controls in 14 groups and 35 control categories. The categorization of groups is:
21 | 1. A.5: Information security policies (2 controls)
22 | 2. A.6: Organization of information security (7 controls)
23 | 3. A.7: Human resource security - 6 controls that are applied before, during, or after employment
24 | 4. A.8: Asset management (10 controls)
25 | 5. A.9: Access control (14 controls)
26 | 6. A.10: Cryptography (2 controls)
27 | 7. A.11: Physical and environmental security (15 controls)
28 | 8. A.12: Operations security (14 controls)
29 | 9. A.13: Communications security (7 controls)
30 | 10. A.14: System acquisition, development and maintenance (13 controls)
31 | 11. A.15: Supplier relationships (5 controls)
32 | 12. A.16: Information security incident management (7 controls)
33 | 13. A.17: Information security aspects of business continuity management (4 controls)
34 | 14. A.18: Compliance; with internal requirements, such as policies, and with external requirements, such as laws (8 controls)
35 |
--------------------------------------------------------------------------------
/protection/security-classifications.md:
--------------------------------------------------------------------------------
1 | # Security classifications
2 |
3 | Data classification of security classification is a specialised term used in the fields of cybersecurity to describe the process of:
4 | * identifying
5 | * categorising and
6 | * protecting
7 | content according to its sensitivity or impact level. Data classification is needed before starting a risk analysis and defining an architecture to protect your assets.
8 |
9 | ```{tip}
10 | Simple security classifications are the best.
11 |
12 | ```
13 |
14 |
15 | A security classification specifies how people must protect the information and equipment they handle.
16 |
17 | The classifications for material that should be protected because of security are:
18 |
19 | * RESTRICTED
20 | * CONFIDENTIAL
21 | * SECRET
22 | * TOP SECRET.
23 |
24 |
25 | The classifications for material that should be protected because of personal privacy are:
26 |
27 | * IN CONFIDENCE or
28 | * SENSITIVE.
29 |
30 | ## Unclassified information
31 |
32 | Information that doesn’t need a security classification is called ‘unclassified’ information. Most information fits in this category.
33 |
34 | UNCLASSIFIED isn’t a real security classification, but it is used as a protective marking because it shows that the impact from unauthorised disclosure or misuse has been assessed.
35 |
36 | Every large organisation must have a policy on how you will mark, protect, and handle information that needs increased protection but doesn’t qualify for a security classification.
37 |
38 |
39 | ## Examples
40 |
41 | Defining a good security classification standard should not be made complex. Simple is remembered.
42 |
43 | But in order to give you some more inspiration for defining your own security classification we provide you with a limited list of examples. This speeds up the process when you need to develop your classification system.
44 |
45 |
46 |
47 | ```{tableofcontents}
48 | ```
49 |
50 |
51 |
--------------------------------------------------------------------------------
/protection/security-guidelines.md:
--------------------------------------------------------------------------------
1 | # Security Guidelines ((MoJ)
2 |
3 | The [Cyber and Technical Security Guidance Guide](https://security-guidance.service.justice.gov.uk/#cyber-and-technical-security-guidance) of the UK Ministry of Justice is an good example of how security policies should look like for a large organization.
4 |
5 | The [Cyber and Technical Security Guidance Guide](https://security-guidance.service.justice.gov.uk/#cyber-and-technical-security-guidance) is published under the UK [Open Government Licence v3.0](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/) license.
6 |
7 | The raw information is available in a [public repository on github](https://github.com/ministryofjustice/security-guidance).
8 |
9 | Overview op policies available in this guide:
10 | - [Avoiding too much security](https://security-guidance.service.justice.gov.uk/setecastronomy/)
11 | - [IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER](https://security-guidance.service.justice.gov.uk/identify-protect-detect-respond-recover/)
12 | - [IT Security All Users Policy](https://security-guidance.service.justice.gov.uk/it-security-all-users-policy/)
13 | - [IT Security Policy (Overview)](https://security-guidance.service.justice.gov.uk/it-security-policy-overview/)
14 | - [Line Manager approval](https://security-guidance.service.justice.gov.uk/line-manager-approval/)
15 |
16 |
17 | - [IT Security Technical Users Policy](https://security-guidance.service.justice.gov.uk/it-security-technical-users-policy/)
18 | - [Shared Responsibility Models](https://security-guidance.service.justice.gov.uk/shared-responsibility-models/)
19 |
20 |
21 | - [Mobile Device and Remote Working Policy](https://security-guidance.service.justice.gov.uk/mobile-device-and-remote-working-policy/)
22 | - [Remote Working](https://security-guidance.service.justice.gov.uk/remote-working/)
23 |
24 | - [End or change of employment](https://security-guidance.service.justice.gov.uk/end-or-change-of-employment/)
25 |
26 | - [Acceptable use](https://security-guidance.service.justice.gov.uk/acceptable-use/)
27 | - [Acceptable use policy](https://security-guidance.service.justice.gov.uk/acceptable-use-policy/)
28 | - [Guidance on IT Accounts and Assets for Long Term Leave](https://security-guidance.service.justice.gov.uk/long-term-leave/)
29 | - [Protect Yourself Online](https://security-guidance.service.justice.gov.uk/protect-yourself-online/)
30 | - [Web browsing security](https://security-guidance.service.justice.gov.uk/web-browsing/)
31 |
32 | - [Government Classification Scheme](https://security-guidance.service.justice.gov.uk/government-classification-scheme/)
33 | - [Information Classification and Handling Guide](https://security-guidance.service.justice.gov.uk/information-classification-handling-and-security-guide/)
34 | - [Information Classification and Handling Policy](https://security-guidance.service.justice.gov.uk/information-classification-and-handling-policy/)
35 |
36 |
37 | - [Data Handling and Information Sharing Guide](https://security-guidance.service.justice.gov.uk/data-handling-and-information-sharing-guide/)
38 | - [Secrets management](https://security-guidance.service.justice.gov.uk/secrets-management/)
39 |
40 |
41 | - [Removable media](https://security-guidance.service.justice.gov.uk/removable-media/)
42 | - [Secure disposal of IT equipment](https://security-guidance.service.justice.gov.uk/secure-disposal-of-it-equipment/)
43 | - [Secure disposal of IT - physical and on-premise](https://security-guidance.service.justice.gov.uk/secure-disposal-of-it-physical-and-on-premise/)
44 | - [Working securely with paper documents and files](https://security-guidance.service.justice.gov.uk/working-securely-with-paper-documents-and-files/)
45 |
46 |
47 |
48 | - [Secure disposal of IT - public and private cloud](https://security-guidance.service.justice.gov.uk/secure-disposal-of-it-public-and-private-cloud/)
49 |
50 |
51 | Access Control policies:
52 | - [Access Control Guide](https://security-guidance.service.justice.gov.uk/access-control-guide/)
53 | - [Access Control Policy](https://security-guidance.service.justice.gov.uk/access-control-policy/)
54 | - [Enterprise Access Control Policy](https://security-guidance.service.justice.gov.uk/enterprise-access-control-policy/)
55 | - [Privileged Account Management Guide](https://security-guidance.service.justice.gov.uk/privileged-account-management-guide/)
56 |
57 | Password policies:
58 |
59 | - [Password Managers](https://security-guidance.service.justice.gov.uk/password-managers/)
60 | - [Passwords](https://security-guidance.service.justice.gov.uk/passwords/)
61 | - [Using 1Password](https://security-guidance.service.justice.gov.uk/using-1password/)
62 |
63 |
64 | - [Account management](https://security-guidance.service.justice.gov.uk/account-management/)
65 | - [Authorisation](https://security-guidance.service.justice.gov.uk/authorisation/)
66 | - [Multi-user accounts and Public-Facing Service Accounts Guide](https://security-guidance.service.justice.gov.uk/multi-user-accounts-and-public-facing-service-accounts-guide/)
67 | - [Password Creation and Authentication Guide](https://security-guidance.service.justice.gov.uk/password-creation-and-authentication-guide/)
68 | - [Password Management Guide](https://security-guidance.service.justice.gov.uk/password-management-guide/)
69 | - [Password Storage and Management Guide](https://security-guidance.service.justice.gov.uk/password-storage-and-management-guide/)
70 | - [Policies for Google Apps administrators](https://security-guidance.service.justice.gov.uk/policies-for-google-apps-administrators/)
71 | - [Policies for MacBook Administrators](https://security-guidance.service.justice.gov.uk/policies-for-macbook-administrators/)
72 | - [System User and Application Administrators](https://security-guidance.service.justice.gov.uk/system-users-and-application-administrators/)
73 |
74 |
75 | Policies for handling Crypto:
76 |
77 | - [Automated certificate renewal](https://security-guidance.service.justice.gov.uk/automated-certificate-renewal/)
78 | - [Cryptography](https://security-guidance.service.justice.gov.uk/cryptography/)
79 | - [HMG Cryptography Business Continuity Management Standard](https://security-guidance.service.justice.gov.uk/hmg-cryptography-business-continuity-management-standard/)
80 | - [Public Key Infrastructure Policy](https://security-guidance.service.justice.gov.uk/public-key-infrastructure-policy/)
81 | - [Use of HMG Cryptography Policy](https://security-guidance.service.justice.gov.uk/use-of-hmg-cryptography-policy/)
82 |
83 |
84 | ```{note}
85 | This is just a summary of policies available from the MoJ. See [here](https://security-guidance.service.justice.gov.uk/#cyber-and-technical-security-guidance) for all policies!
86 | ```
--------------------------------------------------------------------------------
/protection/security-management.md:
--------------------------------------------------------------------------------
1 | # Security Management
2 |
3 | Security is just not an IT technology challenge. Security is in the end
4 | a business issue that must be addressed, managed and controlled. So
5 | people, processes, and technology(FOSS Tools).
6 |
7 | Reuse of security control and management frameworks has a number of
8 | advantages:
9 |
10 | - It saves time (and costs).
11 | - You can easily adjust and improve a good framework for your specific
12 | situation.
13 | - Special Security (FOSS)tools are available that are designed that
14 | make managing and controlling easier.
15 |
16 | In order to control security and privacy risks, you should be able to
17 | apply needed technical security and privacy policies for all your
18 | systems, and monitor your systems to ensure they remain compliant with
19 | the approved settings. The best way to manage this complex challenge is
20 | to automate.
21 |
22 | Using automation is a necessary step for security and privacy. Good
23 | automation tooling has the capability to apply security and privacy
24 | settings for all your IT components in a simple, consistent, manner. And
25 | you far better control in a large complex IT environment. This since
26 | there is often a single point of truth where all settings are stored and
27 | managed.
28 |
29 | Good automation tooling has the capability to apply security and privacy
30 | settings for IT components in a simple, consistent, manner. A single
31 | point of truth where all settings are stored and managed offers
32 | advantages for managing and reporting. But be mind: Not in call use case is using centralised tooling a good choice. The principle of separation
33 | of concerns also applies for designing a security solution architecture.
34 |
35 | A number of (FOSS) tools have proven to be usable for automating
36 | security and privacy settings for all kinds of IT components:
37 |
38 | - Ansible: Ansible () allows you
39 | to simply define your systems settings for security. Ansible works
40 | with a Playbook syntax that allows you to define security settings
41 | for any component in a IT landscape. E.g. firewall rules, users and
42 | groups, or applying custom security policies for applications.
43 | - OpenSCAP (Open Source Security Compliance Solution). The SCAP
44 | () is a specification for expressing and
45 | manipulating data in standardised ways. SCAP uses several individual
46 | specifications in concert to automate continuous monitoring,
47 | vulnerability management, and security policy compliance evaluation
48 | reporting. The Security Content Automation Protocol (SCAP) is U.S.
49 | standard maintained by National Institute of Standards and
50 | Technology (NIST). The OpenSCAP project is a collection of open
51 | source tools for implementing and enforcing this standard.
52 | - Open Policy Agent (OPA). The Open Policy Agent (OPA -
53 | ) is an open source,
54 | general-purpose policy engine for Cloud environments that enables
55 | unified, context-aware policy enforcement across the entire stack.
56 | OPA provides a high-level declarative language for authoring
57 | policies and simple APIs to answer policy queries. Using OPA, you
58 | can offload policy decisions from IT services.
59 | - InSpec. InSpec () is a free and
60 | open-source framework for testing and auditing your applications and
61 | infrastructure. InSpec works of course nice together with
62 | Chef() . Chef is an automation language and
63 | tool for deployment to define your infrastructure as code.
64 |
65 | Security and privacy is a complex field. So there is no silver bullet
66 | solution for managing and controlling. There is also no single tool that
67 | fits all use cases.
68 |
--------------------------------------------------------------------------------
/protection/security-policies.md:
--------------------------------------------------------------------------------
1 | # Security policies
2 |
3 | Security policy defines what you want to protect. Good policies often identify:
4 | * procedures
5 | * guidelines and
6 | * safeguards
7 | for configuring and managing security in the organization's environment.
8 |
9 | Security policies define the organization’s philosophy and requirements for securing information systems and related assets. They outline how controls apply to staff, processes, and environments. Often also consequences for failed compliance with the policies are also addressed.
10 |
11 | Security policies provide many benefits to organizations:
12 |
13 | * Security vulnerabilities are identified and properly treated. This ensures security related risks are aligned with the organization's level of risk tolerance.
14 | * A consistent approach to security reduces the likelihood and impact of a security breach.
15 | * Efficiencies are achieved when information is safely shared within the organization, as well as with customers, partners, and vendors.
16 | * Heightened security awareness increases the likelihood of compliance with the security policies.
17 |
18 |
19 | Security policies are a soft form of protection. Having security policies is no tangible protection. But since human factors and awareness is very important in managing security risks, not having security policies is no option.
20 |
21 | Creating your own security policies from scratch should always be avoided. Use and reuse good existing security policies. This:
22 | - Saves time.
23 | - Improves quality.
24 | Reusing means use and improve the policies if needed.
25 |
26 | The real work and challenge is the implementation of procedures within an organisation. So how to implement good security policies in the 'DNA' of an organisation? This is the real challenge and is always dependent on a specific context, culture and organisation structure.
27 |
28 |
29 | Below are some example information security policies that help you develop your own.
30 |
31 |
32 |
33 | ```{tableofcontents}
34 | ```
35 |
36 |
37 |
--------------------------------------------------------------------------------
/protection/vulnerabilities-search.md:
--------------------------------------------------------------------------------
1 | # Find vulnerabilities
2 |
3 | Periodic searching for new vulnerabilities for your used software and hardware is crucial.
4 |
5 | You SHOULD check vulnerabilities:
6 | * Regularly.
7 | * When system is updated with new functionality.
8 | * When significant security events in commonly used libraries are discovered. This to check if you are more vulnerable to.
9 | * When infrastructure changes. E.g. new hardware or networking components.
10 | * When evaluating new software.
11 |
12 | When a new CVE is out you are vulnerable. It does not matter if exploit code is already published on the Internet or not. Assume that Criminals are misusing the CVEs already.
13 |
14 | A simple way to search for vulnerabilities is using `Search` option that the US National Vulnerability Database (NVD) offers. The NVD is a product of the NIST (National Institute of Standards and Technology).
15 |
16 |
17 |
18 |
19 | ````{admonition} Simple Vulnerabilities Search
20 | :class: tip
21 |
22 | Keep it simple: Use the direct search option of the NVD database.
23 |
24 | ```{button-link} https://nvd.nist.gov/vuln/search
25 | :color: danger
26 | Simple Search for vulnerabilities
27 | ```
28 |
29 | ````
30 |
31 |
--------------------------------------------------------------------------------
/references/governments.md:
--------------------------------------------------------------------------------
1 | # Government security organizations
2 |
3 | Governments worldwide provide good advice for dealing with cyber security risks. Some advice and tips for other governments organisations but also for citizens and private companies.
4 |
5 | Reinventing the wheel is a waste of energy and resources. Put effort on reuse already existing information. Below a collection of governmental foundations that provide good and open information on cyber security.
6 |
7 | This collection of Public security agencies are often governmental organization but also Universities or foundation that are funded and setup by governments and work in the general interest for the public.
8 |
9 |
10 |
11 | ```{include} ../generatedfiles/publicsecurityagencies.md
12 | ```
--------------------------------------------------------------------------------
/references/securitystandards.md:
--------------------------------------------------------------------------------
1 | # Security Standards
2 |
3 |
4 | ## Applying Standards and Best Practices
5 |
6 | Using well-established security standards and best practices is one of the simplest ways to reduce security risks. However, challenges with security standards are:
7 |
8 | - **Too Many and Inconsistent Standards**: Some standards are not that good and do not make sense.
9 | - Some standards are **not open** and are proprietary. You must pay to receive such a document and figure out how to implement the standards.
10 | - Some standards **decrease** your security baseline. Not all standards published are good and should be used.
11 | - Most standards are **too high level** and leave room for interpretation at implementation level. This has cause security breaches in the past and will cause security breaches in the future.
12 |
13 |
14 | Some government certifications require compliance with non open security standards. This is a shame! Security standards should be open and freely accessible (e.g., under a CC-BY license) and include clear examples for implementation.
15 |
16 |
17 | :::{tip}
18 | A good security standard is open (cc-by or equivalent) and has working examples for implementation.
19 | :::
20 |
21 |
22 |
23 |
24 | ```{admonition} Beyond Standards: Best Practices or Bad Practices
25 | :class: warning, dropdown
26 |
27 | While security professionals often use best practices, these can be subjective and vary by context. A more reliable approach is to avoid bad practices. The [OWASP Top 10 list](https://owasp.org) is a helpful resource that identifies common security vulnerabilities to avoid.
28 | ```
29 |
30 |
31 |
32 |
33 |
34 | ```{include} ../generatedfiles/standards.md
35 | ```
--------------------------------------------------------------------------------
/references/specialattacks.md:
--------------------------------------------------------------------------------
1 | # Famous Attacks
2 |
3 | Some cyber vulnerabilities have become famous. Sometime by the impact, some by the research paper and the impact on the security field!
4 |
5 | This is an opinionated collection of vulnerabilities and attacks that are so special, that the have an own website and often also one or more research papers.
6 |
7 | :::{warning}
8 | Most so called **old** famous attacks and vulnerabilities are still actively used. Since patching and fixing hardware, firmware and software components is hard, complex and sometimes not possible at all!
9 | :::
10 |
11 |
12 | ```{include} ../generatedfiles/attacks.md
13 | ```
--------------------------------------------------------------------------------
/requirements.txt:
--------------------------------------------------------------------------------
1 | sphinx-book-theme>=0.0.39
--------------------------------------------------------------------------------
/sponsors.md:
--------------------------------------------------------------------------------
1 | # Sponsors
2 |
3 | Our playbooks are, and always will be, free, without tracking or other breaches of your privacy.
4 |
5 | This means that the website(s) where our Playbooks are published require no registration or membership and have no tracking or cookies. We advocate for openness and more awareness on digital privacy.
6 |
7 | All content of our Playbooks can be used for free since it is licensed under a [Creative Commons license](https://creativecommons.org/licenses/by-sa/4.0/). So you are free to use, reuse and improve our Playbooks with attribution.
8 |
9 | To make the development sustainable, we need users and companies, to support the development by providing their time and money.
10 |
11 | Our content is free to read, but you can support us via a voluntary monthly subscription. We rely on ads and contributions to keep the lights on and expand our reach and impact.
12 |
13 |
14 | ## Become a sponsor
15 |
16 | As a free and open source project, you can sponsor our work to increase the audience for your commercial offerings.
17 | We’ve got an audience of thousands of adopters that read and use our online Playbooks.
18 |
19 |
20 | Please contact us by [using this page](https://nocomplexity.com/ads-and-sponsoring/) to discuss various options.
21 |
22 | ## Premium Sponsors
23 |
24 | ::::{grid} 2
25 | :class-container: text-center
26 | :gutter: 3
27 |
28 |
29 | :::{grid-item-card}
30 | :link: https://nocomplexity.com/
31 | :link-type: url
32 | 
33 |
34 | **Complexity is easy, but simplicity is truly valuable**
35 | :::
36 |
37 | :::{grid-item-card}
38 | :link: https://www.bm-support.org/
39 | :link-type: url
40 | 
41 |
42 |
43 | **Openness by default to solve the most challenging problems!**
44 | :::
45 |
46 |
47 | :::{grid-item-card}
48 | :link: https://organisatieontwerp.nl/
49 | :link-type: url
50 | 
51 |
52 | **Diagnosis, Design and Change**
53 | :::
54 |
55 | :::{grid-item-card}
56 | :link: https://nocomplexity.com/ads-and-sponsoring/
57 | 
58 | :::
59 |
60 | ::::
61 |
62 |
--------------------------------------------------------------------------------