Skip to content

Latest commit

 

History

History
72 lines (39 loc) · 6.4 KB

system-procedures.md

File metadata and controls

72 lines (39 loc) · 6.4 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.

GitHub Access

Site Scanning

The System owner and current project developers need commit rights to Site Scanning project repositories (here and here. The system owner (currently Gray Brooks) manages this access, granting access to new project developers when they come onboard and removing access when they leave.

Specifically, current developers are managed as the FAS - TTS - Solutions - Site Scanning team in the GSA GitHub organization.

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. They directly track the presence and departure of staff, but also receive a monthly separation report to ensure that departing staff are tracked and addressed.

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 Gray Brooks. 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 FAS - TTS - Solutions - Site Scanning GitHub team in the GSA organization and close the ticket.

Cloud.gov Access

The System owner and current project developers need cloud.gov access to Site Scanning. The system owner (currently Gray Brooks) manages this access, granting access to new project developers when they come onboard and removing access when they leave. They directly track the presence and departure of staff, but also receive a monthly separation report to ensure that departing staff are tracked and addressed.

Specifically, current developers are granted OrgManager rights to gsatts-sitescan.

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 issue in the project's issue tracker to track the request.

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

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

  4. The system owner will add a person to the Site Scanning organization in cloud.gov.

  5. The system owner will document the permissions that were assigned in the issue and close the issue when completed.

Public API Users

Pulic API users may self-provision API keys using the sign up form on the API documentation for the Site Scanning API. These keys then allow them general, public access to the API.

These keys are then used to identify the developer when making API calls, but do not provide any site authentication. There is no login or admin experience by which a public API user interacts with or manages their API key(s).

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 (#site-scanning) and the system owner coordinates appropriate investigation and followup. The team will follow the TTS incident response handbook.

Checklist:

  1. Create an issue in the project's issue tracker to track this Security Event Review.
  2. Review tool for all repositories and open a ticket for all "red" alerts.
  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 team immediately. The first team member to see the alert checks the site's status and posts in the project slack channel (#site-scanning) the results. The system owner then coordinates any necessary followup.

Analysis of Security Impacts

Every change is assessed for potential impact on security posture as part of the change request submission, and is code reviewed by GitHub Actions. Changes with a potential impact on security include a review of standards and guidelines as part of requirements development. After a deployment, security posture is reviewed and confirmed via the GSA SecOps scanning suite during regular scanning. Dependabot is used across TTS Github repos to automatically scan for vulnerabilities and dependency versioning. If an update is identified as needed, the team reviews documentation and takes necessary action.