Skip to content

Latest commit

 

History

History
59 lines (33 loc) · 5.12 KB

procedures.md

File metadata and controls

59 lines (33 loc) · 5.12 KB
Raw

This document is to memorialize internal project procedures. Other agencies or teams not at GSA are free to adopt them as well, but don't have to in order to use the software.

Cloud.gov Access

The System owner and current project developers need cloud.gov access to the code.gov API. The system owner (currently Olivier Kamanda) manages this access, granting access to new project developers when they come onboard and removing access when they leave.

Specifically, current developers are granted OrgManager rights to gsa-code-gov and SpaceDeveloper rights to each of the projects spaces.

Both of the adding and removing processes should be initiated by creating an issue in the project's issue tracker. Any one can create the issue, but the system owner should be the one who addresses and closes it.

These accounts are created for developers that need access to contribute code and debug apps.

  1. Create an account with cloud.gov and this will include multi factor authentication with Google authenticator or authy.

  2. Make sure you have gitseekrets installed on your Mac or in your virtualbox, if that is where you do your development.

  3. Then, you will want to contact the system owner, currently Olivier Kamanda. In that message, include your name, the name of your supervisor, confirm you have two factor authentication on and have installed gitseekrets.

  4. The system owner will confirm the GSA identity of the applicant and comment on the ticket to show approval.

  5. The system owner will add a person to the gsa-code-gov organization in cloud.gov.

  6. Documenting what role was assigned

GitHub Access

The System owner and current project developers need commit rights to code.gov API project repository (here. The system owner (currently Olivier Kamanda) manages this access, granting access to new project developers when they come onboard and removing access when they leave.

Both of the adding and removing processes should be initiated by creating an issue in the project's issue tracker. Any one can create the issue, but the system owner should be the one who addresses and closes it.

These accounts are created for developers that need access to contribute code and deploy apps.

  1. Create an account with GitHub and enable multi factor authentication.
  2. Make sure you have gitseekrets installed on your Mac or in your virtualbox, if that is where you do your development. (If you are a Windows only user, you can be exempt from this requirement while the windows version is in development.)
  3. Then, you will want to contact the system owner, currently Olivier Kamanda. In that message, include your name, the name of your supervisor, confirm you have two-factor authentication on and have installed gitseekrets.
  4. The system owner will confirm the GSA identity of the applicant, and signal approval in the ticket.
  5. The system owner will then add the GitHub handle for the new member to the analytics.usa.gov 18F GitHub team and close the ticket.

Weekly Monitoring Checklist

The development team checks for security events weekly. Any unusual or suspicious activities are immediately brought to the team's attention in the project slack channel (#code-gov-partners) and the system owner coordinates appropriate investigation and followup. The team will follow the 18F incident response handbook.

Checklist:

  1. Create an issue in the project's issue tracker to track this Security Event Review.

  2. Review Gemnasium for all alerts flagged with 'red' flags.

  3. Review production logs for unapproved and unusual activities.

  4. Review actionable security events on production logs for successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, system events, all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes.

  5. Deactivate any cloud.gov and github access for people who have left the team.

  6. Note any findings in the Security Event Review issue.

  7. Close the Security Event Review issue.

Monitoring of New Relic Alerts

New Relic alerts are emailed to the full development team immediately. The first team member to see the alert checks the site's status and posts in the project slack channel (#code-gov-partners) the results. The system owner then coordinates any necessary followup.