-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
0 parents
commit 7f13f8e
Showing
43 changed files
with
7,848 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
{ | ||
"name": "Python 3", | ||
"image": "mcr.microsoft.com/devcontainers/python:3.10-bullseye", | ||
"features": { | ||
"ghcr.io/devcontainers/features/node:1": { | ||
"version": "lts" | ||
} | ||
}, | ||
|
||
// Use 'forwardPorts' to make a list of ports inside the container available locally. | ||
// "forwardPorts": [], | ||
|
||
// Use 'postCreateCommand' to run commands after the container is created. | ||
"postCreateCommand": "pip3 install mkdocs mkdocs-material mkdocs-print-site-plugin && mkdocs serve", | ||
|
||
// Set `remoteUser` to `root` to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root. | ||
"remoteUser": "vscode", | ||
"customizations": { | ||
"vscode": { | ||
"extensions": [ | ||
"ms-vsliveshare.vsliveshare" | ||
] | ||
} | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
name: Publish Playbook | ||
|
||
# Controls when the workflow will run | ||
on: | ||
# Triggers the workflow on push or pull request events but only for the main branch | ||
push: | ||
branches: [ main ] | ||
|
||
# Allows you to run this workflow manually from the Actions tab | ||
workflow_dispatch: | ||
|
||
jobs: | ||
build: | ||
runs-on: ubuntu-latest | ||
|
||
# Steps required to build and deploy | ||
steps: | ||
- name: Checkout repository | ||
uses: actions/checkout@v3 | ||
- name: Install python | ||
uses: actions/setup-python@v3 | ||
- name: Install mkdocs | ||
run: pip install mkdocs-material mkdocs-print-site-plugin | ||
- name: Build and deploy | ||
run: mkdocs gh-deploy --force |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
.idea | ||
.DS_Store |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
# High Level Approach | ||
|
||
This page currently covers a brief description of approaches made to support establishing an Ongoing Authorization and continuous Authority to Operate (cATO) for applications that are deploying onto a given platform. | ||
|
||
- [Architecture Inheritance Model](#architecture-inheritance-model) | ||
- [Ongoing Authorization Boundary](#ongoing-authorization-boundary) | ||
- [Secure Release Pipeline Capabilities](#secure-release-pipeline-capabilities) | ||
- [Application Security Assessors](#application-security-assessors) | ||
|
||
<br/> | ||
|
||
## Architecture Inheritance Model | ||
We leverage a modern architecture that allows us to build, deploy and monitor our applications. 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. This means that application development 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. | ||
|
||
<br/> | ||
|
||
![Technology Stack!](images/architecture.png "Technology Stack") | ||
|
||
<br/> | ||
|
||
## Ongoing Authorization Boundary | ||
The platform's Ongoing Authorization Boundary (also known as the *Accountability Boundary*) and approach to performing cATO covers the platform, secure release pipeline, custom applications/products deployed onto the platform, as well as any Commercial Off The Shelf (COTS) software that supports the operations of the platform or secure release pipeline (ie authentication services and security vulnerability scanning tools). All COTS software that is SaaS-based must complete the necessary accreditation for Federal Risk and Authorization Management Program (FedRAMP). | ||
|
||
<br/> | ||
|
||
![Boundary!](images/boundary.png "Boundary") | ||
|
||
<br/> | ||
|
||
## Secure Release Pipeline Capabilities | ||
[Continuous Integration](https://www.martinfowler.com/articles/continuousIntegration.html) (CI) pipelines ensure that Application Development Teams can deliver frequent changes of software into production quickly and safely. Within the platform, app teams have the flexibility to build, test and deploy using whatever strategy is best suited for their product(s). However, before teams can deploy to the platform, they must be registered to and call the secure release pipeline. | ||
|
||
This pipeline service is only available to software development teams that are customers of the platform. The secure release pipeline enables security vulnerability detection and remediation guidance every time an engineer commits code changes to their teams repository. Upon each commit, the app team is receiving 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) being leveraged by the application. The secure release pipeline enforces [policies](policy.md) as gatecheck jobs, that must be adhered to in order for teams to achieve a [digitally signed](https://csrc.nist.gov/glossary/term/digital_signature) application image. Only images signed by the secure release pipeline are allowed onto the platform, and are validated by the platform prior to deployment. | ||
|
||
<br/> | ||
|
||
![SecRel!](images/SecRel.png "Secure Release Pipeline") | ||
|
||
<br/> | ||
|
||
## Security Control Assessors | ||
If you recall the [RMF Structure](overview.md#rmf-structure), there are two major steps of NIST RMF known as Assess and Authorize. At a high level, the Assess step is focused on having third party Assessors create an assessment plan that will be used to assess how the System Owning team implemented controls that were established during earlier steps of the RMF process, and then provide a report to the team and AO regarding the outcomes of the assessment. This assessment report provides findings and recommendations on deficiencies related to security risks. Deficiencies are either addressed before acquiring an ATO from an AO, or listed as a Plan of Action and Milestone (POAM) that will be addressed within a specified time period after acquiring an ATO and deploying to production. | ||
|
||
Traditionally, System Owning teams would need to coordinate a week, or multi-week long assessment exercise months in advance to provide adequate time to address NIST Controls and outcomes of the assessment exercise. This forces teams to operate with a waterfall schedule mentality, taking on coordination risks and planning around the availability of Assessors as well as the readiness of the system for assessment. This inevitably adds months of delay to a teams path to production, and often leads to a large list of unaddressed POA&Ms that then have long shelf lives before being mitigated. | ||
|
||
Our approach is aimed at aligning security assessment practices to how modern software development teams actually develop and deliver products to end-users - iteratively and incrementally. As denoted by the image below, teams learn enough about the problem space and end-users they are solving for, as well as ideating through various solutions. It is at this point when an Application Security Assessor is embedded with the team throughout the lifecycle of their product and Software Development Lifecycle (SDLC). We also employ a COTS solution known as [SD Elements](https://www.securitycompass.com/sdelements/) which allows the System Owning team and Assessors to map out the various technology, architecture and risk vectors using a system survey and threat model diagram to drive [Control Selection](selection.md), implementation and assessment activities. This process of assessing risk and verifying that a security requirement has 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 product to go to production. | ||
|
||
<br/> | ||
|
||
![AppAssessor!](images/AppAssessor.png "Security Control Assessor") |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
# Architecture | ||
We leverage a modern architecture that allows us to build, deploy and monitor our applications. 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 (eg [Delivery Infrastructure](platform.md)) and a secure mechanism for shipping applications (eg a [Secure Release Pipeline](pipeline.md)). | ||
|
||
<br/> | ||
|
||
![Technology Stack!](images/architecture.png "Technology Stack") |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
# Benefits | ||
|
||
***Improve security posture and lower risk*** | ||
|
||
- Reduce the number of security defects through [threat analysis and secure coding practices](https://www.securitycompass.com/sdelements/) | ||
- Continuously detect and remediate application vulnerabilities quickly via the [Secure Release Pipeline](pipeline.md) | ||
- Cybersecurity and vulnerability education is available to application development teams simply by utilizing the secure release pipeline | ||
|
||
<br/> | ||
|
||
***Increase transparency and trust*** | ||
|
||
- Default access to all body of evidence artifacts throughout the software development life cycle (ie source code, documents, diagrams) for security control assessors and cybersecurity personnel to support continuous monitoring (eg assessment and evaluation) | ||
- Incrementally automating risk assessment via secure release pipelines | ||
|
||
<br/> | ||
|
||
***Reduce costs & increase delivery of value to organizations and end-users*** | ||
|
||
- Reducing the number of security defects and risks | ||
- Leveraging a cloud environment | ||
- Shipping software can be accomplished in hours or days, instead of weeks, months or even years |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
# Authorization Boundary | ||
|
||
![Boundary!](images/boundary.png "Boundary") |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
# System Categorization | ||
|
||
## What is System Categorization? | ||
The categorization process determines the worst-case potential impact that could result from a compromise of the confidentiality, integrity, or availability of an information type, and the overall system. This is expressed using a triple rating formula as described below, and where the acceptable values for potential *impact* are LOW, MODERATE, or HIGH. | ||
|
||
**SC**~information_system~ = {(**confidentiality**, *impact*), (**integrity**, *impact*), (**availability**, *impact*)} | ||
|
||
<br/> | ||
|
||
### Example 1 | ||
> If a given information system were categorized {LOW, MODERATE, LOW} the overall outcome would be ***Moderate*** because that was the highest impact level for the overall assessment of risk for the system. | ||
> | ||
> **SC** = {(**confidentiality**, *LOW*), (**integrity**, *MODERATE*), (**availability**, *LOW*)} = ***MODERATE*** | ||
### Example 2 | ||
> If a given information system were categorized {LOW, MODERATE, HIGH} the overall outcome would be ***Moderate*** because that was the highest impact level for the overall assessment of risk for the system. | ||
> | ||
> **SC** = {(**confidentiality**, *LOW*), (**integrity**, *MODERATE*), (**availability**, *HIGH*)} = ***HIGH*** | ||
<br/> | ||
|
||
## Why are they important? | ||
System categorization affects your security and privacy control selection. In general, the higher the impact due to loss, the more security requirements your team will need to address to reduce the risk to your organization and your end-users. The impact levels are described as follows: | ||
|
||
- **Low** - the loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.[^1] | ||
- **Moderate** - the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.[^1] | ||
- **High** - the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.[^1] | ||
|
||
<br/> | ||
|
||
[^1]:[Standards for Security Categorization of Federal Information and Information Systems](https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
# System Diagram | ||
|
||
## What are System Diagrams? | ||
Similar to what was described in our approach for an [Ongoing Authorization Boundary](approach.md#ongoing-authorization-boundary), a system diagram is a visual representation of what components and connections exist in your application/product overall system boundary. | ||
|
||
Other terms that have been used to describe a system diagram are architecture diagrams or threat models. | ||
|
||
<br/> | ||
|
||
## Why are they important? | ||
We require a system diagram be produced by your application/product team in order to tailor security requirements during the control selection process. The diagram is also utilized for threat analysis and our [continuous monitoring](monitoring.md) strategy. | ||
|
||
<br/> | ||
|
||
## How do I complete this task? | ||
Today, teams can leverage any solution and medium preference that they prefer, to create system diagrams. The only requirements are that Application teams must include the items listed below in their system diagram and information flow diagram, and must maintain this artifact with the current and proposed future state of their system. This ensures that Application Teams and Security Control Assessors are on the same page in terms of changes in the systems risk landscape. | ||
|
||
- Show all components that make up your overall system, | ||
- Clarify which components your application team is responsible for maintaining, by drawing an authorization boundary around them, | ||
- Clarify which components are not your application teams responsibility, by leaving them outside of the authorization boundary, | ||
- Identify where any Federal Agency data is to be processed, stored, or transmitted, | ||
- Clarify how all connections between components are handled, by including communication ports, protocols and direction of traffic (including the use of definitive agency DNS), | ||
- Include a legend explaining your system diagram. | ||
|
||
<br/> | ||
|
||
![Process!](images/systemDiagram.png "Process") |
Oops, something went wrong.