Shut down my.usa.gov (MyUSA)

[yozlet]

It's time to send MyUSA to the authentication service farm upstate where it can run around with the other OAuth2 gateways, chase PII and eat all the budget it likes.

Reasoning

We have too few people and resources to be able to maintain the MyUSA service. The code is gradually bit-rotting due to its reliance on outdated versions of key Ruby gems. As this continues, our ability to safely maintain and deploy it is being eroded.

This wouldn't be such a grave situation if there weren't still active projects depending on it. We need to definitively announce closure and coax dependent projects to move to alternative authentication & authorization services.

Plan

Pre-shutdown

• Gather list of active dependent apps
• Gather list of alternative auth systems for apps to switch to
• See if there are any wider GSA stakeholders (unlikely to be many, probably none) we need to run this past
• Investigate requirements around PII disposal - any record retention requirements?
• When does the ATO expire? (Was there actually a final ATO?)
• Tell GSA Privacy so they can take down the SORN (acc. to Noah)
• Have all dependent apps switch away to alternatives
  • C2 (issue)
  • Open Opportunities (issue)
  • Dolores (issue, PR)
  • Tock (issue)
  • Handbook (aiming for 8/4 - issue)
  • 18F Pages (-staging and -internal)
  • Team API
  • Hub (probably ok to shut down)
• Update MyUSA's README to note project deprecation
  • ... and https://github.com/18F/omniauth-myusa
  • ... and then push omniauth-myusa to RubyGems so it's updated there too

Shutdown

• Learn about formal decommissioning and its requirements (probably from Noah)
• Announcements?
  • 18F blog post?
  • Anywhere else?
• Close social media accounts
  • https://twitter.com/myusa
  • https://twitter.com/ProjectMyUSA
  • https://twitter.com/ProjectMyGov
  • https://www.facebook.com/ProjectMyUSA/
• Create new landing page for old MyUSA URLs
• Point domains at new landing page login.gov
• Gather list of AWS MyUSA components for cleanup
• Shut down and remove MyUSA from CF
• Clean up AWS components
  • Databases and their backup snapshots
  • Anything else?
• Remove MyUSA API from data.gov inventory
• Write a report on all the above as (monument to the glory of all who worked on this)/(warning to future generations of what happens if you don't clean up after yourself)
• Give remaining artifacts a Viking burial from Ocean Beach

[jeremiak]

You can remove Handbook from the list, @yozlet.

The documentation working group has a goal of 8/4 to make the Handbook public and are tracking our progress in 18F/handbook#829

[yozlet]

Thanks @jeremiak! I'll keep Handbook in the list for the moment (since it's still a dependent) but link the issue.

[StephenOTT]

What was the final count of apps and departments that were using MyUSA?

[jackiekazil]

[yozlet]

@StephenOTT: Five apps, all 18F (though a couple of those were for users outside 18F, but still within government). See the nested list in the issue checklist.

[StephenOTT]

@yozlet ah! haha, I read that list as those were the alternative apps systems could validate against. Now that i look at the list in more details, that assumption does not make much sense :)

Thanks

[yozlet]

@StephenOTT Yep, sorry if that wasn't clear! Will be providing the list of alternative auth systems shortly.

[yozlet]

@StephenOTT Thanks! Looks impressive, but this isn't the best place to discuss it. Let's chat elsewhere. :)

[pkarman]

https://docs.cloud.gov/apps/leveraging-authentication/ is good alternative for something like C2 (which is all GSA users)

[yozlet]

