-
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.
Merge pull request #7 from rise8-us/fix-index-and-readme
Fix index and readme
- Loading branch information
Showing
3 changed files
with
15 additions
and
33 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 |
---|---|---|
@@ -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. |
This file was deleted.
Oops, something went wrong.
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