├── docs ├── CNAME ├── mythbusting.md ├── images │ ├── Buy.png │ ├── CNCF.png │ ├── aqua.png │ ├── cATO.png │ ├── r8.png │ ├── sdlc.png │ ├── snyk.png │ ├── tips.png │ ├── secrel.png │ ├── boundary.png │ ├── neutral.png │ ├── pipeline.png │ ├── process.png │ ├── AppAssessor.png │ ├── Assumptions.png │ ├── automation.png │ ├── boundaries.png │ ├── flexibility.png │ ├── inheritance.png │ ├── weightScale.png │ ├── architecture.png │ ├── balanced-team.png │ ├── example-task.png │ ├── people-process.png │ ├── poam-response.png │ ├── rmfOrgApproach.png │ ├── systemDiagram.png │ ├── embed-assessors.png │ ├── verify-status-fail.png │ ├── verify-status-pass.png │ ├── opinionated-platform.png │ └── verify-status-partial.png ├── dora.md ├── commit.md ├── communications.md ├── pipeline.md ├── renewal.md ├── runtime.md ├── checks.md ├── extra.css ├── inheritance.md ├── education.md ├── zero-based.md ├── implementation-workflow.md ├── oscal.md ├── grc-agreement.md ├── advanced.md ├── document.md ├── select.md ├── modularity.md ├── overrides │ └── main.html ├── overview.md ├── initial-auth.md ├── ucd.md ├── sla.md ├── integrate.md ├── assessors.md ├── sdlc.md ├── community.md ├── outcomes.md ├── ongoing-auth.md ├── index.md ├── misconceptions.md ├── monitor.md ├── myths.md ├── categorize.md ├── history.md ├── why.md ├── laws.md ├── people.md ├── policy.md ├── prepare.md ├── organize.md ├── implement-assess.md └── diagrams │ ├── architecture.excalidraw │ ├── systemDiagram.excalidraw │ └── boundary.excalidraw ├── .gitignore ├── .github ├── CODEOWNERS ├── workflows │ ├── publish.yml │ └── notify-pr-status.yml └── actions │ └── post-to-slack │ └── action.yml ├── templates ├── slack-notify-pr-approved.tpl ├── slack-notify-pr-opened.tpl └── slack-notify-pr-closed.tpl ├── .devcontainer ├── Dockerfile └── devcontainer.json ├── pull_request_template.md ├── .markdownlint.yml ├── .pre-commit-config.yaml ├── mkdocs.yml └── README.md /docs/CNAME: -------------------------------------------------------------------------------- 1 | playbook.rise8.us 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | site 3 | 4 | .DS_Store 5 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @rise8-us/cato-repo-pr-approvers 2 | -------------------------------------------------------------------------------- /docs/mythbusting.md: -------------------------------------------------------------------------------- 1 | # 6. Mythbusting 2 | 3 | See [here](myths.md). 4 | -------------------------------------------------------------------------------- /docs/images/Buy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/Buy.png -------------------------------------------------------------------------------- /docs/images/CNCF.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/CNCF.png -------------------------------------------------------------------------------- /docs/images/aqua.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/aqua.png -------------------------------------------------------------------------------- /docs/images/cATO.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/cATO.png -------------------------------------------------------------------------------- /docs/images/r8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/r8.png -------------------------------------------------------------------------------- /docs/images/sdlc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/sdlc.png -------------------------------------------------------------------------------- /docs/images/snyk.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/snyk.png -------------------------------------------------------------------------------- /docs/images/tips.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/tips.png -------------------------------------------------------------------------------- /docs/images/secrel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/secrel.png -------------------------------------------------------------------------------- /docs/images/boundary.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/boundary.png -------------------------------------------------------------------------------- /docs/images/neutral.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/neutral.png -------------------------------------------------------------------------------- /docs/images/pipeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/pipeline.png -------------------------------------------------------------------------------- /docs/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/process.png -------------------------------------------------------------------------------- /docs/images/AppAssessor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/AppAssessor.png -------------------------------------------------------------------------------- /docs/images/Assumptions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/Assumptions.png -------------------------------------------------------------------------------- /docs/images/automation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/automation.png -------------------------------------------------------------------------------- /docs/images/boundaries.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/boundaries.png -------------------------------------------------------------------------------- /docs/images/flexibility.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/flexibility.png -------------------------------------------------------------------------------- /docs/images/inheritance.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/inheritance.png -------------------------------------------------------------------------------- /docs/images/weightScale.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/weightScale.png -------------------------------------------------------------------------------- /docs/images/architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/architecture.png -------------------------------------------------------------------------------- /docs/images/balanced-team.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/balanced-team.png -------------------------------------------------------------------------------- /docs/images/example-task.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/example-task.png -------------------------------------------------------------------------------- /docs/images/people-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/people-process.png -------------------------------------------------------------------------------- /docs/images/poam-response.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/poam-response.png -------------------------------------------------------------------------------- /docs/images/rmfOrgApproach.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/rmfOrgApproach.png -------------------------------------------------------------------------------- /docs/images/systemDiagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/systemDiagram.png -------------------------------------------------------------------------------- /docs/images/embed-assessors.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/embed-assessors.png -------------------------------------------------------------------------------- /docs/dora.md: -------------------------------------------------------------------------------- 1 | # 19. Enforce best technical practices (DORA) 2 | 3 | Learn more at [https://dora.dev/](https://dora.dev/) 4 | -------------------------------------------------------------------------------- /docs/images/verify-status-fail.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/verify-status-fail.png -------------------------------------------------------------------------------- /docs/images/verify-status-pass.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/verify-status-pass.png -------------------------------------------------------------------------------- /docs/images/opinionated-platform.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/opinionated-platform.png -------------------------------------------------------------------------------- /docs/images/verify-status-partial.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rise8-us/cato-playbook/HEAD/docs/images/verify-status-partial.png -------------------------------------------------------------------------------- /docs/commit.md: -------------------------------------------------------------------------------- 1 | # 17. Scan on every commit 2 | 3 | See **Secure Release Pipeline** under Implement & Assess [here](implement-assess.md). 4 | -------------------------------------------------------------------------------- /docs/communications.md: -------------------------------------------------------------------------------- 1 | # 3. Develop a communications strategy & plan 2 | 3 | See **Communication Strategy and Plan** under Prepare, [here](prepare.md). 4 | -------------------------------------------------------------------------------- /docs/pipeline.md: -------------------------------------------------------------------------------- 1 | # 12. Build controls into a secure release pipeline 2 | 3 | See **Secure Release Pipeline** under Implement & Assess [here](implement-assess.md). 4 | -------------------------------------------------------------------------------- /docs/renewal.md: -------------------------------------------------------------------------------- 1 | # 23. Quarterly renewal frequency, immediate notification 2 | 3 | See **Authorization Frequency** under Ongoing Authorization, [here](ongoing-auth.md). 4 | -------------------------------------------------------------------------------- /docs/runtime.md: -------------------------------------------------------------------------------- 1 | # 18. Scan applications at runtime 2 | 3 | See **Secure Release Pipeline** and our examples with **Aqua Security** under Implement & Assess [here](implement-assess.md). 4 | -------------------------------------------------------------------------------- /docs/checks.md: -------------------------------------------------------------------------------- 1 | # 20. Periodic spot checks and pen tests 2 | 3 | See how embedding Security Control Assessors, with technical proficiency, can support spot check audit processes under Monitor [here](monitor.md). 4 | -------------------------------------------------------------------------------- /docs/extra.css: -------------------------------------------------------------------------------- 1 | header.md-header, 2 | .md-container nav.md-tabs { 3 | background-color: #3D3D3D; 4 | } 5 | 6 | a.md-tabs__link:not(.md-tabs__link--active) { 7 | color: #FFFFFF; 8 | opacity: 1; 9 | } 10 | -------------------------------------------------------------------------------- /docs/inheritance.md: -------------------------------------------------------------------------------- 1 | # 8. Maximize common control inheritance 2 | 3 | See common control inheritance guidance under Prepare [here](prepare.md) and authorization boundary guidance under Policy [here](policy.md). 4 | -------------------------------------------------------------------------------- /docs/education.md: -------------------------------------------------------------------------------- 1 | # 5. Start an education and training campaign during the prepare step 2 | 3 | See [here](prepare.md) and use this playbook and our video [here](https://www.rise8.us/resources/continuous-delivery-for-nist-rmf-cato). 4 | -------------------------------------------------------------------------------- /docs/zero-based.md: -------------------------------------------------------------------------------- 1 | # 22. Zero-based review to Ongoing Authorization 2 | 3 | See guidance on initial zero-based review [here](initial-auth.md), a monitor period [here](monitor.md), and ongoing authorization [here](ongoing-auth.md). 4 | -------------------------------------------------------------------------------- /docs/implementation-workflow.md: -------------------------------------------------------------------------------- 1 | # 13. Automate control implementation workflows 2 | 3 | See both **Security and Privacy Control Assessment** guidance, and **A Note on Automation**, under Implement & Assess, [here](implement-assess.md). 4 | -------------------------------------------------------------------------------- /docs/oscal.md: -------------------------------------------------------------------------------- 1 | # 11. Incorporate OSCAL as you automate 2 | 3 | We are strong believers that [OSCAL](https://pages.nist.gov/OSCAL/) is the future of RMF automation. We have built our automation using it, and even made our RMF platform OSCAL-native! 4 | -------------------------------------------------------------------------------- /docs/grc-agreement.md: -------------------------------------------------------------------------------- 1 | # 10. Implement the “GRC as code” agreement 2 | 3 | We like to implement an agreement with stakeholders that from this day forward, all GRC has to be delivered “as code” rather than as word documents, powerpoints, and pdfs. 4 | 5 | -------------------------------------------------------------------------------- /templates/slack-notify-pr-approved.tpl: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | cat << EOF > slack_message 4 | :github-check: A pull request has been *approved* by $ACTOR in the <$REPO_URL|$REPO> repository, and is *pending merge*. 5 | 6 | Merge it here: <$PR_URL|$PR_NAME> 7 | EOF 8 | -------------------------------------------------------------------------------- /templates/slack-notify-pr-opened.tpl: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | cat << EOF > slack_message 4 | :exclamation: A new pull request has been *opened* by $PR_AUTHOR in the <$REPO_URL|$REPO> repository, and is *pending approval*. 5 | 6 | Anyone in @cato-repo-pr-approvers can review it here: <$PR_URL|$PR_NAME> 7 | EOF 8 | -------------------------------------------------------------------------------- /docs/advanced.md: -------------------------------------------------------------------------------- 1 | # 21. Advanced: Automated checks and pen tests 2 | 3 | Some organizations are using OSCAL to run automated checks on implementation in operations to monitor controls. Others are writing pen test plays that run as part of the secure release pipeline. These are great improvements as you advance in your journey. 4 | -------------------------------------------------------------------------------- /docs/document.md: -------------------------------------------------------------------------------- 1 | # 15. Actually document things (no, for real) 2 | 3 | We felt like we should really emphasize this one. Too many organizations with cATO and even traditional ATOs have no documentation at all or pencil-whipped documentation. You’re ruining it for all of us. Do the work. Not only is it the law, it actually matters. 4 | -------------------------------------------------------------------------------- /.devcontainer/Dockerfile: -------------------------------------------------------------------------------- 1 | FROM mcr.microsoft.com/devcontainers/python:3.10-bullseye 2 | 3 | # Install the missing Pango library 4 | RUN apt-get update && apt-get install -y libpango-1.0-0 libpangoft2-1.0-0 5 | 6 | RUN pip3 install mkdocs mkdocs-material mkdocs-print-site-plugin mkdocs-with-pdf mkdocs-git-revision-date-localized-plugin 7 | -------------------------------------------------------------------------------- /docs/select.md: -------------------------------------------------------------------------------- 1 | # Control Selection 2 | 3 | During the Select step, make use of control tailoring (Task S-2). This is one of the most overlooked tasks and is critical to efficacy and efficiency of your cRMF 4 | 5 | Think about compensating controls when necessary for things like the use of SaaS awaiting FedRAMP and/or DISA SRG IL P-ATO. 6 | -------------------------------------------------------------------------------- /templates/slack-notify-pr-closed.tpl: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | cat << EOF > slack_message 4 | :github-merged: A pull request has been *merged* into main by $ACTOR in the <$REPO_URL|$REPO> repository :rocket: 5 | 6 | This closes the pull request <$PR_URL|$PR_NAME>, and the merged branch '$PR_BRANCH_NAME' has been automatically removed 7 | EOF 8 | -------------------------------------------------------------------------------- /docs/modularity.md: -------------------------------------------------------------------------------- 1 | # 9. Enable modularity of common control inheritance through automation 2 | 3 | See [here](policy.md) for how to think about authorization boundaries for common controls authorizations. With that in mind, no GRC platforms currently support this, which is why we [built our own](https://www.rise8.us/solutions/tracer) at Rise8. 4 | -------------------------------------------------------------------------------- /docs/overrides/main.html: -------------------------------------------------------------------------------- 1 | {% extends "base.html" %} 2 | 3 | {% block content %} 4 | 5 | {% if page.url_to_pdf %} 6 | 7 | {% include ".icons/material/file-pdf-box.svg" %} 8 | 9 | {% endif %} 10 | 11 | {{ super() }} 12 | {% endblock content %} 13 | -------------------------------------------------------------------------------- /docs/overview.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | We firmly believe that local context is an important factor when making decisions to design and implement an approach to cATO. In fact it’s impossible to succeed with this journey if you don’t know where you’re starting from. Because of this, we chose to outline our recommended approaches and plays in a way that will help change agents navigate risks within their organizations. 4 | -------------------------------------------------------------------------------- /docs/initial-auth.md: -------------------------------------------------------------------------------- 1 | # Initial Authorization 2 | 3 | Submit your authorization package and meet with the Authorizing Official! The good news is that assessors have been involved throughout the entire system life cycle, and the remediation process is already complete. The new level of trust and transparency, in our experience, results in a very smooth initial authorization that is virtually guaranteed. 4 | 5 | Congratulations, the work has only just begun! 6 | -------------------------------------------------------------------------------- /docs/ucd.md: -------------------------------------------------------------------------------- 1 | # 4. Employ user centered design on all the users… especially neglected assessors and authorizers 2 | 3 | As you design your processes, applications, toolchain, and other automation, be sure to practice service design, user research, and user centered design with all users of your cATO which includes the assessor and authorizer personas. The developer and assessor experience should hold equal prioritization in your efforts! You can read more about that in the People section here. 4 | -------------------------------------------------------------------------------- /docs/sla.md: -------------------------------------------------------------------------------- 1 | # 16. Assess in real time and impose assessor SLAs 2 | 3 | When integrating technical assessors into the SDLC, it is important for them to assess implementations and monitor security vulnerability scan results as they happen - not in large batches after the fact. It’s not only fair to product teams, but encouraged to impose an SLA on assessors to ensure they don’t resort back to the “slow is secure” mentality. If they can’t meet their SLAs, it might be time for continuous improvement (process improvement, automation, etc.) or to hire more assessors. 4 | -------------------------------------------------------------------------------- /pull_request_template.md: -------------------------------------------------------------------------------- 1 | # Description 2 | 3 | Please include a summary of the changes being made, and include relevant motivation and context. 4 | List any dependencies that are required for this change. 5 | 6 | ## Type of change 7 | 8 | Please remove any options that are not relevant. 9 | 10 | - [ ] Documentation update 📚 (additions/changes to the playbook docs, spelling mistakes, grammar corrections) 11 | - [ ] Bug fix 🐛 (non-breaking change which fixes an issue) 12 | - [ ] New feature 🎉 (non-breaking change which adds functionality) 13 | - [ ] Breaking change 💔 (fix or feature that would cause existing functionality to not work as expected) 14 | -------------------------------------------------------------------------------- /.markdownlint.yml: -------------------------------------------------------------------------------- 1 | # Overriden rules for markdownlint 2 | # See https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md 3 | 4 | # Default state for all rules 5 | default: true 6 | 7 | # MD007/ul-indent 8 | # Reasoning: https://github.com/markdownlint/markdownlint/blob/main/docs/RULES.md#md007---unordered-list-indentation 9 | MD007: 10 | indent: 4 11 | 12 | # MD013/line-length 13 | MD013: 14 | line_length: 1500 15 | 16 | # MD024/no-duplicate-heading 17 | MD024: 18 | siblings_only: true 19 | 20 | # MD028/no-blanks-blockquote 21 | MD028: false 22 | 23 | # MD029/ol-prefix 24 | MD029: false 25 | 26 | # MD033/no-inline-html 27 | MD033: false 28 | -------------------------------------------------------------------------------- /docs/integrate.md: -------------------------------------------------------------------------------- 1 | # 14. Embed technical assessors into the SDLC at a reasonable ratio 2 | 3 | Don’t just hire independent technical assessors, embed them into the SDLC process. In our experience, assigning 1 assessor per 4 application development teams has been a successful ratio to start with. It supports limited context switching, as well as flexibility for product portfolio situations. As we discussed throughout our recommended approaches, assessors can be integrated into every RMF step, which builds greater trust among teams and agility for your cATO. This also means they should be connected into the software release process, and continuous monitoring operations. 4 | -------------------------------------------------------------------------------- /.devcontainer/devcontainer.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Custom Python 3", 3 | "dockerFile": "Dockerfile", 4 | "features": { 5 | "ghcr.io/devcontainers/features/node:1": { 6 | "version": "lts" 7 | } 8 | }, 9 | 10 | // Use 'forwardPorts' to make a list of ports inside the container available locally. 11 | // "forwardPorts": [], 12 | 13 | // Use 'postCreateCommand' to run commands after the container is created. 14 | "postCreateCommand": "mkdocs serve", 15 | 16 | // Set `remoteUser` to `root` to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root. 17 | "remoteUser": "vscode", 18 | "customizations": { 19 | "vscode": { 20 | "extensions": [ 21 | "ms-vsliveshare.vsliveshare" 22 | ] 23 | } 24 | } 25 | } 26 | -------------------------------------------------------------------------------- /docs/assessors.md: -------------------------------------------------------------------------------- 1 | # 2. Hire independent technical assessors 2 | 3 | This is one of the most important plays in the entire playbook. We recommend fencing off program dollars to be sent to the departments that manage the Security Control Assessor & Privacy Officer functions. You may need to help them award an appropriate contract for this, write job descriptions, and more. But it is important that technical assessors and privacy officers report to whoever is responsible for assessing systems in your organization, so that they maintain their independence. On average over 80% of the time spent getting an ATO is spent waiting in queue, and one of the largest pain points reported is the back and forth between product teams and other functions - especially with (non-technical) assessors. This play solves for both. 4 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: Publish Playbook 2 | 3 | # Controls when the workflow will run 4 | on: 5 | # Triggers the workflow on push or pull request events but only for the main branch 6 | push: 7 | branches: [ main ] 8 | 9 | # Allows you to run this workflow manually from the Actions tab 10 | workflow_dispatch: 11 | 12 | jobs: 13 | build: 14 | runs-on: ubuntu-latest 15 | 16 | # Steps required to build and deploy 17 | steps: 18 | - name: Checkout repository 19 | uses: actions/checkout@v3 20 | - name: Install python 21 | uses: actions/setup-python@v3 22 | - name: Install mkdocs 23 | run: pip install mkdocs-material mkdocs-print-site-plugin mkdocs-with-pdf mkdocs-git-revision-date-localized-plugin 24 | - name: Build and deploy 25 | run: mkdocs gh-deploy --force 26 | -------------------------------------------------------------------------------- /docs/sdlc.md: -------------------------------------------------------------------------------- 1 | # 7. Converge RMF with your SDLC 2 | 3 | We covered this throughout the document, but here is a quick summary: 4 | 5 | **People** 6 | 7 | - Integrated cybersecurity culture (cross-functional teams) 8 | - Technical assessors (from your performer, or from your AO’s contract(s)) 9 | 10 | **Process** 11 | 12 | - Perform all RMF steps 13 | - Create Living documentation by way of your SDLC toolsuite 14 | - Follow NIST Guidance + create an ongoing authorization playbook 15 | - Establish continuous delivery, with metrics for high quality and reduced risk 16 | 17 | **Technology / Automation** 18 | 19 | - Implement high common controls inheritance via opinionated cloud platform 20 | - Modern Security Requirements Management (e.g. Tracer or SD Elements) 21 | - Static Application & Dependency Vulnerability Scanning (e.g. Snyk) 22 | - Image Scanning (e.g. Aqua) 23 | - Container Scanning (e.g. Aqua) 24 | -------------------------------------------------------------------------------- /.pre-commit-config.yaml: -------------------------------------------------------------------------------- 1 | repos: 2 | - repo: https://github.com/punitlad/git-mob 3 | rev: f111493 4 | hooks: 5 | - id: add-coauthors 6 | stages: ["prepare-commit-msg"] 7 | 8 | - repo: https://github.com/pre-commit/pre-commit-hooks 9 | rev: v4.3.0 10 | hooks: 11 | - id: detect-private-key 12 | - id: check-case-conflict 13 | - id: check-merge-conflict 14 | - id: check-symlinks 15 | - id: end-of-file-fixer 16 | - id: mixed-line-ending 17 | args: ['--fix=auto'] 18 | - id: check-json 19 | - id: pretty-format-json 20 | name: format json 21 | args: ['--autofix'] 22 | files: \.json(\.tpl)?$ 23 | types: [text] 24 | - id: check-yaml 25 | args: ["--allow-multiple-documents"] 26 | 27 | - repo: https://github.com/igorshubovych/markdownlint-cli 28 | rev: v0.39.0 29 | hooks: 30 | - id: markdownlint 31 | args: [ "--fix" ] 32 | -------------------------------------------------------------------------------- /docs/community.md: -------------------------------------------------------------------------------- 1 | # Community & Continuous Improvement 2 | 3 | We started with the history of cATO. Unfortunately, the implementations went quite stale since Kessel Run got their memorandum signed. This is a leadership problem, but the community can help fix it. Continuous improvement was not prioritized, as most leaders saw the implementation as a means to continuously deploy software instead of a means to continuously improve security and privacy outcomes. Once they could ship on demand, the mission was labeled “done”. 4 | 5 | We shared our internal playbook with the community to help get it moving forward again. In return, we ask you to use it for good and contribute back. Use it to communicate the benefits beyond just being able to ship software faster, but as a means to improve security and privacy outcomes *while enabling continuous delivery*. Get leaders to invest in continuous improvement of RMF. 6 | 7 | When you do, share your new implementations, plays, automations, and lessons learned! We will be creating a formal open source community around RMF for continuous delivery, and will provide ways for you to contribute as we advance the cause, together. 8 | 9 | ***Together, we rise!*** 10 | -------------------------------------------------------------------------------- /docs/outcomes.md: -------------------------------------------------------------------------------- 1 | # Measuring Outcomes 2 | 3 | Every experiment we introduce must include a way to test and validate a hypothesis for desired outcome(s). Introducing the changes we have outlined in this playbook for people, process and technology are no different. Because your cATO experiment will be touching all three factors at any given time, you’ll need a balanced set of leading and lagging indicators to validate your desired outcomes. We recommend starting with the following combination of outcome types and metrics, adjusting where appropriate for your local context, and ideally confirming a baseline for each: 4 | 5 | **Mission Outcomes** 6 | 7 | - Expect product teams leveraging your cATO, to capture their desired user outcome(s) and business impact(s) metrics for their mission(s). 8 | - User outcomes represent what their intended users (i.e. warfighters, operators and civilians) will do with the software. 9 | - Business impacts represent the results we expect to generate for the organization or agency. 10 | - These demonstrate the actual value proposition(s) of your cATO. 11 | 12 | **cATO Outcomes** 13 | 14 | - Security/Privacy Incidents in Prod 15 | - Time to value (e.g. Time-to-ATO and Time-to-Assessed-Task) 16 | - Security vulnerabilities in Prod 17 | - Security vulnerability Mean Time to Remediation (MTTR) 18 | - POAM count and aging 19 | 20 | **Workforce Happiness Outcomes** 21 | 22 | - Short surveys representing interaction points between product, security, privacy and authorizing officials measuring engagement, psychological safety and satisfaction 23 | 24 | **DevOps Performance Outcomes (Learn more at [https://dora.dev/](https://dora.dev/))** 25 | 26 | - Lead time for changes 27 | - Deployment Frequency 28 | - Change Failure Rate 29 | - Mean Time to Restore (MTTR) after incident, outage or service degradation 30 | -------------------------------------------------------------------------------- /docs/ongoing-auth.md: -------------------------------------------------------------------------------- 1 | # Ongoing Authorization 2 | 3 | Work hard to meet the conditions for ongoing authorization agreed to by your Authorizing Official, and remediate issues along the way. You can do this! 4 | 5 | ## Granting ongoing authorization 6 | 7 | Leverage a memorandum signed by the AO to grant ongoing authorization. Per NIST SP 800-37, Revision 2, in lieu of an authorization termination date, specify an authorization frequency: 8 | 9 | > *“The authorizing official reviews the information with the specific time-driven authorization frequency defined by the organization as part of the continuous monitoring strategy and determines if the risk of continued system operation or the provision of common controls remains acceptable. If the risk remains acceptable, the authorizing official acknowledges the acceptance in accordance with organizational processes. If not, the authorizing official indicates that the risk is no longer acceptable and requires further risk response or a full denial of the authorization.”* 10 | 11 |
12 | 13 | ## Authorization Frequency 14 | 15 | We recommend quarterly authorization frequency as a starting point, with a meeting for risk reporting to stakeholders (AO, SCA, etc.) 16 | 17 | - This again emphasizes more, not less 18 | - Manual reporting to start–slides are ok but move towards automation and a dashboard as you mature 19 | - Identify and accept risk 20 | - Make necessary corrections 21 | - Formally document renewal 22 | 23 | The quarterly reporting should include things like: 24 | 25 | - New applications shipped onto the platform 26 | - % security requirements (e.g. SD Elements) approved by assessor 27 | - Compliance with ongoing authorization and cATO playbook policy’s 28 | - Penetration test results 29 | - Control traceability metrics 30 | - Platform 31 | - Control compliance 32 | - Penetration test results 33 | - Organization 34 | - Risk 35 | - Roles & Responsibilities 36 | - Policy 37 | - Staffing 38 | 39 | Congratulations! You’ve got an ongoing authorization that allows you to continuously deliver applications and services, provided that teams shift left on security and privacy risk. 40 | -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - navigation 4 | - toc 5 | --- 6 | 7 | # Continuous Delivery Risk Management Framework (CD-RMF) Playbook© 8 | 9 | **AKA THE C-ATO[^1] PLAYBOOK** 10 | 11 |
12 | 13 | *Continuous Delivery Risk Management Framework (CD-RMF) Playbook © 2023 by [Rise8, Inc.](https://www.rise8.us/) is licensed under [CC BY-ND 4.0](http://creativecommons.org/licenses/by-nd/4.0/?ref=chooser-v1). This license requires that reusers give credit to the creator. It allows reusers to copy and distribute the material in any medium or format in unadapted form only, even for commercial purposes.* 14 | 15 | README: Please first read our [Manifesto for a Continuous Delivery Risk Management Framework (CD-RMF)©](https://rise8-us.github.io/cato-manifesto/). To advance that cause, we are making our internal playbook available to the entire govtech community. 16 | 17 | This is v1, and we would love your feedback. We had to significantly modify our internal playbook to make it applicable to a wider audience, but we struggled to balance how deep to go on basics as well as how much of NIST documentation to rehash. Feedback there would be especially helpful. 18 | 19 | In return for sharing this, we ask you to use it for good and [contribute back to our playbook repo](https://github.com/rise8-us/cato-playbook). Use it to communicate the benefits beyond just being able to ship software faster, but as a means to improve security and privacy outcomes while enabling continuous delivery. Get leaders to invest in continuous improvement of RMF. 20 | 21 | When you do, share your new implementations, plays, automations, and lessons learned! While the terms of [CC BY-ND 4.0](http://creativecommons.org/licenses/by-nd/4.0/?ref=chooser-v1) allow reusers to copy and distribute the material in unadapted form only, we will be creating a formal open source community around the playbook, and will provide ways for you to contribute to the material, be listed as a contributor, and make the community better. More to follow on that! 22 | 23 | ***Together, we rise!*** 24 | 25 |
26 | 27 | [^1]: We are proposing the term “cATO” no longer be used, see our [Manifesto for a CD-RMF](https://rise8-us.github.io/cato-manifesto/). 28 | 29 | -------------------------------------------------------------------------------- /docs/misconceptions.md: -------------------------------------------------------------------------------- 1 | # Common Misconceptions 2 | 3 | Here are some common misconceptions we’ve heard about cATO: 4 | 5 | - It is a way to avoid having to do RMF - ***you have to do RMF better than most to achieve initial and then ongoing authorization*** 6 | - It is authorizing the people and/or the process - ***FISMA is a law that requires us to authorize systems, which gives consideration but not primacy to people and process*** 7 | - It is a way to push whatever you want, whenever you want - ***you have to meet all security and privacy requirements to deploy to production*** 8 | - It is a pipeline - ***pipelines can enforce some controls and scans, but it does not get you anywhere near ongoing authorization by itself*** 9 | - It requires a platform with sidecar containers - ***the RMF is technology neutral and you could do this with VMs if you do the work*** 10 | - It is a waiver - ***it starts with a zero based authorization and requires incredible RMF implementation to achieve ongoing authorizationIt is something only certain people can do - any authorizing official can grant an ongoing authorization*** 11 | - It is less difficult / documentation / work - ***it requires a zero based review and then ongoing implementation excellence to achieve.*** 12 | 13 |
14 | 15 | There are also common misconceptions about FedRAMP and DISA Provisional Authorizations. Here is what you need to know: 16 | 17 | - FedRAMP does not directly apply to DoD. DISA does, however, use FedRAMP authorization packages to formally grant a sort of Provisional Authorization reciprocity. 18 | - Provisional Authorization is not an ATO. Agency Mission Owner Authorizing Officials must review the Provisional Authorization along with agency specific implementation assessments, then grant an ATO for the system to be used. The goal is to maximize the reuse of existing evidence. 19 | - You do not have to wait for a FedRAMP or DISA Provisional Authorization before your agency can use a system. Agencies are allowed to perform an initial authorization to operate and send their evidence to the JAB or DISA AO for review to sponsor the system for FedRAMP or DISA PA, respectively. This will likely be the fastest route to ATO. Check local policy with your agency. 20 | 21 | 22 | -------------------------------------------------------------------------------- /.github/actions/post-to-slack/action.yml: -------------------------------------------------------------------------------- 1 | name: Send Slack message 2 | description: Sends a Slack message 3 | 4 | inputs: 5 | channel-id: 6 | description: 'Slack channel ID' 7 | required: true 8 | type: string 9 | message: 10 | description: 'The message to send' 11 | required: true 12 | type: string 13 | slack-bot-token: 14 | description: 'The token of the Slack bot' 15 | required: true 16 | thread_ts: 17 | description: 'The threaded timestamp on the message that was posted' 18 | required: false 19 | type: string 20 | outputs: 21 | thread_ts: 22 | description: 'The threaded timestamp on the message that was posted' 23 | value: ${{ steps.send-message.outputs.thread_ts }} 24 | 25 | runs: 26 | using: composite 27 | steps: 28 | - name: Send message 29 | id: send-message 30 | if: inputs.thread_ts == '' 31 | uses: slackapi/slack-github-action@v1 32 | with: 33 | channel-id: ${{ inputs.channel-id }} 34 | payload: | 35 | { 36 | "text": "Slack Message", 37 | "unfurl_links": false, 38 | "unfurl_media": false, 39 | "blocks": [ 40 | { 41 | "type": "section", 42 | "text": { 43 | "type": "mrkdwn", 44 | "text": "${{ inputs.message }}" 45 | } 46 | } 47 | ] 48 | } 49 | env: 50 | SLACK_BOT_TOKEN: ${{ inputs.slack-bot-token }} 51 | 52 | - name: Send message in existing thread 53 | id: update-thread 54 | if: inputs.thread_ts != '' 55 | uses: slackapi/slack-github-action@v1 56 | with: 57 | channel-id: ${{ inputs.channel-id }} 58 | payload: | 59 | { 60 | "text": "Slack Message", 61 | "unfurl_links": false, 62 | "unfurl_media": false, 63 | "thread_ts": "${{ inputs.thread_ts }}", 64 | "blocks": [ 65 | { 66 | "type": "section", 67 | "text": { 68 | "type": "mrkdwn", 69 | "text": "${{ inputs.message }}" 70 | } 71 | } 72 | ] 73 | } 74 | env: 75 | SLACK_BOT_TOKEN: ${{ inputs.slack-bot-token }} 76 | -------------------------------------------------------------------------------- /docs/monitor.md: -------------------------------------------------------------------------------- 1 | # Monitor 2 | 3 | We recommend laying out an initial observation period with your AO of 6-12 months. During this time, meet regularly with assessors and your AO to demonstrate the results of your greatly improved implementation, assessment, and continuous monitoring processes. Set conditions for gaining an ongoing authorization and report on these metrics during these performance reviews. This is also your opportunity to outline recommendations for continuous improvement initiatives, and obtain feedback from assessors and AOs to achieve the virtuous cycle we laid out in our ‘why’. 4 | 5 | Aside from monitoring via automation, embedding Assessors and Privacy Officers should be staffed organically to: 6 | 7 | - Review security scan results when developers mark findings as false positives, or decide to suppress for future sprints 8 | - Provide feedback to developers if disagreements arise 9 | - Assist developers with mitigations 10 | - Review security tasks as developers complete them 11 | - Provide feedback to developers if implementation details aren’t sufficient 12 | - Monitor system diagram and overall SSP for changes 13 | - Perform spot checks on the cATO process 14 | - Perform Penetration Testing exercises 15 | 16 | Perform independent spot checks and penetration tests during this time. There will be findings. Explicitly reject unrealistic standards like ‘zero findings. Instead, focus on time to discovery and time to remediation as key metrics–your continuous delivery capability applied to remediation will impress even the most risk averse of stakeholders. 17 | 18 | In summary, just like building software, managing risk is a continuous process... it is never done. A successful risk management program requires us to treat risk as a first class citizen. Continuously monitoring our security and privacy controls is how we will retain confidence in our security posture and program. Here is a good starter strategy that will ensure we remain honest with ourselves: 19 | 20 | - Product teams are responsible for continuously managing security and compliance risks that are surfaced by security vulnerability scanning solutions (e.g. SAST, SCA, DAST, Image/Container, etc.). 21 | - Product teams and Security Control Assessors are expected to meet at least weekly to discuss upcoming release plans for the product, changes in security vulnerability posture, and any product context that should be updated within security vulnerability scanning tool project surveys. 22 | - Security Control Assessors and Privacy Officers are responsible for ensuring product teams are complying with policy expectations. 23 | -------------------------------------------------------------------------------- /docs/myths.md: -------------------------------------------------------------------------------- 1 | # Myths 2 | 3 | ## Myth 1: NIST RMF wasn’t designed with Agile and DevOps in mind. 4 | 5 | According to NIST SP 800-37, Revision 2 the RMF is technology agnostic and can be adapted for any development approach. 6 | 7 | ![This is an image](images/neutral.png) 8 | 9 |
10 | 11 | ## Myth 2: The RMF doesn’t support the use of automation. 12 | 13 | NIST SP 800-37, Revision 2 encourages organizations to “maximize the use of automation, wherever possible, to increase the speed, effectiveness, and efficiency of executing steps in the RMF.” It includes automating the preparation for authorization packages as well as facilitating real-time decision-making. 14 | 15 | ![This is an image](images/automation.png) 16 | 17 |
18 | 19 | ## Myth 3: There is no flexibility in RMF implementation. 20 | 21 | NIST SP 800-37, Revision 2 states that organizations have significant flexibility in how they carry out the steps of RMF as long as they are meeting all applicable security and privacy requirements. That flexibility also applies to control selection, so anyone who complains about control applicability needs to read about control tailoring. 22 | 23 | ![This is an image](images/flexibility.png) 24 | 25 |
26 | 27 | ## Myth 4: The authorization boundary has to be drawn a certain way (e.g. around everything). 28 | 29 | NIST SP 800-37, Revision 2 states the organization gets to establish the authorization boundary for systems and common controls. It later states that for software applications, “The software elements are included in authorization boundaries, either as part of the information system on which the software is hosted or as a part of an application-only system or subsystem that inherits controls from the hosting system. Software applications may depend on the resources provided by the hosting system and as such, can leverage the controls provided by the hosting system to help provide a foundational level of protection for the hosted applications.” 30 | 31 | ![This is an image](images/boundaries.png) 32 | 33 |
34 | 35 | ## Myth 5: The RMF doesn’t align with modern SDLCs 36 | 37 | NIST SP 800-37, Revision 2 states that the best RMF implementation (remember, implementation is flexible and determined by the organization) is indistinguishable from the organization’s SDLC. 38 | 39 | ![This is an image](images/sdlc.png) 40 | 41 |
42 | 43 | ## Myth 6: There is no way to streamline RMF! 44 | 45 | NIST SP 800-37, Revision 2 gives you a whole list of tips for streamlining implementation: 46 | 47 | ![This is an image](images/tips.png) 48 | 49 |
50 | 51 | ***Now stop making excuses, and start making 🚀 happen!*** 52 | -------------------------------------------------------------------------------- /mkdocs.yml: -------------------------------------------------------------------------------- 1 | site_name: cATO Playbook 2 | site_url: https://rise8-us.github.io/cato-playbook 3 | repo_url: https://github.com/rise8-us/cato-playbook 4 | edit_uri: edit/main/docs/ 5 | repo_name: cato-playbook 6 | theme: 7 | name: material 8 | custom_dir: docs/overrides 9 | logo: images/r8.png 10 | favicon: images/r8.png 11 | # logo: images/logo.png 12 | icon: 13 | repo: fontawesome/brands/github 14 | features: 15 | - navigation.tabs 16 | - navigation.footer 17 | - navigation.expand 18 | extra: 19 | social: 20 | - icon: fontawesome/brands/github 21 | link: https://github.com/rise8-us/cato-playbook 22 | analytics: 23 | provider: google 24 | property: G-RZTRD0E336 25 | extra_css: [extra.css] 26 | markdown_extensions: 27 | - abbr 28 | - footnotes 29 | - def_list 30 | - pymdownx.tasklist: 31 | custom_checkbox: true 32 | - attr_list 33 | - pymdownx.emoji: 34 | emoji_index: !!python/name:material.extensions.emoji.twemoji 35 | emoji_generator: !!python/name:material.extensions.emoji.to_svg 36 | - pymdownx.critic 37 | - pymdownx.caret 38 | - pymdownx.keys 39 | - pymdownx.mark 40 | - pymdownx.tilde 41 | - pymdownx.details 42 | - admonition 43 | plugins: 44 | - search 45 | - git-revision-date-localized: 46 | type: iso_datetime 47 | - with-pdf: 48 | output_path: assets/cATO_Playbook.pdf 49 | author: Rise8 50 | copyright: © 2023 51 | cover_subtitle: "" 52 | toc_title: Table of Contents 53 | toc_level: 1 54 | ordered_chapter_level: 0 55 | two_columns_level: 0 56 | - print-site: 57 | path_to_pdf: "assets/cATO_Playbook.pdf" 58 | nav: 59 | - README: 'index.md' 60 | - 'Introduction': 61 | - 'The Why': 'why.md' 62 | - 'History': 'history.md' 63 | - 'Laws and Regulations': 'laws.md' 64 | - 'Myths': 'myths.md' 65 | - 'misconceptions.md' 66 | - 'Recommended Approach': 67 | - 'Overview': 'overview.md' 68 | - 'people.md' 69 | - 'policy.md' 70 | - 'Integrated Process & Technology': 71 | - 'prepare.md' 72 | - 'categorize.md' 73 | - 'select.md' 74 | - 'implement-assess.md' 75 | - 'initial-auth.md' 76 | - 'monitor.md' 77 | - 'ongoing-auth.md' 78 | - 'outcomes.md' 79 | - 'community.md' 80 | - 'Plays': 81 | - 'organize.md' 82 | - 'assessors.md' 83 | - 'communications.md' 84 | - 'ucd.md' 85 | - 'education.md' 86 | - 'mythbusting.md' 87 | - 'sdlc.md' 88 | - 'inheritance.md' 89 | - 'modularity.md' 90 | - 'grc-agreement.md' 91 | - 'oscal.md' 92 | - 'pipeline.md' 93 | - 'implementation-workflow.md' 94 | - 'integrate.md' 95 | - 'document.md' 96 | - 'sla.md' 97 | - 'commit.md' 98 | - 'runtime.md' 99 | - 'dora.md' 100 | - 'checks.md' 101 | - 'advanced.md' 102 | - 'zero-based.md' 103 | - 'renewal.md' 104 | -------------------------------------------------------------------------------- /.github/workflows/notify-pr-status.yml: -------------------------------------------------------------------------------- 1 | name: Notify PR Status 2 | 3 | on: 4 | pull_request: 5 | types: [opened, closed] 6 | branches: 7 | - main 8 | pull_request_review: 9 | types: [submitted] 10 | 11 | env: 12 | ACTOR: ${{ github.actor }} 13 | PR_NAME: ${{ github.event.pull_request.title }} 14 | PR_BRANCH_NAME: ${{ github.event.pull_request.head.ref }} 15 | PR_URL: ${{ github.event.pull_request.html_url }} 16 | PR_AUTHOR: ${{ github.event.pull_request.user.login }} 17 | PR_AUTHOR_URL: ${{ github.event.pull_request.user.html_url }} 18 | PR_APPROVER: ${{ github.event.review.user.login }} 19 | REPO: ${{ github.repository }} 20 | REPO_URL: ${{ github.event.repository.html_url }} 21 | 22 | jobs: 23 | notify-opened: 24 | runs-on: ubuntu-latest 25 | if: github.event_name == 'pull_request' && github.event.action == 'opened' && github.event.pull_request.draft == false 26 | steps: 27 | - uses: actions/checkout@v4 28 | 29 | - name: Generate message 30 | id: generate-message 31 | run: | 32 | bash templates/slack-notify-pr-opened.tpl 33 | cat slack_message | awk '{printf "%s\\n", $0}' > slack_message.stripped 34 | BODY=$(cat slack_message.stripped) 35 | echo "payload=$BODY" >> $GITHUB_OUTPUT 36 | 37 | - name: Post to Slack 38 | uses: rise8-us/cato-playbook/.github/actions/post-to-slack@main 39 | with: 40 | channel-id: ${{ vars.SLACK_CHANNEL_ID }} 41 | message: ${{ steps.generate-message.outputs.payload }} 42 | slack-bot-token: ${{ secrets.SLACK_BOT_TOKEN }} 43 | 44 | notify-approved: 45 | runs-on: ubuntu-latest 46 | if: github.event_name == 'pull_request_review' && github.event.review.state == 'approved' 47 | steps: 48 | - uses: actions/checkout@v4 49 | 50 | - name: Generate message 51 | id: generate-message 52 | run: | 53 | bash templates/slack-notify-pr-approved.tpl 54 | cat slack_message | awk '{printf "%s\\n", $0}' > slack_message.stripped 55 | BODY=$(cat slack_message.stripped) 56 | echo "payload=$BODY" >> $GITHUB_OUTPUT 57 | 58 | - name: Post to Slack 59 | uses: rise8-us/cato-playbook/.github/actions/post-to-slack@main 60 | with: 61 | channel-id: ${{ vars.SLACK_CHANNEL_ID }} 62 | message: ${{ steps.generate-message.outputs.payload }} 63 | slack-bot-token: ${{ secrets.SLACK_BOT_TOKEN }} 64 | 65 | notify-closed: 66 | runs-on: ubuntu-latest 67 | if: github.event_name == 'pull_request' && github.event.action == 'closed' && github.event.pull_request.merged 68 | steps: 69 | - uses: actions/checkout@v4 70 | 71 | - name: Generate message 72 | id: generate-message 73 | run: | 74 | bash templates/slack-notify-pr-closed.tpl 75 | cat slack_message | awk '{printf "%s\\n", $0}' > slack_message.stripped 76 | BODY=$(cat slack_message.stripped) 77 | echo "payload=$BODY" >> $GITHUB_OUTPUT 78 | 79 | - name: Post to Slack 80 | uses: rise8-us/cato-playbook/.github/actions/post-to-slack@main 81 | with: 82 | channel-id: ${{ vars.SLACK_CHANNEL_ID }} 83 | message: ${{ steps.generate-message.outputs.payload }} 84 | slack-bot-token: ${{ secrets.SLACK_BOT_TOKEN }} 85 | -------------------------------------------------------------------------------- /docs/categorize.md: -------------------------------------------------------------------------------- 1 | # Categorize 2 | 3 | The Categorize step remains largely the same, but is the first opportunity to show that RMF tasks (C-1, C-2, & C-3) can be done more quickly with a cross-functional team (people aspect). As mentioned in previous sections, it’s essential to have technical assessors in place, along with highly competent infrastructure, platform, and pilot application teams. 4 | 5 | Security categorization is the most important step in the Risk Management Framework (RMF) since it ties the information system’s security activities to the organization’s mission/business priorities. [FIPS 199](https://csrc.nist.gov/pubs/fips/199/final), *Standards for Security Categorization of Federal Information and Information Systems*, defines requirements for categorizing information and information systems. [FIPS 200](https://csrc.nist.gov/pubs/fips/200/final), *Minimum Security Requirements for Federal Information and Information Systems*, specifies a risk-based process for selecting the security controls necessary to satisfy the minimum requirements. [NIST SP 800-60](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final), *Guide for Mapping Types of Information and Information Systems to Security Categories*, is a four-step process for categorizing the information and information system level of risk: 6 | 7 | 1. Identify information types 8 | 2. Select provisional impact levels for the information types 9 | 3. Review provisional impact levels and adjust/finalize information impact levels for the information types 10 | 4. Assign a system security category, and overall impact level 11 | 12 | Types of Information and Information Systems to Security Categories, provides guidance in assessing the criticality and sensitivity of the information and associated information system to determine the system’s security category (i.e., potential worst case impact from loss of confidentiality, integrity, and availability) and overall impact level. 13 | 14 | The system’s impact level is used to select a baseline set of security controls for the information system from [NIST SP 800-53, Revision 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), *Recommended Security Controls for Federal Information Systems*, that is then tailored to better reflect the information system’s unique circumstances. In addition, the system’s impact level determines the rigor applied to the remaining steps in the Risk Management Framework, including the assessment of security controls. 15 | 16 |
17 | 18 | ## System Security Plan (SSP) 19 | 20 | Start SSP development utilizing guidance from [NIST Special Publication 800-18, Revision 1](https://csrc.nist.gov/pubs/sp/800/18/r1/final). See note in Implementation & Assessment about SSP digitization and automation. Typical SSP templates will include the following: 21 | 22 | 1. Information System Name 23 | 2. Risk Categorization (following FIPS 199 & 200 guidance) 24 | 3. Information System Owner 25 | 4. Authorizing Official 26 | 5. Additional Key Personnel for the Information System 27 | 6. General description and purpose of the Information System 28 | 7. General description of the technical stack details 29 | 8. List of external system integration details (i.e. system name, organization ownership, agreement (ISA, MOU or MOA), risk categorization, authorization status, and authorizing official) 30 | 9. Unique laws, regulations or policies 31 | 10. In-scope security and privacy controls 32 | 11. Date of completion/update 33 | 12. Date of approval with evidence 34 | -------------------------------------------------------------------------------- /docs/history.md: -------------------------------------------------------------------------------- 1 | # History: The Evolution of Continuous Authority to Operate 2 | 3 | ***It is important to understand that this has already been done.*** 4 | 5 | On April 18, 2018, in an Air Force memorandum titled “Implementation of Ongoing Authorization for Agile Software Development”, Authorizing Official Lauren Knausenberger, then Air Force Director of Cyberspace Innovation, approved the first so-called “Continuous Authority to Operate” (coined by Bryon Kroger) implemented by Kessel Run. 6 | 7 | Kessel Run had stood on the shoulders of giants, such as 18F’s accelerated ATOs on cloud.gov and NGA’s ‘ATO-in-a-day’ for their GEOINT Services Platform, but they were the first to implement the Risk Management Framework in a way that fully aligned with the Agile and DevOps SDLC without tradeoffs between speed and compliance/risk, and included the full-stack implementation and assessment of the associated controls. Kessel Run, at the time, could produce a full, up-to-date authorization package for every release in real time. 8 | 9 | The first applications to achieve this were Raven and Marauder, both deployed to an on-premise cloud stack running Pivotal Cloud Foundry (like our friends at NGA) on the SIPR network. The Kessel Run team, led by Bryon Kroger and Andrew Altizer (ISSM), implemented this combination of people, process, and technology for an ongoing authorization that was tailor made for DevOps with deployment frequencies measured in hours. Bryon coined the term “cATO” to describe that **specific implementation of an ongoing authorization within RMF to enable true continuous delivery**. Some of the technology and process underpinnings were adapted from NGA and 18F, while some were changed or added. 10 | 11 | Unfortunately, the term cATO would take on a life of its own and headed in a different direction, away from an RMF-based controls implementation, assessment, and authorization to something based on political favor and a particular reference design that required the use of certain technologies, at odds with the RMF’s technology neutral stance. Senior leaders also began to espouse “certifying the people and the process”, instead of systems themselves and, unfortunately, placed their trust in the wrong people who weren’t even practicing the RMF-deficient method they were preaching. 12 | 13 | During that time, Bryon Kroger left the Air Force and founded Rise8, where we have continued advancing RMF for continuous delivery, improving both process and automation. It has been difficult, however, to get the community to adopt this rigorous approach given that many organizations were able to get all the benefits of being able to continuously deploy their software without doing the work. It’s a close cousin of Shadow IT: Shadow ATO. 14 | 15 | Thankfully things started to change when the DOD CIO published a cATO memorandum that most insiders would describe as an attempt to clean up the mess of existing cATOs. 16 | 17 | While this was great to see and a cleanup is much needed, we believe it misses the mark on how to apply NIST RMF to continuous delivery. The office has not consulted the actual practitioners who have implemented a truly RMF-based authorization for continuous delivery and, as of this writing, are writing additional guidance without doing so. 18 | 19 | That is why Rise8 authored the [manifesto](https://rise8-us.github.io/cato-manifesto/) and are making our playbook for CD-RMF public. Additionally we are forming a group of like-minded experts to lead an open source community that continues advancing CD-RMF. 20 | -------------------------------------------------------------------------------- /docs/why.md: -------------------------------------------------------------------------------- 1 | # Why? The Need for cATO 2 | 3 | The DevOps Research and Assessment (DORA) organization has nearly a decade of research showing that there is no tradeoff between speed and stability nor speed and security in high performing software organizations. In fact, both stability and security are positively correlated with speed. In other words, organizations with high software delivery performance experience a virtuous cycle between speed and security. 4 | 5 |
6 | 7 | ## The True Cost of Delay 8 | 9 | At the same time, both our citizens and our soldiers are paying the price of an immense cost of delay imposed by the way we currently approach the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) and obtaining Authorization to Operate (ATO). Unlike the commercial sector, in government the cost of delay is often measured in lives. Our security and privacy risk management processes are creating downstream risk to operations. The delay of capability to the battlefield, the operating table, and even in the distribution of government benefits is literally killing people. 10 | 11 |
12 | 13 | ## Continuous Delivery as a Risk Mitigation 14 | 15 | But aren’t we doing Agile, now? It has become popular to adopt Agile Software Development rhetoric in the Federal Government, however it is rarely executed. This is evidenced by the fact that the first principle from the Manifesto for Agile Software Development states, “Our highest priority is to satisfy customers through early and continuous delivery of valuable software.” That is to say that if delivery is not early and continuous, then ‘agile’ clearly has not manifested. When we say continuous delivery, we mean it. 16 | 17 | In their book Continuous Delivery, Dave Farley and Jez Humble define continuous delivery as, “The ability to get changes, features, configuration changes, bug fixes, experiments into production safely and quickly in a sustainable way.” In this way, continuous delivery becomes an exercise in risk reduction not only to security and privacy risk, but especially to operational risk. To realize this benefit, production cannot be an arbitrary designation; production is the setting where software is put into operation for its intended uses by end users. Getting to such a production environment in Federal requires an ATO within the RMF. Continuously delivering to production would require a continuous ATO, which would require continuous application of the RMF. Thankfully, this can be accomplished within existing laws and NIST guidelines. 18 | 19 |
20 | 21 | ## The Benefits of cATO 22 | 23 | **Improve security posture and lower risk** 24 | 25 | - Reduce the number of security defects through threat analysis and secure coding practices 26 | - Continuously detect and remediate application vulnerabilities quickly via the Secure Release Pipeline 27 | - Cybersecurity and vulnerability education is available to application development teams simply by utilizing the secure release pipeline 28 | 29 | **Increase transparency and trust** 30 | 31 | - Default access to all body of evidence artifacts throughout the software development life cycle (i.e. source code, documents, diagrams) for security control assessors and cybersecurity personnel to support continuous monitoring (e.g. assessment and evaluation) 32 | - Incrementally automating risk assessment via secure release pipelines 33 | 34 | **Reduce costs & increase delivery of value to organizations and end-users** 35 | 36 | - Reducing the number of security defects and risks 37 | - Leveraging a cloud environment 38 | - Shipping software can be accomplished in hours or days, instead of weeks, months or even years 39 | 40 |
41 | 42 | ## What's Really at Stake 43 | 44 | In the digital era, both the warfighting domain and policy domain are digital. Both demand the early and continuous delivery of valuable software: 45 | 46 | - We cannot afford to be disrupted on the battlefield–our democracy will be toppled from the outside. 47 | - We cannot afford to fail to deliver on promises to our citizens–our democracy will be toppled from within. 48 | 49 |
50 | 51 | ***The early and continuous delivery of software requires continuous ATO. Why do we need that? Because our democracy hangs in the balance.*** 52 | 53 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # cato-playbook 2 | This playbook is a collection of best practices, tools, and resources for implementing a Continuous Delivery Risk Management Framework (CD-RMF)© in the federal government. It is intended to be a living document that will be updated as new tools and best practices emerge. 3 | 4 | ## Contributing 5 | It is required for external contributors to submit a pull request for review before merging into the main branch. 6 | 7 | ## Development 8 | To accommodate non-technical users, the playbook is written in markdown and compiled to HTML using [MkDocs](https://www.mkdocs.org/). We have included a devcontainer for VSCode that will install all the necessary dependencies and allow you to preview the playbook locally. 9 | 10 | ### Editing Files on GitHub 11 | GitHub provides various methods for editing files in your repositories, each with its own set of features and limitations. Depending on your needs and preferences, you can choose from the following options: 12 | 13 | ### 1. GitHub Web UI 14 | 15 | The GitHub web user interface (UI) is a straightforward way to edit files in your repository. To use it, follow these steps: 16 | 17 | 1. **Navigate to the File:** Go to your repository on GitHub and navigate to the file you want to edit. 18 | 19 | 2. **Edit the File:** Click the "Edit this file" button (the pencil icon) on the file's page to open the in-browser editor. 20 | 21 | 3. **Make Changes:** You can make changes directly in the editor, similar to a basic code editor. It offers syntax highlighting for various file types. 22 | 23 | 4. **Commit Changes:** After making your changes, scroll down to the "Commit changes" section. Provide a commit message explaining your changes, and choose to commit them directly to the default branch or create a new branch for your changes. 24 | 25 | **Limitations:** 26 | 27 | - The GitHub web UI editor is suitable for minor changes or quick edits. 28 | - You will not be able to preview your changes in a browser or run any scripts or commands. 29 | - Editing multiple files simultaneously is not be supported; you may need to edit and commit each file separately to a new branch before submitting a pull request. 30 | 31 | ### 2. GitHub.dev Editor 32 | Prerequisites: 33 | - You will need a basic understanding of Git and GitHub and the VSCode editor, as well as the [VSCode Source Control extension](https://code.visualstudio.com/docs/sourcecontrol/overview). 34 | 35 | GitHub.dev is an integrated development environment (IDE) that GitHub offers directly in your web browser. It provides a more robust editing experience compared to the standard web UI: 36 | 37 | 1. **Access GitHub.dev:** You can access by going to https://github.dev/rise8-us/cato-playbook. You can also find the file you wish to edit in the GitHub web UI and click the "Open with... gitHub.dev" option from the "Edit this file" button (the pencil icon) dropdown. 38 | 39 | 2. **Edit Files:** Navigate to the file you want to edit and click on it. The GitHub.dev editor will open with syntax highlighting, code suggestions, and more. 40 | 41 | 3. **Commit Changes:** Similar to the web UI, you can commit your changes directly or create a new branch for your edits. 42 | 43 | **Limitations:** 44 | 45 | - You will not be able to preview your changes in a browser or run any scripts or commands. 46 | 47 | ### 3. GitHub Codespaces (Recommended) 48 | Prerequisites: 49 | - You will need a basic understanding of Git and GitHub and the VSCode editor, as well as the [VSCode Source Control extension](https://code.visualstudio.com/docs/sourcecontrol/overview) or alternatively how to use Git in the terminal. 50 | 51 | GitHub Codespaces is a powerful cloud-based development environment that allows you to work on your projects in a full-fledged development environment directly in your web browser. It's ideal for more extensive coding and collaboration: 52 | 53 | 1. **Access Codespaces:** You can access it by clicking the "Code" button on your repository's main page and selecting "Open with Codespaces." 54 | 55 | 2. **Development Environment:** Codespaces provides a complete development environment with support for multiple programming languages, extensions, and tools. When you open your repository in Codespaces, it will take a moment to load and then a postCreateCommand will run that starts a Mkdocs server. You can access this server by selecting the `PORTS` tab in the terminal and then selecting the `Open in Browser` button (the globe icon), under `Forwarded Addresses` for the port `8000`. If for any reason this does not start, you can run `mkdocs serve` in the terminal to start the server manually. 56 | 57 | 3. **Edit Files:** Open, edit, and save your files just like you would in a local development environment. 58 | 59 | 4. **Commit and Push:** You can commit your changes and push them to your repository right from Codespaces using the VSCode Source Control extension or the terminal. 60 | -------------------------------------------------------------------------------- /docs/laws.md: -------------------------------------------------------------------------------- 1 | # FISMA 2 | 3 | *Copied from the NIST RMF website [FISMA background](https://csrc.nist.gov/Projects/risk-management/fisma-background)* 4 | 5 | ## What is FISMA? 6 | 7 | The Federal Information Security Management Act (FISMA) [FISMA 2002], part of the [E-Government Act (Public Law 107-347)](https://www.govinfo.gov/content/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf) was passed in December 2002. FISMA 2002 requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other sources. 8 | 9 | [The Federal Information Security Modernization Act of 2014](https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf) amends FISMA 2002, by providing several modifications that modernize federal security practices to address evolving security concerns. These changes result in less overall reporting, strengthens the use of continuous monitoring in systems, increases focus on the agencies for compliance and reporting that is more focused on the issues caused by security incidents. FISMA 2014 also required the Office of Management and Budget (OMB) to amend/revise OMB Circular A-130 to eliminate inefficient and wasteful reporting and reflect changes in law and advances in technology. 10 | 11 | FISMA, along with the Paperwork Reduction Act of 1995 and the Information Technology Management Reform Act of 1996 (Clinger-Cohen Act), explicitly emphasizes a risk-based policy for cost-effective security. In support of and reinforcing FISMA, the Office of Management and Budget (OMB) through [Circular A-130](https://www.whitehouse.gov/omb/information-for-agencies/circulars/), “Managing Federal Information as a Strategic Resource,” requires executive agencies within the federal government to: 12 | 13 | - Plan for security 14 | - Ensure that appropriate officials are assigned security responsibility 15 | - Periodically review the security controls in their systems 16 | - Authorize system processing prior to operations and, periodically, thereafter 17 | 18 |
19 | 20 | ## What does FISMA require? 21 | 22 | Federal agencies need to provide information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of: 23 | 24 | - information collected/maintained by or on behalf of an agency 25 | - Information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency. 26 | 27 | Also, federal agencies need to “com[ply] with the information security standards” and guidelines, and mandatory required standards developed by NIST. 28 | 29 |
30 | 31 | ## To whom does FISMA apply? 32 | 33 | Federal agencies, contractors, or other sources that provide information security for the information and information systems that support the operations and assets of the agency. 34 | 35 |
36 | 37 | ## What is a Federal Information System? 38 | 39 | As defined in FISMA 2002, "[t]he term ‘Federal information system’ means an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency." 40 | 41 |
42 | 43 | # NIST Risk Management Framework 44 | 45 | *Copied from the NIST RMF website [FISMA background](https://csrc.nist.gov/Projects/risk-management/fisma-background)* 46 | 47 | The NIST Risk Management Framework (RMF), outlined in NIST Special Publication 800-37, provides a flexible, holistic, and repeatable 7-step process to manage security and privacy risk 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). 48 | 49 | **The risk-based approach of the NIST RMF helps an organization:** 50 | 51 | 1. **Prepare** for risk management through essential activities critical to design and implementation of a risk management program. 52 | 2. **Categorize** systems and information based on an impact analysis. 53 | 3. **Select** a set of the NIST SP 800-53 controls to protect the system based on risk assessments. 54 | 4. **Implement** the controls, and document how the controls are deployed. 55 | 5. **Assess** the control implementation to determine if the controls are in place, operating as intended, and producing the desired results to manage risk. 56 | 6. **Authorize** the system to operate by a senior-level official that understands the controls in place to manage risk and any residual risk. 57 | 7. **Continuously monitor** control implementation and changes to the risks to the system. 58 | 59 | We recommend reading [NIST SP 800-37, Revision 2](https://csrc.nist.gov/pubs/sp/800/37/r2/final) in its entirety before embarking on your ATO journey, paying particular attention to information about ongoing authorization, automation, and aligning the RMF with the SDLC. Appendix F is important to understand as you move towards Ongoing Authorization. These excerpts are just to help set a baseline for the playbook. 60 | 61 | -------------------------------------------------------------------------------- /docs/people.md: -------------------------------------------------------------------------------- 1 | # People 2 | 3 | Just like any other problem worth prioritizing and solving, establishing cATO and Ongoing Authorization demands that we identify, build and support the right team - a Dream Team! Start by identifying a passionate change agent within your own organization who fully understands how software delivery is achieved today, and how it currently impacts both the business as well as the product teams who are focused on delivering outcomes to warfighters, operators and civilians. There is a high likelihood that this change agent will assume the role and responsibilities of a Product Manager, focused on navigating risks surrounding the viability of each cATO implementation detail as an opportunity to impact the business. 4 | 5 | ![This is an image](images/balanced-team.png) 6 | 7 | From there, you’ll want to build a fully balanced team by incorporating additional roles and competencies that help manage desirability risks, by employing User Centered Design and Service Design principles that considers the local goals, wants and needs of your users – including assessors and authorizing officials. Finally, you’ll also include the right mixture of engineering and cyber security personnel to manage feasibility risks for solution(s) that consider your local constraints. 8 | 9 | In order to foster a decentralized, and creative working environment for this team to quickly discover and prioritize the right problems to help establish your cATO, we recommend applying Jeff Bezos’s 'two pizza' team concept. We’re starting down a journey that, believe it or not, has a lot of unknown unknowns, and by keeping the team small and nimble, we stand a greater chance at being able to quickly learn and make decisions to persevere or pivot on our strategies for cATO. By including the right balance of competencies, and empowering the team to own the outcomes of their decisions by way of accountability, you then also stand a greater chance of establishing and continuously improving cATO for the organization. Only when this Dream Team demonstrates success will they propose options and recommendations on how to address maturing and scaling the RMF implementation and cATO. 10 | 11 |
12 | 13 | ## What if we don't have the right skills? 14 | 15 | When you encounter situations such as members of a Dream Team possessing strengths for the local context of your business, but lack technical or industry experience for Lean Product Management, User Centered Design and modern engineering practices, we recommend leveraging a pairing model. The benefits of this approach are the long term investment in growing workforce talent, and it ensures that the team is well equipped with the full range of competencies to help navigate the various risks we’ve previously discussed. Pairing models demand trust, as each pairing situation typically looks like one person leading their teammate through the journey navigating the business with their years of knowledge and experiences with the local context. While the other teammate is focused on applying and teaching the practices and skills that will forge new behaviors that drive curiosity-led outcomes, rather than solutions and outputs. 16 | 17 |
18 | 19 | ## Critical RMF Supporting Roles 20 | 21 | We also recommend fencing off program dollars to be sent to the departments that manage the Security Control Assessors & Privacy Officer roles, competencies and standard operating procedures. This is an opportunity to partner and hire assessors that have strong technical proficiency as additional dedicated members of your cATO efforts. This is one of the most important plays in the playbook! You may need to help them award an appropriate contract for this, write job descriptions, and more. But it is important that technical assessors report to whoever is responsible for assessing systems in your organization, so that they maintain their independence. On average over 80% of the time spent getting an ATO is spent waiting in queue, and one of the largest pain points reported is the back and forth between engineering and (non-technical) assessors. This play solves for both. This is also another opportunity where a pairing model can increase the technical proficiency of your assessors if need be. 22 | 23 |
24 | 25 | ## What if cybersecurity is not a strength for teams? 26 | 27 | Whether it's the actual teams implementing and supporting cATO, or the product teams who are delivering outcomes to warfighters, operators and civilians, we want to observe how security, privacy and operations become first class citizens throughout the system life cycle. There are actually multiple recommendations that should be considered here. 28 | 29 | Start with a principle of learning by doing, by creating learning opportunities directly within, and throughout, your SDLC processes. Similar to the pairing model described earlier, and to support our rationale for having dedicated assessors, there is an opportunity for product teams to pair with assessors beyond just the assessment step of RMF. Think of it like embedding another subject matter expert into the product team, where the product team can now learn in near real-time about threats, weaknesses and general security concepts. This helps: 30 | 31 | - Create a bi-directional learning environment for teams to learn about cybersecurity and complex privacy laws and regulations, and assessors to learn deeper context about the products they will be assessing. 32 | - Build better quality into your products, earlier. 33 | - Reduce the feedback loop process between control implementation, assessment and authorization. 34 | - Improve the overall trust between product, security, and privacy teams. 35 | 36 | You should also consider leveraging the educational content that is readily available in the security, privacy and RMF tools you leverage within the SDLC process. While this seems obvious, you would be surprised how often organizations don’t grant product teams direct access to tools that are governing their ATOs, or that provide vulnerability feedback and remediation examples. If you could help product teams learn and understand what cybersecurity and privacy weaknesses their systems could be impacted by, before they even started writing code, would you? Commercial software such as [Security by Design Elements (SD Elements)](https://www.securitycompass.com/sdelements/) is a solution we frequently leverage to support just that. Product, security and privacy teams can outline unique context about a given system by way of a threat model and survey which help to identify potential risks and weaknesses that can be addressed as the system is being developed. During the SDLC process, engineers have access to a wealth of training content about these potential risks and weaknesses, why they’re important, and actionable remediation tips. Because product, security and privacy teams all have access to the same toolsuite, their ability to pair and support one another becomes even more effective and efficient. 37 | 38 | 39 | -------------------------------------------------------------------------------- /docs/policy.md: -------------------------------------------------------------------------------- 1 | # Policy 2 | 3 | Before we dive into integrated process and technology, readers need a baseline understanding of key concepts from NIST SP 800-37, Revision 2, “Risk Management Framework for Information Systems and Organizations.” 4 | 5 | ***The following definitions are directly from NIST SP 800-37, Revision 2*** 6 | 7 |
8 | 9 | ## Authorization Boundary 10 | 11 | The authorization boundary for a system is established during the RMF Prepare Task. Organizations have flexibility in determining what constitutes the authorization boundary for a system. The set of system elements included within an authorization boundary defines the system (i.e., the scope of the authorization). When a set of system elements is identified as an authorization boundary for a system, the elements are generally under the same direct management. Other considerations for determining the authorization boundary include identifying system elements that: 12 | 13 | - Support the same mission or business functions; 14 | - Have similar operating characteristics and security and privacy requirements; 15 | - Process, store, and transmit similar types of information (e.g., categorized at the same impact level); or 16 | - Reside in the same environment of operation (or in the case of a distributed system, reside in various locations with similar operating environments). 17 | 18 |
19 | 20 | ## Authorization Boundaries for Software Applications 21 | 22 | Authorization boundaries include all system elements, including hardware, firmware, and software. Software elements include applications (e.g., database applications, customized business applications, and web applications), middleware, and operating systems. The software elements are included in authorization boundaries, either as part of the information system on which the software is hosted or as a part of an application-only system or subsystem that inherits controls from the hosting system. Software applications may depend on the resources provided by the hosting system and as such, can leverage the controls provided by the hosting system to help provide a foundational level of protection for the hosted applications. Additional application-level controls are provided by the respective software applications, as needed. 23 | 24 |
25 | 26 | ## Authorization Types 27 | 28 | System and common control authorization occurs as part of the RMF Authorize step. A system authorization or a common control authorization can be an initial authorization, an ongoing authorization, or a reauthorization as defined below: 29 | 30 | - ***Initial*** authorization is defined as the initial (start-up) risk determination and risk acceptance decision based on a complete, zero-based review of the system or of common controls. The zero-based review of the system includes an assessment of all implemented system-level controls (including the system-level portion of the hybrid controls) and a review of the security status of inherited common controls as specified in security and privacy plans. The zero-based review of common controls (other than common controls that are system-based) includes an assessment of applicable controls (e.g. policies, operating procedures, implementation information) that contribute to the provision of a common control or set of common controls. 31 | - ***Ongoing authorization*** is defined as the subsequent (follow-on) risk determinations and risk acceptance decisions taken at agreed-upon and documented frequencies in accordance with the organization’s mission/business requirements and organizational risk tolerance. Ongoing authorization is a time-driven or event-driven authorization process. The authorizing official is provided with the necessary information regarding the near real-time security and privacy posture of the system to determine whether the mission/business risk of continued system operation or the provision of common controls is acceptable. Ongoing authorization is fundamentally related to the ongoing understanding and ongoing acceptance of security and privacy risk and is dependent on a robust continuous monitoring program. 32 | - ***Reauthorization*** is defined as the static, single point-in-time risk determination and risk acceptance decision that occurs after initial authorization. In general, reauthorization actions may be time-driven or event-driven. However, under ongoing authorization, reauthorization is in most instances, an event-driven action initiated by the authorizing official or directed by the senior accountable official for risk management or risk executive (function) in response to an event that results in security and privacy risk above the level of risk previously accepted by the authorizing official. Reauthorization consists of a review of the system or the common controls similar to the review carried out during the initial authorization. The reauthorization differs from the initial authorization because the authorizing official can choose to initiate a complete zero-based review of the system or of the common controls or to initiate a targeted review based on the type of event that triggered the reauthorization. Reauthorization is a separate activity from the ongoing authorization process. However, security and privacy information generated from the continuous monitoring program may be leveraged to support reauthorization. The reauthorization actions may necessitate a review of and changes to the organization’s information security and privacy continuous monitoring strategies which may in turn affect ongoing authorization. 33 | 34 |
35 | 36 | ## Authorization Decisions 37 | 38 | ​​Authorization decisions are based on the content of the authorization package. There are four types of authorization decisions that can be rendered by authorizing officials: 39 | 40 | - Authorization to operate (ATO) 41 | - Common control authorization 42 | - Authorization to use 43 | - Denial of authorization 44 | 45 | If the authorizing official, after reviewing the authorization package, determines that the risk to organizational operations, organizational assets, individuals, other organizations, and the Nation is acceptable, an ***authorization to operate (ATO)*** is issued for the information system. 46 | 47 | A ***common control authorization*** is similar to an authorization to operate for systems. If the authorizing official, after reviewing the authorization package submitted by the common control provider, determines that the risk to organizational operations and assets, individuals, other organizations, and the Nation is acceptable, a common control authorization is issued. 48 | 49 | An ***authorization*** to use is employed when an organization (hereafter referred to as the customer organization) chooses to accept the information in an existing authorization package produced by another organization (either federal or nonfederal) for an information system that is authorized to operate by a federal entity (referred to as the provider organization) 50 | 51 |

52 | 53 | *The following excerpts are directly from NIST SP 800-37, Revision 2* 54 | 55 |
56 | 57 | ## More about Ongoing Authorization 58 | 59 | Risk management can become near real-time by using automation and state-of-the-practice tools, techniques, and procedures for the ongoing monitoring of controls and changes to systems and the environments in which those systems operate. 60 | 61 | Continuous monitoring helps to achieve a state of ongoing authorization where the authorizing official maintains sufficient knowledge of the current security and privacy posture of the system to determine whether continued operation is acceptable based on ongoing risk determinations—and if not, which steps in the RMF need to be revisited to effectively respond to the additional risk. 62 | 63 |
64 | 65 | ## Conditions for Implementation of Ongoing Authorization 66 | 67 | When the RMF has been effectively applied across the organization and the organization has implemented a robust continuous monitoring program, systems may transition from a static, point-in-time authorization process to a dynamic, near real-time ongoing authorization process. To do so, the following conditions must be satisfied: 68 | 69 | - The system or common control being considered for ongoing authorization has received an initial authorization based on a complete, zero-based review of the system or the common controls. 70 | - An organizational continuous monitoring program is in place that monitors implemented controls with the appropriate degree of rigor and at the required frequencies specified by the organization in accordance with the continuous monitoring strategy and NIST standards and guidelines. 71 | 72 |
73 | 74 | ## Final Note 75 | 76 | We recommend reading [NIST SP 800-37, Revision 2](https://csrc.nist.gov/pubs/sp/800/37/r2/final) in its entirety, paying particular attention to information about ongoing authorization, automation, and aligning the RMF with the SDLC. Appendix F is important to understand as you move towards Ongoing Authorization. These excerpts are just to help set a baseline for the playbook. 77 | 78 | -------------------------------------------------------------------------------- /docs/prepare.md: -------------------------------------------------------------------------------- 1 | # Prepare (for a zero-based review) 2 | 3 | Use the Prepare step to align all stakeholders to go on a journey towards ongoing authorization strategy using people, process, and technology to achieve near real-time continuous monitoring of controls and cybersecurity. 4 | 5 |
6 | 7 | ## Communication Strategy and Plan 8 | 9 | It is important to develop a communications strategy with your team and relevant stakeholders. Key points to emphasize in your communications strategy are: 10 | 11 | - RMF is our common denominator, start there 12 | - Discuss real concerns, don’t generalize 13 | - Compare outcomes, not intentions vs. outcomes 14 | - Afford us the ability to experiment and create a better process 15 | 16 |
17 | 18 | ## Resources 19 | 20 | It is important to emphasize with your stakeholders that you will be following NIST SP 800-37, Revision 2 to the letter. If you aren’t an expert, now’s the time to read up. If you know up front that local policy is more restrictive than RMF and that you may require an exception to policy, now is the time to ask for it while emphasizing that the agency will still meet all FISMA requirements. Be sure to clearly communicate that no matter the destination, you will be starting with an initial authorization to operate, which involves a full zero-based review. We also like to make a promise to our stakeholders, documented formally, that they will have higher quality documentation that is always up to date, with more transparency, more traceability, more auditability, more frequent monitoring, and most importantly, better security and privacy outcomes. We can deliver on this promise! 21 | 22 | For cATO, this playbook is a great resource to share, and we highly recommend watching [this video](https://www.rise8.us/resources/continuous-delivery-for-nist-rmf-cato) along with all your stakeholders as a starting point. 23 | 24 | For general RMF knowledge, we highly recommend this [RMF Introductory Course](https://csrc.nist.gov/Projects/risk-management/rmf-course) and, again, a thorough study of [NIST SP 800-37, Revision 2](https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final). The [NIST RMF Website](https://csrc.nist.gov/projects/risk-management) also has other great resources and the NIST documentation is incredibly well-written, organized, and useful. 25 | 26 |
27 | 28 | ## Common Controls Inheritance 29 | 30 | We also recommend presenting your plan for maximizing common control inheritance. Common control inheritance is a critical enabler at the intersection of process and technology. As noted in the policy section, “software elements are included in authorization boundaries, either as part of the information system on which the software is hosted or as a part of an application-only system or subsystem that inherits controls from the hosting system.” The more controls that applications can inherit, the lower the burden on each application team, and the lower the burden on assessors who only have to assess inherited controls once. 31 | 32 | We recommend that you leverage a modern architecture that allows you to build, deploy, and monitor application systems. This is also the foundation to supporting a common control inheritance model through [common control providers](https://csrc.nist.gov/glossary/term/common_control_provider#:~:text=Definition(s)%3A,controls%20inherited%20by%20information%20systems). At the lowest level, a cloud environment serves as our infrastructure and provides flexible compute and storage capabilities. Above that is a modern platform which leverages this infrastructure to provide both operating environments, as well as a secure mechanism for shipping applications. The cloud environment, the platform, and the secure release pipeline account for a percentage of NIST 800-53 Controls that are solely owned by each layer of the stack, as shown in the diagram below. This means that System Owning teams benefit in having an overall reduction in effort and responsibility for NIST 800-53 Controls that are addressed from the other layers in the stack, when shipping software onto the platform. 33 | 34 | ![This is an image!](images/inheritance.png) 35 | 36 | The more structure and opinionation built into the application platform, the more controls it will provide and the lower the cost of your RMF implementation. Because of the reduced overhead, it will also result in significantly higher speed and quality outcomes. To illustrate this, here is an approximation of the inheritability from different architecture decisions: 37 | 38 | ![This is an image!](images/opinionated-platform.png) 39 | 40 | A highly structured and opinionated platform also reduces the cost of development and operations. Taken together with a lower cost of compliance, it can drastically reduce total cost of ownership for the system while improving software delivery performance to include quality, security, and speed. It is essential to communicate this as well, because many RMF and Program Management Office (PMO) stakeholders will be concerned about potential tradeoffs regarding cost, schedule, and performance. 41 | 42 |
43 | 44 | ## Authorization Boundary 45 | 46 | The way the authorization boundary is drawn is also incredibly important. For example, if only teams within the mission owner’s purview will be deploying to the platform, and the platform services are not optional, the optimal authorization boundaries would likely be drawn at the infrastructure, platform, and application layers, with the infrastructure and platform receiving a common controls authorization. We will outline a few hypothetical scenarios. 47 | 48 | ### Scenario 1: All teams/systems are within the Mission Owner’s purview, platform services are not optional for applications 49 | 50 | For this scenario, as noted above, we recommend the boundaries be drawn at the infrastructure, platform, and application layers, with the infrastructure and platform receiving a common controls authorization. As ConMon grows in maturity, each should move to an ongoing authorization. Each application deploying to the platform should go through a zero-based review, inheriting all applicable controls from the infrastructure and platform, to receive an initial authorization to operate. Once maturity has been reached in the organization's ongoing authorization journey, these applications should be automatically promoted to an ongoing authorization as well, provided the zero-based review meets pre-defined requirements outlined by the AO. 51 | 52 | > [!NOTE] 53 | > The Air Force began using the term Certificate to Field (CtF) which came from Kessel Run’s original partnership with NGA. This term and process do not have a basis in RMF and we recommend moving away from them. 54 | 55 | ### Scenario 2: All teams/systems are within the Mission Owner’s purview, platform services are optional for applications 56 | 57 | In the case that platform/infrastructure services are optional, meaning application teams are not forced to consume them via API or otherwise, then the infrastructure and platform authorization boundaries need to be broken down into components according to how they are consumed. Usually this means drawing boundaries at the API level. This way, applications only inherit controls for services they are consuming. While this can be tracked by exception at the platform and/or application layer, we find that with the right automation it is a much better experience for developers, assessors, and auditors to issue common controls authorizations in a more granular way to promote modularity and composability. It improves speed, reduces errors, and improves transparency, traceability, and auditability. This is especially true during Day 2 operations as the infrastructure and platform teams patch and upgrade existing services and deliver new ones, which creates cascading effects up the tech stack. 58 | 59 | ### Scenario 3: Not all teams/systems are within the Mission Owner’s purview. 60 | 61 | An example of this scenario would be if enterprise cloud organizationally belonged to one mission owner AO (e.g. Enterprise IT AO) and they allowed other mission owners to use their infrastructure to deploy and operate platform and/or application services (e.g. Intelligence Analysis Product Line, Mission Planning Product Line, etc). This would also apply if the platform services were under the purview of the former and only applications were deployed and operated by other Mission Owner AOs. 62 | 63 | In this case, we recommend that consuming Mission Owner AOs review the common controls authorizations from the providing Mission Owner AO and grant an Ongoing Authorization to Use, taking note of any risks being inherited and accepted. Then the consumer must follow the same processes above for any platform services and/or applications they deploy and operate. This can be difficult from a cultural and psychological perspective. For instance, many times the enterprise service provider will want to weigh in on what is being deployed on their enabling system. 64 | 65 | To help with this, we recommend formalizing a Shared Responsibility Model using best practices from the commercial cloud providers. In this, both Authorizing Officials will sign a document that explicitly lays out the responsibilities of each Mission Owner, including shared responsibilities. This overlap is where the consumer will need to accept any risk, or put in requirements for future consideration. It is also where the provider will exert requirements on the consumer, such as the use of an enterprise secure release pipeline that blocks critical findings or runtime scanning of containers and an SLA for remediation. This must be a negotiation between the provider and consumers, and usually the provider will exert more influence as they have to meet the needs of an entire enterprise. 66 | 67 |
68 | 69 | ## Tools and Automation 70 | 71 | This is also a good time to present any tools and automation to be used for both digitization of documentation and workflows and their subsequent automation. This is especially important if you elect not to use the enterprise’s preferred GRC platform, such as eMASS or XACTA. FISMA and RMF do not mandate any tools, though an exception to policy may be required at some level of your organization if these solutions have been mandated. 72 | -------------------------------------------------------------------------------- /docs/organize.md: -------------------------------------------------------------------------------- 1 | # 1. Organizing teams and platforms for success 2 | 3 | We recommend that organizations take an incremental approach to funding and building the teams necessary to establish and continuously improve cATO. We expect that our list of prioritized problems will change over time. Because of this, we can focus on things such as scaling problems once we have achieved desirable outcomes defined by our initial, smaller experiments. To do this we’ve outlined what we believe organizations will need (or at least consider) for (A) Day 1 Team Topologies vs. what they should consider funding for (B) Day 2 Team Topologies, if they achieve success. We also provide an overview of (C) Platform Strategy. This play assumes that your organization already has an established set of enterprise support teams in place (e.g. teams that support SDLC toolsuite, GRC, NSOC, CSOC, etc.), and focuses solely on structuring new teams required to enable cATO. 4 | 5 |
6 | 7 | ## A) Day 1 Team Topologies 8 | 9 | Your **Platform Team** will enable all of the necessary capabilities required for application teams to safely and securely host, develop and deploy their software onto the platform, leveraging your cATO. This team will also be responsible for providing necessary user docs and either API or CLI interfaces that allow all other teams to consume its services without requiring time from your platform engineers. They will also manage their own authorization, inheritable common control baseline details, day two operational support to dev teams, and ongoing feature development for future application team needs. 10 | 11 | Operating as both a customer to the platform, and an enabler of cATO for application development teams, is a **Pipelines & Pathways Team**. While the number of capabilities being offered may vary, this team is responsible for a centralized service offering of CI/CD pipelines. These pipelines must be reliable, readily available and well maintained for business continuity. They are also responsible for ensuring that the attestation of software changes being shipped onto the platform has been fully vetted through gating criteria built into the pipeline itself. Similar to the platform team, this pipelines & pathways team is also responsible for maintaining inheritable common control baseline details that are used to define how configuration management is enforced. In some cases of net-new application development, it can also be valuable for this team to maintain a repository of starter kits (i.e. hello-world apps) that provide application teams with a baseline set of security and privacy controls that can be considered fully assessed. 12 | 13 | We’ve mentioned this in several areas of the playbook already, but you’ll want to fence off some of your budget to reserve a **Security Controls Assessor & Privacy Officer Team** (if privacy data is applicable for your situation). Following the ratio guidance we outlined here, the good news is that during your start up phase of cATO, you should really only need one of each for this team. 14 | 15 |
16 | 17 | ## B) Day 2 Team Topologies 18 | 19 | At some point in this journey, it will no longer be sustainable for Day 1 Team Topology teams to help handhold every product team through onboarding and guidance on the path to production, nor will they have the time to consistently interview and perform user research with every product team leveraging your cATO. It’s also safe to assume that as you begin to increase adoption of the platform and cATO, that the needs of application teams will be increasing beyond your ability to deliver all at once. This is where introducing a **Customer Success Team** can really come in handy. When done right, this team can properly segment and offer various services to application teams based upon specific maturity demographics. This also includes breaking down helpful resources that can be consumed, on-demand, during different phases of the path to production. Equipped with the bandwidth to interview and experience what your customers are experiencing, makes it easier to relay both optimizations and opportunities for new ways to engage with users using the products and services being offered. Therefore, the most important responsibility for this team is creatively gaining insights for improvement, serving the needs of application teams on their path to production, and contributing into any resources that support those activities. 20 | 21 | Another scaling problem that we always witness, is the desire to enable a seamless, end-to-end, customer experience - from onboarding to achieving ATO and continuous delivery. The last thing you want is to have every platform or services team, marketing or enabling consumption of their services in a disparate and disjointed way. This will degrade user advocacy and adoption, thus killing your business cases for scale. This is where we recommend introducing a **Marketplace Team**. This can be as simple as centralizing and standarding your marketing strategy, materials and having a single user doc that explains how to consume and provision all of the various capabilities and services being offered for your path to production. It can also be as elegant as providing a web application experience that guides application teams through the provisioning, configuring and management of resources they need to ship code (e.g. accounts, SDLC tools, platform resources, governance, requirements and compliance, etc), in an on-demand and continuous way. Typically, this team will focus on making it easy to consume, swap and retire the resources they require for developing and shipping code onto your platform. As your platform, pipeline and cATO capabilities begin to mature, and a desire for Customer Relationship Management starts to increase, this team may also start to integrate with other systems to share and consume data for unique business needs. 22 | 23 | While each product team should always be investing in their own ability to capture data and metrics to help drive decision making processes, the volume and complexity of your data will require a **Data & Analytics Team**. At a minimum we believe this team will be responsible for defining standard data solutions and processes for creating, consuming, storing, processing and visualizing data in reports or dashboard, for all teams to leverage. 24 | 25 |
26 | 27 | ## C) Platform Strategy 28 | 29 | Don’t build when you can buy, don’t buy when you can rent. 30 | 31 | We have a forthcoming video on this topic. In the meantime, we want to explain why building your own platform services, including those associated with implementation security and privacy risk management, will likely keep you from ever having a well-paved path to production. 32 | 33 | According to the CNCF Platforms White Paper, “here are capability domains to consider when building platforms for cloud-native computing: 34 | 35 | 1. Web portals for observing and provisioning products and capabilities 36 | 2. APIs (and CLIs) for automatically provisioning products and capabilities 37 | 3. "Golden path" templates and docs enabling optimal use of capabilities in products 38 | 4. Automation for building and testing services and products 39 | 5. Automation for delivering and verifying services and products 40 | 6. Development environments such as hosted IDEs and remote connection tools 41 | 7. Observability for services and products using instrumentation and dashboards, including observation of functionality, performance and costs 42 | 8. Infrastructure services including compute runtimes, programmable networks, and block and volume storage 43 | 9. Data services including databases, caches, and object stores 44 | 10. Messaging and event services including brokers, queues, and event fabrics 45 | 11. Identity and secret management services such as service and user identity and authorization, certificate and key issuance, and static secret storage 46 | 12. Security services including static analysis of code and artifacts, runtime analysis, and policy enforcement 47 | 13. Artifact storage including storage of container image and language-specific packages, custom binaries and libraries, and source code 48 | 49 | Here is what that looks like: 50 | 51 | ![This is an image!](images/CNCF.png) 52 | 53 | That is a lot of capability. Developing, deploying, operating, and maintaining all that capability would realistically take more resources (people and money) than you want to spend for what is below the mission value line. Here is a very conservative look at solely the labor costs for each area: 54 | 55 | ![This is an image!](images/Assumptions.png) 56 | 57 | What’s the value in that? Since we are part of the federal acquisition system, I really want to emphasize that cost, schedule, and performance are one side of a value equation. Value equals performance divided by the product of schedule and cost. It’s important because no matter how much you minimize cost and schedule, if performance is low, value will be low. It’s also worth noting that performance isn’t measured against a specification, but against what the mission and the user really needed–in this case a platform that enables applications to continuously deliver with reduced cognitive load. 58 | 59 | I’m going to expand the variables using Alex Hormozi’s version where performance is actually the dream outcome multiplied by the likelihood of achievement and the cost is both effort and sacrifice, not just money. We all understand the dream outcome: we want a mature platform that includes all the 13 capability areas. According to the CNCF Platforms White Paper, it needs to have: High User satisfaction and productivity, high organizational efficiency, and high product and feature delivery. 60 | 61 | But how likely are we to achieve that? Can we get the talent? Will they be productive? Will your acquisitions strategy and contract rates get approved? Will you get the right contractors? The likelihood of achievement is low… off to a bad start. The time delay is high… I already said that’s a five year journey minimum. Effort and sacrifice are incredibly high… we haven’t even calculated the total cost of ownership and we already know it will cost a lot of people/FTEs and is high effort on the government’s part. Small numerator, really big denominator… ladies and gentlemen, DIY platform is a low value endeavor for you until this equation changes. 62 | 63 | Here is a buy example, where many FTEs are avoided by buying platform licenses, conservatively reducing total cost by 50% while improving likelihood, drastically lowering TTV, and lowering effort and stress: 64 | 65 | ![This is an image!](images/Buy.png) 66 | -------------------------------------------------------------------------------- /docs/implement-assess.md: -------------------------------------------------------------------------------- 1 | # Implement & Assess 2 | 3 | Below is an example of integrated people, process, and technology supporting controls implementation and assessment performed in tandem to produce an authorization package that includes, at a minimum as per RMF, an executive summary, system security plan (SSP), privacy plan, security control assessment, privacy control assessment, and any relevant plans of action and milestones (POAM). RMF and cATO implementations are meant to be technology agnostic, and below is just an example. 4 | 5 | ![This is an image!](images/people-process.png) 6 | 7 | The ideal situation is that control selection is tailored based upon the system authorization boundary that has been confirmed, and then further tailored to each service/application at the start of development. For systems that have already completed development, the same implementation documentation will be required but will likely take much longer to complete and assess. 8 | 9 |
10 | 11 | ## Security and Privacy Control Assessment 12 | 13 | In the graphic above, let’s assume that the platform has a common controls authorization and we are deploying an application to it. After accounting for inheritance, SD Elements would run an application survey to determine what security requirements the application development team is uniquely responsible for, and any additional tailoring could be performed. These can be added to the team’s backlog via native integrations or API, creating a traceable identifier for each. 14 | 15 | To start, we recommend a kickoff meeting with security (including privacy if the system is impacted): 16 | 17 | - An hour meeting 18 | - Assign the team an assessor 19 | - Perform product architectural analysis 20 | - Determines app-level categorization 21 | - Select and assign team controls 22 | - Assigned assessor will help team prioritize backlog 23 | 24 | Assuming a code level implementation, the engineers would pick up the story, complete implementation and documentation, and assessor acceptance would be required, much like PM acceptance for user stories. It helps to standardize the way teams respond to these tasks: 25 | 26 | - Describe the team’s technical decisions and task implementation details 27 | - Provide a link to the code and/or regularly maintained artifacts to make reviewing easier 28 | - Provide a technical point of contact with name and email, who signed for the task completion 29 | - Add a security assessor assigned to the project as a reviewer for the completion of this story 30 | 31 | The acceptance process might include reviewing the implementation in Git, requesting changes or additional information, and providing resources to help them with implementation (like SD Elements’ helpful context-specific training videos). Here is an example of a real back-and-forth between developer and assessor: 32 | 33 | ![This is an image!](images/example-task.png) 34 | 35 |
36 | 37 | ## Secure Release Pipeline 38 | 39 | [Continuous Integration (CI)](https://www.martinfowler.com/articles/continuousIntegration.html) pipelines ensure that System Owning teams can deliver frequent changes of software into production quickly and safely. On a development platform, app teams have the flexibility to build, test and deploy using whatever strategy is best suited for their system. However, before teams can deploy to the platform, they must be registered to and call the secure release pipeline. 40 | 41 | This pipeline service should only be available to software development teams that are customers of your platform. A strong secure and release pipeline enables security vulnerability detection and remediation guidance every time an engineer commits code changes to their repository. At a minimum, your pipelines should provide immediate feedback on security vulnerabilities for Static Application Security Testing (SAST), Software Composition Analysis (SCA) for open source packages, as well as vulnerabilities that exist within Image(s)/Container(s). The secure release pipeline enforces policies as gate-check jobs that must be adhered to in order for teams to achieve a digitally signed application image. Only images signed by your secure release pipeline should be allowed onto the platform, and are validated by the platform prior to upper environment deployments. 42 | 43 | ![This is an image!](images/secrel.png) 44 | 45 | Vulnerabilities must be addressed by teams and validated by an assessor in accordance with the operating procedures your organization sets, including any changes over time. Operating procedures might, for instance, not allow critical or high severity vulnerabilities to be deployed into upper environments. As you mature, your secure release pipeline should also enforce adequate unit, journey, integration testing, and release engineering best practices. 46 | 47 | Here are examples of how we used Snyk and Aqua in one implementation: 48 | 49 | ![This is an image!](images/snyk.png) 50 | ![This is an image!](images/aqua.png) 51 | 52 | To ensure adequate progress throughout the course of development, we recommend periodic control and scan reviews such as: 53 | Weekly meeting will be set between assessor and team 54 | 55 | - Assigned assessor must have access to the team's backlog 56 | - Help prioritize security controls 57 | - Determine product security progress 58 | - Answer any questions or concerns by the team 59 | 60 |
61 | 62 | ## SSP and POAM 63 | 64 | The SSP and POAM should be digitized, and automation can be applied as your maturity increases. For instance, you could start with a low-fidelity automation to track the last time a new system architecture diagram was updated and trigger a manual review when it exceeds 30 days. Later, you might trigger the same rule when an integration is added but a new diagram was not uploaded. For POAMs, one could set automated alerts for milestones so they can be tracked and enforced. This ensures that planned actions are carried out or, if not feasible, deferred with assessor involvement. 65 | 66 | The POAM describes the actions that are planned to correct deficiencies in a given control identified during the assessment of controls as well as during continuous monitoring. A POAM typically includes tasks to be accomplished with a recommendation for completion before or after system authorization; resources required to accomplish the tasks; milestones established to meet the tasks; and the scheduled completion dates for the milestones and tasks. POAMs are reviewed by the Authorizing Official (AO) to ensure there is agreement with the remediation actions planned to correct the identified deficiencies. 67 | 68 | POAMs are not needed when deficiencies are accepted by the AO as residual risk, or, are remediated during an assessment and before a release. Residual risk is often covered by other controls that were fully and successfully addressed. 69 | 70 | - Residual risk is defined as risk that remains after efforts to identify and mitigate said risk have been taken. 71 | - Information System Security Officers (ISSO) or Application Security Assessors will monitor for new POAM items submitted for review, and report them to the AO as needed. 72 | 73 |
74 | 75 | ## Security and Privacy Assessment Report 76 | 77 | If you follow the high-level approach laid out here, everything you need for the assessment report is already completed. You may have some work ahead of you if a particular format or system of record is required for documenting it. Again, we recommend getting an exception here to allow the report to be generated and stored in your native SDLC tools. Even if the data and artifacts aren’t aggregated and consolidated in the early days of cATO, that is ok. It is almost certainly in a better place than the rest of your enterprise, where systems are tracked primarily in spreadsheets, word docs and PDFs, and then manually transposed into systems of record like eMASS. Consolidating yours is an important part of improving the assessor and AO experience, and should be prioritized against other areas of improvement as you mature. 78 | 79 | Security Control Assessors (SCA) should provide a Security Assessment Report (SAR) to AO regarding the outcomes of their assessment. This report provides findings and recommendations on deficiencies related to security risks. Deficiencies are either addressed before acquiring an ATO approval from an AO, or listed in the aforementioned POAM to be addressed within a specified time period after acquiring an ATO approval and deploying to production. 80 | 81 | Traditionally, System Owners would coordinate a week, or multi-week long assessment exercise, months in advance to provide adequate time to address assessment, any remediation, and authorization. This forces teams to operate with a waterfall mentality, taking on coordination risks, and planning around the availability of Assessors as well as the actual readiness of the system for assessment. This typically adds months of delay to a team's path to production, focuses on an incomplete picture of known risks, and often leads to a large list of unaddressed POAM items that often go stale and are not addressed as planned, if at all. 82 | 83 | Our approach is aimed at aligning NIST RMF steps and practices to how modern software development teams actually develop and deliver systems to end-users - iteratively and incrementally. As denoted by the image below, teams learn enough about the problem space, the end-users they are solving for, the data and types of technology that will be used to deliver the end results. It is at this point when an SCA (and privacy officer when applicable) is embedded with the team throughout the lifecycle of their system and Software Development Lifecycle (SDLC). 84 | 85 | ![This is an image!](images/embed-assessors.png) 86 | 87 | This process of assessing risks and verifying that requirements have been met occurs as changes are introduced by the System Owning team or system dependencies. By iteratively and incrementally addressing small amounts of security risks, Assessors and System Owning teams have greater transparency and trust in the process of certifying the system to go to production. 88 | 89 |
90 | 91 | ## A Note on Automation 92 | 93 | We recommend starting simple and adding automation based on your largest bottlenecks. This looks very different in an organization with 5 apps versus 100, or with 100 users versus 100,000, or with 1,000 monthly API calls versus 10M. Trying to automate all the things on day 1 is a terrible strategy (you will fail) and unnecessary. The goal is risk management, and then continuous improvement. Sure, think big… but then start small and scale appropriately. 94 | 95 | [OSCAL](https://pages.nist.gov/OSCAL/) looks promising when it comes to generating authorization packages dynamically, saving a great deal of time and money as [demonstrated by AWS](https://aws.amazon.com/blogs/security/aws-achieves-the-first-oscal-format-system-security-plan-submission-to-fedramp/) last year. We have built an OSCAL-based RMF platform and are beginning to implement it with our customers. In the future we may add implementations to the playbook or as an external reference. 96 | -------------------------------------------------------------------------------- /docs/diagrams/architecture.excalidraw: -------------------------------------------------------------------------------- 1 | { 2 | "type": "excalidraw", 3 | "version": 2, 4 | "source": "https://excalidraw.com", 5 | "elements": [ 6 | { 7 | "type": "rectangle", 8 | "version": 231, 9 | "versionNonce": 1242931389, 10 | "isDeleted": false, 11 | "id": "9x9FrYplawFRMHcyidB0B", 12 | "fillStyle": "hachure", 13 | "strokeWidth": 1, 14 | "strokeStyle": "solid", 15 | "roughness": 1, 16 | "opacity": 100, 17 | "angle": 0, 18 | "x": 1124.5977935791016, 19 | "y": 329.9318542480469, 20 | "strokeColor": "#000000", 21 | "backgroundColor": "transparent", 22 | "width": 351.7841796875, 23 | "height": 75.85360717773439, 24 | "seed": 1253623595, 25 | "groupIds": [], 26 | "frameId": null, 27 | "roundness": null, 28 | "boundElements": [ 29 | { 30 | "id": "g22A5PwXvUDnIS-uNj7s8", 31 | "type": "arrow" 32 | } 33 | ], 34 | "updated": 1698357840311, 35 | "link": null, 36 | "locked": false 37 | }, 38 | { 39 | "type": "rectangle", 40 | "version": 328, 41 | "versionNonce": 1142920595, 42 | "isDeleted": false, 43 | "id": "pglVCAjm-KzReXuwYKgu-", 44 | "fillStyle": "hachure", 45 | "strokeWidth": 1, 46 | "strokeStyle": "solid", 47 | "roughness": 1, 48 | "opacity": 100, 49 | "angle": 0, 50 | "x": 1122.4370727539062, 51 | "y": 414.43212890625, 52 | "strokeColor": "#000000", 53 | "backgroundColor": "transparent", 54 | "width": 352, 55 | "height": 75.85360717773439, 56 | "seed": 1338522981, 57 | "groupIds": [], 58 | "frameId": null, 59 | "roundness": null, 60 | "boundElements": [], 61 | "updated": 1698357840311, 62 | "link": null, 63 | "locked": false 64 | }, 65 | { 66 | "type": "rectangle", 67 | "version": 403, 68 | "versionNonce": 1065124125, 69 | "isDeleted": false, 70 | "id": "B-FD7Bqdxg9gtXTg0UsGf", 71 | "fillStyle": "hachure", 72 | "strokeWidth": 1, 73 | "strokeStyle": "solid", 74 | "roughness": 1, 75 | "opacity": 100, 76 | "angle": 0, 77 | "x": 1124.5977935791016, 78 | "y": 498.9324035644531, 79 | "strokeColor": "#000000", 80 | "backgroundColor": "transparent", 81 | "width": 351.7841796875, 82 | "height": 75.85360717773439, 83 | "seed": 1638206053, 84 | "groupIds": [], 85 | "frameId": null, 86 | "roundness": null, 87 | "boundElements": [ 88 | { 89 | "id": "LPWdi9fTTNGYq7e8LLVEk", 90 | "type": "arrow" 91 | } 92 | ], 93 | "updated": 1698357840311, 94 | "link": null, 95 | "locked": false 96 | }, 97 | { 98 | "type": "text", 99 | "version": 125, 100 | "versionNonce": 1700621107, 101 | "isDeleted": false, 102 | "id": "7o9yGLYgjNTqNDm0mQDDV", 103 | "fillStyle": "hachure", 104 | "strokeWidth": 1, 105 | "strokeStyle": "solid", 106 | "roughness": 1, 107 | "opacity": 100, 108 | "angle": 0, 109 | "x": 1148.1483154296875, 110 | "y": 355.0943603515625, 111 | "strokeColor": "#000000", 112 | "backgroundColor": "transparent", 113 | "width": 114, 114 | "height": 25, 115 | "seed": 520909253, 116 | "groupIds": [], 117 | "frameId": null, 118 | "roundness": null, 119 | "boundElements": [ 120 | { 121 | "id": "dGpYdkucpmmLNu7W-Q-gM", 122 | "type": "arrow" 123 | } 124 | ], 125 | "updated": 1698357840311, 126 | "link": null, 127 | "locked": false, 128 | "fontSize": 20, 129 | "fontFamily": 1, 130 | "text": "Applications", 131 | "textAlign": "left", 132 | "verticalAlign": "top", 133 | "containerId": null, 134 | "originalText": "Applications", 135 | "lineHeight": 1.25, 136 | "baseline": 17 137 | }, 138 | { 139 | "type": "text", 140 | "version": 131, 141 | "versionNonce": 971527549, 142 | "isDeleted": false, 143 | "id": "jPNgM_JzzYBvEnBz9WfR1", 144 | "fillStyle": "hachure", 145 | "strokeWidth": 1, 146 | "strokeStyle": "solid", 147 | "roughness": 1, 148 | "opacity": 100, 149 | "angle": 0, 150 | "x": 1148.1483154296875, 151 | "y": 437.5723876953125, 152 | "strokeColor": "#000000", 153 | "backgroundColor": "transparent", 154 | "width": 86, 155 | "height": 25, 156 | "seed": 1008054411, 157 | "groupIds": [], 158 | "frameId": null, 159 | "roundness": null, 160 | "boundElements": [], 161 | "updated": 1698357840311, 162 | "link": null, 163 | "locked": false, 164 | "fontSize": 20, 165 | "fontFamily": 1, 166 | "text": "Platform", 167 | "textAlign": "left", 168 | "verticalAlign": "top", 169 | "containerId": null, 170 | "originalText": "Platform", 171 | "lineHeight": 1.25, 172 | "baseline": 17 173 | }, 174 | { 175 | "type": "text", 176 | "version": 49, 177 | "versionNonce": 2005896403, 178 | "isDeleted": false, 179 | "id": "bBW2hIWK8MopZ5_wjSk8s", 180 | "fillStyle": "hachure", 181 | "strokeWidth": 1, 182 | "strokeStyle": "solid", 183 | "roughness": 1, 184 | "opacity": 100, 185 | "angle": 0, 186 | "x": 1148.1483154296875, 187 | "y": 524.8660888671875, 188 | "strokeColor": "#000000", 189 | "backgroundColor": "transparent", 190 | "width": 147, 191 | "height": 25, 192 | "seed": 2124347819, 193 | "groupIds": [], 194 | "frameId": null, 195 | "roundness": null, 196 | "boundElements": [ 197 | { 198 | "id": "LPWdi9fTTNGYq7e8LLVEk", 199 | "type": "arrow" 200 | } 201 | ], 202 | "updated": 1698357840311, 203 | "link": null, 204 | "locked": false, 205 | "fontSize": 20, 206 | "fontFamily": 1, 207 | "text": "Infrastructure", 208 | "textAlign": "left", 209 | "verticalAlign": "top", 210 | "containerId": null, 211 | "originalText": "Infrastructure", 212 | "lineHeight": 1.25, 213 | "baseline": 17 214 | }, 215 | { 216 | "type": "arrow", 217 | "version": 2272, 218 | "versionNonce": 183560637, 219 | "isDeleted": false, 220 | "id": "LPWdi9fTTNGYq7e8LLVEk", 221 | "fillStyle": "hachure", 222 | "strokeWidth": 1, 223 | "strokeStyle": "solid", 224 | "roughness": 1, 225 | "opacity": 100, 226 | "angle": 0, 227 | "x": 1015.0126253815209, 228 | "y": 494.5681638512947, 229 | "strokeColor": "#000000", 230 | "backgroundColor": "transparent", 231 | "width": 125.60586857734336, 232 | "height": 39.43551891618972, 233 | "seed": 427308901, 234 | "groupIds": [], 235 | "frameId": null, 236 | "roundness": { 237 | "type": 2 238 | }, 239 | "boundElements": [], 240 | "updated": 1698357870420, 241 | "link": null, 242 | "locked": false, 243 | "startBinding": { 244 | "elementId": "0VNY4jt-T8GXlW_GS7_Pp", 245 | "focus": 0.21496614791664514, 246 | "gap": 8.480090120825935 247 | }, 248 | "endBinding": { 249 | "elementId": "bBW2hIWK8MopZ5_wjSk8s", 250 | "focus": -0.620580282308985, 251 | "gap": 7.529821470823208 252 | }, 253 | "lastCommittedPoint": null, 254 | "startArrowhead": null, 255 | "endArrowhead": "arrow", 256 | "points": [ 257 | [ 258 | 0, 259 | 0 260 | ], 261 | [ 262 | 125.60586857734336, 263 | 39.43551891618972 264 | ] 265 | ] 266 | }, 267 | { 268 | "type": "arrow", 269 | "version": 2322, 270 | "versionNonce": 1850505843, 271 | "isDeleted": false, 272 | "id": "dGpYdkucpmmLNu7W-Q-gM", 273 | "fillStyle": "hachure", 274 | "strokeWidth": 1, 275 | "strokeStyle": "solid", 276 | "roughness": 1, 277 | "opacity": 100, 278 | "angle": 0, 279 | "x": 999.6757789451599, 280 | "y": 318.8661680016853, 281 | "strokeColor": "#000000", 282 | "backgroundColor": "transparent", 283 | "width": 142.29238542386065, 284 | "height": 47.46358378048285, 285 | "seed": 46180752, 286 | "groupIds": [], 287 | "frameId": null, 288 | "roundness": { 289 | "type": 2 290 | }, 291 | "boundElements": [], 292 | "updated": 1698357840311, 293 | "link": null, 294 | "locked": false, 295 | "startBinding": { 296 | "elementId": "oiK02bVaH-ai7uXWjU3ZM", 297 | "focus": 0.22861353912443413, 298 | "gap": 11.364932039771247 299 | }, 300 | "endBinding": { 301 | "elementId": "7o9yGLYgjNTqNDm0mQDDV", 302 | "focus": -0.6286267847919298, 303 | "gap": 6.180151060666958 304 | }, 305 | "lastCommittedPoint": null, 306 | "startArrowhead": null, 307 | "endArrowhead": "arrow", 308 | "points": [ 309 | [ 310 | 0, 311 | 0 312 | ], 313 | [ 314 | 142.29238542386065, 315 | 47.46358378048285 316 | ] 317 | ] 318 | }, 319 | { 320 | "type": "text", 321 | "version": 1121, 322 | "versionNonce": 290079997, 323 | "isDeleted": false, 324 | "id": "0VNY4jt-T8GXlW_GS7_Pp", 325 | "fillStyle": "hachure", 326 | "strokeWidth": 1, 327 | "strokeStyle": "solid", 328 | "roughness": 1, 329 | "opacity": 100, 330 | "angle": 0, 331 | "x": 857.64111328125, 332 | "y": 436.08807373046875, 333 | "strokeColor": "#000000", 334 | "backgroundColor": "transparent", 335 | "width": 173.099853515625, 336 | "height": 50, 337 | "seed": 1070989035, 338 | "groupIds": [], 339 | "frameId": null, 340 | "roundness": null, 341 | "boundElements": [ 342 | { 343 | "id": "LPWdi9fTTNGYq7e8LLVEk", 344 | "type": "arrow" 345 | } 346 | ], 347 | "updated": 1698357870420, 348 | "link": null, 349 | "locked": false, 350 | "fontSize": 20, 351 | "fontFamily": 1, 352 | "text": "We use the Cloud\nto host systems", 353 | "textAlign": "center", 354 | "verticalAlign": "top", 355 | "containerId": null, 356 | "originalText": "We use the Cloud\nto host systems", 357 | "lineHeight": 1.25, 358 | "baseline": 42 359 | }, 360 | { 361 | "type": "ellipse", 362 | "version": 134, 363 | "versionNonce": 106607635, 364 | "isDeleted": false, 365 | "id": "31MRdSR2AnxIAnPIy74V0", 366 | "fillStyle": "cross-hatch", 367 | "strokeWidth": 1, 368 | "strokeStyle": "solid", 369 | "roughness": 1, 370 | "opacity": 100, 371 | "angle": 0, 372 | "x": 1463.6050720214844, 373 | "y": 440.5104522705078, 374 | "strokeColor": "#000000", 375 | "backgroundColor": "#000000", 376 | "width": 21.1444091796875, 377 | "height": 21.3902587890625, 378 | "seed": 354480461, 379 | "groupIds": [], 380 | "frameId": null, 381 | "roundness": null, 382 | "boundElements": [ 383 | { 384 | "id": "ZhOUvQxFeeAjMAdoaUFQ0", 385 | "type": "arrow" 386 | }, 387 | { 388 | "id": "g22A5PwXvUDnIS-uNj7s8", 389 | "type": "arrow" 390 | } 391 | ], 392 | "updated": 1698357840311, 393 | "link": null, 394 | "locked": false 395 | }, 396 | { 397 | "type": "ellipse", 398 | "version": 202, 399 | "versionNonce": 686328477, 400 | "isDeleted": false, 401 | "id": "aBxUoniFlpeA0Z3RIhqVE", 402 | "fillStyle": "cross-hatch", 403 | "strokeWidth": 1, 404 | "strokeStyle": "solid", 405 | "roughness": 1, 406 | "opacity": 100, 407 | "angle": 0, 408 | "x": 1463.6050720214844, 409 | "y": 357.1635284423828, 410 | "strokeColor": "#000000", 411 | "backgroundColor": "#000000", 412 | "width": 21.1444091796875, 413 | "height": 21.3902587890625, 414 | "seed": 582532387, 415 | "groupIds": [], 416 | "frameId": null, 417 | "roundness": null, 418 | "boundElements": [ 419 | { 420 | "id": "g22A5PwXvUDnIS-uNj7s8", 421 | "type": "arrow" 422 | } 423 | ], 424 | "updated": 1698357840311, 425 | "link": null, 426 | "locked": false 427 | }, 428 | { 429 | "type": "ellipse", 430 | "version": 221, 431 | "versionNonce": 531675571, 432 | "isDeleted": false, 433 | "id": "K4z6p3S8nYjteXCAm7Dtt", 434 | "fillStyle": "cross-hatch", 435 | "strokeWidth": 1, 436 | "strokeStyle": "solid", 437 | "roughness": 1, 438 | "opacity": 100, 439 | "angle": 0, 440 | "x": 1463.6050720214844, 441 | "y": 525.9182281494141, 442 | "strokeColor": "#000000", 443 | "backgroundColor": "#000000", 444 | "width": 21.1444091796875, 445 | "height": 21.3902587890625, 446 | "seed": 1878611885, 447 | "groupIds": [], 448 | "frameId": null, 449 | "roundness": null, 450 | "boundElements": [ 451 | { 452 | "id": "ZhOUvQxFeeAjMAdoaUFQ0", 453 | "type": "arrow" 454 | } 455 | ], 456 | "updated": 1698357840311, 457 | "link": null, 458 | "locked": false 459 | }, 460 | { 461 | "type": "arrow", 462 | "version": 323, 463 | "versionNonce": 2081894141, 464 | "isDeleted": false, 465 | "id": "ZhOUvQxFeeAjMAdoaUFQ0", 466 | "fillStyle": "cross-hatch", 467 | "strokeWidth": 1, 468 | "strokeStyle": "solid", 469 | "roughness": 1, 470 | "opacity": 100, 471 | "angle": 0, 472 | "x": 1489.6957786600833, 473 | "y": 536.1529460579172, 474 | "strokeColor": "#000000", 475 | "backgroundColor": "#000000", 476 | "width": 79.3236047822752, 477 | "height": 84.35793352050689, 478 | "seed": 880121357, 479 | "groupIds": [], 480 | "frameId": null, 481 | "roundness": { 482 | "type": 2 483 | }, 484 | "boundElements": [], 485 | "updated": 1698357840311, 486 | "link": null, 487 | "locked": false, 488 | "startBinding": { 489 | "elementId": "K4z6p3S8nYjteXCAm7Dtt", 490 | "focus": 0.8824873561643858, 491 | "gap": 9.01082173742861 492 | }, 493 | "endBinding": { 494 | "elementId": "31MRdSR2AnxIAnPIy74V0", 495 | "focus": -0.5660519882276847, 496 | "gap": 3.4570012843067985 497 | }, 498 | "lastCommittedPoint": null, 499 | "startArrowhead": null, 500 | "endArrowhead": "arrow", 501 | "points": [ 502 | [ 503 | 0, 504 | 0 505 | ], 506 | [ 507 | 73.14857672163953, 508 | -42.35214954912817 509 | ], 510 | [ 511 | -6.175028060635668, 512 | -84.35793352050689 513 | ] 514 | ] 515 | }, 516 | { 517 | "type": "arrow", 518 | "version": 452, 519 | "versionNonce": 1467288403, 520 | "isDeleted": false, 521 | "id": "g22A5PwXvUDnIS-uNj7s8", 522 | "fillStyle": "cross-hatch", 523 | "strokeWidth": 1, 524 | "strokeStyle": "solid", 525 | "roughness": 1, 526 | "opacity": 100, 527 | "angle": 0, 528 | "x": 1489.6394375186437, 529 | "y": 446.6280854122558, 530 | "strokeColor": "#000000", 531 | "backgroundColor": "#000000", 532 | "width": 79.3404541015625, 533 | "height": 83.16122614145007, 534 | "seed": 1364222275, 535 | "groupIds": [], 536 | "frameId": null, 537 | "roundness": { 538 | "type": 2 539 | }, 540 | "boundElements": [], 541 | "updated": 1698357840311, 542 | "link": null, 543 | "locked": false, 544 | "startBinding": { 545 | "elementId": "31MRdSR2AnxIAnPIy74V0", 546 | "focus": 0.2867123289349761, 547 | "gap": 5.299605903084839 548 | }, 549 | "endBinding": { 550 | "elementId": "aBxUoniFlpeA0Z3RIhqVE", 551 | "focus": -0.8235833238386275, 552 | "gap": 1 553 | }, 554 | "lastCommittedPoint": null, 555 | "startArrowhead": null, 556 | "endArrowhead": "arrow", 557 | "points": [ 558 | [ 559 | 0, 560 | 0 561 | ], 562 | [ 563 | 73.13488499112191, 564 | -38.65053109096675 565 | ], 566 | [ 567 | -6.205569110440592, 568 | -83.16122614145007 569 | ] 570 | ] 571 | }, 572 | { 573 | "type": "text", 574 | "version": 155, 575 | "versionNonce": 1320306525, 576 | "isDeleted": false, 577 | "id": "o7bMgTijhpiMdrDGY0exA", 578 | "fillStyle": "cross-hatch", 579 | "strokeWidth": 1, 580 | "strokeStyle": "solid", 581 | "roughness": 1, 582 | "opacity": 100, 583 | "angle": 0, 584 | "x": 1578.4084777832031, 585 | "y": 410.9816665649414, 586 | "strokeColor": "#000000", 587 | "backgroundColor": "#000000", 588 | "width": 193, 589 | "height": 75, 590 | "seed": 765354499, 591 | "groupIds": [], 592 | "frameId": null, 593 | "roundness": null, 594 | "boundElements": [], 595 | "updated": 1698357840311, 596 | "link": null, 597 | "locked": false, 598 | "fontSize": 20, 599 | "fontFamily": 1, 600 | "text": "We leverage common\ncontrol inheritance \nup the stack", 601 | "textAlign": "left", 602 | "verticalAlign": "top", 603 | "containerId": null, 604 | "originalText": "We leverage common\ncontrol inheritance \nup the stack", 605 | "lineHeight": 1.25, 606 | "baseline": 67 607 | }, 608 | { 609 | "type": "text", 610 | "version": 419, 611 | "versionNonce": 1644046579, 612 | "isDeleted": false, 613 | "id": "oiK02bVaH-ai7uXWjU3ZM", 614 | "fillStyle": "hachure", 615 | "strokeWidth": 1, 616 | "strokeStyle": "solid", 617 | "roughness": 1, 618 | "opacity": 100, 619 | "angle": 0, 620 | "x": 815.9955291748047, 621 | "y": 257.50123596191406, 622 | "strokeColor": "#000000", 623 | "backgroundColor": "transparent", 624 | "width": 238, 625 | "height": 50, 626 | "seed": 31336848, 627 | "groupIds": [], 628 | "frameId": null, 629 | "roundness": null, 630 | "boundElements": [ 631 | { 632 | "id": "dGpYdkucpmmLNu7W-Q-gM", 633 | "type": "arrow" 634 | } 635 | ], 636 | "updated": 1698357840311, 637 | "link": null, 638 | "locked": false, 639 | "fontSize": 20, 640 | "fontFamily": 1, 641 | "text": "About 70% of security \ncontrols are inherited", 642 | "textAlign": "left", 643 | "verticalAlign": "top", 644 | "containerId": null, 645 | "originalText": "About 70% of security \ncontrols are inherited", 646 | "lineHeight": 1.25, 647 | "baseline": 42 648 | }, 649 | { 650 | "type": "text", 651 | "version": 597, 652 | "versionNonce": 1661686717, 653 | "isDeleted": false, 654 | "id": "rKYQ-xhSvSrQ44VSa0eT8", 655 | "fillStyle": "hachure", 656 | "strokeWidth": 1, 657 | "strokeStyle": "solid", 658 | "roughness": 1, 659 | "opacity": 100, 660 | "angle": 0, 661 | "x": 1170.521011352539, 662 | "y": 258.3459014892578, 663 | "strokeColor": "#000000", 664 | "backgroundColor": "transparent", 665 | "width": 253, 666 | "height": 36, 667 | "seed": 4624752, 668 | "groupIds": [], 669 | "frameId": null, 670 | "roundness": null, 671 | "boundElements": [], 672 | "updated": 1698357840311, 673 | "link": null, 674 | "locked": false, 675 | "fontSize": 28, 676 | "fontFamily": 1, 677 | "text": "The Modern Stack", 678 | "textAlign": "left", 679 | "verticalAlign": "top", 680 | "containerId": null, 681 | "originalText": "The Modern Stack", 682 | "lineHeight": 1.2857142857142858, 683 | "baseline": 25 684 | }, 685 | { 686 | "type": "arrow", 687 | "version": 172, 688 | "versionNonce": 617779859, 689 | "isDeleted": false, 690 | "id": "Bwfmrusw4RLdbOYN51GhF", 691 | "fillStyle": "hachure", 692 | "strokeWidth": 1, 693 | "strokeStyle": "solid", 694 | "roughness": 2, 695 | "opacity": 100, 696 | "angle": 0, 697 | "x": 1499.8531103488883, 698 | "y": 301.6197280883789, 699 | "strokeColor": "#000000", 700 | "backgroundColor": "transparent", 701 | "width": 99.14694884986488, 702 | "height": 60.693359375, 703 | "seed": 1229795712, 704 | "groupIds": [], 705 | "frameId": null, 706 | "roundness": { 707 | "type": 2 708 | }, 709 | "boundElements": [], 710 | "updated": 1698357840311, 711 | "link": null, 712 | "locked": false, 713 | "startBinding": { 714 | "elementId": "9Nb6Vlu7ahZwuEtTdfDK2", 715 | "focus": 0.4226617193485916, 716 | "gap": 1.10638427734375 717 | }, 718 | "endBinding": null, 719 | "lastCommittedPoint": null, 720 | "startArrowhead": null, 721 | "endArrowhead": "arrow", 722 | "points": [ 723 | [ 724 | 0, 725 | 0 726 | ], 727 | [ 728 | -99.14694884986488, 729 | 60.693359375 730 | ] 731 | ] 732 | }, 733 | { 734 | "type": "text", 735 | "version": 152, 736 | "versionNonce": 1299089117, 737 | "isDeleted": false, 738 | "id": "9Nb6Vlu7ahZwuEtTdfDK2", 739 | "fillStyle": "hachure", 740 | "strokeWidth": 1, 741 | "strokeStyle": "solid", 742 | "roughness": 2, 743 | "opacity": 100, 744 | "angle": 0, 745 | "x": 1490.8743743896484, 746 | "y": 275.51334381103516, 747 | "strokeColor": "#000000", 748 | "backgroundColor": "transparent", 749 | "width": 136.49989318847656, 750 | "height": 25, 751 | "seed": 1622746752, 752 | "groupIds": [], 753 | "frameId": null, 754 | "roundness": null, 755 | "boundElements": [ 756 | { 757 | "id": "Bwfmrusw4RLdbOYN51GhF", 758 | "type": "arrow" 759 | } 760 | ], 761 | "updated": 1698357906769, 762 | "link": null, 763 | "locked": false, 764 | "fontSize": 20, 765 | "fontFamily": 1, 766 | "text": "We build APIs", 767 | "textAlign": "left", 768 | "verticalAlign": "top", 769 | "containerId": null, 770 | "originalText": "We build APIs", 771 | "lineHeight": 1.25, 772 | "baseline": 17 773 | } 774 | ], 775 | "appState": { 776 | "gridSize": null, 777 | "viewBackgroundColor": "#ffffff" 778 | }, 779 | "files": {} 780 | } -------------------------------------------------------------------------------- /docs/diagrams/systemDiagram.excalidraw: -------------------------------------------------------------------------------- 1 | { 2 | "type": "excalidraw", 3 | "version": 2, 4 | "source": "https://excalidraw.com", 5 | "elements": [ 6 | { 7 | "type": "rectangle", 8 | "version": 154, 9 | "versionNonce": 1387312398, 10 | "isDeleted": false, 11 | "id": "osuVftQFVdF5nShmylU4K", 12 | "fillStyle": "hachure", 13 | "strokeWidth": 1, 14 | "strokeStyle": "solid", 15 | "roughness": 1, 16 | "opacity": 100, 17 | "angle": 0, 18 | "x": 903.8056030273438, 19 | "y": 420.8743591308594, 20 | "strokeColor": "#000000", 21 | "backgroundColor": "transparent", 22 | "width": 175, 23 | "height": 81, 24 | "seed": 141145515, 25 | "groupIds": [], 26 | "strokeSharpness": "sharp", 27 | "boundElements": [ 28 | { 29 | "type": "text", 30 | "id": "k_ei4Ez5SMenK44QJ3Bqh" 31 | }, 32 | { 33 | "id": "ubPLCeytW-WtHtROMn-z-", 34 | "type": "arrow" 35 | }, 36 | { 37 | "id": "lFjMuooqJRH_tC-baiLWg", 38 | "type": "arrow" 39 | }, 40 | { 41 | "id": "mZHlYy-komb4fnj2QQcQz", 42 | "type": "arrow" 43 | }, 44 | { 45 | "id": "-_8O-APgNwfF234BbM1xn", 46 | "type": "arrow" 47 | } 48 | ], 49 | "updated": 1653343911759, 50 | "link": null, 51 | "locked": false 52 | }, 53 | { 54 | "type": "rectangle", 55 | "version": 314, 56 | "versionNonce": 1974168274, 57 | "isDeleted": false, 58 | "id": "8BsUEe76GjAhuqnGj4AHh", 59 | "fillStyle": "hachure", 60 | "strokeWidth": 1, 61 | "strokeStyle": "solid", 62 | "roughness": 1, 63 | "opacity": 100, 64 | "angle": 0, 65 | "x": 904.0514526367188, 66 | "y": 652.8469848632812, 67 | "strokeColor": "#000000", 68 | "backgroundColor": "transparent", 69 | "width": 175, 70 | "height": 81, 71 | "seed": 1988421509, 72 | "groupIds": [], 73 | "strokeSharpness": "sharp", 74 | "boundElements": [ 75 | { 76 | "id": "Z6s26MPK580hqYyK90pew", 77 | "type": "text" 78 | }, 79 | { 80 | "id": "ubPLCeytW-WtHtROMn-z-", 81 | "type": "arrow" 82 | }, 83 | { 84 | "id": "lFjMuooqJRH_tC-baiLWg", 85 | "type": "arrow" 86 | }, 87 | { 88 | "type": "text", 89 | "id": "Z6s26MPK580hqYyK90pew" 90 | }, 91 | { 92 | "id": "mZHlYy-komb4fnj2QQcQz", 93 | "type": "arrow" 94 | } 95 | ], 96 | "updated": 1653343911759, 97 | "link": null, 98 | "locked": false 99 | }, 100 | { 101 | "type": "rectangle", 102 | "version": 633, 103 | "versionNonce": 489874254, 104 | "isDeleted": false, 105 | "id": "zE2kZToqpRCv8_zhZfnGJ", 106 | "fillStyle": "hachure", 107 | "strokeWidth": 1, 108 | "strokeStyle": "solid", 109 | "roughness": 1, 110 | "opacity": 100, 111 | "angle": 0, 112 | "x": 904.0514526367188, 113 | "y": 223.24490356445312, 114 | "strokeColor": "#000000", 115 | "backgroundColor": "transparent", 116 | "width": 175, 117 | "height": 81, 118 | "seed": 1900842251, 119 | "groupIds": [], 120 | "strokeSharpness": "sharp", 121 | "boundElements": [ 122 | { 123 | "id": "wq6Uy5H_birF1lboudQJu", 124 | "type": "text" 125 | }, 126 | { 127 | "id": "ubPLCeytW-WtHtROMn-z-", 128 | "type": "arrow" 129 | }, 130 | { 131 | "id": "lFjMuooqJRH_tC-baiLWg", 132 | "type": "arrow" 133 | }, 134 | { 135 | "id": "wq6Uy5H_birF1lboudQJu", 136 | "type": "text" 137 | }, 138 | { 139 | "id": "mZHlYy-komb4fnj2QQcQz", 140 | "type": "arrow" 141 | }, 142 | { 143 | "type": "text", 144 | "id": "wq6Uy5H_birF1lboudQJu" 145 | }, 146 | { 147 | "id": "-_8O-APgNwfF234BbM1xn", 148 | "type": "arrow" 149 | } 150 | ], 151 | "updated": 1653343911759, 152 | "link": null, 153 | "locked": false 154 | }, 155 | { 156 | "type": "rectangle", 157 | "version": 318, 158 | "versionNonce": 777666706, 159 | "isDeleted": false, 160 | "id": "9SCbJACOqMaHOgN6E5kyp", 161 | "fillStyle": "hachure", 162 | "strokeWidth": 1, 163 | "strokeStyle": "solid", 164 | "roughness": 1, 165 | "opacity": 100, 166 | "angle": 0, 167 | "x": 529.1781616210938, 168 | "y": 420.8743591308594, 169 | "strokeColor": "#000000", 170 | "backgroundColor": "transparent", 171 | "width": 175, 172 | "height": 81, 173 | "seed": 331943909, 174 | "groupIds": [], 175 | "strokeSharpness": "sharp", 176 | "boundElements": [ 177 | { 178 | "id": "KySQqQXTME6CZOkwKDovF", 179 | "type": "text" 180 | }, 181 | { 182 | "id": "ubPLCeytW-WtHtROMn-z-", 183 | "type": "arrow" 184 | }, 185 | { 186 | "id": "lFjMuooqJRH_tC-baiLWg", 187 | "type": "arrow" 188 | }, 189 | { 190 | "type": "text", 191 | "id": "KySQqQXTME6CZOkwKDovF" 192 | } 193 | ], 194 | "updated": 1653343911760, 195 | "link": null, 196 | "locked": false 197 | }, 198 | { 199 | "type": "rectangle", 200 | "version": 348, 201 | "versionNonce": 735398286, 202 | "isDeleted": false, 203 | "id": "H3SPXOoph8lpCWyMXQDj4", 204 | "fillStyle": "hachure", 205 | "strokeWidth": 1, 206 | "strokeStyle": "solid", 207 | "roughness": 1, 208 | "opacity": 100, 209 | "angle": 0, 210 | "x": 1214.4671020507812, 211 | "y": 420.8743591308594, 212 | "strokeColor": "#000000", 213 | "backgroundColor": "transparent", 214 | "width": 175, 215 | "height": 81, 216 | "seed": 943223211, 217 | "groupIds": [], 218 | "strokeSharpness": "sharp", 219 | "boundElements": [ 220 | { 221 | "id": "4qMAWdCvqFHoAA2_X6yAJ", 222 | "type": "text" 223 | }, 224 | { 225 | "type": "text", 226 | "id": "4qMAWdCvqFHoAA2_X6yAJ" 227 | }, 228 | { 229 | "id": "ubPLCeytW-WtHtROMn-z-", 230 | "type": "arrow" 231 | } 232 | ], 233 | "updated": 1653343911760, 234 | "link": null, 235 | "locked": false 236 | }, 237 | { 238 | "type": "text", 239 | "version": 72, 240 | "versionNonce": 505962066, 241 | "isDeleted": false, 242 | "id": "k_ei4Ez5SMenK44QJ3Bqh", 243 | "fillStyle": "hachure", 244 | "strokeWidth": 1, 245 | "strokeStyle": "solid", 246 | "roughness": 1, 247 | "opacity": 100, 248 | "angle": 0, 249 | "x": 908.8056030273438, 250 | "y": 448.8743591308594, 251 | "strokeColor": "#000000", 252 | "backgroundColor": "transparent", 253 | "width": 165, 254 | "height": 25, 255 | "seed": 1694971877, 256 | "groupIds": [], 257 | "strokeSharpness": "sharp", 258 | "boundElements": [], 259 | "updated": 1653343911760, 260 | "link": null, 261 | "locked": false, 262 | "fontSize": 20, 263 | "fontFamily": 1, 264 | "text": "Web Application", 265 | "baseline": 18, 266 | "textAlign": "center", 267 | "verticalAlign": "middle", 268 | "containerId": "osuVftQFVdF5nShmylU4K", 269 | "originalText": "Web Application" 270 | }, 271 | { 272 | "type": "text", 273 | "version": 254, 274 | "versionNonce": 2110842830, 275 | "isDeleted": false, 276 | "id": "Z6s26MPK580hqYyK90pew", 277 | "fillStyle": "hachure", 278 | "strokeWidth": 1, 279 | "strokeStyle": "solid", 280 | "roughness": 1, 281 | "opacity": 100, 282 | "angle": 0, 283 | "x": 909.0514526367188, 284 | "y": 680.8469848632812, 285 | "strokeColor": "#000000", 286 | "backgroundColor": "transparent", 287 | "width": 165, 288 | "height": 25, 289 | "seed": 1313013579, 290 | "groupIds": [], 291 | "strokeSharpness": "sharp", 292 | "boundElements": [], 293 | "updated": 1653343911760, 294 | "link": null, 295 | "locked": false, 296 | "fontSize": 20, 297 | "fontFamily": 1, 298 | "text": "EXTERNAL API", 299 | "baseline": 18, 300 | "textAlign": "center", 301 | "verticalAlign": "middle", 302 | "containerId": "8BsUEe76GjAhuqnGj4AHh", 303 | "originalText": "EXTERNAL API" 304 | }, 305 | { 306 | "type": "text", 307 | "version": 593, 308 | "versionNonce": 837600274, 309 | "isDeleted": false, 310 | "id": "wq6Uy5H_birF1lboudQJu", 311 | "fillStyle": "hachure", 312 | "strokeWidth": 1, 313 | "strokeStyle": "solid", 314 | "roughness": 1, 315 | "opacity": 100, 316 | "angle": 0, 317 | "x": 909.0514526367188, 318 | "y": 238.74490356445312, 319 | "strokeColor": "#000000", 320 | "backgroundColor": "transparent", 321 | "width": 165, 322 | "height": 50, 323 | "seed": 22469925, 324 | "groupIds": [], 325 | "strokeSharpness": "sharp", 326 | "boundElements": [], 327 | "updated": 1653343911760, 328 | "link": null, 329 | "locked": false, 330 | "fontSize": 20, 331 | "fontFamily": 1, 332 | "text": "IDENTITY \nPROVIDER", 333 | "baseline": 43, 334 | "textAlign": "center", 335 | "verticalAlign": "middle", 336 | "containerId": "zE2kZToqpRCv8_zhZfnGJ", 337 | "originalText": "IDENTITY PROVIDER" 338 | }, 339 | { 340 | "type": "text", 341 | "version": 261, 342 | "versionNonce": 1128185358, 343 | "isDeleted": false, 344 | "id": "KySQqQXTME6CZOkwKDovF", 345 | "fillStyle": "hachure", 346 | "strokeWidth": 1, 347 | "strokeStyle": "solid", 348 | "roughness": 1, 349 | "opacity": 100, 350 | "angle": 0, 351 | "x": 534.1781616210938, 352 | "y": 448.8743591308594, 353 | "strokeColor": "#000000", 354 | "backgroundColor": "transparent", 355 | "width": 165, 356 | "height": 25, 357 | "seed": 888933611, 358 | "groupIds": [], 359 | "strokeSharpness": "sharp", 360 | "boundElements": [], 361 | "updated": 1653343911760, 362 | "link": null, 363 | "locked": false, 364 | "fontSize": 20, 365 | "fontFamily": 1, 366 | "text": "Browser (User)", 367 | "baseline": 18, 368 | "textAlign": "center", 369 | "verticalAlign": "middle", 370 | "containerId": "9SCbJACOqMaHOgN6E5kyp", 371 | "originalText": "Browser (User)" 372 | }, 373 | { 374 | "type": "text", 375 | "version": 286, 376 | "versionNonce": 597586386, 377 | "isDeleted": false, 378 | "id": "4qMAWdCvqFHoAA2_X6yAJ", 379 | "fillStyle": "hachure", 380 | "strokeWidth": 1, 381 | "strokeStyle": "solid", 382 | "roughness": 1, 383 | "opacity": 100, 384 | "angle": 0, 385 | "x": 1219.4671020507812, 386 | "y": 436.3743591308594, 387 | "strokeColor": "#000000", 388 | "backgroundColor": "transparent", 389 | "width": 165, 390 | "height": 50, 391 | "seed": 1526796933, 392 | "groupIds": [], 393 | "strokeSharpness": "sharp", 394 | "boundElements": [], 395 | "updated": 1653343911760, 396 | "link": null, 397 | "locked": false, 398 | "fontSize": 20, 399 | "fontFamily": 1, 400 | "text": "Postgres \nDatabase", 401 | "baseline": 43, 402 | "textAlign": "center", 403 | "verticalAlign": "middle", 404 | "containerId": "H3SPXOoph8lpCWyMXQDj4", 405 | "originalText": "Postgres Database" 406 | }, 407 | { 408 | "type": "arrow", 409 | "version": 202, 410 | "versionNonce": 1092078670, 411 | "isDeleted": false, 412 | "id": "ubPLCeytW-WtHtROMn-z-", 413 | "fillStyle": "hachure", 414 | "strokeWidth": 1, 415 | "strokeStyle": "solid", 416 | "roughness": 1, 417 | "opacity": 100, 418 | "angle": 0, 419 | "x": 1083.3376644564964, 420 | "y": 461.58788743573433, 421 | "strokeColor": "#000000", 422 | "backgroundColor": "transparent", 423 | "width": 125.73093905912856, 424 | "height": 0.25981546208760165, 425 | "seed": 191886411, 426 | "groupIds": [], 427 | "strokeSharpness": "round", 428 | "boundElements": [], 429 | "updated": 1653343911760, 430 | "link": null, 431 | "locked": false, 432 | "startBinding": { 433 | "elementId": "osuVftQFVdF5nShmylU4K", 434 | "focus": 0.0005739697641680151, 435 | "gap": 4.532061429152691 436 | }, 437 | "endBinding": { 438 | "elementId": "H3SPXOoph8lpCWyMXQDj4", 439 | "focus": -0.016354465357494363, 440 | "gap": 5.39849853515625 441 | }, 442 | "lastCommittedPoint": null, 443 | "startArrowhead": "arrow", 444 | "endArrowhead": "arrow", 445 | "points": [ 446 | [ 447 | 0, 448 | 0 449 | ], 450 | [ 451 | 125.73093905912856, 452 | 0.25981546208760165 453 | ] 454 | ] 455 | }, 456 | { 457 | "type": "text", 458 | "version": 69, 459 | "versionNonce": 1448372114, 460 | "isDeleted": false, 461 | "id": "zjws7AhYzLZadnRCrdVVt", 462 | "fillStyle": "hachure", 463 | "strokeWidth": 1, 464 | "strokeStyle": "solid", 465 | "roughness": 1, 466 | "opacity": 100, 467 | "angle": 0, 468 | "x": 1090.8538818359375, 469 | "y": 418.0213623046875, 470 | "strokeColor": "#000000", 471 | "backgroundColor": "transparent", 472 | "width": 114, 473 | "height": 25, 474 | "seed": 413282021, 475 | "groupIds": [], 476 | "strokeSharpness": "sharp", 477 | "boundElements": [ 478 | { 479 | "id": "ubPLCeytW-WtHtROMn-z-", 480 | "type": "arrow" 481 | } 482 | ], 483 | "updated": 1653343911760, 484 | "link": null, 485 | "locked": false, 486 | "fontSize": 20, 487 | "fontFamily": 1, 488 | "text": "TLS//5432", 489 | "baseline": 18, 490 | "textAlign": "left", 491 | "verticalAlign": "top", 492 | "containerId": null, 493 | "originalText": "TLS//5432" 494 | }, 495 | { 496 | "type": "text", 497 | "version": 198, 498 | "versionNonce": 892670606, 499 | "isDeleted": false, 500 | "id": "d1iMNkpw8-zZfq0jz-j8T", 501 | "fillStyle": "hachure", 502 | "strokeWidth": 1, 503 | "strokeStyle": "solid", 504 | "roughness": 1, 505 | "opacity": 100, 506 | "angle": 0, 507 | "x": 1014.624755859375, 508 | "y": 568.7504577636719, 509 | "strokeColor": "#000000", 510 | "backgroundColor": "transparent", 511 | "width": 116, 512 | "height": 25, 513 | "seed": 1991527749, 514 | "groupIds": [], 515 | "strokeSharpness": "sharp", 516 | "boundElements": [], 517 | "updated": 1653343911760, 518 | "link": null, 519 | "locked": false, 520 | "fontSize": 20, 521 | "fontFamily": 1, 522 | "text": "MTLS//443", 523 | "baseline": 18, 524 | "textAlign": "left", 525 | "verticalAlign": "top", 526 | "containerId": null, 527 | "originalText": "MTLS//443" 528 | }, 529 | { 530 | "type": "text", 531 | "version": 477, 532 | "versionNonce": 843425106, 533 | "isDeleted": false, 534 | "id": "w_-eh9O_m5LCqANcfAu99", 535 | "fillStyle": "hachure", 536 | "strokeWidth": 1, 537 | "strokeStyle": "solid", 538 | "roughness": 1, 539 | "opacity": 100, 540 | "angle": 0, 541 | "x": 740.4722900390625, 542 | "y": 418.0213623046875, 543 | "strokeColor": "#000000", 544 | "backgroundColor": "transparent", 545 | "width": 129, 546 | "height": 25, 547 | "seed": 682858245, 548 | "groupIds": [], 549 | "strokeSharpness": "sharp", 550 | "boundElements": [], 551 | "updated": 1653343911760, 552 | "link": null, 553 | "locked": false, 554 | "fontSize": 20, 555 | "fontFamily": 1, 556 | "text": "HTTPS//443", 557 | "baseline": 18, 558 | "textAlign": "left", 559 | "verticalAlign": "top", 560 | "containerId": null, 561 | "originalText": "HTTPS//443" 562 | }, 563 | { 564 | "type": "text", 565 | "version": 658, 566 | "versionNonce": 978292942, 567 | "isDeleted": false, 568 | "id": "O43-_6d7lFPL9SGRU4aqu", 569 | "fillStyle": "hachure", 570 | "strokeWidth": 1, 571 | "strokeStyle": "solid", 572 | "roughness": 1, 573 | "opacity": 100, 574 | "angle": 0, 575 | "x": 845.58447265625, 576 | "y": 333.007568359375, 577 | "strokeColor": "#000000", 578 | "backgroundColor": "transparent", 579 | "width": 129, 580 | "height": 25, 581 | "seed": 2054951749, 582 | "groupIds": [], 583 | "strokeSharpness": "sharp", 584 | "boundElements": [], 585 | "updated": 1653343911760, 586 | "link": null, 587 | "locked": false, 588 | "fontSize": 20, 589 | "fontFamily": 1, 590 | "text": "HTTPS//443", 591 | "baseline": 18, 592 | "textAlign": "left", 593 | "verticalAlign": "top", 594 | "containerId": null, 595 | "originalText": "HTTPS//443" 596 | }, 597 | { 598 | "type": "arrow", 599 | "version": 492, 600 | "versionNonce": 13183762, 601 | "isDeleted": false, 602 | "id": "lFjMuooqJRH_tC-baiLWg", 603 | "fillStyle": "hachure", 604 | "strokeWidth": 1, 605 | "strokeStyle": "solid", 606 | "roughness": 1, 607 | "opacity": 100, 608 | "angle": 0, 609 | "x": 902.8056030273438, 610 | "y": 463.7413985950944, 611 | "strokeColor": "#000000", 612 | "backgroundColor": "transparent", 613 | "width": 190.61962890625, 614 | "height": 2.0441047251352416, 615 | "seed": 139915755, 616 | "groupIds": [], 617 | "strokeSharpness": "round", 618 | "boundElements": [], 619 | "updated": 1653343911760, 620 | "link": null, 621 | "locked": false, 622 | "startBinding": { 623 | "elementId": "osuVftQFVdF5nShmylU4K", 624 | "focus": -0.07957831176212558, 625 | "gap": 1 626 | }, 627 | "endBinding": { 628 | "elementId": "9SCbJACOqMaHOgN6E5kyp", 629 | "focus": -0.01225706517438956, 630 | "gap": 8.0078125 631 | }, 632 | "lastCommittedPoint": null, 633 | "startArrowhead": "arrow", 634 | "endArrowhead": "arrow", 635 | "points": [ 636 | [ 637 | 0, 638 | 0 639 | ], 640 | [ 641 | -190.61962890625, 642 | -2.0441047251352416 643 | ] 644 | ] 645 | }, 646 | { 647 | "type": "rectangle", 648 | "version": 1186, 649 | "versionNonce": 816059787, 650 | "isDeleted": false, 651 | "id": "VL08bzihxhlmPa0JnpZ0X", 652 | "fillStyle": "hachure", 653 | "strokeWidth": 1, 654 | "strokeStyle": "dashed", 655 | "roughness": 2, 656 | "opacity": 100, 657 | "angle": 0, 658 | "x": 868.4284057617188, 659 | "y": 377.3962097167969, 660 | "strokeColor": "#aaaaaa", 661 | "backgroundColor": "transparent", 662 | "width": 554.40283203125, 663 | "height": 163.62847900390625, 664 | "seed": 1447169349, 665 | "groupIds": [], 666 | "strokeSharpness": "sharp", 667 | "boundElements": [ 668 | { 669 | "id": "-5ovmL1ulpfWBnHHrOCGL", 670 | "type": "arrow" 671 | } 672 | ], 673 | "updated": 1661478062881, 674 | "link": null, 675 | "locked": false 676 | }, 677 | { 678 | "type": "text", 679 | "version": 566, 680 | "versionNonce": 1455034898, 681 | "isDeleted": false, 682 | "id": "JE_dURViiTcIsz4cXpZ52", 683 | "fillStyle": "hachure", 684 | "strokeWidth": 1, 685 | "strokeStyle": "dotted", 686 | "roughness": 1, 687 | "opacity": 100, 688 | "angle": 0, 689 | "x": 1141.1515502929688, 690 | "y": 335.9356994628906, 691 | "strokeColor": "#aaaaaa", 692 | "backgroundColor": "transparent", 693 | "width": 269, 694 | "height": 25, 695 | "seed": 1122335909, 696 | "groupIds": [], 697 | "strokeSharpness": "sharp", 698 | "boundElements": [], 699 | "updated": 1653343922482, 700 | "link": null, 701 | "locked": false, 702 | "fontSize": 20, 703 | "fontFamily": 1, 704 | "text": "Product (System) Boundary", 705 | "baseline": 18, 706 | "textAlign": "left", 707 | "verticalAlign": "top", 708 | "containerId": null, 709 | "originalText": "Product (System) Boundary" 710 | }, 711 | { 712 | "type": "arrow", 713 | "version": 184, 714 | "versionNonce": 180368718, 715 | "isDeleted": false, 716 | "id": "mZHlYy-komb4fnj2QQcQz", 717 | "fillStyle": "hachure", 718 | "strokeWidth": 1, 719 | "strokeStyle": "solid", 720 | "roughness": 1, 721 | "opacity": 100, 722 | "angle": 0, 723 | "x": 990.2920932758921, 724 | "y": 508.5739229656198, 725 | "strokeColor": "#000000", 726 | "backgroundColor": "transparent", 727 | "width": 2.2166225595100286, 728 | "height": 141.18511023750523, 729 | "seed": 1624527045, 730 | "groupIds": [], 731 | "strokeSharpness": "round", 732 | "boundElements": [], 733 | "updated": 1653343911760, 734 | "link": null, 735 | "locked": false, 736 | "startBinding": { 737 | "elementId": "osuVftQFVdF5nShmylU4K", 738 | "focus": 0.01991449933088067, 739 | "gap": 6.753122184369772 740 | }, 741 | "endBinding": { 742 | "elementId": "8BsUEe76GjAhuqnGj4AHh", 743 | "focus": 0.018625780470417994, 744 | "gap": 3.08795166015625 745 | }, 746 | "lastCommittedPoint": null, 747 | "startArrowhead": "arrow", 748 | "endArrowhead": "arrow", 749 | "points": [ 750 | [ 751 | 0, 752 | 0 753 | ], 754 | [ 755 | 2.2166225595100286, 756 | 141.18511023750523 757 | ] 758 | ] 759 | }, 760 | { 761 | "type": "arrow", 762 | "version": 141, 763 | "versionNonce": 679677586, 764 | "isDeleted": false, 765 | "id": "-_8O-APgNwfF234BbM1xn", 766 | "fillStyle": "hachure", 767 | "strokeWidth": 1, 768 | "strokeStyle": "solid", 769 | "roughness": 1, 770 | "opacity": 100, 771 | "angle": 0, 772 | "x": 990.6573298483156, 773 | "y": 417.60205359736455, 774 | "strokeColor": "#000000", 775 | "backgroundColor": "transparent", 776 | "width": 0.021587660815612253, 777 | "height": 112.23935218134892, 778 | "seed": 1354940325, 779 | "groupIds": [], 780 | "strokeSharpness": "round", 781 | "boundElements": [], 782 | "updated": 1653343911760, 783 | "link": null, 784 | "locked": false, 785 | "startBinding": { 786 | "elementId": "osuVftQFVdF5nShmylU4K", 787 | "focus": -0.007311968392463077, 788 | "gap": 3.27230553349483 789 | }, 790 | "endBinding": { 791 | "elementId": "zE2kZToqpRCv8_zhZfnGJ", 792 | "focus": 0.010555803677278677, 793 | "gap": 1.1177978515625 794 | }, 795 | "lastCommittedPoint": null, 796 | "startArrowhead": "arrow", 797 | "endArrowhead": "arrow", 798 | "points": [ 799 | [ 800 | 0, 801 | 0 802 | ], 803 | [ 804 | -0.021587660815612253, 805 | -112.23935218134892 806 | ] 807 | ] 808 | }, 809 | { 810 | "id": "-5ovmL1ulpfWBnHHrOCGL", 811 | "type": "arrow", 812 | "x": 1411.4772772270012, 813 | "y": 632.0707244873047, 814 | "width": 84.50389424026457, 815 | "height": 86.86730957031239, 816 | "angle": 0, 817 | "strokeColor": "#000000", 818 | "backgroundColor": "transparent", 819 | "fillStyle": "hachure", 820 | "strokeWidth": 1, 821 | "strokeStyle": "solid", 822 | "roughness": 2, 823 | "opacity": 100, 824 | "groupIds": [], 825 | "strokeSharpness": "round", 826 | "seed": 1320910501, 827 | "version": 280, 828 | "versionNonce": 190868555, 829 | "isDeleted": false, 830 | "boundElements": null, 831 | "updated": 1661478045071, 832 | "link": null, 833 | "locked": false, 834 | "points": [ 835 | [ 836 | 0, 837 | 0 838 | ], 839 | [ 840 | -84.50389424026457, 841 | -86.86730957031239 842 | ] 843 | ], 844 | "lastCommittedPoint": null, 845 | "startBinding": { 846 | "elementId": "CTEpP2PqVuaEwTVHY-kT9", 847 | "focus": 0.19736639538844972, 848 | "gap": 9.06170654296875 849 | }, 850 | "endBinding": { 851 | "elementId": "VL08bzihxhlmPa0JnpZ0X", 852 | "focus": -0.2738033550861045, 853 | "gap": 4.178726196289176 854 | }, 855 | "startArrowhead": null, 856 | "endArrowhead": "arrow" 857 | }, 858 | { 859 | "id": "CTEpP2PqVuaEwTVHY-kT9", 860 | "type": "text", 861 | "x": 1272.9607543945312, 862 | "y": 641.1324310302734, 863 | "width": 295, 864 | "height": 75, 865 | "angle": 0, 866 | "strokeColor": "#000000", 867 | "backgroundColor": "transparent", 868 | "fillStyle": "hachure", 869 | "strokeWidth": 1, 870 | "strokeStyle": "solid", 871 | "roughness": 2, 872 | "opacity": 100, 873 | "groupIds": [], 874 | "strokeSharpness": "sharp", 875 | "seed": 356860043, 876 | "version": 120, 877 | "versionNonce": 1959326187, 878 | "isDeleted": false, 879 | "boundElements": [ 880 | { 881 | "id": "-5ovmL1ulpfWBnHHrOCGL", 882 | "type": "arrow" 883 | } 884 | ], 885 | "updated": 1661478038242, 886 | "link": null, 887 | "locked": false, 888 | "text": "We're responsible for managing\nthe risk of systems inside\nthe boundary", 889 | "fontSize": 20, 890 | "fontFamily": 1, 891 | "textAlign": "left", 892 | "verticalAlign": "top", 893 | "baseline": 68, 894 | "containerId": null, 895 | "originalText": "We're responsible for managing\nthe risk of systems inside\nthe boundary" 896 | } 897 | ], 898 | "appState": { 899 | "gridSize": null, 900 | "viewBackgroundColor": "#ffffff" 901 | }, 902 | "files": {} 903 | } -------------------------------------------------------------------------------- /docs/diagrams/boundary.excalidraw: -------------------------------------------------------------------------------- 1 | { 2 | "type": "excalidraw", 3 | "version": 2, 4 | "source": "https://excalidraw.com", 5 | "elements": [ 6 | { 7 | "type": "rectangle", 8 | "version": 806, 9 | "versionNonce": 1182031699, 10 | "isDeleted": false, 11 | "id": "HNkMGcVnK-wUfVxfBacEW", 12 | "fillStyle": "hachure", 13 | "strokeWidth": 1, 14 | "strokeStyle": "solid", 15 | "roughness": 1, 16 | "opacity": 100, 17 | "angle": 0, 18 | "x": 427.949462890625, 19 | "y": 504.3445739746094, 20 | "strokeColor": "#000000", 21 | "backgroundColor": "transparent", 22 | "width": 188.1015625, 23 | "height": 99.72448730468749, 24 | "seed": 1273454524, 25 | "groupIds": [], 26 | "frameId": null, 27 | "roundness": null, 28 | "boundElements": [ 29 | { 30 | "type": "text", 31 | "id": "HwWnPPhotTd6af2VmiLDB" 32 | }, 33 | { 34 | "id": "61RZkX3nr_p5tVRagBYZ8", 35 | "type": "arrow" 36 | } 37 | ], 38 | "updated": 1698357327132, 39 | "link": null, 40 | "locked": false 41 | }, 42 | { 43 | "type": "rectangle", 44 | "version": 904, 45 | "versionNonce": 1359098717, 46 | "isDeleted": false, 47 | "id": "c44rf-QJuCNKQmzt4jRyQ", 48 | "fillStyle": "hachure", 49 | "strokeWidth": 1, 50 | "strokeStyle": "solid", 51 | "roughness": 1, 52 | "opacity": 100, 53 | "angle": 0, 54 | "x": 427.949462890625, 55 | "y": 669.6751708984375, 56 | "strokeColor": "#000000", 57 | "backgroundColor": "transparent", 58 | "width": 188.1015625, 59 | "height": 99.72448730468749, 60 | "seed": 1020740475, 61 | "groupIds": [], 62 | "frameId": null, 63 | "roundness": null, 64 | "boundElements": [ 65 | { 66 | "id": "T1Ez9N-2b0Kg57R0QfMV6", 67 | "type": "text" 68 | }, 69 | { 70 | "id": "61RZkX3nr_p5tVRagBYZ8", 71 | "type": "arrow" 72 | }, 73 | { 74 | "id": "qOAFq63qgarB7oTtPltQd", 75 | "type": "arrow" 76 | } 77 | ], 78 | "updated": 1698357327132, 79 | "link": null, 80 | "locked": false 81 | }, 82 | { 83 | "type": "rectangle", 84 | "version": 848, 85 | "versionNonce": 1576205555, 86 | "isDeleted": false, 87 | "id": "PTNJ5h20Um60-r1LHZ6kK", 88 | "fillStyle": "hachure", 89 | "strokeWidth": 1, 90 | "strokeStyle": "solid", 91 | "roughness": 1, 92 | "opacity": 100, 93 | "angle": 0, 94 | "x": 768.2563781738281, 95 | "y": 669.6455688476562, 96 | "strokeColor": "#000000", 97 | "backgroundColor": "transparent", 98 | "width": 400, 99 | "height": 100, 100 | "seed": 1592490172, 101 | "groupIds": [], 102 | "frameId": null, 103 | "roundness": null, 104 | "boundElements": [ 105 | { 106 | "id": "VYUQgMZSI9JbTEFnbOkcO", 107 | "type": "text" 108 | }, 109 | { 110 | "id": "ottOICHhl1SbIV6GcSpgL", 111 | "type": "arrow" 112 | }, 113 | { 114 | "id": "68OiNQBi_v3ZG8pn7UDfK", 115 | "type": "arrow" 116 | }, 117 | { 118 | "id": "-W8Snv91xYNAhRQgSnCV0", 119 | "type": "arrow" 120 | }, 121 | { 122 | "id": "qOAFq63qgarB7oTtPltQd", 123 | "type": "arrow" 124 | } 125 | ], 126 | "updated": 1698357327132, 127 | "link": null, 128 | "locked": false 129 | }, 130 | { 131 | "type": "rectangle", 132 | "version": 883, 133 | "versionNonce": 1935927389, 134 | "isDeleted": false, 135 | "id": "32YCrhnS_a4Fd0r-WsHmO", 136 | "fillStyle": "hachure", 137 | "strokeWidth": 1, 138 | "strokeStyle": "solid", 139 | "roughness": 1, 140 | "opacity": 100, 141 | "angle": 0, 142 | "x": 768.1597595214844, 143 | "y": 904.5863952636719, 144 | "strokeColor": "#000000", 145 | "backgroundColor": "transparent", 146 | "width": 400, 147 | "height": 100, 148 | "seed": 1054668804, 149 | "groupIds": [], 150 | "frameId": null, 151 | "roundness": null, 152 | "boundElements": [ 153 | { 154 | "id": "VDgzkE0tl__0Tg6KfgM5i", 155 | "type": "text" 156 | }, 157 | { 158 | "id": "68OiNQBi_v3ZG8pn7UDfK", 159 | "type": "arrow" 160 | } 161 | ], 162 | "updated": 1698357507460, 163 | "link": null, 164 | "locked": false 165 | }, 166 | { 167 | "type": "rectangle", 168 | "version": 1201, 169 | "versionNonce": 1930225299, 170 | "isDeleted": false, 171 | "id": "9pVXe2avVVk75FCo08uas", 172 | "fillStyle": "hachure", 173 | "strokeWidth": 1, 174 | "strokeStyle": "solid", 175 | "roughness": 1, 176 | "opacity": 100, 177 | "angle": 0, 178 | "x": 769.7563781738281, 179 | "y": 504.5608215332031, 180 | "strokeColor": "#000000", 181 | "backgroundColor": "transparent", 182 | "width": 397, 183 | "height": 100, 184 | "seed": 165210628, 185 | "groupIds": [], 186 | "frameId": null, 187 | "roundness": null, 188 | "boundElements": [ 189 | { 190 | "id": "izolZJmQwDnx5XDT-oXn9", 191 | "type": "text" 192 | }, 193 | { 194 | "id": "4XnKy79EIs9gpeAO_VUQw", 195 | "type": "arrow" 196 | }, 197 | { 198 | "id": "ottOICHhl1SbIV6GcSpgL", 199 | "type": "arrow" 200 | }, 201 | { 202 | "id": "61RZkX3nr_p5tVRagBYZ8", 203 | "type": "arrow" 204 | }, 205 | { 206 | "id": "7Bi62pgRnYYTirIaYXler", 207 | "type": "arrow" 208 | } 209 | ], 210 | "updated": 1698357327132, 211 | "link": null, 212 | "locked": false 213 | }, 214 | { 215 | "type": "rectangle", 216 | "version": 1438, 217 | "versionNonce": 1032372253, 218 | "isDeleted": false, 219 | "id": "LLTTYdYTyIxWPlIhAltpl", 220 | "fillStyle": "hachure", 221 | "strokeWidth": 1, 222 | "strokeStyle": "solid", 223 | "roughness": 1, 224 | "opacity": 100, 225 | "angle": 0, 226 | "x": 768.7563781738281, 227 | "y": 339.47601318359375, 228 | "strokeColor": "#000000", 229 | "backgroundColor": "transparent", 230 | "width": 399, 231 | "height": 100, 232 | "seed": 636862524, 233 | "groupIds": [], 234 | "frameId": null, 235 | "roundness": null, 236 | "boundElements": [ 237 | { 238 | "id": "9CD5xE0DrkNeLgiENkFQ_", 239 | "type": "text" 240 | }, 241 | { 242 | "id": "4XnKy79EIs9gpeAO_VUQw", 243 | "type": "arrow" 244 | } 245 | ], 246 | "updated": 1698357327132, 247 | "link": null, 248 | "locked": false 249 | }, 250 | { 251 | "type": "text", 252 | "version": 733, 253 | "versionNonce": 1282972723, 254 | "isDeleted": false, 255 | "id": "HwWnPPhotTd6af2VmiLDB", 256 | "fillStyle": "hachure", 257 | "strokeWidth": 1, 258 | "strokeStyle": "solid", 259 | "roughness": 1, 260 | "opacity": 100, 261 | "angle": 0, 262 | "x": 444.46031188964844, 263 | "y": 529.2068176269531, 264 | "strokeColor": "#000000", 265 | "backgroundColor": "transparent", 266 | "width": 155.07986450195312, 267 | "height": 50, 268 | "seed": 1737648644, 269 | "groupIds": [], 270 | "frameId": null, 271 | "roundness": null, 272 | "boundElements": [], 273 | "updated": 1698357327132, 274 | "link": null, 275 | "locked": false, 276 | "fontSize": 20, 277 | "fontFamily": 1, 278 | "text": "Version Control \nSystem (VCS)", 279 | "textAlign": "center", 280 | "verticalAlign": "middle", 281 | "containerId": "HNkMGcVnK-wUfVxfBacEW", 282 | "originalText": "Version Control System (VCS)", 283 | "lineHeight": 1.25, 284 | "baseline": 42 285 | }, 286 | { 287 | "type": "text", 288 | "version": 815, 289 | "versionNonce": 1242870909, 290 | "isDeleted": false, 291 | "id": "T1Ez9N-2b0Kg57R0QfMV6", 292 | "fillStyle": "hachure", 293 | "strokeWidth": 1, 294 | "strokeStyle": "solid", 295 | "roughness": 1, 296 | "opacity": 100, 297 | "angle": 0, 298 | "x": 496.0702590942383, 299 | "y": 707.0374145507812, 300 | "strokeColor": "#000000", 301 | "backgroundColor": "transparent", 302 | "width": 51.85997009277344, 303 | "height": 25, 304 | "seed": 298649013, 305 | "groupIds": [], 306 | "frameId": null, 307 | "roundness": null, 308 | "boundElements": [], 309 | "updated": 1698357327132, 310 | "link": null, 311 | "locked": false, 312 | "fontSize": 20, 313 | "fontFamily": 1, 314 | "text": "SIEM", 315 | "textAlign": "center", 316 | "verticalAlign": "middle", 317 | "containerId": "c44rf-QJuCNKQmzt4jRyQ", 318 | "originalText": "SIEM", 319 | "lineHeight": 1.25, 320 | "baseline": 17 321 | }, 322 | { 323 | "type": "text", 324 | "version": 775, 325 | "versionNonce": 987655069, 326 | "isDeleted": false, 327 | "id": "VYUQgMZSI9JbTEFnbOkcO", 328 | "fillStyle": "hachure", 329 | "strokeWidth": 1, 330 | "strokeStyle": "solid", 331 | "roughness": 1, 332 | "opacity": 100, 333 | "angle": 0, 334 | "x": 852.3464889526367, 335 | "y": 707.1455688476562, 336 | "strokeColor": "#000000", 337 | "backgroundColor": "transparent", 338 | "width": 231.8197784423828, 339 | "height": 25, 340 | "seed": 1626669372, 341 | "groupIds": [], 342 | "frameId": null, 343 | "roundness": null, 344 | "boundElements": [], 345 | "updated": 1698357503991, 346 | "link": null, 347 | "locked": false, 348 | "fontSize": 20, 349 | "fontFamily": 1, 350 | "text": "Delivery Infrastructure", 351 | "textAlign": "center", 352 | "verticalAlign": "middle", 353 | "containerId": "PTNJ5h20Um60-r1LHZ6kK", 354 | "originalText": "Delivery Infrastructure", 355 | "lineHeight": 1.25, 356 | "baseline": 17 357 | }, 358 | { 359 | "type": "text", 360 | "version": 871, 361 | "versionNonce": 959321939, 362 | "isDeleted": false, 363 | "id": "VDgzkE0tl__0Tg6KfgM5i", 364 | "fillStyle": "hachure", 365 | "strokeWidth": 1, 366 | "strokeStyle": "solid", 367 | "roughness": 1, 368 | "opacity": 100, 369 | "angle": 0, 370 | "x": 864.0498580932617, 371 | "y": 929.5863952636719, 372 | "strokeColor": "#000000", 373 | "backgroundColor": "transparent", 374 | "width": 208.2198028564453, 375 | "height": 50, 376 | "seed": 1670478396, 377 | "groupIds": [], 378 | "frameId": null, 379 | "roundness": null, 380 | "boundElements": [], 381 | "updated": 1698357510932, 382 | "link": null, 383 | "locked": false, 384 | "fontSize": 20, 385 | "fontFamily": 1, 386 | "text": "Cloud Infrastructure\nProvider", 387 | "textAlign": "center", 388 | "verticalAlign": "middle", 389 | "containerId": "32YCrhnS_a4Fd0r-WsHmO", 390 | "originalText": "Cloud Infrastructure\nProvider", 391 | "lineHeight": 1.25, 392 | "baseline": 42 393 | }, 394 | { 395 | "type": "text", 396 | "version": 1146, 397 | "versionNonce": 990866291, 398 | "isDeleted": false, 399 | "id": "izolZJmQwDnx5XDT-oXn9", 400 | "fillStyle": "hachure", 401 | "strokeWidth": 1, 402 | "strokeStyle": "solid", 403 | "roughness": 1, 404 | "opacity": 100, 405 | "angle": 0, 406 | "x": 774.7563781738281, 407 | "y": 542.0608215332031, 408 | "strokeColor": "#000000", 409 | "backgroundColor": "transparent", 410 | "width": 387, 411 | "height": 25, 412 | "seed": 1275439164, 413 | "groupIds": [], 414 | "frameId": null, 415 | "roundness": null, 416 | "boundElements": [], 417 | "updated": 1698357327132, 418 | "link": null, 419 | "locked": false, 420 | "fontSize": 20, 421 | "fontFamily": 1, 422 | "text": "Secure Release Pipeline", 423 | "textAlign": "center", 424 | "verticalAlign": "middle", 425 | "containerId": "9pVXe2avVVk75FCo08uas", 426 | "originalText": "Secure Release Pipeline", 427 | "lineHeight": 1.25, 428 | "baseline": 17 429 | }, 430 | { 431 | "type": "text", 432 | "version": 1403, 433 | "versionNonce": 1350924605, 434 | "isDeleted": false, 435 | "id": "9CD5xE0DrkNeLgiENkFQ_", 436 | "fillStyle": "hachure", 437 | "strokeWidth": 1, 438 | "strokeStyle": "solid", 439 | "roughness": 1, 440 | "opacity": 100, 441 | "angle": 0, 442 | "x": 773.7563781738281, 443 | "y": 376.97601318359375, 444 | "strokeColor": "#000000", 445 | "backgroundColor": "transparent", 446 | "width": 389, 447 | "height": 25, 448 | "seed": 762474884, 449 | "groupIds": [], 450 | "frameId": null, 451 | "roundness": null, 452 | "boundElements": [], 453 | "updated": 1698357327132, 454 | "link": null, 455 | "locked": false, 456 | "fontSize": 20, 457 | "fontFamily": 1, 458 | "text": "Applications", 459 | "textAlign": "center", 460 | "verticalAlign": "middle", 461 | "containerId": "LLTTYdYTyIxWPlIhAltpl", 462 | "originalText": "Applications", 463 | "lineHeight": 1.25, 464 | "baseline": 17 465 | }, 466 | { 467 | "type": "rectangle", 468 | "version": 680, 469 | "versionNonce": 2140636435, 470 | "isDeleted": false, 471 | "id": "YxvxXnfANVMHL7akQSO5r", 472 | "fillStyle": "hachure", 473 | "strokeWidth": 1, 474 | "strokeStyle": "dashed", 475 | "roughness": 2, 476 | "opacity": 100, 477 | "angle": 0, 478 | "x": 695.6219482421875, 479 | "y": 303.222900390625, 480 | "strokeColor": "#aaaaaa", 481 | "backgroundColor": "transparent", 482 | "width": 543.793212890625, 483 | "height": 523.3718872070314, 484 | "seed": 1571593965, 485 | "groupIds": [], 486 | "frameId": null, 487 | "roundness": null, 488 | "boundElements": [ 489 | { 490 | "id": "HGVXfEl0Z7uZtFzrRUTIk", 491 | "type": "arrow" 492 | } 493 | ], 494 | "updated": 1698357327132, 495 | "link": null, 496 | "locked": false 497 | }, 498 | { 499 | "type": "text", 500 | "version": 237, 501 | "versionNonce": 190663069, 502 | "isDeleted": false, 503 | "id": "CuvJuMyYCeLTXz44sXUuk", 504 | "fillStyle": "hachure", 505 | "strokeWidth": 1, 506 | "strokeStyle": "dashed", 507 | "roughness": 1, 508 | "opacity": 100, 509 | "angle": 0, 510 | "x": 996.0159912109375, 511 | "y": 267.69842529296875, 512 | "strokeColor": "#aaaaaa", 513 | "backgroundColor": "transparent", 514 | "width": 231, 515 | "height": 25, 516 | "seed": 1182146564, 517 | "groupIds": [], 518 | "frameId": null, 519 | "roundness": null, 520 | "boundElements": [], 521 | "updated": 1698357327132, 522 | "link": null, 523 | "locked": false, 524 | "fontSize": 20, 525 | "fontFamily": 1, 526 | "text": "Authorization Boundary", 527 | "textAlign": "left", 528 | "verticalAlign": "top", 529 | "containerId": null, 530 | "originalText": "Authorization Boundary", 531 | "lineHeight": 1.25, 532 | "baseline": 17 533 | }, 534 | { 535 | "type": "arrow", 536 | "version": 216, 537 | "versionNonce": 1529572019, 538 | "isDeleted": false, 539 | "id": "4XnKy79EIs9gpeAO_VUQw", 540 | "fillStyle": "hachure", 541 | "strokeWidth": 1, 542 | "strokeStyle": "solid", 543 | "roughness": 1, 544 | "opacity": 100, 545 | "angle": 0, 546 | "x": 967.8407563841413, 547 | "y": 440.2538597043138, 548 | "strokeColor": "#000000", 549 | "backgroundColor": "transparent", 550 | "width": 1.0017901942272829, 551 | "height": 60.820238505722955, 552 | "seed": 994816388, 553 | "groupIds": [], 554 | "frameId": null, 555 | "roundness": { 556 | "type": 2 557 | }, 558 | "boundElements": [], 559 | "updated": 1698357327132, 560 | "link": null, 561 | "locked": false, 562 | "startBinding": { 563 | "elementId": "LLTTYdYTyIxWPlIhAltpl", 564 | "focus": 0.0062498909022546964, 565 | "gap": 1 566 | }, 567 | "endBinding": { 568 | "elementId": "9pVXe2avVVk75FCo08uas", 569 | "focus": 0.0073607244695083835, 570 | "gap": 3.486723323166359 571 | }, 572 | "lastCommittedPoint": null, 573 | "startArrowhead": "triangle", 574 | "endArrowhead": "triangle", 575 | "points": [ 576 | [ 577 | 0, 578 | 0 579 | ], 580 | [ 581 | 1.0017901942272829, 582 | 60.820238505722955 583 | ] 584 | ] 585 | }, 586 | { 587 | "type": "arrow", 588 | "version": 313, 589 | "versionNonce": 1335627261, 590 | "isDeleted": false, 591 | "id": "ottOICHhl1SbIV6GcSpgL", 592 | "fillStyle": "hachure", 593 | "strokeWidth": 1, 594 | "strokeStyle": "solid", 595 | "roughness": 1, 596 | "opacity": 100, 597 | "angle": 0, 598 | "x": 967.7803820251181, 599 | "y": 605.2161399777513, 600 | "strokeColor": "#000000", 601 | "backgroundColor": "transparent", 602 | "width": 0.9381067427488006, 603 | "height": 61.311876689316705, 604 | "seed": 1179235900, 605 | "groupIds": [], 606 | "frameId": null, 607 | "roundness": { 608 | "type": 2 609 | }, 610 | "boundElements": [], 611 | "updated": 1698357327132, 612 | "link": null, 613 | "locked": false, 614 | "startBinding": { 615 | "elementId": "9pVXe2avVVk75FCo08uas", 616 | "focus": 0.012627239957051235, 617 | "gap": 1 618 | }, 619 | "endBinding": { 620 | "elementId": "PTNJ5h20Um60-r1LHZ6kK", 621 | "focus": 0.000048432843741427474, 622 | "gap": 3.117552180588291 623 | }, 624 | "lastCommittedPoint": null, 625 | "startArrowhead": "triangle", 626 | "endArrowhead": "triangle", 627 | "points": [ 628 | [ 629 | 0, 630 | 0 631 | ], 632 | [ 633 | 0.9381067427488006, 634 | 61.311876689316705 635 | ] 636 | ] 637 | }, 638 | { 639 | "type": "arrow", 640 | "version": 133, 641 | "versionNonce": 309435475, 642 | "isDeleted": false, 643 | "id": "61RZkX3nr_p5tVRagBYZ8", 644 | "fillStyle": "hachure", 645 | "strokeWidth": 1, 646 | "strokeStyle": "solid", 647 | "roughness": 1, 648 | "opacity": 100, 649 | "angle": 0, 650 | "x": 618.804931640625, 651 | "y": 554.9665810880903, 652 | "strokeColor": "#000000", 653 | "backgroundColor": "transparent", 654 | "width": 145.276123046875, 655 | "height": 0.8577620214294939, 656 | "seed": 1574275588, 657 | "groupIds": [], 658 | "frameId": null, 659 | "roundness": { 660 | "type": 2 661 | }, 662 | "boundElements": [], 663 | "updated": 1698357327132, 664 | "link": null, 665 | "locked": false, 666 | "startBinding": { 667 | "elementId": "HNkMGcVnK-wUfVxfBacEW", 668 | "focus": 0.002358324746719733, 669 | "gap": 2.75390625 670 | }, 671 | "endBinding": { 672 | "elementId": "9pVXe2avVVk75FCo08uas", 673 | "focus": -0.04824991718696099, 674 | "gap": 5.675323486328125 675 | }, 676 | "lastCommittedPoint": null, 677 | "startArrowhead": "arrow", 678 | "endArrowhead": "arrow", 679 | "points": [ 680 | [ 681 | 0, 682 | 0 683 | ], 684 | [ 685 | 145.276123046875, 686 | 0.8577620214294939 687 | ] 688 | ] 689 | }, 690 | { 691 | "type": "arrow", 692 | "version": 272, 693 | "versionNonce": 1011041885, 694 | "isDeleted": false, 695 | "id": "qOAFq63qgarB7oTtPltQd", 696 | "fillStyle": "hachure", 697 | "strokeWidth": 1, 698 | "strokeStyle": "solid", 699 | "roughness": 1, 700 | "opacity": 100, 701 | "angle": 0, 702 | "x": 620.5288696289062, 703 | "y": 717.8176553068403, 704 | "strokeColor": "#000000", 705 | "backgroundColor": "transparent", 706 | "width": 145.276123046875, 707 | "height": 0.8577620214294939, 708 | "seed": 63098243, 709 | "groupIds": [], 710 | "frameId": null, 711 | "roundness": { 712 | "type": 2 713 | }, 714 | "boundElements": [], 715 | "updated": 1698357327132, 716 | "link": null, 717 | "locked": false, 718 | "startBinding": { 719 | "elementId": "c44rf-QJuCNKQmzt4jRyQ", 720 | "focus": -0.04564893053357676, 721 | "gap": 4.47784423828125 722 | }, 723 | "endBinding": { 724 | "elementId": "PTNJ5h20Um60-r1LHZ6kK", 725 | "focus": -0.004399957031303045, 726 | "gap": 2.451385498046875 727 | }, 728 | "lastCommittedPoint": null, 729 | "startArrowhead": "arrow", 730 | "endArrowhead": "arrow", 731 | "points": [ 732 | [ 733 | 0, 734 | 0 735 | ], 736 | [ 737 | 145.276123046875, 738 | 0.8577620214294939 739 | ] 740 | ] 741 | }, 742 | { 743 | "type": "arrow", 744 | "version": 102, 745 | "versionNonce": 410421629, 746 | "isDeleted": false, 747 | "id": "68OiNQBi_v3ZG8pn7UDfK", 748 | "fillStyle": "hachure", 749 | "strokeWidth": 1, 750 | "strokeStyle": "solid", 751 | "roughness": 1, 752 | "opacity": 100, 753 | "angle": 0, 754 | "x": 969.4022536869145, 755 | "y": 773.5146484375, 756 | "strokeColor": "#000000", 757 | "backgroundColor": "transparent", 758 | "width": 0.3423552860263044, 759 | "height": 127.332275390625, 760 | "seed": 1197040956, 761 | "groupIds": [], 762 | "frameId": null, 763 | "roundness": { 764 | "type": 2 765 | }, 766 | "boundElements": [], 767 | "updated": 1698357507461, 768 | "link": null, 769 | "locked": false, 770 | "startBinding": { 771 | "elementId": "PTNJ5h20Um60-r1LHZ6kK", 772 | "focus": -0.0048572159655797436, 773 | "gap": 3.86907958984375 774 | }, 775 | "endBinding": { 776 | "elementId": "32YCrhnS_a4Fd0r-WsHmO", 777 | "focus": 0.008640879372815016, 778 | "gap": 3.739471435546875 779 | }, 780 | "lastCommittedPoint": null, 781 | "startArrowhead": "arrow", 782 | "endArrowhead": "arrow", 783 | "points": [ 784 | [ 785 | 0, 786 | 0 787 | ], 788 | [ 789 | 0.3423552860263044, 790 | 127.332275390625 791 | ] 792 | ] 793 | }, 794 | { 795 | "type": "arrow", 796 | "version": 249, 797 | "versionNonce": 1437912307, 798 | "isDeleted": false, 799 | "id": "-W8Snv91xYNAhRQgSnCV0", 800 | "fillStyle": "hachure", 801 | "strokeWidth": 1, 802 | "strokeStyle": "solid", 803 | "roughness": 1, 804 | "opacity": 100, 805 | "angle": 0, 806 | "x": 1311.980712890625, 807 | "y": 701.7575188986908, 808 | "strokeColor": "#000000", 809 | "backgroundColor": "transparent", 810 | "width": 136.44042968749955, 811 | "height": 28.824391666491465, 812 | "seed": 698633348, 813 | "groupIds": [], 814 | "frameId": null, 815 | "roundness": { 816 | "type": 2 817 | }, 818 | "boundElements": [], 819 | "updated": 1698357368822, 820 | "link": null, 821 | "locked": false, 822 | "startBinding": { 823 | "elementId": "tqSpq7jpjBsr9CFzg7WrS", 824 | "focus": 0.5981062673120938, 825 | "gap": 8.4522705078125 826 | }, 827 | "endBinding": { 828 | "elementId": "PTNJ5h20Um60-r1LHZ6kK", 829 | "focus": 0.593235167994937, 830 | "gap": 7.283905029297102 831 | }, 832 | "lastCommittedPoint": null, 833 | "startArrowhead": null, 834 | "endArrowhead": "arrow", 835 | "points": [ 836 | [ 837 | 0, 838 | 0 839 | ], 840 | [ 841 | -136.44042968749955, 842 | 28.824391666491465 843 | ] 844 | ] 845 | }, 846 | { 847 | "type": "arrow", 848 | "version": 211, 849 | "versionNonce": 77521811, 850 | "isDeleted": false, 851 | "id": "7Bi62pgRnYYTirIaYXler", 852 | "fillStyle": "hachure", 853 | "strokeWidth": 1, 854 | "strokeStyle": "solid", 855 | "roughness": 1, 856 | "opacity": 100, 857 | "angle": 0, 858 | "x": 1309.5068359375, 859 | "y": 524.1916462311627, 860 | "strokeColor": "#000000", 861 | "backgroundColor": "transparent", 862 | "width": 136.68627929687477, 863 | "height": 31.417862003796017, 864 | "seed": 1914722052, 865 | "groupIds": [], 866 | "frameId": null, 867 | "roundness": { 868 | "type": 2 869 | }, 870 | "boundElements": [], 871 | "updated": 1698357327132, 872 | "link": null, 873 | "locked": false, 874 | "startBinding": { 875 | "elementId": "YaNRUL8B9xQhseydcg87V", 876 | "focus": 0.7969872883324268, 877 | "gap": 10.9261474609375 878 | }, 879 | "endBinding": { 880 | "elementId": "9pVXe2avVVk75FCo08uas", 881 | "focus": 0.5026724098862194, 882 | "gap": 6.064178466797102 883 | }, 884 | "lastCommittedPoint": null, 885 | "startArrowhead": null, 886 | "endArrowhead": "arrow", 887 | "points": [ 888 | [ 889 | 0, 890 | 0 891 | ], 892 | [ 893 | -136.68627929687477, 894 | 31.417862003796017 895 | ] 896 | ] 897 | }, 898 | { 899 | "type": "text", 900 | "version": 135, 901 | "versionNonce": 840218259, 902 | "isDeleted": false, 903 | "id": "tqSpq7jpjBsr9CFzg7WrS", 904 | "fillStyle": "hachure", 905 | "strokeWidth": 1, 906 | "strokeStyle": "solid", 907 | "roughness": 1, 908 | "opacity": 100, 909 | "angle": 0, 910 | "x": 1320.4329833984375, 911 | "y": 679.9630126953125, 912 | "strokeColor": "#000000", 913 | "backgroundColor": "transparent", 914 | "width": 228.3997802734375, 915 | "height": 50, 916 | "seed": 142198076, 917 | "groupIds": [], 918 | "frameId": null, 919 | "roundness": null, 920 | "boundElements": [ 921 | { 922 | "id": "-W8Snv91xYNAhRQgSnCV0", 923 | "type": "arrow" 924 | } 925 | ], 926 | "updated": 1698357371532, 927 | "link": null, 928 | "locked": false, 929 | "fontSize": 20, 930 | "fontFamily": 1, 931 | "text": "Includes platform \nauthentication services", 932 | "textAlign": "center", 933 | "verticalAlign": "top", 934 | "containerId": null, 935 | "originalText": "Includes platform \nauthentication services", 936 | "lineHeight": 1.25, 937 | "baseline": 42 938 | }, 939 | { 940 | "type": "text", 941 | "version": 107, 942 | "versionNonce": 885193011, 943 | "isDeleted": false, 944 | "id": "YaNRUL8B9xQhseydcg87V", 945 | "fillStyle": "hachure", 946 | "strokeWidth": 1, 947 | "strokeStyle": "solid", 948 | "roughness": 1, 949 | "opacity": 100, 950 | "angle": 0, 951 | "x": 1320.4329833984375, 952 | "y": 509.7509765625, 953 | "strokeColor": "#000000", 954 | "backgroundColor": "transparent", 955 | "width": 291.0997314453125, 956 | "height": 50, 957 | "seed": 401197700, 958 | "groupIds": [], 959 | "frameId": null, 960 | "roundness": null, 961 | "boundElements": [ 962 | { 963 | "id": "7Bi62pgRnYYTirIaYXler", 964 | "type": "arrow" 965 | } 966 | ], 967 | "updated": 1698357327132, 968 | "link": null, 969 | "locked": false, 970 | "fontSize": 20, 971 | "fontFamily": 1, 972 | "text": "Includes security vulnerability\nscanning tools", 973 | "textAlign": "center", 974 | "verticalAlign": "top", 975 | "containerId": null, 976 | "originalText": "Includes security vulnerability\nscanning tools", 977 | "lineHeight": 1.25, 978 | "baseline": 42 979 | }, 980 | { 981 | "type": "arrow", 982 | "version": 378, 983 | "versionNonce": 669689725, 984 | "isDeleted": false, 985 | "id": "HGVXfEl0Z7uZtFzrRUTIk", 986 | "fillStyle": "hachure", 987 | "strokeWidth": 1, 988 | "strokeStyle": "solid", 989 | "roughness": 2, 990 | "opacity": 100, 991 | "angle": 0, 992 | "x": 512.5985713873138, 993 | "y": 414.7292022705078, 994 | "strokeColor": "#000000", 995 | "backgroundColor": "transparent", 996 | "width": 171.18505898377998, 997 | "height": 39.27326885736022, 998 | "seed": 1065429315, 999 | "groupIds": [], 1000 | "frameId": null, 1001 | "roundness": { 1002 | "type": 2 1003 | }, 1004 | "boundElements": [], 1005 | "updated": 1698357327132, 1006 | "link": null, 1007 | "locked": false, 1008 | "startBinding": { 1009 | "elementId": "OOdE6_z6YdWAqnGr_Tuia", 1010 | "focus": 0.6295175046455058, 1011 | "gap": 4.50244140625 1012 | }, 1013 | "endBinding": { 1014 | "elementId": "YxvxXnfANVMHL7akQSO5r", 1015 | "focus": 0.14136668975394426, 1016 | "gap": 11.83831787109375 1017 | }, 1018 | "lastCommittedPoint": null, 1019 | "startArrowhead": null, 1020 | "endArrowhead": "arrow", 1021 | "points": [ 1022 | [ 1023 | 0, 1024 | 0 1025 | ], 1026 | [ 1027 | 171.18505898377998, 1028 | 39.27326885736022 1029 | ] 1030 | ] 1031 | }, 1032 | { 1033 | "type": "text", 1034 | "version": 279, 1035 | "versionNonce": 521362131, 1036 | "isDeleted": false, 1037 | "id": "OOdE6_z6YdWAqnGr_Tuia", 1038 | "fillStyle": "hachure", 1039 | "strokeWidth": 1, 1040 | "strokeStyle": "solid", 1041 | "roughness": 2, 1042 | "opacity": 100, 1043 | "angle": 0, 1044 | "x": 381.47442626953125, 1045 | "y": 335.2267608642578, 1046 | "strokeColor": "#000000", 1047 | "backgroundColor": "transparent", 1048 | "width": 275, 1049 | "height": 75, 1050 | "seed": 2011183715, 1051 | "groupIds": [], 1052 | "frameId": null, 1053 | "roundness": null, 1054 | "boundElements": [ 1055 | { 1056 | "id": "HGVXfEl0Z7uZtFzrRUTIk", 1057 | "type": "arrow" 1058 | } 1059 | ], 1060 | "updated": 1698357327132, 1061 | "link": null, 1062 | "locked": false, 1063 | "fontSize": 20, 1064 | "fontFamily": 1, 1065 | "text": "We're responsible to manage\nthe risk of systems inside \nthe boundary", 1066 | "textAlign": "left", 1067 | "verticalAlign": "top", 1068 | "containerId": null, 1069 | "originalText": "We're responsible to manage\nthe risk of systems inside \nthe boundary", 1070 | "lineHeight": 1.25, 1071 | "baseline": 67 1072 | } 1073 | ], 1074 | "appState": { 1075 | "gridSize": null, 1076 | "viewBackgroundColor": "#ffffff" 1077 | }, 1078 | "files": {} 1079 | } --------------------------------------------------------------------------------