Thanks @pkarman! Yep, the current alternative auth methods list looks like this (and I'll keep this comment updated):

Cloud.gov Auth

See information here

Pros:

• OAuth2
• Can use existing GSA login or add new accounts, can also backend to other existing gov auth systems if needed
• Actively maintained, and very likely to remain so
• Already has at least one client implementation example (Python)
• Maintained by us, so chance of getting features added if needed; the team is eager to talk to potential client app teams; mmm, yummy dogfood

Cons:

• Still relatively immature
• While Cloud.gov is aiming to become a rock-solid highly-available platform, it's not there yet
• Users expecting MyUSA will need extra training (looking at C2 here)
• Only sends over email address, not other profile details (which is probably fine for most of our needs)
• Can't verify that user is 18F staff (but then, neither could MyUSA)

GitHub Auth

Pros:

• OAuth2
• Tons of existing client implementations, should be very easy to integrate
• Highly-available, mature
• Can verify that user is part of 18F team if needed
• 18F users are likely to be logged-in already, so fast click-through

Cons:

• Only a good option if all users are guaranteed to have GitHub accounts; otherwise, imposes a higher registration/training barrier than other options

Google Auth

Pros:

• OAuth2
• Tons of existing client implementations, should be very easy to integrate
• Highly-available, mature
• Almost all GSA/18F users are likely to be logged in already, so very fast click-through
• It's Google! Everyone knows Google!

Cons:

• Can't verify that user is 18F staff (but then, neither could MyUSA)
• Really? We're using Google?

MAX.gov

Pros:

• Intended for gov-2-gov auth
• Already delegates to a load of existing agency auth systems (but not GSA)
• Can authenticate using PIV cards
• Relatively mature

Cons:

• No OAuth2, only SAML
• The topic of UX appears to be somewhat subdued within their priority matrix
• Does not currently delegate to GSA SecureAuth

Not in this list: login.gov. (because it's too far from ready, and also it's not meant for gov-to-gov auth)

[harrisj]

I added an item to remove MyUSA from the the data.gov inventory once the AWS instances have been shut down. This is not a difficult process (it just means sending an email and @gbinal or I can handle it), but I wanted to add it to the list.

[ric7694]

FYI - I'm working with Yoz to shut down MyUSA so may be reaching to folks with questions and asks for help.

[ric7694]

@yozlet FYI https://github.com/18F/Infrastructure/issues/691

[ric7694]

@yozlet per guidance from @NoahKunin:

1. Work with [email protected], acting chief privacy officer on SORN
2. Ask her who to connect with for proper PII disposal

• From NK: "...presuming there is an issue. My presumption is that since MyUSA never became the canonical version of anything, we can just delete"

@yozlet I'll reach out to Lauren Pierce.

[ric7694]

no word from Lauren Pierce yet. Pinged today.

[ric7694]

still no word from Lauren Pierce. Trying to get info another way through CIO/CTO contacts.

[NoahKunin]

Also pinged.

On Tue, Oct 11, 2016 at 11:19 AM, Ric Miller [email protected]
wrote:

still no word from Lauren Pierce. Trying to get info another way through
CIO/CTO contacts.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#762 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAifT8W1M3sClG6Dq4dueGZ_sbFJ9xgWks5qy9NAgaJpZM4JK6Ua
.

Noah S. Kunin
Infrastructure Director https://18f.gsa.gov/team/noah/ | Technology
Transformation Service http://www.gsa.gov/portal/category/25729

[NoahKunin]

Adding note to redirect my.usa.gov to login.gov once this is done.

[yozlet]

@NoahKunin Good idea - in that case, I'll take out the gravestone landing page.

[yozlet]

Open Opps's recent security incident has caused them to shut down MyUSA access. However, I'm not ticking them off the list just yet because they may still need access to the MyUSA data in order to retain access to those accounts. I'm planning on talking to their team about it.

[ric7694]

guidance from Lauren Pierce. will review NARA guidance and work with @yozlet on next steps.

Since this is just profile data for users of a system/website not involving classified data, then the profile data can be destroyed when there is no longer a business case to keep it. The disposition authority is GRS 3.2/030. GRS stands for the NARA General Records Schedule that can be referenced here: (https://www.archives.gov/files/records-mgmt/grs/grs-trs24.pdf).

NARA guidance
DAA-GRS-2013-0006

[NoahKunin]

Great! Since the system is no longer ours (OPM), I'm going to set a
deadline of 10/31 on this before we "tick them off". No OPM users had MyUSA
after all.

On Fri, Oct 21, 2016 at 2:21 PM, Yoz Grahame [email protected]
wrote:

Open Opps's recent security incident has caused them to shut down MyUSA
access. However, I'm not ticking them off the list just yet because they
may still need access to the MyUSA data in order to retain access to those
accounts. I'm planning on talking to their team about it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#762 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAifT__iDzqex7x3n8NcI5DgoCXUkkBtks5q2QKagaJpZM4JK6Ua
.

Noah S. Kunin
Infrastructure Director https://18f.gsa.gov/team/noah/ | Technology
Transformation Service http://www.gsa.gov/portal/category/25729

[ric7694]

updating issue based on past convos w/ @yozlet . sorry it took so long

I spoke with Navin and Pranjali Desai re: who is responsible for records archiving and destruction. Program office is responsible.

I also reviewed General Records Schedule Section 3.1, and 3.2 - specifically item 3.2/030 - along with the accompanying disposition authority DAA-GRS-2013-0006-0003. I think we need to:

Under 3.2
(1) Archive "files created as part of the user identification and authorization process to gain access to systems and monitor system usage", and "destroy 1 year after user account is terminated or password is altered or when no longer needed for investigative or security purposes, whichever is later." Examples include:

• - user profiles
• - log in files
• - password files
• - system usage files

Under section 3.1
(2) [very conservative interpretation but doesn't hurt us to go this way] Archive the following types of records and "destroy 5 years after system is superseded by a new iteration, or is terminated, defunded, or no longer needed for agency/IT administrative purposes, but longer retention is authorized if required for business use." [basically: all other work product not covered under #1]

• • system development records. eg: "records include case files containing documentation of planning, decision making, designing, programming, testing, evaluation, and problem solving."
• • configuration and change management records. eg: "Records created and retained for asset management, performance and capacity management, system management, configuration and change management, and planning, follow-up, and impact assessment of operational networks and systems."

@yozlet I think at this point you're up in deciding next steps on how we do ^. What do you need from me? Happy to help where I can.

[yozlet]

@ric7694 Thanks for this. Extracting the data from the database - in a single mostly-encrypted big blob - is pretty easy. However, I'm not sure where or how we should store it. I'm guessing that creating an S3 bucket in GovCloud with an additional explanatory README file is a start, along with pointers from various places (such as this issue) should we somehow ever need to find it again.

@NoahKunin: do you know of a better place to put it?

[yozlet]

App switch updates:

• I met with folks from Open Opportunities and confirmed that the accounts affected by the deactivation of their MyUSA integration are still accessible without needing any more from MyUSA. 👍
• C2 has switched their production site to cloud.gov authentication. I'm currently creating a new 18F-only C2 site that is still using MyUSA during the testing phase, but it should all be finished in the next couple of days.

And with that, I believe we've removed all the dependencies on MyUSA.

[yozlet]

@ric7694 I assume that the "system development records, configuration records and change management records" discussed in 3.1 (2) basically consist of this GitHub repo. (My previous comment about The Big Database Blob is in answer to 3.2 (1), though that might also need log file storage, which would need to be retrieved from cloud.gov.

[ric7694]

@yozlet yep, I think that's a reasonable interpretation/assumption of "system development records, configuration records, and change management records." I also think that google docs and other work-product falls w/in those buckets.

My question at this point - for all of us to engage on - is which records housed in GitHub (as part of an open source project) should be destroyed vs. which ones should be open for all time for all to see. If we draw a line (dotted or solid) from "business use" as justification for "long retention" to 18F's business decision to be open first, it's arguable that some parts of the repo - even if we're not actively maintaining it day-to-day - should not be destroyed ever, and should remain open and available to all for all time. I'm just spitballing tho.

I'm interested to hear @NoahKunin and @konklone 's opinions.

[konklone]

Yeah, I don't think we should destroy our GitHub repositories and documentation after 5 years. It's certainly possible we could archive this repository (and other unused ones) in some way, but if we did that it should be a public archive. The easiest thing to do is leave this repository as is and mark it as deprecated or inactive in its description.

[NoahKunin]

@konklone beat me to it. ^^ is what we do for now. Record retention policies set floors for us in this regard. Not ceilings.

Conversely, we treat user data the opposite way. We try to destroy or ideally avoid the collection of private data to begin with, as much as possible.

[NoahKunin]

Also, HUGE CONGRATS to @yozlet @ric7694 @harrisj and anyone else who worked on this. Huge effort.

Let's get my.usa.gov (presuming this will need a GSA IT Service Desk ticket) redirecting to login.gov and get this issue closed!

[yozlet]

Adding detail on the SORN conversation - this from @jpyuda:

"The former myUSA SORN was renewed and amended so as to be in place for the (very early stages) usa.gov information exchange project. [...] Keeping this SORN alive, while somewhat unusual, will save us time and money later and is something we want to continue to do."

I am thus ticking off the SORN item from the pre-shutdown checklist, which means that all the pre-shutdown items are now done.

Next step: Formal decommissioning. Adding @NoahKunin and @jezhumble here since they have the required form(s).

[yozlet]

Regarding Data.gov: Link to MyUSA from "Developers" page removed, and MyUSA Citizen API will be removed by Cindy Smith from the Data Catalog tomorrow.

[wslack]

The decommissioning from has been signed and transmitted.

[yozlet]

@NoahKunin So, just to absolutely clarify plans for the user data, which is stored as a big mostly-encrypted MySQL snapshot, which of these is best?

1. Delete it all, ASAP
2. Store the MySQL snapshot in S3 somewhere (addendum: There is also a MyUSA folder in Google Drive that might be a good home for this), with a README, but don't worry about the decryption key; put a "delete that bucket" event on people's calendars, dated a year from now
3. Option 2, but also working out somewhere to put the key (I have no idea where)
4. Other: _____________________

I ask because I'm slightly confused between discussion of GRS 3.2/030 apparently saying "at least 1 year", and you saying that we want to destroy user data as quickly as possible (which makes much more sense to me).

[NoahKunin]

As per the Privacy Officer at the time, delete it.

But now I'm a little confused, what do you mean by "mostly" encrypted? My understanding was that profile data was encrypted at the row level.

[yozlet]

AFAIK (and I can double-check this if needed) the user's email address was not encrypted, whereas all other PII fields (incl. first & last name, etc.) were.

[pkarman]

If the app uses Devise and there was no additional encryption work done, then yes, the email is stored in plain text. We just had to solve that problem for login.gov.

[yozlet]

The draft MyUSA Infrastructure removal audit document is now on GSA Google Drive, and that is what it's called so you can search for it (because I think I shouldn't be directly linking to it from here, but maybe I'm wrong), and I would greatly appreciate folks in this thread giving it a quick scan (it's very short) and thinking about whether I've missed anything.

[NoahKunin]

Aware of the email not being encrypted, that's fine. It was the term "mostly" that threw me off. Either it's a blob or it's in a structured filed, it's either encrypted or it's not. No worries there.

No comments on the doc. Links to GSA Google Docs are fine in public places, it just means you'll occasionally get weird people / strangers potentially asking for access. Obviously, don't give it to them (and since they're outside of our domain, you can't).

Audit looks good, nothing off the top of my head.