Skip to content

Commit

Permalink
Merge pull request #7 from rise8-us/fix-index-and-readme
Browse files Browse the repository at this point in the history
Fix index and readme
  • Loading branch information
rmonroe-va authored Nov 14, 2023
2 parents 1ac903a + 28669bc commit 19b774b
Show file tree
Hide file tree
Showing 3 changed files with 15 additions and 33 deletions.
23 changes: 14 additions & 9 deletions docs/index.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,23 @@
# Prologue
# Continuous Delivery Risk Management Framework (CD-RMF) Playbook©

This playbook is meant to be a living document[^1] outlining the people, process and technology practices that will help organizations enable continuous Authority to Operate (cATO) in a concise and consumable way. We ***highly encourage*** all readers of this playbook to watch 🎥 [Continuous ATO: RMF & Ongoing Authorization](https://www.youtube.com/watch?v=k4lO3-9kIM0) before proceeding to other pages of the playbook.
**AKA THE C-ATO[^1] PLAYBOOK**

<br/>

As warfighters and operators continue to rely more and more on the success of mission critical software, the consequences of experiencing software outages and exploited cybersecurity threats are unprecedented. It is incumbent on organizations, and application development teams, to manage the risks that their systems introduce to their organizations network, and to mitigate those risks to the greatest extent possible. Through a process of Certification and Accreditation, a system can be granted what is known as an Authority to Operate (ATO). An ATO is the official authorization for a system to be deployed into a production envrionment, and the acceptance of any open risks that could impact organizational operations, assets, individuals, other even other organizations and the nation as a whole. A tremendous amount of work and responsibility goes into certifying a system for use, and requires that an Authorizing Official (AO) be the individual who accepts both the benefits and risks of the system going into production for the first time, as well as maintaining an ATO. As software becomes more dependent on microservice-based architectures, and application development teams adopt modern methodologies and technologies to achieve continuous delivery of software, we must also be willing to continuously adapt and evolve our security practices to support **continuous assessment, authorization and monitoring of risks**.
*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.*

<br/>
README: Please first read our Manifesto for a Continuous Delivery Risk Management Framework (CD-RMF)©. To advance that cause, we are making our internal playbook available to the entire govtech community.

![This is an image](images/weightScale.png)
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.

<br/>
In return for sharing this, 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.

Throughout our research and experiences, we've consistently validated that when organizations applied traditional waterfall practices to risk management implementations, they failed to match the speed and agility of modern software development, and increased the number security and privacy risks going undetected and unaddressed in production. In fact, we found that most application development teams we interviewed had limited to no awareness, or working knowledge of what an ATO is, how to achieve one, or that they had direct responsibilities tied to their path to production. This begs the question - if teams are not aware of what responsibilities they own in terms of security and privacy risk management, and how it supports their goal of delivering value, then how can we assume that security risks are actually being mitigated to the greatest extent possible? This is why we felt it was critical to publish a cATO playbook, and empower a community of change agents to take action.
<br/>
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!

***Together, we rise!***


<br/><br/>

[^1]: We are proposing the term “cATO” no longer be used, see our Manifesto for a CD-RMF.

[^1]: We maintain the documentation so that it represents how we manage cybersecurity risks and threats, through lessons learned and outcomes.
23 changes: 0 additions & 23 deletions docs/readme.md

This file was deleted.

2 changes: 1 addition & 1 deletion mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ plugins:
- search
- print-site
nav:
- 'README': 'readme.md'
- 'README': 'index.md'
- 'Introduction':
- 'The Why': 'why.md'
- 'History': 'history.md'
Expand Down

0 comments on commit 19b774b

Please sign in to comment.