diff --git a/docs/security/AC_policy/component.yaml b/docs/security/AC_policy/component.yaml deleted file mode 100644 index 0849956e0e4..00000000000 --- a/docs/security/AC_policy/component.yaml +++ /dev/null @@ -1,488 +0,0 @@ ---- -documentation_complete: false -name: Access Control Policies for 18F -satisfies: -- control_key: AC-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - The 18F Program Office develops, documents, and disseminates - to all 18F staff the 18F Access Control Policy which addresses purpose, scope, - roles, responsibilities, management commitment, coordination among organizational - entities, compliance, and procedures to facilitate the implementation of - the access control policy and associated access controls. The 18F Access Control - Policy is listed within 18F’s private Github repository and the docs.cloud.gov - site that is accessible to all 18F staff. - - key: b - text: | - The 18F Program Office will review and update the current 18F Access Control Policy at least every 3 years and any documented access procedures at least annually. - standard_key: NIST-800-53 -- control_key: AC-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - The 18F Program identifies and selects the following types of - information system accounts to support organizational missions/business functions: - - key: b - text: | - 18F has established designated DevOps personnel as the assigned - account managers for all information system accounts relating to the infrastructure - and the Login.gov platform. - System Owners, whose web applications and/or websites - reside on the Login.gov platform, have the responsibility to assign an account - manager for their information systems. - - key: c - text: | - 18F establishes conditions - for group and role membership within the Login.gov platform and its virtual - environment. - Conditions for groups and roles membership are based on an established - need to manage and access the virtual infrastructure and Login.gov environments. - The user must meet the following conditions in order for the System Owner / Project - Manager to approve a group membership request: - * The user’s assigned role is required to access a particular group. - * The user has the requirements and understanding to assume permissions associated with the group. - * The user has completed the security role-based training. - * The user complies with any other group-specific conditions created by the system owner. - Once conditions have been met, the System Owner / Project Manager will request access within - GitHub, 18F’s tracking and ticketing system. Once approved, the 18F DevOps group - completes the request for group and role membership within its infrastructure - and Login.gov platform. - - key: d - text: | - The 18F Program Office specifies authorized - users of the information system, group and role membership, and access authorizations - (i.e., privileges) and other attributes (as required) for each account. System - Owners / Project Managers provide the details of what type of access is needed - for an authorized authorized user. - All accounts will be documented within their - respective information systems, detailing their group and role membership, and - access authorizations. This documentation will be exported by DevOps and archived - for up to a year from the date of account creation by the managing 18F project - lead and Login.gov Technical Point of Contact (Operating Environment) in accordance - with best business and security practices. - - key: e - text: | - 18F requires approvals by the project lead and system owners for requests to create information system - accounts. All accounts will be documented within the GitHub ticketing and tracking - system with their respective information systems, detailing their group, role - membership, and access authorizations. - - key: f - text: | - User account establishment, - activation, modification, disablement or removal requires approval by the managing - \ project lead and Login.gov Information System Technical Point of Contact. - Accounts will be created, enabled, modified, disabled, and removed from AWS in accordance - with 18F policies, guidelines and established by the project lead and DevOps. - - key: g - text: | - 18F monitors the use of all information system accounts within - its environment. - - key: h - text: | - 18F notifies its DevOps account managers when accounts are no longer required, users are terminated or transferred, and when - individual’s information system usage or need-to-know changes within the Login.gov - platform and virtual private cloud infrastructure. - The Project Manager or Information - System Owner will be notified when accounts have been terminated, disabled or - transferred based on the access request submitted via GitHub. Notification - will be sent via email or the GitHub ticketing and tracking system when changes - to user and system access occur. - - key: i - text: | - 18F authorizes access to its - information systems based on a valid access authorization from System Owners - and DevOps, intended system usage within the network environment, and other - attributes as required by the organization or associated missions/business functions. - This is documented within section 3 of the 18F Access Control Policy: Access - Management. - User and system access is provided only to those with an established - need to access and manage the virtual private cloud and Login.gov environments. - * User group membership is restricted to the least privilege necessary for the user to accomplish their assigned duties. - * All user accounts are issued only to those who have gained approval by 18F DevOps. - Once approved, the DevOps team creates the user account and adds it to the appropriate role and organization - within its information systems. - 18F grants access to the information system - based on: - * A valid need-to-know/need-to-share that is determined by assigned official duties and satisfying all personnel security criteria. - * Intended system usage. - 18F requires proper identification for requests to establish information - system accounts, and it approves all such requests based on organizational or mission/business - function attributes. - - key: j - text: | - 18F reviews user and system accounts for compliance with account management requirements at least on an annual basis. - \ Currently, system and user accounts are being monitored manually on a monthly - basis and programmatically on a continuous basis. - - key: k - text: | - 18F establishes a process for reissuing shared/group account credentials when individuals are - removed from the group. 18F uses its GitHub tracking and ticketing system - for requests to reissue and remove individuals from group memberships within - its environment. - standard_key: NIST-800-53 -- control_key: AC-2 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov integrates its user management application with enterprise single sign on systems. - Login.gov automates user management by delegating user verification to a centralized system. - standard_key: NIST-800-53 -- control_key: AC-2 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - This control is not applicable. Login.gov does not contain any guest/anonymous, - group, or temporary user accounts. For PU DevOps only creates individual user accounts - and grants role based access to users within Login.gov's AWS VPC or ssh keys. - standard_key: NIST-800-53 -- control_key: AC-2 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F manages information system identifiers for users and devices by: Disabling - the user identifier after ninety (90) days of inactivity for general user accounts - and thirty (30) days for administrator level accounts. - standard_key: NIST-800-53 -- control_key: AC-2 (5) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - The 18F Access Control Policy Section 3 - Session Lock states - 18F information systems prevents further access to the system by initiating a session lock after a period of 20 minutes or less of inactivity or upon receiving a request from a user. 18F information systems retain the session lock until the user reestablishes access using established identification and authentication procedures. - standard_key: NIST-800-53 -- control_key: AC-2 (7) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov allows the creation of general user accounts. Privileged accounts are managed through AWS IAM RBAC and ssh keys. Roles are created by the administrators on a need by need basis. - - key: c - text: | - 18F removes users from privileged access rights when privileged role assignments are no longer appropriate or have been requested by the system owner and program manager. Removal of access is sent to the DevOps team through a change request within the GitHub ticketing system. - standard_key: NIST-800-53 -- control_key: AC-2 (9) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov does not permit shared accounts. Every user requires their own account. - standard_key: NIST-800-53 -- control_key: AC-2 (10) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov does not permit shared accounts. Every user requires their own account. - standard_key: NIST-800-53 -- control_key: AC-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F information systems enforce approved authorizations for logical access to information and system resources in accordance with the 18F Access Control Policy Section 3 Access Enforcement which states: - * 18F must enforce approved authorizations for logical access to its information systems in accordance with all applicable federal and 18F policies. - * 18F must provide access enforcement through the use of access control lists, access control matrices, and cryptography to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system. - * 18F must employ access enforcement mechanisms at the application level, when necessary, to provide increased information security for the organization. - standard_key: NIST-800-53 -- control_key: AC-4 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - The information system enforces approved authorizations for controlling the flow - of information within the system and between interconnected systems based on the - 18F Access Control Policy Section 3 - Information Flow Enforcement which states: - * 18F enforces approved authorizations for controlling the flow of information - within its information systems and between interconnected systems in accordance - with applicable federal laws and 18F policies and procedures. - * 18F shall use flow control restrictions to include: keeping export controlled - information from being transmitted in the clear to the internet, blocking outside - traffic that claims to be from within the organization and not passing any web - requests to the internet that are not from the internal web proxy. - * 18F shall use boundary protection devices (e.g., proxies, gateways, guards, - encrypted tunnels, firewalls, and routers) that employ rule sets or establish - configuration settings that restrict information system services, provide a - packet-filtering capability based on header information, or message-filtering - capability based on content (e.g., using keyword searches or document characteristics. - standard_key: NIST-800-53 -- control_key: AC-5 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F implements Identity and Access Management (IAM) - roles and individual user accounts for separation of duties at the AWS layer. - - key: b - text: | - 18F documents separation of duties of AWS users. All AWS IAM - users, groups and roles can be viewed within the AWS console. IAM users reports - are generated to show all separation of duties. - - key: c - text: | - Login.gov defines roles at each layer of the system. Authorization to each - of those roles is defined within the documentation of the setup and maintenance - of the layers. - standard_key: NIST-800-53 -- control_key: AC-6 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - IAM policies are attached to the users, enabling centralized control of permissions - for users under 18F AWS Account to access services, buckets or objects. With IAM - policies, 18F only grants users within its own AWS account permission to access - its Amazon resources. - 18F AWS IAM policies are defined to grant only the required access for 18F staff - necessary to perform their functions. 18F defines least privilege access to each user, - group, or role. - Security functions within the AWS infrastructure are explicitly defined within IAM to - include read-only permissions for any user functions. - 18F incorporate running the IAM Policy Simulator to test policies for least privilege access - for users and groups. - standard_key: NIST-800-53 -- control_key: AC-6 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Because Login.gov is a PaaS all accessible functions are privileged functions. - Nevertheless, 18F team members use different accounts with increasing security - requirements for accessing Cloud Foundry as a user, Cloud Foundry as a administrator, - and AWS as an administrator. - standard_key: NIST-800-53 -- control_key: AC-6 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Security functions within the Login.gov platform are limited to roles that can be taken - only by using BOSH, Concourse or UAA CLI. Non-security functions are performed using a - non-privileged Cloud Foundry account. - standard_key: NIST-800-53 -- control_key: AC-6 (5) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F restricts privileged accounts such as administrator and root access - accounts to designated members within the 18F Devops and SecOps teams. Within - the virtual infrastructure the admin account is not used for privileged access. - It’s only used for billing and metrics. - standard_key: NIST-800-53 -- control_key: AC-6 (9) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - * Privileged access to the information system is using an audit trail through - the BOSH tasks command. This command shows all actions that an operator has - taken with the platform. Additionally, all logging activity is forwarded to - CloudWatch Logs. - * ELK (Logstash, Elasticsearch, Kibana) is used to collect, manage and display - all user activity within the Login.gov platform. - standard_key: NIST-800-53 -- control_key: AC-6 (10) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - The Login.gov platform has built-in role based access controls (RBAC). This - ensures that users can only view and affect the spaces for which they have been - granted access to. It also prevents non-privileged users from executing privileged - functions to include disabling, circumventing, or altering implemented security - safeguards/countermeasures. - Only designated Org Managers from the DevOps team can execute privileged functions - to the Login.gov platform. All other accounts are non-privileged accounts. - Service providers integrating with Login.gov are only permitted to change settings within their enclave. These accounts do not have access to the underlying Login.gov platform. - standard_key: NIST-800-53 -- control_key: AC-7 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: NA - User management is delegated to each organization's enterprise user management system. - - key: b - text: NA - User management is delegated to each organization's enterprise user management system. - standard_key: NIST-800-53 -- control_key: AC-8 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: Implementation in progress - standard_key: NIST-800-53 -- control_key: AC-10 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: NA - User management is delegated to each organization's enterprise user management system. - standard_key: NIST-800-53 -- control_key: AC-11 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: NA - User management is delegated to each organization's enterprise user management system. - - key: b - text: NA - User management is delegated to each organization's enterprise user management system. - standard_key: NIST-800-53 -- control_key: AC-11 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Every user interaction with the Login.gov APIs requires a valid token. If a user session is locked - no Login.gov actions are allowed. - standard_key: NIST-800-53 -- control_key: AC-12 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Session termination is managed by UAA and set to expire within 15 minutes. - standard_key: NIST-800-53 -- control_key: AC-14 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: b - text: | - It is not possible for members of the 18F Devops and SecOps teams to access the 18F virtual - private cloud infrastructure without multifactor authentication and identification. All General users of Login.gov must login using authenticated credentials in order to access the system. - standard_key: NIST-800-53 -- control_key: AC-17 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov has a distributed administrator, operator, and management team. All remote actions are allowed. - - key: b - text: | - AWS Security Groups are implemented to ensure that only users that have been granted access can perform administrative actions. - standard_key: NIST-800-53 -- control_key: AC-17 (4) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F authorizes the execution of privileged commands and access - to security-relevant information via remote access only for monitoring, managing, - and troubleshooting the 18F virtual infrastructure and Login.gov platform. This - authorization is only given to specific members of the DevOps and SecOps teams. - All other members are excluded from this type of access. - standard_key: NIST-800-53 -- control_key: AC-18 - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-18 (1) - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-19 (5) - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-19 - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-20 - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-20 (1) - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-20 (2) - covered_by: [] - implementation_status: none - narrative: - - text: Not Applicable for Login.gov - standard_key: NIST-800-53 -- control_key: AC-21 - covered_by: [] - implementation_status: none - narrative: - - text: | - Not applicable to the the Login.gov platform. The Login.gov platform is - for use of development of and deployment of web applications. This control would - be handled at the application level and is the responsibility of the application - system owner. - standard_key: NIST-800-53 -- control_key: AC-22 - covered_by: [] - implementation_status: none - narrative: - - text: | - Not applicable to the the Login.gov platform. The Login.gov platform is - for use of development of and deployment of web applications. This control would - be handled at the application level and is the responsibility of the application - system owner. - standard_key: NIST-800-53 -schema_version: 3.0.0 -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/AC-Policy.md - type: URL -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 08:25:17.375257000 -05:00 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/AT_policy/component.yaml b/docs/security/AT_policy/component.yaml deleted file mode 100644 index 6ed8f3ade28..00000000000 --- a/docs/security/AT_policy/component.yaml +++ /dev/null @@ -1,70 +0,0 @@ -documentation_complete: false -name: Security Awareness Training Policy for 18F -satisfies: -- control_key: AT-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: The 18F Program office reviews AT-2 - standard_key: NIST-800-53 -- control_key: AT-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - The 18F Program Office develops, documents, and disseminates to all 18F staff - The 18F Security Awareness policy which addresses purpose, scope, roles, - responsibilities, management commitment, coordination among organizational - entities, and compliance and procedures to facilitate the implementation of the - security awareness access and training policy and associated security awareness - controls. The 18F accecss control policy is listed within its private Github - repository that is accessible to all 18F staff. - - key: b - text: | - The 18F Program Office will review and update the current 18F Security Awareness - and training control policy at least every 3 years and any documented access - procedures at least annually. - standard_key: NIST-800-53 -- control_key: AT-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: The 18F Program office reviews AT-2 - standard_key: NIST-800-53 -- control_key: AT-2 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: The 18F Program office reviews AT-2 - standard_key: NIST-800-53 -- control_key: AT-4 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Completed the development of the Awareness training policy specifically - for 18F program. ISSO support is looking into possible solutions for specific - security awareness training for 18F staff. currently reviewing the SEI training - programs for Secure DevOps and Online line Learning management system. - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/AT-Policy.md - type: URL -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.456091 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/AU_policy/component.yaml b/docs/security/AU_policy/component.yaml deleted file mode 100644 index 5894836b963..00000000000 --- a/docs/security/AU_policy/component.yaml +++ /dev/null @@ -1,252 +0,0 @@ -documentation_complete: false -name: Audit and Accountability Policy for 18F -satisfies: -- control_key: AU-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: complete - narrative: - - key: a - text: | - The 18F Program Office develops, documents, and disseminates to all 18F staff, - The 18F Audit and Accountability Policy which addresses purpose, scope, roles, - responsibilities, management commitment, coordination among organizational entities, - compliance and procedures to facilitate the implementation of the audit and - accountability policy and associated audit controls. The 18F Audit and Accountability - policy is listed within 18F's private Github repository and the docs.cloud.gov site - that is accessible to all 18F staff. - - key: b - text: | - The 18F Program Office will review and update the current 18F Audit control policy - at least every 3 years and any documented audit procedures at least annually. - standard_key: NIST-800-53 -- control_key: AU-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: complete - narrative: - - key: b - text: | - Audit logs will be made available to organizations for mutual support in - response to security breaches, system and user access, incident reporting and - continuous monitoring. 18F will generate and distribute audit reports, provide - customized dashboard access for audited events, and send audit log data to SIEM - and log analysis systems from its audit logging and metrics tools for the - cloud.gov platform and virtual infrastructure as needed. - - key: c - text: | - 18F retains audit logs according to NARA retention standards to provide support - for after-the-fact investigations of security incidents and to meet regulatory - and organizational information retention requirements. The log management - framework will provide the capability to retain logs for 90 days online and - one-year offline, with sufficient capacity as to mitigate the risk of exceeding - storage space. - - Specific Policies, Procedures, Points of Contact, and Guidance will be established - between 18F and other agencies to support after-the-fact investigations, by the - 18F Project Lead. - standard_key: NIST-800-53 -- control_key: AU-2 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - The Devops and SecOps teams review all events that can be audited on a real time - basis using its event and monitoring solution for cloud.gov and through captured - user and event API calls within its virtual infrastructure. - standard_key: NIST-800-53 -- control_key: AU-3 (1) - covered_by: [] - implementation_status: none - narrative: - - text: | - The cloud.gov system includes more detailed information in the audit events - identified by type, location or subject. The Loggregator component of cloud.gov - produces additional information based on the log type and origin of the logs. - - There are six log types within cloud.gov: - - - API - logs all API calls from a user - - STG - logs when staging or restaging an app - - DEA - logs when the Droplet excution agent starts and stops an app - - RTR - logs when it routes HTTP requests to the application - - LGR - logs when there are problems with the logging process itself - - APP - logs all application data based on choices by the developer - - All of the audit logs from cloud.gov are drained to the - ELK Stack which has even more versitility in producing additional audit capabilities - for the 18FDevOps and SecOps team for reivew. - standard_key: NIST-800-53 -- control_key: AU-4 - covered_by: [] - implementation_status: none - narrative: - - text: | - cloud.gov audit logs are stored within the elasticsearch component of - the ELK stack which is clusterd for redundancy and failover functions. This solutions - provide the capability to extend the audit storage capacity without the likelihood - of the capacity being exceeded. 18F plans to incorporate the use of the S3 cloud - service for greater storage capacity if needed. - standard_key: NIST-800-53 -- control_key: AU-5 - covered_by: [] - implementation_status: none - narrative: - - text: | - In progress - standard_key: NIST-800-53 -- control_key: AU-6 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - AWS Auditable Events: - DevOps and SecOps teams will conduct weekly manual and automated continuous - audits of authorized accounts and configurations. These audits will include - but are not limited to: - - Administrative Accounts - - * Virtual Private Cloud (VPC) - * Elastic Compute Cloud (EC2) - * Simple Storage Service (S3) - * Identity and Access Management (IAM) - * Elastic Block Store (EBS) - - Cloud Foundry Auditable Events: - By default, Loggregator streams logs to a terminal. 18F will drain logs to - a third-party log management service such as ELK and AWS CloudTrail Cloud - Foundry logs are captured in multiple tables and log files. These will be - reviewed weekly and if discovery of anomalous audit log content which appears - to indicate a breach are handled according to the GSA Security Incident - Handling Guide: CIO IT Security 01-02 Revision 7 (August 18, 2009) requirements. - - key: b - text: | - When a credible source to the GSA Agency provides information that causes - reason to enhance audit activities, develop and implement an enhanced auditing - use-case that will adequately enhance auditing practices in a fashion necessary - per the identified threat and following the Incident Reporting Procedures in - GSA IT Security Procedural Guide 01-02 (04/07/2015), Incident Response. The GSA - Agency may also, through analysis pertaining to the GSA Agency environment - provide additional audit measures that will require an increase in review, - analysis, and reporting for a necessary. - - Upon implementation, 18F will monitor information security news and alerts for - indications of a need to heighten information system security monitoring. - standard_key: NIST-800-53 -- control_key: AU-6 (1) - covered_by: - - verification_key: POLICY_DOC - narrative: - - text: | - Audit Monitoring, Analysis and Reporting - - * 18F establishes processes for regularly reviewing audit log information, and - reporting security issues if discovered. Reviews will occur at a minimum of - weekly. These processes should be integrated with processes for incident - response, in order to ensure standardization and cross-functional collaboration - * 18F employs automated mechanisms to integrate audit monitoring, analysis and - reporting into an overall process for investigation and response to suspicious - activities. - * 18F employs automated mechanisms to immediately alert security personnel of - inappropriate or unusual activities that have security implications. - standard_key: NIST-800-53 -- control_key: AU-6 (3) - covered_by: - - verification_key: POLICY_DOC - narrative: - - text: | - Audit Monitoring, Analysis and Reporting - * 18F establishes processes for regularly reviewing audit log information, and - reporting security issues if discovered. Reviews will occur at a minimum of - weekly. These processes should be integrated with processes for incident response, - in order to ensure standardization and cross-functional collaboration - * 18F employs automated mechanisms to integrate audit monitoring, analysis and - reporting into an overall process for investigation and response to suspicious - activities. - * 18F employs automated mechanisms to immediately alert security personnel of - inappropriate or unusual activities that have security implications. - standard_key: NIST-800-53 -- control_key: AU-7 - covered_by: [] - implementation_status: none - narrative: - - text: | - The ELK Stack logging and monitoring system provides additional audit - reduction and report generation capabilities for 18F DevOps and end users of the - cloud.gov platform. With the elasticsearch capability 18F DevOps and SecOps teams - can structure and customize audit logs queries to specific app instances, API - calls, system metrics, user access, system components, network traffic flow and - other functions. Kibana is used to generate customized dashboards and Logstash - to generate reports for analysis and review. - standard_key: NIST-800-53 -- control_key: AU-7 (1) - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -- control_key: AU-8 - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -- control_key: AU-8 (1) - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -- control_key: AU-9 - covered_by: [] - implementation_status: none - narrative: - - text: | - Audit logs are stored and protected in specified S3 buckets and elasticsearch - clusters for cloud.gov. Access to logs are limited to designated 18F DevOps and - Security staff and logs cannot be modified without proper authorization to the - platform. Client agencies are restricted to access and view only their specified - audit logs pertaining to the corresponding Org and space accounts. - standard_key: NIST-800-53 -- control_key: AU-9 (2) - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -- control_key: AU-9 (4) - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -- control_key: AU-11 - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -- control_key: AU-12 - covered_by: [] - implementation_status: none - narrative: - - text: In Progress - standard_key: NIST-800-53 -schema_version: 3.0.0 -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/AU-Policy.md - type: URL -- description: "GIVEN the github link - THEN the policy has been updated\ - \ within the last 180 days \n" - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.473505 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/CA_policy/component.yaml b/docs/security/CA_policy/component.yaml deleted file mode 100644 index df34857b705..00000000000 --- a/docs/security/CA_policy/component.yaml +++ /dev/null @@ -1,200 +0,0 @@ ---- -schema_version: 3.0.0 -documentation_complete: false -name: Security Assessment and Authorization Policy for 18F -satisfies: -- control_key: CA-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - The 18F Program Office develops, documents, and disseminates to all 18F staff. The 18F Security Assessnet and authorization policy which addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance and procedures to facilitate the implementation of the security assessment and authroization policy and associated security assessnet controls. The 18F security assessnet and authorization policy is listed within its private Github repository that is accessible to all 18F staff. - - key: b - text: | - The 18F Program Office will review and update the current 18F Security Assessment policy at least every 3 years and any documented assessment procedures at least annually. - standard_key: NIST-800-53 -- control_key: CA-2 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F will accept the results of the Login.gov assessment performed by the designated 3PAO and reviewed by the FedRAMP PMO office when the assessment meets the condtions for a Provisional ATO. - standard_key: NIST-800-53 -- control_key: CA-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - The 18F Program develops a security assessment plan that describes the scope of the assessment including: - - * Security controls and control enhancements under assessment - * Assessment procedures to be used to determine security control effectiveness - * Assessment environment, assessment team, and assessment roles and responsibilities - - Login.gov is designed for compliance with the Federal Risk and Authroization Management Plan and has adopted the FedRAMP Assessment and Authorization program as the basis for its Security and Priavacy compliance activities. Login.gov engages a FedRAMP Accredited Third Pary Assessment Organzation (3PAO) to develop a compliant security assessment plan. - - key: b - text: | - Login.gov has engaged the 3PAO to assess the security controls in the information system at least annually to determine the extent to which the controls are implemented correctly, operation as intended, and producing the desired outcome with respoect to meeting the security requirements for the system. - - key: c - text: | - Login.gov has engaged the 3PAO to produce a security assessment report that documents the issues, test activities, findings, and recommendations from the assessment. - - key: d - text: | - 18F will deliver all documents used in or created during the assessment to generate a complete FedRAMP Authorization package. The package is transmitted to the FedRAMP Program Management Office (PMO) for submission to the FedRAMP JAB - standard_key: NIST-800-53 -- control_key: CA-2 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: 18F will enegage the 3PAO to conduct annual vulnerability assessments and penetration testing or when there are significant changes to its information systems to meet the FedRAMP continuous monitoring program objectives. All assessment activities will be planned, approved and announced before testing takes place. - standard_key: NIST-800-53 -- control_key: CA-2 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: 18F has engaged an accredited 3PAO to conduct the independent assessment of security controls for the Login.gov information system. - standard_key: NIST-800-53 -- control_key: CA-2 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: Login.gov implements continuous monitoring and vulnerability scanning that is conducted at least weekly. Manual penetration testing and red teaming is scheduled to happen in a yearly basis but it is an in-progress process. - standard_key: NIST-800-53 -- control_key: CA-2 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: 18F will accept the assesment conducted by the 3PAO according to the FedRAMP P-ATO requirements in the Secure Repository. - standard_key: NIST-800-53 -- control_key: CA-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: The Login.gov informaton system does not have any connections to other external information systems or interconnection security agreements (ISA) with other external agencies at this time. - standard_key: NIST-800-53 -- control_key: CA-3 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: This control is not applicable to the Login.gov information system and essentially would be inherited from the cloud infrastructure as a service level. Login.gov does not connect to any other external information systems. - standard_key: NIST-800-53 -- control_key: CA-3 (5) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: This control is not applicable to the Login.gov information system. Login.gov currently does not have any connections to other external information systems. - standard_key: NIST-800-53 -- control_key: CA-5 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F has developed a plan of action and milestones (POA&M) for the information system which documents the remediation actions to correct weaknesses found or deficiencies noted during the assessment of the security controls and to reduce or eliminate known vulnerabilities. - - The majority of vulnerabilities are found during continuous monitoring activities including monthly vulnerability scanning, updates to Login.gov systems components, static code analysis on applications and infrastucture and system monitoring tools. The 18F ISSOs are tasked with developing plans of actions and milestones for valid findings and vulnerabilities. The devops administrators are tasked to mitigate high findings within 30 days, moderate findings within 60 days and low findings within 120 days. - - key: b - text: The 18F ISSOs updates the Login.gov plan of action and milestones at least monthly based on the findings from security controls assessments, security impacy analysis, and continuous monitoring activites. - standard_key: NIST-800-53 -- control_key: CA-6 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: 18F has assigned an Authorizing Official (AO) for the Login.gov information system. The designated AO is listed in Section 4 of the system security plan. - - key: b - text: The Authorizing Official responsibilities include ensuring the Login.gov information system is assessed and authorized before going to an operational state. Authorization descisions are based on the contenct of them. - - key: c - text: 18F updates the security authorzation of Login.gov on an annual basis or when there are significant changes within the information system. Significant changes include, - standard_key: NIST-800-53 -- control_key: CA-7 - covered_by: [] - implementation_status: none - narrative: - - key: a - text: The organization-defined metrics are collected by a combination of AWS CloudWatch (in real time, CPU Utilization, Disk IO, Network In/Out), application logging policy (see AU-2) and a vulnerability scanner. - - key: b - text: AWS CloudWatch Metrics (CPU Utilization, Disk IO, Network In/Out) are collected in real time. Other metrics are collected in frequencies ranging between 5 minutes and 1 hour. Host vulnerability scans are run daily. - - key: c - text: Compliance with security controls that can be tested from the operating system level (eg. presence of configuration settings, etc) are monitored and automatically corrected as part of configuration management. Non-automated security processes are handled by the Login.gov operations team. - - key: d - text: See CA-7(c) - - key: e - text: See CA-7(c) - - key: f - text: Response actions will use the mitigation strategy defined in RA-5(d). - - key: g - text: Reporting of the security status of the system will be provided by the Login.gov team according to the Federal and FedRAMP requirements on a monthly basis. - standard_key: NIST-800-53 -- control_key: CA-7 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: 18F will engage an accredited 3PAO to conduct the independent assessment of security controls for the Login.gov information system on a yearly basis. - standard_key: NIST-800-53 -- control_key: CA-8 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: GSA ISE will perform Penetration testing of the all 18F systems that are in the purview of GSA. All other penetration testing for the Login.gov platform will be conducted by an Independent Third party assessor (3PAO) as requested. - standard_key: NIST-800-53 -- control_key: CA-8 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - External Penetration testing - - External penetration testing activities are conducted by GSA OCISO on an annual basis. These activites are designed to perform the necessary vulnerability analysis against Login.gov based on all necessary security requirements. The GSA OCISO follows the GSA CIO IT Security Procedural Guide, CIO-IT Security-11-51, Conducting Penetration Test Exercises when performing these tests. - - 18F must request permission from AWS using the AWS Vulnerability / Penetration Testing Request Form to conduct penetration test activities against its own Virtual Private Cloud infrastructure and follow the AWS Acceptable Use Policy. - Amazon requires customers to obtain authorization for penetration testing (or vulnerability assessments) both from or to their AWS resources. - - AWS Acceptable Use Policy, http://aws.amazon.com/aup/ - AWS Penetration testing, http://aws.amazon.com/security/penetration-testing/ - - GSA ISE performs penetration testing services for the GSA information systems hosted on the Login.gov platform. It is also bound by the AWS penetration testing policy and procedures when conducting its penetration tests. - - Internal Penetration testing - - For internal penetration testing inside 18F's Virtual Private Cloud, 18F team members will conduct whitebox/greybox testing of the 18F environment using approved assessment tools. - - For compliance with NIST Publication 800-53 CA-8, Parameter 1 Penetration Testing of all 18F Infrastructure and Application Components will occur annually. Parameter 2 Penetration Testing of Publicly Accessible Infrastructure will be performed on the direction of the 18F . - standard_key: NIST-800-53 -- control_key: CA-9 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: In progress - standard_key: NIST-800-53 -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/CA-Policy.md - type: URL -- description: "GIVEN the github link - THEN the policy has been updated - within the last 180 days" - key: Policy_Update_Test - last_run: 2016-04-07 08:25:17.527067000 -05:00 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/CM_Policy/component.yaml b/docs/security/CM_Policy/component.yaml deleted file mode 100644 index cea98ee14ef..00000000000 --- a/docs/security/CM_Policy/component.yaml +++ /dev/null @@ -1,214 +0,0 @@ -documentation_complete: false -name: Configuration Management Policy for 18F -satisfies: -- control_key: CM-1 - covered_by: [] - implementation_status: none - narrative: - - key: a - text: | - Agency Configuration Management Policy - The GSA CM policy is defined in the GSA IT Security Policy (CIO P 2100.1), which addresses purpose, scope, roles, - responsibilities, and compliance for CM activities. - The DHS Office of the CISO is responsible for publishing the above documents to System Program Managers and Information - System Security Officers and Managers (ISSO/Ms) on a centralized, agency-accessible website. - CM procedures are documented in the GSA IT Security Procedural Guide: Managing Enterprise Risks (CIO IT Security-06-30). - The 18F Program Office develops, documents, and disseminates to all 18F staff - The 18F configuration management policy which addresses purpose, scope, roles, responsibilities, management commitment, - coordination among organizational entities, and compliance and procedures to facilitate the implementation of the - configuration management policy and associated configuration controls. The 18F security assessment and authorization - policy is listed within its private GitHub repository https://github.com/18F/compliance-docs/blob/master/CM-Policy.md - that is accessible to all 18F staff. - - key: b - text: | - The DHS Office of the CISO is responsible for reviewing and updating the above documents annually, and notifying - System Program Managers and Information System Security Officers and Managers (ISSO/Ms). - The 18F Program Office will review and update the current 18F configuration management policy at least every 3 years - and any documented configuration procedures at least annually. - standard_key: NIST-800-53 -- control_key: CM-2 - covered_by: [] - implementation_status: none - narrative: - - text: | - For AWS Baseline Configurations: - AWS Cloud Formation templates, CIS Level 1 benchmarks and any GSA/18F benchmarks such as hardening guidelines - and baselines are the approved baseline for all changes to the infrastructure and simplify provisioning and management - on AWS. They provide an automated method to assess the status of an operational infrastructure against an approved - baseline. - Windows and Linux instances are based on the standard AWS AMI images in accordance with DHS configuration requirements. - - Note: Additional OS/Device-specific industry standards and guidance may also be used whenever appropriate. It is - understood that when industry standards are adopted they may need to be adapted for the specific implementation - and if/where this has occurred it should be mentioned/referenced. 18F ensures that the most current, relevant - OS/Device-specific industry standards and guidance is maintained where appropriate to support Login.gov configurations. - These best practice updates are captured during the annual review of the CM Policy which also incorporates 18 procedures. - standard_key: NIST-800-53 -- control_key: CM-2 (1) - covered_by: [] - implementation_status: none - narrative: - - key: a - text: | - The 18F PMO must review baseline configuration changes at a minimum on an annual basis and on an as needed basis as - a result of any significant change that impacts risk to the system, security audits or industry guidance. - - key: b - text: | - The 18F PMO reviews and updates the baseline configuration of the information system when required by the DHS Authorizing Officals. Significant change may result from, but are not limited to, multiple required changes occurring simultaneously, - changes that impact/modify security settings, and/or major component additions and/or upgrades. - Such changes will go - through the 18F CM Process, presented to the DHS assigned ISSO and if applicable, be submitted to the DHS for - review, vetting acceptability and to ensure ongoing acceptance of security control implementation(s). - - key: c - text: | - 18F reviews all baseline configurations when there is a significant change to the Login.gov system architecture or - when its components undergo installation or upgrades. - standard_key: NIST-800-53 -- control_key: CM-2 (2) - covered_by: [] - implementation_status: none - narrative: - - text: | - Configuration management at the AWS level is managed through Terraform configuration files, AWS Config? and VisualOps?. 18F maintains baseline configurations for VPC, EBS, EC2 instances and AMIs. Terraform configuration files help maintains a strict configuration management scheme of the Login.gov. Because these templates are text files, 18F can simply track differences in these templates to track changes to its infrastructure. - For Login.gov, an operator initiates a new deployment using the Capistrano. Automated Configuration of Login.gov platform - components is handled by the Travis.ci, a continuous integration and deployment tool which utilizes the Login.gov - AWS FISMA hardened Ubuntu AMI. - standard_key: NIST-800-53 -- control_key: CM-2 (3) - covered_by: [] - implementation_status: none - narrative: - - text: | - If there is any manual change on any part of the infrastructure Terraform will correct the settings and revert back to the known state. - standard_key: NIST-800-53 -- control_key: CM-2 (7) - covered_by: [] - implementation_status: none - narrative: - - key: a - text: | - This control is Not Applicable (NA) for the Login.gov information system. Per Federal policy 18F employees are not allowed to take equipment outside of the United States without explicit permission. - - key: b - text: | - This control is NA for the Login.gov information system. Per Federal policy 18F employees are not allowed to take equipment outside of the United States without explicit permission. - standard_key: NIST-800-53 -- control_key: CM-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - All Configuration Change control: - Login.gov team provisions its infrastructure with Terraform configuration files. These - tools use configuration files to describe the components to build with exactly what resources are provisioned and their settings. - Because these files are text files, 18F can simply track differences in - these templates to track changes to its infrastructure, similar to the way - developers control revisions to source code. - Login.gov team uses version control systems to manage changes to Login.gov systems and to determine exactly what changes were made, who made them, and when. If at any point Login.gov admin team needs to revert changes to infrastructure, you can use a previous version of a configuration templates. - Login.gov team uses GitHub for additional tracking and documenting of authorized changes - within the infrastructure. Within GitHub, a diff function is used to compare and contrast any changes made to configurations of Login.gov. - - key: b - text: | - Login.gov team reviews proposed configuration-controlled changes to all of its information systems and infrastructure and approves or disapproves such changes with explicit consideration for security impact analysis within the Virtual Private Cloud - environment. All reviews and approvals are conducted within 18Fs GitHub ticketing - and tracking system. - - key: c - text: | - Login.gov team uses the following methods to document configuration change decisions - associated with its information systems. For changes related to the its - virtual infrastructure, Login.gov operator manages configuration changes which are documented, approved and tracked within GitHub. - All Login.gov configuration changes are documented, approved and tracked within 18F's GitHub site. All configuration changes related to applications and websites hosted within the 18F AWS environment are requested by the systems owner and approved by Login.gov operators within the 18F GitHub tracking systems. - - key: d - text: | - When configuration changes have been approved through 18F's GitHub - ticketing and tracking system, the Login.gov operators team implements approved configuration-controlled changes to the information system and then provides a status of the changes completed and closes out the ticket. - - key: e - text: | - Records of configuration-controlled changes are retained for at least 1 year in accordance with the 18F Configuration Management policy and utilizing the 18F GitHub site and S3 to retain all changes requested, approved, disapproved, implemented and pending. - - key: f - text: | - Audits for the virtual infrastructure are conducted by Login.gov operators, and ISSOs of all configuration-controlled changes to the information - system. These audits take place no less than once a month and are documented - in the GitHub ticketing and tracking system, per the 18F Configuration - management policy Section 3 which states 18F will conduct a monthly audit of information system which identifies and eliminates unnecessary functions, ports, protocols, and/or services. - - key: g - text: | - Login.gov team coordinates and provides oversight for configuration change control activities through its GitHub tracking and ticketing systems and Slack communications channel which is integrated with GitHub that convenes whenever there are significant and pending changes to the 18F security, cloud infrastructure and applications. - standard_key: NIST-800-53 -- control_key: CM-6 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov team uses established and documents configuration settings - for its information technology products employed within the AWS that reflect the most restrictive mode consistent with operational requirements. - 18F follows industry best practices and guidance provided in NIST Special Publication 800-70, Security Configuration Checklist Program for IT Products - - Infrastructure documented configuration settings: - Login.gov operators maintain the baseline configuration for VPC, EBS and AMIs. Best practices, FISMA compliant AMIs, and hardened cloud formation templates are utilized as there are no benchmarks available. Login.gov uses the following approved FISMA ready baselines located at - https://github.com/fisma-ready - Login.gov documented configuration settings: - Login.gov team follows industry best practices for configuring and implementing an identity platform. - Configuration settings are documented within the deployment manifest on the GitHub. - - key: b - text: | - 18F Implements the configuration settings based on its documented process and practices. Login.gov operators implement the configuration benchmarks identified in Part a, maintains the baseline configuration for all cloud infrastructure and is responsible - for ensuring all systems are configured in accordance with applicable hardening - guides. - - key: c - text: | - Login.gov operators document any exceptions to established baseline - configurations for all of it's AWS virtual infrastructure and information systems. - 18F maintains exception documents which detail specific items from the established - configuration settings which cannot be applied to instances due to operational - requirements. - - key: d - text: | - 18F Monitors and controls changes to the configuration - settings in accordance with its documented configuration management policy and - procedures. - All Configuration Change Control: - Login.gov operators maintain the baseline configurations within - it's VPC. Configuration will be reviewed in real-time using - automated methods and at least quarterly to ensure no unauthorized changes - were made to the baseline configuration. - Internal vulnerability scans are performed at least on a quarterly basis in the - event that no enhancements or upgrades are performed. - standard_key: NIST-800-53 -- control_key: CM-8 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F posts its current inventory of information systems on its dashboard - located at https://18f.gsa.gov/dashboard/. Several sources are used to capture - complete inventories of the virtual infrastructure and its information systems - while providing the level of granularity deemed necessary for tracking and reporting. - The AWS Management Console, and Github are used to provide additional enumeration capabilities. - - The 18F GitHub repository also is used to show a current lists of components that make up the Login.gov inventory [NEED TO DO] - - This includes all information system within the VPCs and components within the Login.gov platform as a service. - - Login.gov operators continuously maintains inventory of all instances and configuration. - Login.gov operators review and update the information system component inventory - on a monthly basis and updates the inventory of information system whenever installations, removals, and other changes are made. Login.gov operators will verify that all components within the authorized boundary of the information system are either inventoried as part of the system or recognized by another system as a component within that systems inventory. - standard_key: NIST-800-53 -schema_version: 3.0.0 -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/CM-Policy.md - type: URL -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.581078 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/CP_policy/component.yaml b/docs/security/CP_policy/component.yaml deleted file mode 100644 index d97c6b76177..00000000000 --- a/docs/security/CP_policy/component.yaml +++ /dev/null @@ -1,26 +0,0 @@ -documentation_complete: false -name: Contingency Planning Policy for 18F -satisfies: -- control_key: CP-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F Policy - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -references: -- name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/CP-Policy.md - type: URL -verifications: -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.622244 - name: 18F Policies Update - path: https://github.com/18F/cg-compliance/blob/master/BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/IA_policy/component.yaml b/docs/security/IA_policy/component.yaml deleted file mode 100644 index 958cb35f0d5..00000000000 --- a/docs/security/IA_policy/component.yaml +++ /dev/null @@ -1,221 +0,0 @@ ---- -documentation_complete: false -name: Identification and Authentication Policy for 18F -satisfies: -- control_key: IA-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - The 18F Program Office develops, documents, and disseminates to all 18F staff the 18F Identification and Authentication Policy which addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, compliance, and procedures to facilitate the implementation of the identification and authentication policy and associated identification controls. The 18F Identification and Authentication Policy is listed within 18F's private GitHub repository and the docs.cloud.gov site that is accessible to all 18F staff. - - key: b - text: | - The 18F Program Office will review and update the current 18F Identification and Authentication Policy at least every three years and any documented identification and authentication procedures at least annually. - standard_key: NIST-800-53 -- control_key: IA-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - The cloud.gov platform delegates authentication to either the GSA enterprise system or GitHub for any administrator access. - standard_key: NIST-800-53 -- control_key: IA-2 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Multifactor authentication is enforced both in the GSA enterprise login system and GitHub. - standard_key: NIST-800-53 -- control_key: IA-2 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Non-privileged accounts can be delegated to enterprise user systems that have multifactor authentication. - standard_key: NIST-800-53 -- control_key: IA-2 (5) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - NA - Local access is treated the same as remote access. See IA-2 (1). - standard_key: NIST-800-53 -- control_key: IA-2 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - NA - Only individual authentication is allowed. - standard_key: NIST-800-53 -- control_key: IA-2 (8) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - cloud.gov implements UAA which has session tokens and CSRF prevention that prevents replay attacks. - standard_key: NIST-800-53 -- control_key: IA-2 (11) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to multiple separate single sign on (SSO) systems which implement multifactor in multiple ways. - standard_key: NIST-800-53 -- control_key: IA-2 (12) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to multiple separate single sign on (SSO) system which implement multifactor that may or may not include PIV cards. - standard_key: NIST-800-53 -- control_key: IA-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - cloud.gov monitors and tracks all network connections using AWS VPC flow logs, router access logs, and application access logs. cloud.gov assigns each connection a unique identifier and tracks it across queries. - standard_key: NIST-800-53 -- control_key: IA-4 - covered_by: [] - implementation_status: none - narrative: - - text: | - The 18F Identification and Authentication Policy section 3 Identifier Management states: - Identifier Management: - 18F manages information system identifiers for users and devices by: - * Receiving authorization from a designated organizational official to assign a user or device identifier. - * Selecting an identifier that uniquely identifies an individual or device. - * Assigning the user identifier to the intended party or the device identifier to the intended device. - * Preventing reuse of user or device identifiers for one (1). - * Disabling the user identifier after ninety (90) days of inactivity for general user accounts and thirty (30) days for administrator level accounts. - standard_key: NIST-800-53 -- control_key: IA-4 (4) - covered_by: [] - implementation_status: none - narrative: - - text: | - 18F manages individual identifiers that uniquely identify individuals as employees, contractors, or foreign nationals. - standard_key: NIST-800-53 -- control_key: IA-5 - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (1) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (2) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (3) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (4) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (6) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (7) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-5 (11) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-7 - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -- control_key: IA-8 - covered_by: [] - implementation_status: none - narrative: - - text: | - Every user has an individual account and their source is tracked to the main authentication system. - standard_key: NIST-800-53 -- control_key: IA-8 (1) - covered_by: [] - implementation_status: none - narrative: - - text: | - PIV verification is subject to the delegated enterprise SSO system. - standard_key: NIST-800-53 -- control_key: IA-8 (2) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov does not accept third-party credentials. - standard_key: NIST-800-53 -- control_key: IA-8 (3) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov does not accept third-party credentials. - standard_key: NIST-800-53 -- control_key: IA-8 (4) - covered_by: [] - implementation_status: none - narrative: - - text: | - NA - cloud.gov delegates authentication to an enterprise single sign on (SSO) system. - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/IA-Policy.md - type: URL -- description: "GIVEN the github link - THEN the policy has been updated within the last 180 days" - key: Policy_Update_Test - last_run: 2016-04-07 08:25:17.630024000 -05:00 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/IR_policy/component.yaml b/docs/security/IR_policy/component.yaml deleted file mode 100644 index 96ef122211a..00000000000 --- a/docs/security/IR_policy/component.yaml +++ /dev/null @@ -1,23 +0,0 @@ -documentation_complete: false -name: Incident Response for 18F -satisfies: -- control_key: IR-1 - covered_by: [] - implementation_status: none - narrative: 18F Policy - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/IR-Policy.md - type: URL -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.644608 - name: 18F Policies Update - path: https://github.com/18F/cg-compliance/blob/master/BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/MA_policy/component.yaml b/docs/security/MA_policy/component.yaml deleted file mode 100644 index 9f0c9cd70b1..00000000000 --- a/docs/security/MA_policy/component.yaml +++ /dev/null @@ -1,25 +0,0 @@ -documentation_complete: false -name: System Maintenance Policy for 18F -satisfies: -- control_key: MA-1 - covered_by: [] - implementation_status: none - narrative: - - text: | - 18F Policy - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/MA-Policy.md - type: URL -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.652660 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/MP_policy/component.yaml b/docs/security/MP_policy/component.yaml deleted file mode 100644 index 07239973493..00000000000 --- a/docs/security/MP_policy/component.yaml +++ /dev/null @@ -1,23 +0,0 @@ -documentation_complete: false -name: Media Protection Policy for 18F -satisfies: -- control_key: MP-1 - covered_by: [] - implementation_status: none - narrative: 18F Policy - standard_key: NIST-800-53 -schema_version: 2.0 -system: 18F -verifications: -- key: POLICY_DOC - name: Policy Document - path: https://github.com/18F/compliance-docs/blob/master/MP-Policy.md - type: URL -- description: "GIVEN the github link - THEN the policy has been updated\ - \ within the last 180 days \n" - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.675575 - name: 18F Policies Update - path: https://github.com/18F/cg-compliance/blob/master/BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/PL_policy/component.yaml b/docs/security/PL_policy/component.yaml deleted file mode 100644 index 4b247853949..00000000000 --- a/docs/security/PL_policy/component.yaml +++ /dev/null @@ -1,47 +0,0 @@ -documentation_complete: false -name: Security Planning Policy for 18F -satisfies: -- control_key: PL-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F Policy - standard_key: NIST-800-53 -- control_key: PL-8 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F has developed the system security plan (SSP) for Login.gov containing the information security architecture for the information system that: - - Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information - - Describes how the information security architecture is integrated into and supports the enterprise architecture - - Describes any information security assumptions about, and dependencies on, external services - - key: b - text: | - 18F Reviews and updates the information security architecture within the System Security plans and the 18F GitHub repository on an annual basis or when a significant change takes place to reflect updates in the enterprise architecture. - - Due to the dynamic and elastic nature of cloud computing, 18F monitors real-time updates of its information security architecture using its infrastructure management and visual security consoles. - - key: c - text: | - 18F ensures that planned information security architecture changes are reflected in the security plan and organizational procurements/acquisitions. - 18F follows the risk management framework (RMF) which includes conducting annual risk assessments for its information systems and infrastructure. Any changes are then updated in systems security plans, plan of actions and milestones POA&Ms, security assessment reports (SAR) - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: policy document - path: https://github.com/18f/compliance-docs/blob/master/PL-Policy.md - type: url -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.693033 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/PS_policy/component.yaml b/docs/security/PS_policy/component.yaml deleted file mode 100644 index 9192627938f..00000000000 --- a/docs/security/PS_policy/component.yaml +++ /dev/null @@ -1,25 +0,0 @@ -documentation_complete: false -name: Personnel Security Policy for 18F -satisfies: -- control_key: PS-1 - covered_by: [] - implementation_status: none - narrative: - - text: | - 18F Policy - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: policy document - path: https://github.com/18f/compliance-docs/blob/master/PS-Policy.md - type: url -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.707361 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/RA_policy/component.yaml b/docs/security/RA_policy/component.yaml deleted file mode 100644 index 78664743fb8..00000000000 --- a/docs/security/RA_policy/component.yaml +++ /dev/null @@ -1,46 +0,0 @@ -documentation_complete: false -name: Risk Assessment Policy for 18F -satisfies: -- control_key: RA-1 - covered_by: [] - implementation_status: none - narrative: - - text: | - 18F Policy - standard_key: NIST-800-53 -- control_key: RA-5 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F Conducts monthly Operating System (OS) and web application scanning; quarterly database scanning; and, OS and Web application scanning with every code release. 18F conducts internal vulnerability scanning of its VPC and private subnets within the 18F Virtual Private Cloud. - - key: b - text: | - 18F vulnerability scanning tools utilize techniques that promote interoperability such as Common Vulnerability Scoring System v2 (CVSS2), Common Platform Enumeration (CPE), and Common Vulnerability Enumeration (CVE) and OWASP TOP 10 vulnerabilities. - - key: c - text: | - 18F Analyzes vulnerability scan reports from its vulnerability scanning tools assessments at least weekly and appropriate actions taken on discovery of vulnerabilities within the 18F Cloud Infrastructure and applications and from security control assessments conducted on its information systems. - - key: d - text: | - High-risk vulnerabilities are mitigated within thirty days (30); moderate risk vulnerabilities mitigated within ninety days (90). If the recommended steps will adversely impact functionality or performance, the ISSO/ISSM will reviews changes and mitigating controls with 18F DevOps as well as the Cloud Foundry system owners. - - key: e - text: | - 18F shares information obtained from the vulnerability scanning process and security control assessments with designated System Owners, DevOps, GSA SecOps, ISSM and the Authorizing Official (AO) to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies). - standard_key: NIST-800-53 -schema_version: 3.0.0 -system: 18F -verifications: -- key: POLICY_DOC - name: policy document - path: https://github.com/18f/compliance-docs/blob/master/RA-policy.md - type: url -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.715124 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/SA_policy/component.yaml b/docs/security/SA_policy/component.yaml deleted file mode 100644 index e7c8dab1d4c..00000000000 --- a/docs/security/SA_policy/component.yaml +++ /dev/null @@ -1,399 +0,0 @@ -schema_version: 3.0.0 -documentation_complete: false -name: System and Services Acquisition Policy for 18F -satisfies: -- control_key: SA-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: |- - Agency System Maintenance Policy Implementation - - System Maintenance Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 4. Policy on Operational Controls. It states, "The availability and usability of GSA equipment and software must be maintained and safeguarded to enable agency objectives to be accomplished." - - GSA OCISO ISP also defined agency-wide system maintenance procedures in IT Security Procedural Guide: Maintenance (CIO-IT Security-10-50). - - 18F follows the GSA System Maintenance policy for its information systems hosted within GSA facilities. The Login.gov information system is hosted with the AWS GovCloud and will be in purview of the hosting site’s Maintenance policy and procedures. - - key: b - text: |- - The GSA Office of the CISO is responsible for reviewing and updating the above documents annually, and notifying System Program Managers and Information System Security Officers and Managers (ISSO/Ms). The GSA OCISO has determined SA-1 to be an Enterprise-Wide Common Control and is provided by the OCISO ISP. For specific details, please refer to the GSA IT FY-15 Information Security Program Plan Version 1.0. - standard_key: NIST-800-53 -- control_key: SA-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: |- - The Login.gov team does two-week sprints. Before each sprint, we look at open tasks and prioritize, including security needs. The team also hires for security expertise specifically. - - key: b - text: |- - Determines, documents, and allocates the resources required to protect the information system or information system service as part of its capital planning and investment control process - - key: c - text: |- - Establishes a discrete line item for information security in organizational programming and budgeting documentation. - standard_key: NIST-800-53 -- control_key: SA-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F practices the Scrumban process when developing new features or fixing existing issues, including security fixes and enhancements for Login.gov. Each feature or issue is assigned to a card in the system, where it goes through a process of being identified, prioritized, explored, delivered, and finally demonstrated. Each card is reviewed by the team as a whole throughout its lifecycle to identify any security risks or concerns, which are recorded on the card as "acceptance criteria" that must be addressed before development is complete. - - Once development is complete, a team member submits the code to our version control system as a "pull request", where at least one other team member further reviews it before merging it into the code base. The team then deploys new features into our staging area where they undergo further security review and stakeholder acceptance testing, as well as automated acceptance tests. - - key: b - text: | - The Login.gov operations team is broken into several sub-teams with different areas of responsibility and expertise. Security is a foremost concern for members of all teams. The Login.gov operations team is primarily focused on implementing security policies at the platform level. - - key: c - text: | - Each member of the Login.gov operations team has the necessary security background to properly handle sensitive data, such as security keys and certificates, and to evaluate the security implications associated with configuration changes. The Login.gov operations team controls access to Login.gov and its components through the access control tools appropriate for its components, including AWS security groups, Cloud Foundry roles, and GitHub team membership. - - key: d - text: | - The Login.gov operations team continually monitors the configurations of the various components of Login.gov to ensure they meet the requirements for protecting sensitive data. - standard_key: NIST-800-53 - # parameters -- control_key: SA-4 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - - key: b - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - - key: c - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - - key: d - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - - key: e - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - - key: f - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - - key: g - text: |- - System and Services Acquisition Policy is included in CIO P 2100.1 - GSA IT Security Policy, Chapter 5. Policy on Technical Controls. It states, "GSA system program managers and contracting officers shall ensure that the appropriate security requirements of this order are included in task orders and contracts for all IT systems designed, developed, implemented, and operated by a contractor on behalf of the government, including systems operating in a Cloud Computing environment including but not limited to Software as a Service (SaaS)." - - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - standard_key: NIST-800-53 -- control_key: SA-4 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - standard_key: NIST-800-53 -- control_key: SA-4 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - GSA OCISO ISP also defined agency-wide system and services acquisition procedures in IT Security Procedural Guide: Security Language for IT Acquisition Efforts (CIO-IT Security-09-48) - parameters: - # This parameter can be a reference to the fact that we are complying with the FedRAMP controls. - # [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics;] - - key: SA-4 (2) - text: | - [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information] - # Parameter for [Assignment: organization-defined design/implementation information]. Need value for this text. - - key: SA-4 (2) - text: | - [Assignment: organization-defined design/implementation information] - # This parameter can be a reference to the Configuration Management/GitHub process. - - key: SA-4 (2) - text: | - [Assignment: organization-defined design/implementation information] - # Parameter for [Assignment: organization-defined level of detail] - - key: SA-4 (2) - text: | - 18F - standard_key: NIST-800-53 -- control_key: SA-4 (8) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - clould.gov developed a continous monitoring plan and requires all system components to adhere to it. - parameters: - # This parameter can be a reference to Configuration Management plan. - # [Assignment: organization-defined level of detail] - - key: SA-4 (8) - text: | - continous monitoring plan - standard_key: NIST-800-53 -- control_key: SA-4 (9) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - # Do we require application design documents - narrative: - - text: |- - 18F utilizes an agile development process which means that changes are made early and often. Functions, ports and protocols are part of this process. - Login.gov enables developers to be flexible on what functions are used but customers can only open one port per application. - standard_key: NIST-800-53 -- control_key: SA-4 (10) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - # Possibly covered by GSA identification policies - narrative: - - text: |- - Login.gov delegates identity verification to customer's single sign on services. - standard_key: NIST-800-53 -- control_key: SA-5 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: |- - The Login.gov team maintains documentation for Login.gov in the GitHub repositories for the components of the system and at https://docs.Login.gov. - The "Contributing" section describes secure deployment and operation of Login.gov. - All known vulnerabilities are patched and documented in the GitHub repositories. - - key: b - text: |- - Best practices for secure usage of Login.gov are available and continuously updated at https://docs.Login.gov. - - key: c - text: |- - Anyone can file a report of incomplete or unavailable documentation using GitHub issues attached to https://github.com/18F/cg-docs or to the repositories that store various Login.gov components. - The Login.gov team responds to those issues and the creates documentation required. - - key: d - text: |- - Because Login.gov documentation does not contain sensitive information, documentation is publicly accessible in GitHub and at https://docs.Login.gov. - Changes to that documentation can only be accepted by authorized individuals on the Login.gov team through GitHub team membership. - - key: e - text: |- - The Login.gov team maintains documentation for Login.gov in the GitHub repositories for the components of the system and at https://docs.Login.gov. - The team directs new members to this documentation, and expects team members to be aware of its contents. - standard_key: NIST-800-53 -- control_key: SA-8 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - Login.gov uses the Cloud Foundry secure deployment best practices, which include the following: - - Configure UAA clients and users using a standard BOSH manifest for Cloud Foundry Development. - - Login.gov develops and maintains documentation on the baseline configuration of the information system that include network topology, system architecture, application, web, and server components along with software standards. - - Cloud Foundry protects the information system from security threats by minimizing network surface area, applying security controls, isolating applications and data in containers, and encrypting connections. - - It also implements role-based access controls, applying and enforcing permissions to isolate user to their space. Baseline configurations settings are reviewed on a continual basis to to comply with federal mandates and compliance standards. - - Login.gov documents changes to the baseline configuration in GitHub for review. Part of this process includes a thorough security analysis of the proposed change prior to the configuration change being implemented on the operational system. - - Login.gov deploys with every application a standard set of tools for security and monitoring of each application to identify security issues. - For more details please refer to 18F Configuration Management Policy and security controls CM-2, CM-3, and CM-6. - standard_key: NIST-800-53 -- control_key: SA-9 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - As a government system, Login.gov requires that all external services comply with all applicable federal software requirements. - The infrastructure utilized by Login.gov is AWS GovCloud, which is FedRAMP certified. - - key: b - text: | - GSA procurement practices defines all monitoring requirements for external information systems. - - key: c - text: | - Login.gov employs continuous monitoring for both internal and external information systems. - parameters: - # This parameter can be a reference to the fact that we are complying with the FedRAMP controls. - - key: SA-9 - text: | - FedRAMP Security Controls Baseline - # This parameter can be a reference to the Configuration Management plan/process. - - key: SA-9 - text: | - Federal/FedRAMP Continuous Monitoring requirements - standard_key: NIST-800-53 -- control_key: SA-9 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - GSA complies with federal regulations requiring agencies to evaluate risk prior to acquiring any tool or service. - - key: b - text: | - The GSA Office of the CIO approves any information security services. The FedRAMP JAB will take over that responsibility once Login.gov receives its approval. - standard_key: NIST-801-53 -- control_key: SA-9 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - GSA requires that any external service receives an Authority to Operate which includes identification of all functions, protocols, etc. - standard_key: NIST-800-53 -- control_key: SA-9 (4) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - GSA requires that any external service receives an Authority to Operate which includes alignment of organizational interests. - parameters: - # This can be a reference to the FedRAMP process again since AWS Govcloud is also FedRamp certified. - # [Assignment: organization-defined security safeguards] - - key: SA-9 (4) - text: | - All external systems where Federal information is processed or stored - standard_key: NIST-800-53 -- control_key: SA-9 (5) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - Login.gov restricts the location of all user data to AWS GovCloud and related services. - parameters: - # This is a reference to AWS GovCloud - - key: SA-9 (5) - text: | - all user data and information - # This is a reference to AWS GovCloud Avaliability Zone - - key: SA-9 (5) - text: | - AWS GovCloud - # This is a reference to FedRAMP - - key: SA-9 (5) - text: | - FedRAMP approval - standard_key: NIST-800-53 -- control_key: SA-10 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: |- - Configuration and deployment of the Login.gov platform is managed using the BOSH project. BOSH releases and deployment manifests are stored in GitHub; sensitive credentials are stored in Amazon S3 and are protected using both client- and server-side encryption. - - key: b - text: |- - Changes to BOSH configuration are tracked in GitHub. Documentation is stored alongside deployment manifests and updated as configuration is changed; high-level documentation is also available at https://docs.Login.gov. - - key: c - text: |- - All proposed configuration changes are reviewed by members of the Login.gov team. Proposed changes must pass unit, integration, and acceptance tests before being deployed. - - key: d - text: |- - Configuration changes are made through pull requests in GitHub, which need to include documentation of all of the relevant context, as specified in 18F-wide policy here: https://github.com/18F/development-guide/tree/master/git_protocol#write-a-feature - - key: e - text: |- - BOSH stemcell images and BOSH deployment artifacts are updated regularly, so that upstream security updates are applied. - standard_key: NIST-800-53 -- control_key: SA-10 (1) - covered_by: - - verification_key: DEPLOYMENT_TESTING - narrative: - - text: |- - Deployment artifacts are stored and distributed by BOSH along with SHA-1 hashes to allow verification of file integrity. - standard_key: NIST-800-53 -- control_key: SA-11 - covered_by: - - verification_key: DEPLOYMENT_TESTING - narrative: - - key: a - # https://18f.slack.com/archives/cloud-gov/p1465929760000146 - text: |- - The security assessment plan is created by the FedRAMP Accredited Third Pary Assessment Organzation (3PAO). It will It will be used for annual assessments conducted by the 3PAO for continuous monitoring of Login.gov. - - key: b - text: |- - Login.gov performs unit and integration testing on the sytem on each deployment. - parameters: - - key: SA-11 - text: | - unit and integration - - key: SA-11 - text: | - Login.gov - - key: c - text: |- - Testing is done automatically and tracked using tools like Nessus, OWASP and Concourse. - - key: d - text: |- - The process of remediation is by implementing changes to the configuration on configuration management, redeploying and testing. - - key: e - text: |- - Flaws are identified by automated tools and false positives are marked as such. - standard_key: NIST-800-53 -- control_key: SA-11 (1) - covered_by: - - verification_key: DEPLOYMENT_TESTING - narrative: - - text: |- - The Cloud Foundry community uses Code Climate on platform components such as BOSH and Cloud Controller. The results of the scans are publicly available and can be run by 18F at any time. - standard_key: NIST-800-53 -- control_key: SA-11 (2) - covered_by: - - verification_key: DEPLOYMENT_TESTING - narrative: - - text: |- - Login.gov requires the developer of the information system, system component, or information system service to perform threat and vulnerability analyses and subsequent testing/evaluation of the as-built system, component, or service. - standard_key: NIST-800-53 -- control_key: SA-11 (8) - covered_by: - - verification_key: DEPLOYMENT_TESTING - narrative: - - text: |- - Login.gov requires the developer of the information system, system component, or information system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis. - standard_key: NIST-800-53 -- control_key: SA-22 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: |- - 18F will replace information system components when support for the components is no longer available from the developer, vendor, or manufacturer; and will provide justification and documented approval for the continued use of unsupported system components required to satisfy mission/business needs. - - Cloud Foundry Platform as a Service system replacement: - - A system and software inventory is run nightly, and the DevOps team reviews the inventory weekly to ensure that all software inventoried is accurate and currently supported. This process includes: - - * Verify that the software license support expiration date is not within six months. 18F uses the open source version of Cloud Foundry which uses the open source Apache 2.0 license. - * Ensure that the software version is still supported. - * Refer to the vendor's support website to verify that support does not have an \u201CEnd of Life\u201D date of less than six months. - - Since 18F is using the open source version of Cloud Foundry, an additional task will be issued to upgrade the Cloud Foundry suite to the latest versions. DevOps will review the GitHub cloudfoundry/cf-release repository for implementation of the updated version. - standard_key: NIST-800-53 -system: 18F -verifications: -- key: DEPLOYMENT_TESTING - name: Cloud Foundry Code Analysis - path: https://runtime.ci.cf-app.com/pipelines/cf-release?groups=cf-release - type: URL -- key: POLICY_DOC - name: policy document - path: https://github.com/18f/compliance-docs/blob/master/SA-Policy.md - type: url -- description: GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.730678 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/SC_policy/component.yaml b/docs/security/SC_policy/component.yaml deleted file mode 100644 index 53677b5d4a2..00000000000 --- a/docs/security/SC_policy/component.yaml +++ /dev/null @@ -1,510 +0,0 @@ ---- -schema_version: 3.0.0 -documentation_complete: false -name: System and Communications Protection Policy for 18F -satisfies: -- control_key: SC-1 - covered_by: [] - implementation_status: partial - narrative: - - text: | - 18F Policy the 18F program includes a library of security policies that address federal - and non-federal requirements. These policies guide and govern the actions of 18F employees - and contractors in conducting any United States business. - - The 18F security assessment, communications and authorization policy are listed - within its private Github repository that is accessible to all 18F staff. - - key: a - text: | - Authorized 18F helps develop, document, and disseminate policy informatin to 18F staff members. - - key: a1 - text: | - 18F policy contains protection policy that addresses purpose, scope, - roles, responsibilities, management commitment, coordination among organizational - entities, and compliance. - - key: a2 - text: | - 18F Before You Ship guide aids to facilitate the implementation of the system and communications - protection policy and associated system and communications protection controls. - - key: b - text: | - Reviews and updates the current - - key: b1 - text: | - System and communications protection policy every three years. - - key: b2 - text: | - 18F Policy the 18F program includes a library of security policies that address federal - and non-federal requirements. These policies guide and govern the actions of 18F employees - and contractors in conducting any United States business. - - The 18F security assessment, communications and authorization policy are listed - within its private Github repository that is accessible to all 18F staff. - standard_key: NIST-800-53 -- control_key: SC-2 - covered_by: [] - implementation_status: complete - narrative: - - key: b - text: | - 18F implements subnetworks for publicly accessible system components that - are logically separated from internal organizational networks. System management - functionality to Login.gov infrastructure is hosted on AWS FedRAMP Certificated - Cloud Service Provider (CSP) and is accessible only to 18F Administrative teams - through AWS IAM specified roles. This is a Service Provider and Customer Responsibility. - standard_key: NIST-800-53 -- control_key: SC-4 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov system architecture prevents unauthorized and unintended information transfer - via shared system resources. Login.gov uses Cloudfoundry components to protect - users and shared resources from security threats by minimizing network surface area, applying - security controls, isolating customer applications and data in containers, and - encrypting connections. - standard_key: NIST-800-53 -- control_key: SC-5 - covered_by: [] - implementation_status: partial - narrative: - - text: | - Refer to the 18F policy statement for the types of denial of service (DoS) to - protect our systems against. - Policy https://github.com/18f/compliance-docs/blob/master/SC-Policy.md - - Login.gov limits the effects of Volume Based and Protocol DoS type attacks by - utilizing the following groups of technical measure: - - 18F administrative staff maintains hardened Amazon Managed Images (AMI) and - Cloud Foundry custom buildpacks with the lates patches and updates. - A buildpacks provides framework and runtime support for an applications that - are deployed on Login.gov. The AMI and custome buildpacks are maintained - and secured within 18F's software repository, Github. - - Login.gov also uses AWS's IaaS services with well formed Vitual Private Cloud (VPC) - firewall rules to reduce the attack surface, while service resiliencey is maintained - by utilizing AWS Avaliability zones, Elastic Load balancing and Autoscaling services. - Suricata, a NIDS/IPS is used to detected as well as prevent attacks and anomolies - based on threat signatures published on a regular basis. - - Cloud Foundry's security components limits the effects of an attack at the - Application Layer. It limits DoS attacks on this layer through - resource starvation and reduction of the attack surface even further with - well formed application security groups which control the traffic flowing from - hosted applications. - - These tools combined with SOC staffing are responsible for maintaining system - security. - parameters: - - key: SC-5-1 - text: | - 18F policy statement - - key: SC-5-2 - text: | - 18F policy statement - standard_key: NIST-800-53 -- control_key: SC-6 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov protects the availability of resources by allocating - volatile and non-volatile storage, bandwidth, availability by using automated - AWS features such as Elasctic load balancing and auto scaling technology at the - infrastructure layer and CF's application lifecycle manage components, - Cloud Controller and Droplet Execution Agent (DEA), at the application layers. - - 18F safeguards are in place if resource are reaching their limits with multiple sets of - resource monitoring tools: CF's build in health monitoring system, New Relic, - CloudWatch, ELK which combined provide with real-time alerts and visibility into critical - systems and applications. - parameters: - - key: SC-6-1 - text: | - volatile and non-volatile storage, bandwidth, availability of applications - - key: SC-6-2 - text: | - by priority and quota - - key: SC-6-3 - text: | - See system description for list of safeguards - standard_key: NIST-800-53 -- control_key: SC-7 - covered_by: [] - implementation_status: none - narrative: - - key: a - text: | - 18F monitors and controls communications at the external boundary of the - system and at key internal boundaries within the system. - - key: b - text: | - 18F implements subnetworks for publicly accessible system components that - are logically separated from internal organizational networks by using well formed - Virtual Private Cloud. VPC is a virtual network dedicated to your AWS account. - It is logically isolated from other virtual networks in the AWS cloud. - You can launch your AWS resources, such as Amazon EC2 instances, into your VPC. - Login.gov VPC has selected its IP address range, create subnets, and configure route - tables, network gateways, and security settings outside of the internal organizational - boundaries. - - key: c - text: | - 18F staff Connects to external networks or information systems only through managed - interfaces consisting of boundary protection devices arranged in accordance - with organizational security architecture. - parameters: - - key: SC-7-b - text: | - logically - standard_key: NIST-800-53 -- control_key: SC-7 (3) - covered_by: [] - implementation_status: complete - narrative: - - text: | - 18F limits the number external network connections to the information system - through the use of AWS network security groups which restricts types of network connections. - AWS API authenticated service keys and managed ssh keys restrict PU access to the systems. - - Login.gov CF components run on AWS AMI that exist within AWS VPCs. - In this configuration, the only access points visible on a public network are a - load balancer that maps to one or more Cloud Foundry routers. - standard_key: NIST-800-53 -- control_key: SC-7 (4) - covered_by: [] - implementation_status: none - narrative: - - key: a - text: | - Implements a managed interface for each external telecommunication service. - - key: b - text: | - 18F establishes a traffic flow policy for each managed interface as AWS VPC security groups. - - key: c - text: | - 18F protects the confidentiality and integrity of the information being transmitted - across each interface by using TSL for HTTP based connection and SSH system access. - - key: d - text: | - 18F documents each exception to the traffic flow policy with a supporting mission/business - need and duration of that need - - key: e - text: | - 18F reviews exceptions to the traffic flow policy at least annually - and removes exceptions that are no longer supported by an explicit mission/business need. - parameters: - - key: SC-7-4-e - text: | - at least annually - standard_key: NIST-800-53 -- control_key: SC-7 (5) - covered_by: [] - implementation_status: none - narrative: - - text: | - Login.gov's managed interfaces at the AWS security control group defintions - denies network traffic by default and allows network communications traffic by exception. - standard_key: NIST-800-53 -- control_key: SC-7 (7) - covered_by: [] - implementation_status: none - narrative: - - text: | - VPNs and split tunneling are not an applicable use when accessing this system. - 18F adminitrative staff gain access to this system have access through - AWS multi-factor authentication to perform adminitrative functions and duties. - standard_key: NIST-800-53 -- control_key: SC-7 (8) - covered_by: [] - implementation_status: none - narrative: - - text: | - Login.gov doesn't require authenticated proxy servers at managed interfaces. - 18F adminitrative staff gain access to this system have access through - AWS IAM multi-factor authentication process to perform adminitrative functions - and duties at the IaaS layer to administer to any managed interfaces. - parameters: - - key: SC-7-8-1 - text: | - N/A - - key: SC-7-8-2 - text: | - N/A - standard_key: NIST-800-53 -- control_key: SC-7 (12) - covered_by: [] - implementation_status: none - narrative: - - key: b - text: | - Host-based boundary protection for application services hosted on Login.gov - are provided by CF components. - - CF Application Security Groups (ASGs) control the traffic flowing out of applications. - Each cf application uses a dedicated Linux container, and each container includes a - dedicated virtual network interface. Application security groups - are a collection of ‘allow’ rules that can be made with global or application specific - assignments enabling access to be set on individual application requirements. - These requirements are added through whitelisting and whitelisting is layered on top - of a series of container-centric lock-downs, allowing limited access to other applications - and services. - parameters: - - key: SC-7-12-1 - text: | - N/A - - key: SC-7-12-1 - text: | - N/A - standard_key: NIST-800-53 -- control_key: SC-7 (13) - covered_by: [] - implementation_status: none - narrative: - - key: b - text: | - 18F practices defense in depth. Sensistive security tools are logically - isolated by well defined VPC boundries between intra system boundaries. Additionally 3rd party - approved tools are utilized which are accessed via authenticated API keys over encrypted connections such as HTTPS. - parameters: - - key: SC-7-13-1 - text: | - Nessus, Suricata, OWASP ZAP, ELK stack, Pagerduty, Code Climate, Cloudability, CloudTrail, CloudWatch - standard_key: NIST-800-53 -- control_key: SC-7 (18) - covered_by: [] - implementation_status: none - narrative: - - key: b - text: | - 18F doesn't operate any control interfaces outside of what's provided by AWS CSP. - in the event of an operational failure of a boundary protection device AWS CSP teams - should respond to this event and notify 18F DevOps team. - standard_key: NIST-800-53 -- control_key: SC-8 - covered_by: [] - implementation_status: none - narrative: - - text: | - Login.gov provides integrity and confidentiality protection over data in transit - by applying HTTPS to all public interfaces connecting to the service. - Seee how HTTPS (TLS) https://tools.ietf.org/html/rfc5246 for details. - parameters: - - key: SC-8 - text: | - confidentiality and integrity - standard_key: NIST-800-53 -- control_key: SC-8 (1) - covered_by: [] - implementation_status: none - narrative: - - text: | - Login.gov implements cryptographic mechanisms to prevent - unauthorized disclosure of information and detect changes to - information during transmission only as shown in SC-8. - a hardened or alarmed carrier Protective Distribution System (PDS) is provided - at the AWS CSP layer. See FedRAMP AWS CSP SSP for further details. - parameters: - - key: SC-8-1 - text: | - N/A - standard_key: NIST-800-53 -- control_key: SC-10 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov's RAS access terminates immediately at the end of the session. - parameters: - - key: SC-10 - text: | - immediately - standard_key: NIST-800-53 -- control_key: SC-12 - covered_by: - - verification_key: KEY_ROTATION - implementation_status: complete - narrative: - - text: | - Authorized federal staff rotate, encrypt, and backup keys monthly. - Privileged users accesses the keys only with two-factor authentication and a decryption - passphrase. In the rare case that both the keys and the decryption passphrase - for the backup are lost or compromised, new keys can be rotated in by authorized staff, - while maintaining availability of information. - parameters: - - key: SC-12 - text: | - see https://docs.Login.gov/ops/key-rotation/ - standard_key: NIST-800-53 -- control_key: SC-12 (2) - implementation_status: partial - narrative: - - text: | - Login.gov doesn't produce , controls, and distributes symmetric cryptographic - keys. - parameters: - - key: SC-12-2 - text: N/A - standard_key: NIST-800-53 -- control_key: SC-12 (3) - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov doesn't produce , controls, and distributes asymmetric cryptographic - keys. - parameters: - - key: SC-12-3 - text: N/A - standard_key: NIST-800-53 -- control_key: SC-13 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov inherits the control from the GovCloud package for the ELB SSL termination. - See https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf for further details. - parameters: - - key: SC-13 - text: | - N/A - standard_key: NIST-800-53 -- control_key: SC-15 - covered_by: [] - implementation_status: complete - narrative: - - key: a - text: | - Login.gov doesn't allow remote activation of collaborative computing devices thus not applicable. - - key: b - text: | - Explicit indication of use to users physically present at the devices is not applicable to Login.gov. - parameters: - - key: SC-15-a - text: N/A - standard_key: NIST-800-53 -- control_key: SC-17 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov obtains public key certificates from COMODO, an approved service provider. - parameters: - - key: SC-17 - text: N/A - standard_key: NIST-800-53 -- control_key: SC-18 - covered_by: [] - implementation_status: complete - narrative: - - key: a - text: | - This is not an applicable control for Login.gov. It doesn't depend on any mobile code such as flash, java, activex, etc. - - key: b - text: | - This is not an applicable control for Login.gov. It doesn't depend on any mobile code such as flash, java, activex, etc. - - key: c - text: | - This is not an applicable control for Login.gov. It doesn't depend on any mobile code such as flash, java, activex, etc. - standard_key: NIST-800-53 -- control_key: SC-19 - covered_by: [] - implementation_status: complete - narrative: - - key: a - text: | - This is not an applicable control for Login.gov. It doesn't depend on any VoIP techologies. - - key: b - text: | - This is not an applicable control for Login.gov. It doesn't depend on any VoIP techologies. - standard_key: NIST-800-53 -- control_key: SC-20 - covered_by: [] - implementation_status: complete - narrative: - - key: a - text: | - Login.gov Login.gov inherits from AWS CSP Route 53 the ability to use DNS with HTTP Strict Transport Security (HSTS) to achieve data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries. - - key: b - text: | - By allowing endpints to use Publie Key Infrastructure (PKI) certificates containing unique domain identifiers that map with top-level registered domain, Login.gov provides the means to indicate the security status of child zones and (if the child supports secure resolution services to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace. - standard_key: NIST-800-53 -- control_key: SC-21 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov inherits from AWS CSP Route 53 the ability request and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources by using DNS, HSTS, HTTP Public Key Pinning , and PKI path validation. - standard_key: NIST-800-53 -- control_key: SC-22 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov inherits from AWS CSP Route 53 the ability to provide name/address resolution service for an organization with fault-tolerance and does not require implementation of internal vs. external role separations since all connections are considered external non-administrative users. - - See https://aws.amazon.com/route53/ for further details. - standard_key: NIST-800-53 -- control_key: SC-23 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov inherits from AWS CSP Route 53 the ability to protect the authenticity of communications sessions via DNS, HSTS, HTTP Public Key Pinning , and PKI path validation. _check if al in action here_ - standard_key: NIST-800-53 -- control_key: SC-28 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov protects the confidentiality and integrity by encrypting internal system databases and AWS S3 object stores. - parameters: - - key: SC-28-1 - text: | - confidentiality; integrity - key: SC-28-2 - text: | - Administrative and policy information for system database and S3 store - standard_key: NIST-800-53 -- control_key: SC-28 (1) - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov implements cryptographic mechanisms to prevent unauthorized - disclosure and modification of Login.gov data stored in databases and S3 stores. - parameters: - - key: SC-28-1-1 - text: | - Administrative and policy information - key: SC-28-1-2 - text: | - system database and S3 store - standard_key: NIST-800-53 -- control_key: SC-39 - covered_by: [] - implementation_status: complete - narrative: - - text: | - Login.gov maintains a separate execution domain for each executing process by - running within its own self contained environment, a Garden container that isolates - processes, memory, and the file system. - standard_key: NIST-800-53 -system: 18F -verifications: -- key: KEY_ROTATION - name: Key Rotation Policy - path: https://github.com/18F/cg-docs/blob/master/content/ops/key-rotation.md - type: URL -- key: POLICY_DOC - name: policy document - path: https://github.com/18f/compliance-docs/blob/master/SC-Policy.md - type: URL -- description: | - GIVEN the github link - THEN the policy has been updated within the last 180 days - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.749496 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/SI_policy/component.yaml b/docs/security/SI_policy/component.yaml deleted file mode 100644 index 289ff223f38..00000000000 --- a/docs/security/SI_policy/component.yaml +++ /dev/null @@ -1,394 +0,0 @@ ---- -schema_version: 3.0.0 -documentation_complete: false -name: System and Information Integrity Policy for 18F -satisfies: -- control_key: SI-1 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F Policy - standard_key: NIST-800-53 -- control_key: SI-2 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F identifies all system flaws related to Login.gov, reports system flaws to information system owners, Authorizing officials, Login.gov operators and SecOps, and corrects information system flaws that affect Login.gov. - - key: b - text: | - 18F tests software updates against a staging environment for any updates, including those related to flaw remediation, for effectiveness and potential side effects before deploying the updates to production environment. - Cloud Foundry manages software vulnerability using releases and BOSH stemcells. - New Cloud Foundry releases are created with updates to address code issues, while new - stemcells are created with patches for the latest security fixes to address - any underlying operating system issues. New Cloud Foundry releases are located - at https://github.com/cloudfoundry/cf-release. - - key: c - text: | - Installs security-relevant software and firmware updates within [FedRAMP Assignment: Within 30 days of release of updates] of the release of the updates - - key: d - text: | - 18F incorporates flaw remediation into the organizational configuration management process. - - 18F implements the release of Cloud Foundry and (or the software - developer/vendor in the case of software developed and maintained by a - vendor/contractor) promptly installs newly released security relevant - patches and tests patches, for effectiveness and potential - side effects on information systems before installation. - parameters: - # [FedRAMP Assignment: Within 30 days of release of updates] - - key: SI-2 - text: | - promptly installs newly released - standard_key: NIST-800-53 -- control_key: SI-2 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov operators and SecOps teams employ automated mechanisms daily to determine the state of information system components with regard to flaw remediation. - parameters: - # [Assignment: organization-defined frequency] - - key: SI-2 (2) - text: | - [Assignment: organization-defined frequency] - standard_key: NIST-800-53 -- control_key: SI-2 (3) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov operators and SecOps teams measure the time between flaw identification - and flaw remediation - - key: b - text: | - Login.gov operators and SecOps teams establish [Assignment: organization-defined benchmarks] for taking corrective actions. - parameters: - # [Assignment: organization-defined benchmarks] - - key: SI-2 (3) - text: | - [Assignment: organization-defined benchmarks] - standard_key: NIST-800-53 -- control_key: SI-3 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov employs ClamAV at information system entry and exit points to detect and eradicate malicious code - - key: b - text: | - 18F updates ClamAV whenever new releases are available in accordance with organizational configuration management policy and procedures - - key: c - text: | - Login.gov operators and SecOps teams configure ClamAV to: - - 1. Perform on-access scans of Login.gov [Assignment: organization- defined frequency] and real-time scans of files from external sources at [Selection (one or more); endpoint; network entry/exit points] as the files are downloaded, opened, or executed in accordance with organizational security policy - - 2. [Selection (one or more): block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined action]] in response to malicious code detection - - key: d - text: | - Login.gov addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system. - parameters: - # [Assignment: organization- defined frequency] and real-time scans of files - # from external sources at [Selection (one or more); endpoint; network - # entry/exit points] - - key: SI-3 - text: | - [Assignment: organization- defined frequency] and real-time scans of files from external sources at [Selection (one or more); endpoint; network entry/exit points]] - # [Selection (one or more): block malicious code; quarantine malicious code; - # send alert to administrator; [Assignment: organization-defined action]] - - key: SI-3 - text: | - [Selection (one or more): block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined action]] - standard_key: NIST-800-53 -- control_key: SI-3 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F centrally manages malicious code protection mechanisms. - standard_key: NIST-800-53 -- control_key: SI-3 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov automatically updates ClamAV - standard_key: NIST-800-53 -- control_key: SI-3 (7) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov implements nonsignature-based malicious code detection mechanisms. - standard_key: NIST-800-53 -- control_key: SI-4 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov operators and SecOps teams monitor the Login.gov information - system to detect potential attacks and intrusions from internal and external - sources in accordance with the 18F System Information and Integrity Policy section - 3 - Information System monitoring, the FedRAMP Incident communication procedures, - and GSA CIO-IT Security-08-39 section "System Monitoring / Audit Record - Review" for GSA specific information systems. - - key: b - text: | - 18F identifies un-authorized access to the Login.gov information system using automated monitoring - tools within its virtual private cloud for monitoring, log management and - event analysis. 18F monitors for attacks and indicators of potential attacks, - unauthorized local, network, and remote connections. - - key: c - text: | - The infrastructure - that hosts Login.gov provides monitoring and intrusion detcetion of unusual activity - at the physical and network layers. 18F is responsible for monitoring everything - related to its virtual infrastructure and has deployed monitoring and intrusion - detection tools within its virtual private cloud to log and detect malicious - activities to its information systems including Login.gov. - - key: d - text: | - 18F ensures intrusion and monitoring tools are protected from unauthorized access - by only granting access to certain members from the DevOps and SecOps teams. - All monitoring and intrusion information data is protected by limiting accounts - to authorized privileged users only and is maintained in secured repositories - for review by those members. - - key: e - text: | - Information system monitoring will - be heightened based on advisories from Pivotal, US-CERT Advisories, commercial - security communities, and other sources. - - key: f - text: | - Information system monitoring will be conducted in accordance and compliance - with 18F security policies and all applicable laws, Executive Orders, directives, - and regulations. - - key: g - text: | - 18F provides monitoring of all information system components. In the event - of an event or incident, information will be provided as it is available. Scheduled - reports will be provided for events such as after-hours administrative logins, - users being added to privileged groups, persistent malware detections, etc., - to designated members of the DevOps teams and SecOps teams as needed. - standard_key: NIST-800-53 -- control_key: SI-4 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov operators and SecOps teams use BOSH to configure and deploy Tripwire. - standard_key: NIST-800-53 -- control_key: SI-4 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F uses BOSH to configure and deploy Riemann to support near real-time analysis of events. - standard_key: NIST-800-53 -- control_key: SI-4 (4) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - # Need to add how often we check for unusual traffic or conditions - - text: | - Login.gov monitors inbound and outbound communications traffic [FedRAMP Assignment: continually] for unusual or unauthorized activities or conditions. - standard_key: NIST-800-53 -- control_key: SI-4 (5) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov alerts SecOps when - the following indications of compromise or potential compromise occur: - malicious code, file integrity, and network traffic. - standard_key: NIST-800-53 -- control_key: SI-4 (14) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - This control is not applicable. Login.gov does not contain any wireless system. - standard_key: NIST-800-53 -- control_key: SI-4 (16) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F correlates information from Grafana employed throughout Login.gov. - standard_key: NIST-800-53 -- control_key: SI-4 (23) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F implements Riemann for host based monitoring for all server metrics on Login.gov. - standard_key: NIST-800-53 -- control_key: SI-5 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - 18F receives information system security alerts, advisories, and directives from US-CERT on an ongoing basis; - - key: b - text: | - 18F generates internal security alerts, advisories, and directives as deemed necessary; - - key: c - text: | - 18F disseminates security alerts, advisories, and directives to: [Selection - (one or more): [Assignment: organization-defined personnel or roles]; - [Assignment: organization-defined elements within the organization]; - [Assignment: organization-defined external organizations]]; and - - key: d - text: | - 18F implements security directives in accordance with established time - frames, or notifies the issuing organization of the degree of noncompliance. - standard_key: NIST-800-53 -- control_key: SI-6 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov verifies the correct operation of services that detect malicious code, viruses, file integrity, network traffic, and security compliance of the OS using a contious integration tool called concourse. - - key: b - text: | - Performs this verification [FedRAMP Assignment: to include upon system startup - and/or restart at least monthly; - - key: c - text: | - Notifies [FedRAMP Assignment: to include system administrators and security - personnel] of failed security verification tests; and - - key: d - text: | - Shuts the information system down; [FedRAMP Assignment: to include notification - of system administrators and security personnel] when anomalies are discovered. - standard_key: NIST-800-53 -- control_key: SI-7 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F employs Tripwire to detect unauthorized changes to Login.gov applications. - standard_key: NIST-800-53 -- control_key: SI-7 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov performs an integrity check using Tripwire at startup and every hour. - standard_key: NIST-800-53 -- control_key: SI-7 (7) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - 18F incorporates the detection of unauthorized access to the Login.gov infrastructure, leveraged services, and other components used to deliver Login.gov products and services as documented in - organizational incident response capability. - standard_key: NIST-800-53 -- control_key: SI-8 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - This control is not applicalbe since Login.gov does not accept messages. - - key: b - text: | - This control is not applicalbe since Login.gov does not accept messages. - standard_key: NIST-800-53 -- control_key: SI-8 (1) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - This control is not applicalbe since Login.gov does not accept messages. - standard_key: NIST-800-53 -- control_key: SI-8 (2) - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - This control is not applicalbe since Login.gov does not accept messages. - standard_key: NIST-800-53 -- control_key: SI-10 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov system monitors the integrity of system inputs using Tripwire. - standard_key: NIST-800-53 -- control_key: SI-11 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - key: a - text: | - Login.gov generates errors through Riemann which then sends an alert to Pager Duty for action. - - key: b - text: | - Reveals error messages only to Login.gov operators. - standard_key: NIST-800-53 -- control_key: SI-12 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov handles and retains information within Login.gov system and information output from the system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and operational requirements. - standard_key: NIST-800-53 -- control_key: SI-16 - covered_by: - - verification_key: POLICY_DOC - implementation_status: none - narrative: - - text: | - Login.gov system implements ClamAV and Tripwire to protect its memory from unauthorized code execution. - standard_key: NIST-800-53 -system: 18F -verifications: -- key: POLICY_DOC - name: policy document - path: https://github.com/18f/compliance-docs/blob/master/SI-Policy.md - type: url -- description: "GIVEN the github link - THEN the policy has been updated\ - \ within the last 180 days \n" - key: Policy_Update_Test - last_run: 2016-04-07 13:25:17.764795 - name: 18F Policies Update - path: BDD/policies.feature - test_passed: false - type: TEST diff --git a/docs/security/Staticfile b/docs/security/Staticfile deleted file mode 100644 index 660fa851146..00000000000 --- a/docs/security/Staticfile +++ /dev/null @@ -1 +0,0 @@ -root: _book/ diff --git a/docs/security/Staticfile.auth b/docs/security/Staticfile.auth deleted file mode 100644 index 7a0dc86f4da..00000000000 --- a/docs/security/Staticfile.auth +++ /dev/null @@ -1 +0,0 @@ -ssp_viewer:$apr1$/O6mfuN.$pct4cTe8r1j2B5RjM9mDZ1 diff --git a/docs/security/manifest.yaml b/docs/security/manifest.yaml deleted file mode 100644 index 1f02ef4f92e..00000000000 --- a/docs/security/manifest.yaml +++ /dev/null @@ -1,8 +0,0 @@ -applications: -- name: ssp-wip - memory: 64M - buildpack: https://github.com/cloudfoundry/staticfile-buildpack.git - directory: visible - root: _book/ - env: - FORCE_HTTPS: true diff --git a/docs/security/markdowns/README.md b/docs/security/markdowns/README.md deleted file mode 100644 index d35bc4cf761..00000000000 --- a/docs/security/markdowns/README.md +++ /dev/null @@ -1,6 +0,0 @@ -# FedRAMP Moderate System Security Plan -### 18F - Login.gov - -* [About the SSP](system_documentation/about-the-ssp.md) -* [Login.gov System Classification](system_documentation/system-data.md) -* [Login.gov General System Description](system_documentation/system-description.md) diff --git a/docs/security/markdowns/SUMMARY.md b/docs/security/markdowns/SUMMARY.md deleted file mode 100644 index ab4674efb5f..00000000000 --- a/docs/security/markdowns/SUMMARY.md +++ /dev/null @@ -1,12 +0,0 @@ - - -# FedRAMP Moderate System Security Plan - -***This SSP was created using [Compliance Masonry](https://github.com/opencontrol/compliance-masonry) and the documentation source is stored on [Login.gov's Compliance Repository](https://github.com/18F/identity-idp/tree/master/docs/security)*** - -### 18F - Cloud.Gov - - -* [About the SSP](system_documentation/about-the-ssp.md) -* [Login.gov System Classification](system_documentation/system-data.md) -* [Login.gov General System Description](system_documentation/system-description.md) diff --git a/docs/security/markdowns/ssp.yaml b/docs/security/markdowns/ssp.yaml deleted file mode 100644 index 434126ba970..00000000000 --- a/docs/security/markdowns/ssp.yaml +++ /dev/null @@ -1,53 +0,0 @@ -prepared_by: - organization: GSA OCISO and Valiant Solutions - street_address: 1800 F St, NW - suite: 4400 Infill - city: Washington - state: DC - zip: 20405 -prepared_for: - organization: - street_address: - suite: - city: - state: - zip: -information_system: - unique_id: login.gov - name: Consumer Identification Platform as a Service - abbreviation: login.gov - security_categorization: moderate - security_objects_categorization: - confidentiality: moderate - integrity: moderate - availability: low - e_authentication: - internet_auth: false - browser_usage: false - internet_usage: true - owner: - name: Noah Kunin - title: 18F Infrastructure Director - organization: 18F/GSA - phone_number: 202-577-7167 - email: noah.kunin [at] gsa.gov - street_address: 1800 F Street, NW - city: Washington - state: DC - zip: 20405 - authorizing_official: - name: Aaron Snow - title: Authorizing Official - organization: 18F/GSA - email: aaron.snow [at] gsa.gov - street_address: 1800 F Street, NW - city: Washington - state: DC - zip: 20405 - operation_status: operational - system_type: IdPaaS - deployment_model: Public - leveraged_authorizations: - - system_name: - owner: Amazon Web Services (AWS) - date_granted: 2013-13-05 diff --git a/docs/security/markdowns/system_documentation/about-the-ssp.md b/docs/security/markdowns/system_documentation/about-the-ssp.md deleted file mode 100644 index 2049954017b..00000000000 --- a/docs/security/markdowns/system_documentation/about-the-ssp.md +++ /dev/null @@ -1,7 +0,0 @@ -## About the System Security Plan -This document is released in template format. Once populated with content, this document will include detailed information about service provider information security controls. -The System Security Plan is the main document in which the CSP describes all the security controls in use on the information system and their implementation. - -## Who should use this document? -This document is intended to be used by service providers who are applying for a Provisional Authorization through the U.S. Federal government FedRAMP program. U.S. Federal agencies may want to use it to document information systems security plans that are not part of the FedRAMP program. -Other uses of this template include using it to document organizational information security controls for the purpose of creating a plan to manage a large information security infrastructure. Complex and sophisticated systems are difficult to manage without a documented understanding of how the infrastructure is architected. diff --git a/docs/security/markdowns/system_documentation/continuous_delivery_infrastructure.png b/docs/security/markdowns/system_documentation/continuous_delivery_infrastructure.png deleted file mode 100644 index 5bdae150b15..00000000000 Binary files a/docs/security/markdowns/system_documentation/continuous_delivery_infrastructure.png and /dev/null differ diff --git a/docs/security/markdowns/system_documentation/login_gov_sys_arch.png b/docs/security/markdowns/system_documentation/login_gov_sys_arch.png deleted file mode 100644 index a4b87f94c9d..00000000000 Binary files a/docs/security/markdowns/system_documentation/login_gov_sys_arch.png and /dev/null differ diff --git a/docs/security/markdowns/system_documentation/system-data.md b/docs/security/markdowns/system_documentation/system-data.md deleted file mode 100644 index c0cab459b9a..00000000000 --- a/docs/security/markdowns/system_documentation/system-data.md +++ /dev/null @@ -1,134 +0,0 @@ -# Identity Platform as a Service (Login.Gov) -This System Security Plan provides an overview of the security requirements for the Login.gov as ruby based OSS Identity Management Platform as a Service (Login.gov) and describes the controls in place or planned for implementation to provide a level of security appropriate for the information to be transmitted, processed or stored by the system. Information security is vital to our critical infrastructure and its effective performance and protection is a key component of our national security program. Proper management of information technology systems is essential to ensure the confidentiality, integrity and availability of the data transmitted, processed or stored by the login.gov information system. - -The security safeguards implemented for the Login.gov system meet the policy and control requirements set forth in this System Security Plan (SSP). All systems are subject to monitoring consistent with applicable laws, regulations, agency policies, procedures and practices. - -Unique Identifier | Information System Name | Information System Abbreviation ---- | --- | --- -Login.gov | Federal Identity as a Service | LOGIN.GOV -This System Security Plan provides an overview of the security requirements for the consumer identity platform (Login.gov) and describes the controls in place or planned for implementation to provide a level of security appropriate for the information to be transmitted, processed or stored by the system. Information security is vital to our critical infrastructure and its effective performance and protection is a key component of our national security program. Proper management of information technology systems is essential to ensure the confidentiality, integrity and availability of the data transmitted, processed or stored by the Cloud.Gov information system. - -The security safeguards implemented for the Login.Gov system meet the policy and control requirements set forth in this System Security Plan. All systems are subject to monitoring consistent with applicable laws, regulations, agency policies, procedures and practices. - -Unique Identifier | Information System Name | Information System Abbreviation ---- | --- | --- -Login.gov | Federal Identity as a Service | Login.gov - - -# Security Objectives Categorization (FIPS 199) -Security Objective | Low, Moderate or High ---------------- |----------|------- -Confidentiality | Moderate -Integrity | Moderate -Availability | Low - -# Information System Categorization -The overall information system sensitivity categorization is noted in the table that follows. - -Low | Moderate | High ---- | --- | --- - | X | - - -Using this categorization, in conjunction with the risk assessment and any unique security requirements, we have established the security controls for this system, as detailed in this SSP. - -# Information Types -The following tables identify the information types that are input, stored, processed, and/or output from Login.Gov. The selection of information types is based on guidance provided by OMB Federal Enterprise Architecture Program Management Office Business Reference Model 2.0, and FIPS Pub 199, Standards for Security Categorization of Federal Information and Information Systems which is based on NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories. - - -|Information Type | Confidentiality | Integrity | Availability| -|-----------------|-------------------|-----------|-------------| -|C.3.5.1 System Development |Low | Moderate | Low -|C.3.5.2 life-cycle/Change Management |Low | Moderate | Low -|C.3.5.3 System Maintenance |Low | Moderate | Low -|C.3.5.4 Infrastructure Maintenance |Low | Low | Low - -# E-Authentication Determination - -### E-Authentication Question -Yes | No | E-Authentication Question ---- | --- | --- - x | | Does the system require authentication via the Internet? - x | | Is data being transmitted over the Internet via browsers? - x | | Do users connect to the system from over the Internet? - -Note: Refer to OMB Memo M-04-04 E-Authentication Guidance for Federal Agencies for more information on e-Authentication. - -The summary E-Authentication Level is recorded in the table that follows. - -### E-Authentication Determination -|System Name| System Owner| Assurance Level| Date Approved| -|-----------| -|Login.gov Platform as a Service| 18F/GSA| LEVEL 2| May 23, 2016| - -# Information System Owner -Name | Title | Organization | Address | Phone Number | Email Address ---- | --- | --- | --- | --- | --- -Noah Kunin | 18F Infrastructure Director | 18F/GSA | 1800 F Street, NW Washington DC 20405 | 202-577-7167 | noah.kunin [at] gsa.gov - -# Authorizing Official -Name | Title | Organization | Address | Phone Number | Email Address ---- | --- | --- | --- | --- | --- -Aaron Snow | Authorizing Official | 18F/GSA | 1800 F Street, NW Washington DC 20405 | | aaron.snow [at] gsa.gov - -# Other Designated Contacts -Name | Title | Organization | Address | Phone Number | Email Address ---- | --- | --- | --- | --- | --- -Amos Stone | Innovation Specialist |18F/GSA| 1800 F Street, NW Washington DC 20405| 202-317-0125| amos.stone [at] gsa.gov -Mossadeq Zia | Innovation Specialist |18F/GSA| 1800 F Street, NW Washington DC 20405| 202-256-2063| mossadeq.zia [at] gsa.gov - -# Assignment of Security Responsibility -Name | Title | Organization | Address | Phone Number | Email Address ----|----|----|----| -Noah Kunin| 18F Infrastructure Director|18F/GSA| 1800 F Street DC 20405| 202-577-7167| noah.kunin [at] gsa.gov - -# Information System Operational Status -The system is currently in the life-cycle phase noted in the table that follows. (Only operational systems can be granted an ATO). - -# System Status -Operational | Under Development | Major Modification | Other ---- | --- | --- | --- -X | | | - -# Information System Type -The Login.gov makes use of FedRAMP AWS services for IaaS. - -# Cloud Service Models -Information systems, particularly those based on cloud architecture models, are made up of different service layers. The layers of the Login.gov defined in this SSP are indicated in the table that follows. - -X |Software as a Service (SaaS) | Application - -|- - |Infrastructure as a service (IaaS)| General Support System - |Platform as a Service (PaaS) | Application -======= -The Cloud.Gov makes use of unique managed service provider architecture layer(s). - -# Cloud Service Models -Information systems, particularly those based on cloud architecture models, are made up of different service layers. The layers of the Cloud .Gov defined in this SSP are indicated in the table that follows. - -X |Platform as a Service (PaaS) | Application - -|- - |Software as a Service (SaaS) | Application - |Infrastructure as a service (IaaS)| General Support System - |Other| Explain: - - -# Cloud Deployment Models -Information systems, particularly those based on cloud services and infrastructures, are made up of different deployment models. The deployment models of the Login.gov that are defined in this SSP, and are not leveraged by any other Provisional Authorizations, are indicated in the table that follows. - -X |**Public** | Cloud services and infrastructure supporting consumer and multiple agency services| -======= -Information systems, particularly those based on cloud services and infrastructures, are made up of different deployment models. The deployment models of the Cloud.Gov that are defined in this SSP, and are not leveraged by any other Provisional Authorizations, are indicated in the table that follows. - -X |**Public** | Cloud services and infrastructure supporting multiple organizations and agency clients| --|- -|Private| Cloud services and infrastructure dedicated to a specific organization/agency and not other clients -|Community| Cloud services and infrastructure shared by several organizations/agencies with the same policy and compliance considerations -|Hybrid| Explain: (e.g., cloud services and infrastructure that provides private cloud for secured applications and data where required and public cloud for other applications and data) - -# Leveraged Authorizations -The Login.gov information system plans to leverage a pre-existing Provisional Authorization. Provisional Authorizations leveraged by this AWS FedRAMP ATO (issued by the HHS are noted in the table that follows. - -Information System Name | Service Provider Owner | Date Granted ---- | --- | --- -AWS FedRamp Agency ATO (issued by the HHS) | Amazon | May 13, 2013 diff --git a/docs/security/markdowns/system_documentation/system-description.md b/docs/security/markdowns/system_documentation/system-description.md deleted file mode 100644 index 2066a313eaf..00000000000 --- a/docs/security/markdowns/system_documentation/system-description.md +++ /dev/null @@ -1,151 +0,0 @@ -# General System Description - -## System Function or Purpose -Login.gov is 18F’s product line for the tools, tech, and services 18F provides to help teams delivering federal digital services to operate efficiently at-scale in a cloud-hosted environment, while complying with federal regulatory requirements. It’s based on and built using the open source ruby based identity-idp project, which is an open platform as a service, providing a choice of developer frameworks, and application services which makes it faster and easier to build, test, deploy, and scale applications. Login.gov is a Identity platform as a service (IdaaS) which can be used on top of underlying infrastructures such as Cloud Foundry AWS, VMware and Open Stack. - -## Information System Components and Boundaries -18F has created a specific set of VPCs (Live production, tooling, and staging) for Login.gov. All VPCs have subnets used to separate and control IP address space within each individual VPC. Subnets must be created in order to launch Availability Zone (AZ) specific services within a VPC. 18F has setup VPC Peering between the Staging VPC, tooling VPC and the CF Live production VPC. - -Login.gov components include identity provisioning and security components that will aid in protecting consumer PII data. - -The Login.gov IdaaS Information System is hosted on AWS East Public Cloud in the Northern Virginia Region. AWS services utilized include ENI, EC2, EBS, VPC, RDS, S3, MFA, Route 53, ELB and IAM. These are listed as leveraged hardware, network and server components. - -Physical aspects of the Login.gov IdaaS information system are outside of the authorization boundary due to all hardware being physically managed by AWS. While other services are reviewed and approved for use by the GSA OCISO, they were deemed to be ancillary support services that do not directly process/store data but rather provide general support services. _These services include Cloudwatch, CloudFormation, AWS Config and Trusted Advisor._ - -The authorization boundary diagram represented depicts the core components which make up the System in its entirety. Login.gov resides within Cloud.gov. While Cloud.gov is outside the boundary, it belongs to an authorized System thus allowing for inheritance of the component. Other support services outside the Login.Gov information system authorization boundary include Twilio, New Relic, SMPT service, MFA service, Experian, and Federal Information Technology systems. - -## Network Architecture -The following architectural diagram(s) provides a visual depiction of the system network components that constitute Login.gov. - -Login.gov service architecture: ![mz](login_gov_sys_arch.png) - -Login.gov Admin infrastructure: ![mz](continuous_delivery_infrastructure.png) - -## Login.Gov Security Domain Stack -### Identification and Authentication Control - -18F staff utilizes multi-factor authentication (MFA) for AWS IAM, GitHub, Trello and Slack. Access to these services requires multi-factor authentication using both the login and the MFA device. When a user signs into these services, they are prompted for an authentication code from their MFA device. Once the user has entered their username and password along with their authentication code, they will then be granted access. Slack, GitHub and Trello use authentication codes delivered to users’ cell phones generated by an application such as Google authenticator or sent as a text message (SMS). Trello also performs pass-thru authentication by using google authenticator or GSA’s SecureAuth and a GSA email account of the user. - -AWS Identity and Access management (IAM) is used to manage 18F users and their privileges that use the virtual private cloud environment. Each user is assigned a specific role or multiple roles within IAM to ensure they are only allowed authorized privileges and functions required to perform their job. All access to IAM requires multi-factor authentication through AWS MFA. 18F staff uses a mobile application such as google authenticator to receive randomly generated authorization codes to access the AWS management console and services. - -Login.gov is administered by designated 18F DevOps staff members who require access to the underlying Cloud.Gov platform login to the Cloud.Gov jump box using SSH credentials. MFA functionality for the Cloud.gov jump box is on 18F’s roadmap to implement for privileged access. The jumpbox is a virtual machine (VM) that acts as an access point for the deployed VMs. Direct access to other Login.gov VMs is disabled. The jumpbox is located in the us-east-1d Availability zone. Privileged access to the jumpbox is restricted to originate only from GSA IP space and a limited set of IPs that 18F DevOps use to access from the office. - -### ACLs, Software defined Firewalls and Security Groups - -Login.gov AWS IaaS as the underlying control domain that provides a layer of protection to enhance each boundary, both external and internal. The VPC is configured to utilize routing tables, network access control lists, subnet rules, and security group (firewall) rules. Each of these controls must have appropriate rules and routes in-place before any external service is able to reach a host within Cloud.Gov. - -Amazon S3 Access Control Lists (ACLs) enable 18F to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a sub-resource. It defines which AWS accounts or groups are granted access and the type of access. When a request is received against a resource, Amazon S3 checks the corresponding ACL to verify the requester has the necessary access permissions. When a bucket or an object is created, Amazon S3 creates a default ACL that grants the resource owner full control over the resource. A grantee can be an AWS account or one of the predefined Amazon S3 groups. - -Each Login.gov EC2 instance or group of instances is assigned to at least one Security Group with specific assigned roles. These roles delineate what traffic is allowed inbound & outbound for each instance by allowing or denying ports, protocols, and services. Access controls within EC2 include, secure login to instances using key pairs and username, a firewall that enables the specification of ports, protocols and source IP ranges that can reach instances. - -The Login.Gov platform is secured using VPC F/Wed routing rules. - -### Audit Logging, Monitoring and intrusion detection - -Login.gov depends on AWS for CloudWatch, AWS Elasticsearch managed services, and Kinesis for centralized audit logging and monitoring of Login.gov components, applications, and data APIs. The logs captured from the Auditing tool set can be used in forensic analysis to track down the time of intrusion, as well as the method used to penetrate into the network. It’s used in a way to monitor attacker activities in the network and help determine the reason behind an attack. - -The Auditing tool set includes CloudWatch, a centralized logging and parsing data pipeline that is used to process logs in different formats. It uses different rules to format each log message into multiple fields, which are indexed by the Elasticsearch search engine used for deep searches and data analytics. Kinesis is a web interface that provides an overview of the collected data, so 18F can easily view and analyze the collected logs. - -18F has implemented CloudWatch for its resource monitoring. It allows 18F to monitor AWS resources in near real-time, including Amazon EC2 instances, Amazon EBS volumes, Elastic Load Balancers, and Amazon RDS DB instances. Metrics such as CPU utilization, latency, and request counts are provided automatically for these AWS resources. It allows 18F to supply logs or custom application and system metrics, such as memory usage, transaction volumes, or error rates. All VPC Flow logs, CloudWatch and CloudTrail data in relation to Cloud.Gov are consumed by the ELK stack and visualized through a Grafana dashboard. - -### Vulnerability Scanning, Penetration testing - -18F utilizes ?OpenVAS? for vulnerability scanning and asset management of its network environment. 18F conducts baseline configurations scans, compliance scans, virtual infrastructure and network scans using custom scan policies and templates. The Nessus manager is located in a separate VPC, which is a peer of Login.gov live VPC. Public access to the Nessus Manager is limited within the GSA IP address only. It runs both authenticated/unauthenticated scans against 18F assets and provides reporting and grouping functions of vulnerabilities with scanned assets. OpenVAS allows 18F to track risk level changes based on remediation efforts and provides a variety of scan report outputs. OpenVAS reports 18F assets vulnerable to common exploits. Metasploit is a penetration testing platform designed to exploit and validate vulnerabilities found within 18F’s virtual private cloud and applications. - -18F utilizes OWASP ZAP for internal web application scanning of information systems and components. It is used to scan for the OWASP Top 10 vulnerabilities within applications and it can perform enhanced automated penetration testing functions. - -### Cloud Inventory and Asset Management - -18F utilizes VisualOps Cloud management to provide a visual, real-time representation of 18F’s virtual cloud infrastructure. It also provides a global view of the 18F AWS account where all regions and services can be seen in one place. Visual Ops has a WYSIWYG editor to design, configure and provision AWS cloud applications. Once applications are deployed, VisualOps monitors and manages the apps to ensure they are running in the defined states. - -AWS Config can export a complete inventory of AWS resources with all configuration details, determine how a resource was configured at any point in time, and get notified via Amazon SNS when the configuration of a resource changes. AWS Config can provide configuration snapshots, which is a point-in-time capture of all 18F resources and their configurations. Configuration snapshots are generated on demand via the AWS CLI, or API, and delivered to an Amazon S3 bucket that is specified. - -18F uses Cloudability for AWS cost and usage management of the AWS virtual infrastructure. It provides graphical information of detailed billing of the AWS account information through analytics on usage and consumption across 18F’s AWS account. - -### Static and Dynamic Code Analysis - -Code Analysis for Login.Gov is performed by Code Climate which is integrated by Cloud Foundry in GitHub to perform all static code analysis for the platform. Code Climate is an automated static code analysis for the platform as a service that is Cloud.Gov. It integrates directly into 18F's continuous integration (CI) workflow and provides notifications of actionable findings in GitHub, and Slack when an issue arises. 18F uses a variety of other analyzers based on the type of codebase used on top of the platform. OWASP Zap is used as an dynamic code analysis tool. It has the capability to dynamically probe web applications looking for unknown vulnerabilities found in the source code. - -### Incident Response Resolution and Communication - -18F utilizes PagerDuty for Incident response and communication. It integrates with 18Fs entire monitoring and deployment stack which includes Slack, Cloudwatch, New Relic and Auditing service with real-time alerts and visibility into critical systems and applications. It allows the DevOps team to quickly detect, triage, and resolve incidents from development through production. - -The SecOps team can view centralized alerts from Auditing stack for 18F’s visibility of the entire application stack and virtual infrastructure which enables the team to prioritize, escalate and execute the incident response process. - -### Configuration Management and Version Control - -18F’s configuration management process consists of GitHub. Baselines and configuration files are stored in GitHub repositories using version control. These files are then deployed using a pipeline yaml file with Travis, continuous integration platform. - -# System Environment -The following describes the Login.Gov Identity Platform as a Service (IdPaaS) as deployed in production based on the network diagrams. It is implemented as hardened EC2 instances or virtual servers operating within Login.gov Virtual Private Cloud (VPC). The instances are deployed to grow and shrink based on demand. - -To provide high availability, Login.gov's blob store is on AWS S3, and the backend DB on AWS. The DB resource is allocated from AWS Relational Database Service (RDS). _The backups of the database are configured with a Retention Point Objective (RPO) within the last five minutes._ - -Login.Gov is a system with multiple components. All traffic through AWS elastic load balancer (ELB). - -A load-balancing router sits at the front of login.gov to route incoming requests to the correct application.  The only access points visible on a public network are a load balancer that maps to one or more Login.gov routers and, optionally, a NAT VM and a Bastion Host (Jumpbox). -\ -### Login.gov Virtual Private Cloud (VPC) environment - -#### Public Subnet -The hosts within the Public subnet are only used for system maintenance and DNS purposes only. Instances do not contain any GSA operational data. The Public subnet allows only the necessary inbound and outbound access with the Internet defined by AWS Security Groups. In the public subnet there exists a Cloud Foundry bastion host (jump box), A VM that acts as a single access point for the deployed instances as disabling direct access to the instances is a common security measure. The bastion host (Jumpbox) is used for the purpose of managing the infrastructure. - -#### Private Subnet - Core Tier -The Core Tier is a production subnet where the Login.gov instances reside.   Access to this subnet is restricted to only administrators.  All application development, maintenance and deployment are conducted within the Core Tier subnet. - -#### Private Subnet - Database Tier -The Database Tier hosts the Cloud.Gov configurations within a PostgreSQL database (i.e. users, orgs, and spaces). These are hosted in geographically separated, isolated by failure physical locations; in short the RDS database is in a Multi-AZ deployment. - -#### Private Subnet - Metrics -The Metrics subnet includes Login.gov’s continuous integration continuous deployment (CI/CD) pipeline. Baseline and configuration files are stored in GitHub repositories using version control. These files are then deployed using a pipeline yaml file within the Concourse continuous integration platform. It also hosts the Audit service logging and collection tools used for Login.gov. - -#### User Accounts -All users have their employee status categorized with a sensitivity level in accordance with PS-2. Employees (or contractors) of service providers are considered Internal Users. All other users are considered External Users. User privileges (authorization permission after authentication takes place) are described in the table that follows. At this time all users who have access to the 18F AWS VPC and the underlying Login.gov are internal users. There is no external access granted to users outside of the 18F/USDS programs and GSA. - -## Types of Users -| Role | Internal or External | Sensitivity Level | Authorized Privileges and Functions Performed | -|-----------------|----------------------|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| administrators | Internal | High | AWS IAM RBAC with MFA access to AWS AMI and VPC rules - -## Hardware Inventory - -None - Leveraged from AWS Infrastructure| --| - -## Software Inventory -| Hostname | Function | Version | Patch Level | Virtual (Yes / No) | -|---------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------|--------------------| -| Login.gov Server | Handles authentication for general users and delegates all other identity management tasks to the SP.| Version 1 | | Yes | -| JumpBox | Used to run AWS AMI management | Version 1 | | Yes | -| Audit services | Front end for consuming logging and monitoring data for metrics reporting | Version 1 | | Yes | -| Concourse CI | Performs continuous deployment and integration of Login.gov components | Version 0.75| 0.75 | Yes | -| Code Climate | Static code analysis tool for the source code| Latest Version| NA| Yes| -| GitHub| Login.gov code repository and version control| Latest Version| NA | Yes| -| Login.gov AMI| operating system used in deployed EC2 instances for Login.gov| Ubuntu 12.04 LTS| 12| Yes| - -The following table lists all other applications and components used in relation to the Login.gov information system. - -|Component Name| Function| Version| Patch Level| Virtual| -|--------------|---------|--------|------------|--------| -|OpenVAS| Vulnerability scanner for the Login.gov platform| Latest Version |NA|Yes| -|New Relic| Application and performance metrics for Cloud.Gov| Latest Version|NA| Yes| -|Cloudability| Monitor, optimize and govern Cloud Costs related to the AWS Infrastructure| Latest Version |NA| Yes| -|Slack| Message, alert and communications app | Latest Version | NA |Yes| -|Trello| Used for agile, scrum and story boarding| Latest Version | NA | Yes| -|Pager Duty| Incident communication platform used by DevOps| Latest Version| - - -## Network Inventory -None - Leveraged from AWS Infrastructure| --| - -## Ports, Protocols and Services -| Ports (T or U) | Protocols | Services | Purpose | Used By | -|----------------|-----------|----------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------| -| 443 (T) | HTTPS | HTTPS | LG ec2 web service | AWS | -| 2222 (T) | SSH | Secure Shell deamon (SSH) | External port for SSH access for apps | SSH Jumpbox | - | - -## System Interconnections -None - Not Applicable| --| diff --git a/docs/security/opencontrol.yaml b/docs/security/opencontrol.yaml deleted file mode 100644 index f39113a7b35..00000000000 --- a/docs/security/opencontrol.yaml +++ /dev/null @@ -1,33 +0,0 @@ -schema_version: "1.0.0" -name: Login.gov # Name of the project -metadata: - description: central logon application - maintainers: - - jrahaghi@omb.eop.gov -components: # A list of paths to components written in the opencontrol format for more information view: https://github.com/opencontrol/schemas - - ./CM_Policy - - ./AC_Policy - - ./SC_Policy - - ./IA_Policy - - ./CA_Policy - - ./AU_Policy - - ./AT_Policy - - ./CP_Policy - - ./IR_Policy - - ./MA_Policy - - ./MP_Policy - - ./PL_Policy - - ./PS_Policy - - ./RA_Policy - - ./SA_Policy - - ./SI_Policy -dependencies: - systems: - - url: https://github.com/opencontrol/aws-compliance - revision: master - standards: - - url: https://github.com/opencontrol/NIST-800-53-Standards - revision: master - certifications: - - url: https://github.com/opencontrol/FedRAMP-Certifications - revision: master