Skip to content
This repository has been archived by the owner. It is now read-only.
Permalink
Browse files

create a Background section

  • Loading branch information...
afeld committed Oct 19, 2017
1 parent fbf73f7 commit a09250e26de4ec3cc083ec31a7440f20f02bdfbc
@@ -31,19 +31,26 @@ navigation:
- text: Background
url: background/
internal: true
- text: Goals
url: goals/
internal: true
- text: Stakeholders
url: stakeholders/
internal: true
children:
- text: Goals
url: goals/
internal: true
- text: Stakeholders
url: stakeholders/
internal: true
- text: FAQs
url: faq/
internal: true
- text: Pre-Discovery
url: pre-discovery/
internal: true
children:
- text: Knowns
url: knowns/
internal: true
- text: Areas of ATO work
url: areas/
internal: true
- text: Hypotheses
url: hypotheses/
internal: true
@@ -59,12 +66,6 @@ navigation:
internal: true
- text: Pitch for next Phase
url: /assets/phase_3_pitch_deck.pdf
- text: Areas of ATO work
url: areas/
internal: true
- text: FAQs
url: faq/
internal: true
- text: Trello board
url: https://trello.com/b/2SJKtNUA/project-boise
- text: Contact us
@@ -12,7 +12,7 @@ styles:

<details markdown="1">
<summary>Are you going to "fix" ATOs?</summary>
No. See the [Knowns](../pre-discovery/knowns/) page.
No. See the [Knowns](../../pre-discovery/knowns/) page.
</details>

<details markdown="1">
@@ -16,4 +16,4 @@ More tactically, here are the primary things that Boise will complete in the fir

1. First, we will **pick up existing conversations** that members of the Boise team have had around ATOs, making sure they are aware of Boise, and submit this pitch for feedback.
1. Second, we will **identify and map common compliance journeys**. While NIST's [Risk Management Framework](http://csrc.nist.gov/groups/SMA/fisma/framework.html) provides a high-level view, our team wants to more fully understand the information ecosystems created across federal agencies: what are the various touchpoints, by the various stakeholders, etc? From there we want to categorize what detailed parts of the process are hard vs. soft requirements, and which are government-wide vs. varying by agency.
1. Third, we will finish **mapping the [areas of ATO work](../areas/)**. We will take those various efforts and see where they fall along the mapping, to understand overlap/gaps. This will help steer Boise towards a specific area of the ATO process that is un(der)addressed.
1. Third, we will finish **mapping the [areas of ATO work](../../pre-discovery/areas/)**. We will take those various efforts and see where they fall along the mapping, to understand overlap/gaps. This will help steer Boise towards a specific area of the ATO process that is un(der)addressed.
File renamed without changes.
@@ -6,7 +6,7 @@ title: Overview
- The process by which software staged for use in the federal government is checked for security compliance is known as the "Authority to Operate (ATO)" process. The ATO process is usually handled by either government staff or a third-party vendor.
- "Project Boise" is a working title for a Discovery (exploratory) phase of research that builds upon 18F's [Compliance Toolkit](https://github.com/18F/compliance-toolkit).
- The Project Boise team is led by Aidan Feldman, with help from designer Andrew Maier and strategist Timothy Jones.
- In the short term, the Project Boise team will evaluate the ATO landscape and determine where GSA can provide the most value. In the long term, the Project Boise team hopes to **reduce the burden (time, cost, and pain) and improve the effectiveness of the federal government's software security compliance processes**. See the [Goals](goals/) page for more details.
- In the short term, the Project Boise team will evaluate the ATO landscape and determine where GSA can provide the most value. In the long term, the Project Boise team hopes to **reduce the burden (time, cost, and pain) and improve the effectiveness of the federal government's software security compliance processes**. See the [Goals](background/goals/) page for more details.

The Project Boise team are relatively new to government, and even newer to ATOs. We hope that

File renamed without changes.
@@ -12,7 +12,7 @@ We launched this site! Most of the content was pulled out from [our Discovery pl

## Stakeholder interviews

We've done over 25 [stakeholder interviews](https://methods.18f.gov/discover/stakeholder-and-user-interviews/) thus far (here's a list of the [Project Boise stakeholders]({{ site.url }}/stakeholders/)). Most of our interviewees work inside of government agencies, but we've also spoken with vendors in the risk-management space. In addition to our own outreach we've heard from a lot of people who are generally interested in the project, which is encouraging. We're still working on synthesis, but will get some takeaways public as soon as we can.
We've done over 25 [stakeholder interviews](https://methods.18f.gov/discover/stakeholder-and-user-interviews/) thus far (here's a list of the [Project Boise stakeholders]({{ site.url }}/background/stakeholders/)). Most of our interviewees work inside of government agencies, but we've also spoken with vendors in the risk-management space. In addition to our own outreach we've heard from a lot of people who are generally interested in the project, which is encouraging. We're still working on synthesis, but will get some takeaways public as soon as we can.

In short: **the risk-management process is painful for everyone,** and improving this is not as simple as changing one piece of policy. Rather than invalidating any of [our initial expected outcomes]({{ site.url }}/pre-discovery/outcomes/), we've only found _more_ opportunity for TTS to get involved.

@@ -12,7 +12,7 @@ The team is disappointed, but still believes in [our proposed direction]({{ site

## Shift of emphasis

In talking more and more about Project Boise, the team has had a realization that we have been successful in being a largely neutral player in the security compliance realm, getting groups from a large swath of [the space]({{ site.baseurl }}/stakeholders/) to open up to us. One the main things we observed was a pervasive culture of fear, which manifested itself as a reluctance to share compliance processes, documentation, etc. Because information is locked away in Word docs and spreadsheets, a lot of redundant work is done, because individuals don't know the work has already been done elsewhere.
In talking more and more about Project Boise, the team has had a realization that we have been successful in being a largely neutral player in the security compliance realm, getting groups from a large swath of [the space]({{ site.baseurl }}/background/stakeholders/) to open up to us. One the main things we observed was a pervasive culture of fear, which manifested itself as a reluctance to share compliance processes, documentation, etc. Because information is locked away in Word docs and spreadsheets, a lot of redundant work is done, because individuals don't know the work has already been done elsewhere.

Early on when developing our [pitch]({{ site.baseurl }}/assets/phase_3_pitch_deck.pdf) ([source](https://docs.google.com/presentation/d/1n02JdQuia-DerMp6WRsFpTtORC-UdLfcT1eIRf4AwgM/edit#slide=id.p)), we perhaps over-emphasized [Compliance Masonry](https://github.com/opencontrol/compliance-masonry) as a product, or a even a tool that would be used directly by a broad audience. **Compliance Masonry is most useful as a reference implementation that shows the value of the OpenControl schema**, and the way of working that encourages. Compliance Masonry provides the most benefit when compliance documentation is shared publicly, broken down into components, and provided in a structured format.

0 comments on commit a09250e

Please sign in to comment.
You can’t perform that action at this time.