Introduction

The Computational and Information Sciences and Technology Office (CISTO – Code 606) at the NASA Goddard Space Flight Center (GSFC) provides a managed cloud environment using public cloud services specifically designed for collaborative science and application development. The Science Cloud is a FISMA-Moderate information technology environment using Amazon Web Services (AWS) and Microsoft Azure for NASA funded researchers and collaborators. This environment is designed for the following: 

  • Provide public cloud access to NASA funded projects with team members both within and external to NASA;
  • Perform research using emerging cloud computing capabilities without extensive start-up times;
  • Access to innovative tools and methods from commercial cloud providers to build cloud-nativeapplications;
  • Scalable computing and storage infrastructure.

The Science Cloud has a NASA Authorization to Operate (ATO) with approved controls that comply with relevant security requirements to guard the confidentiality, integrity, and availability of the work performed in the Science Cloud. This document provides information about the Science Cloud environment, security, roles and responsibilities, and user behavior. All Principal Investigators and Project SysAdmins within the Science Cloud are required to acknowledge that they have read and will abide by this document once per year.

Roles and Responsibilities

Science Cloud Management Team: The Science Cloud Management Team provides overall project management, operational oversight, and security services for the managed environment.

Science Cloud Security Team: The Science Cloud Security Team includes the Information Systems Security Officer (ISSO) and other security support staff. This team is present to implement security controls, monitor compliance with NASA security guidelines, and maintain the Authorization to Operate (ATO).

Science Cloud Cloud Administrator (Science Cloud CloudAdmin): The Science Cloud has an operational staff of system administrators that are responsible for the overall configuration management and security of the managed environment, including any shared services, such as scanning and logging. Furthermore, the Science Cloud CloudAdmins are available to answer questions and trouble shoot problems as they may arise. Each project will have one or more user accounts associated with the Science Cloud CloudAdmins that are included in the “Administrators” group.

Principal Investigator (PI): This is the person responsible for managing the project within the Science Cloud and the users of the environment and will be granted limited access to the AWS console. The PI is responsible for communications with the Science Cloud system administrators and management team, and responsible for the associated AWS costs. The PI will be placed into the “PowerUsers” group.

Each PI is responsible for assigning a Project SysAdmin to their project to ensure adherence to Science Cloud security guidelines. The Project SysAdmin will be the primary point of contact for the Science Cloud CloudAdmin and Security Teams, who will receive automated emails related to account management, vulnerability management, and other security-related activities. If a PI does not have a dedicated Project SysAdmin assigned to their project, they should contact the Science Cloud CloudAdmin team for temporary assistance, or add a Project SysAdmin to their team. 

Principal Investigator / Admin (PIAdmin): The PIAdmin is another type of PI who manages a project within the Science Cloud. Similar to the PI, the PIAdmin is responsible for communications with the Science Cloud system administrators and management team, is responsible for the associated AWS costs, and also serves as the Project SysAdmin. The PIAdmin will be placed into the “PowerUsers” group.

Project System Administrator (Project SysAdmin): Each project must define a system administrator that will be responsible for the patching and configuration management of the project’s environment and applications. In the event of a security vulnerability, the Project SysAdmin (and ultimately the PI) is responsible for mitigating the vulnerability. The Project SysAdmin will be placed into the “Administrators” group. A part of the on-boarding and security training will include general information about managing users and EC2 instances in the AWS Console. There can be multiple Project SysAdmins. 

Project Console User: Each project may also define general users that access AWS resources within the project. All Project Console Users must be placed within the “PowerUsers” group, which will provide some limits on these user accounts; for example, general project users will not be able to create other user accounts (only the PI and the Project SysAdmin can create accounts).

End User / Service User: Each project may provide certain users with access to their project’s services, but without AWS console access. These users (who are authorized, deployed, and managed by each Project SysAdmin) must adhere to the project and/or service requirements and are not required to abide by the terms of this User Agreement. 

Science Cloud User: Any consumer of Science Cloud resources, to include the PI, PIAdmin, Project SysAdmin, Project Console Users, and End/Service Users. 

Authorization

Once a project is initiated, console users (both NASA and non-NASA) may be created by the PIAdmin, Project SysAdmin, or a Science Cloud CloudAdmin once a signed user agreement has been provided for each individual. The PI, PIAdmin, and/or Project SysAdmin is responsible for providing the following information to the Science Cloud CloudAdmins for each user account (with access to the AWS or Azure console) to help with communications:

  • Full Name
  • Preferred User Identifier
  • Organization
  • Email
  • Phone Number

In the event that a console user is no longer authorized to access the project resources, the PI, PIAdmin, and/or the Project SysAdmin must remove the account and any related AWS or Azure permissions and notify the Science Cloud SysAdmins of this account removal. The Science Cloud CloudAdmins can support access removals if the project needs support to do this on their behalf.

Multi-Factor Authentication

For enhanced security, all Science Cloud console users must authenticate using Multi-Factor Authentication (MFA), which employs something they know (their UserID/Password), and something they have (such as a hard or soft “token”). For users who have a NASA identity, the Science Cloud implementation integrates EntraID and NASA PIV, and for non-NASA badged users, the Science Cloud requires a TOTP application (e.g. Authy, Google Authenticator), which is used to generate a soft “token” at the time of login.

The MFA requirement for Science Cloud also applies to the use of AWS API Keys, which can be used to provide automated script-based access to Science Cloud resources. Proper use of AWS API Keys will also require the use of a TOTP application, which will issue a soft “token” to each user, and which will be required to generate a temporary session key at the time of each API Key use.

In the event that automated processes require access to the AWS API, an exception may be granted that will not require MFA for certain “service” accounts that are never used for interactive logins. All exceptions must be documented and approved by the ISSO.

API Key Usage

Use of AWS API Keys shall be minimized. These keys shall be treated as Controlled Unclassified Information (CUI) information and always protected as such. AWS API Keys shall never be uploaded to publicly available locations, as this could cause the entire Science Cloud environment to be severely compromised.

User Password and Key Expiration

All Science Cloud passwords and AWS API Keys must comply with NIST guidelines and shall be changed at least every 60 days (if not sooner). Any passwords or API Keys that are discovered to exceed this threshold will immediately be expired and will need to be changed prior to use. In addition, any user IDs that are inactive for > 60 days will also be expired. In all cases, a Science Cloud CloudAdmin will need to be contacted via support@sciencecloud.nasa.gov to regain access to Science Cloud.

Data

Science Cloud has been categorized as a Federal Information Security Management Act (FISMA) “Moderate” system, and is appropriate for the storage and processing of public data that is openly available. Uploading of classified, Export Administration Regulations (EAR), or ITAR data to the Science Cloud is not permitted. Storage and processing of Controlled Unclassified Information (CUI) is allowed, but it shall be encrypted both at rest and in transit. PIs are responsible for ensuring the data in use by their project is compliant with these requirements at all times. 

Rules of Behavior

Users of the Science Cloud are responsible for using the managed cloud environment for NASA research and do so in a secure, ethical, and lawful manner. Users are responsible for all actions taken within their account and while the user account is open. As such, users must adhere to the following behaviors:

  • Shall not share their account, passwords, or keys.
  • Shall not import, use, or store any Classified, Export Administration Regulations (EAR), or International Traffic in Arms Regulation (ITAR) information.
  • Shall not import, use, or store any fraudulent, harassing, or obscene information.
  • Shall not divulge access information to any non-user of the project.
  • Shall not purposefully engage in activities to harass another user, to deprive another user, to gain access to other information technology resources for which access has not been authorized, to degrade the performance of a system or service, or to circumvent security measures.
  • Shall report any weakness in the security of the environment to the Science Cloud management, security, and system administration team members, and shall disclose any incident of possible unauthorized use.

Configuration Management

Projects are free to use AMIs of their choice, but Project SysAdmins are highly encouraged to incorporate standard security settings that will ensure compliance with NASA and NIST security guidelines.  Examples of applicable security hardening settings include: 

  • Systems Manager agents installed on all EC2 instances via attaching the pre-built SMCE_SSMAgent IAM role
  • Adherence to Cybersecurity Standards and Engineering Team (CSET) guidelines for recommended operating systems and configuration settings. 
  • Setting up a NIST-compliant patch management schedule (see Vulnerability Management) 
  • Notification to Science Cloud Security Team of unsuccessful login attempts 
  • Use of a NASA-approved system use notice (at time of logon) 
  • Adequate storage/configuration to preserve at least 1 year of audit records

Information System Backups

All backups and disaster recovery are the responsibility of the PI, PIAdmin, or Project SysAdmin for each project. If applicable for individual project requirements, PIAdmins or Project SysAdmins should have a backup strategy for all data stored within their individual project resources and will ensure that regular backups are conducted. In addition, it is recommended that PIAdmins and Project SysAdmins create backups prior to performing major system upgrades. 

Incident Response

In the unlikely event of a security incident, PIs, PIAdmins, and/or Project SysAdmins will be required to immediately cooperate with the Science Cloud Management and Security teams to effectively respond to an incident and to perform any necessary remediation activities. If a PI, PIAdmin, or Project SysAdmin believes an EC2 instance or data from their project has been compromised, they should immediately do the following:

  1. Stop the affected EC2 instances (but do not terminate them). Terminating an EC2 instance will delete any system logs that will be necessary for post-incident forensic activities.
  2. Contact the Science Cloud System Administration via support@sciencecloud.nasa.gov to create a support ticket. Specific information about how PIs, PIAdmins, and/or Project SysAdmins can effectively respond to security incidents is included in the annual Science Cloud General Security Training.

Vulnerability Management

PIs, PIAdmins, and Project SysAdmins will receive weekly Inspector vulnerability reports on Saturdays for all EC2 instances that have patches that are overdue. The PIAdmin or Project SysAdmin is required to remediate all vulnerabilities according to the following schedule:

  • Expedited (SOC MAR): 7 Calendar Days
  • Critical: 15 calendar days
  • High: 30 calendar days
  • Medium: 30 calendar days
  • Low: 60 calendar days

These updates will include both Operating System patches and application updates, the details of which will be included in custom weekly reports delivered to all PIs, PIAdmins, and Project SysAdmins with vulnerable EC2 instances. Additional information about the Common Vulnerabilities and Exposures (CVE) presented in the custom weekly Inspector reports is available in the AWS Inspector Dashboard.

SSM Agent Remediation Processing

If a non-ephemeral EC2 instance doesn’t have the Systems Manager (SSM) agent installed, the Science Cloud Security Team will notify the responsible PI, PIAdmin, and/or Project SysAdmin for immediate action. If the SSM agent is still not functioning after 7 days, the Science Cloud Security team will notify the PI, PIAdmin, and/or Project SysAdmin and shut down the instance.

Auto Isolation Processing

If an EC2 instance for a Science Cloud project has not been patched within the required timeframe as noted in the Vulnerability Management section above, the PI, PIAdmin, and Project SysAdmin will be notified 4 days and 2 days prior to weekly automated instance isolations. If the required actions to remediate the vulnerabilities are not completed within the timeframes specified above, the affected EC2 instance will be isolated via the assignment of a custom security group that blocks all inbound access from the public internet. As necessary, the Science Cloud Security Team will communicate with affected PIs, PIAdmins, and Project SysAdmins to ensure the pending isolations are known in advance.

Science Cloud Website Hosting

Any new public-facing websites mused be vetted and approved by the Science Cloud Administration team prior to being brought online. The following guidelines should be followed to facilitate timely approval:

  1. Permissible websites include web services and web applications built using RESTful APIs. Static information-only websites are not allowed.
  2. Website design and configuration must follow the Science Cloud Web Hosting Guidelines, which must be signed and returned prior to bringing a new web application online.
  3. Recommended domain names for all new websites are https://xxxx.sciencecloud.nasa.gov

Application Certification Process

Each Science Cloud project with public-facing websites/applications must pass an application certification process, which includes the following steps:

  1. Maintenance of documentation including the instance ID, instance name, IP, URL, and a description of the functionality for all publicly available URLs
  2. Completion of Static Code Analysis scans across codebases for all public-facing applications/websites
  3. Satisfactory remediation of results from Penetration Tests for all public-facing applications/websites via collaboration with the Science Cloud Security Team
  4. Supply Chain Risk Management (SCRM) approvals for all installed software components in use
  5. Participation in weekly Science Cloud “office hours” meetings (as necessary) to encourage collaboration with Science Cloud Security team to adopt recommended best practices employed by the Science Cloud development community

This certification process will serve to minimize the threat to the Science Cloud and NASA by ensuring security best practices are being followed to secure all external-facing assets.

Security Training

All Science Cloud users who require access to the AWS console must complete the Science Cloud General Security training, and PIAdmins and Project SysAdmins must also complete the Science Cloud Elevated Privileges Security Training.

For all NASA credentialed users, the NASA security training requirements still apply, as do all Science Cloud User’s host institution training requirements. In addition, all PIAdmins and Project SysAdmins are strongly encouraged to take the NASA Elevated Privileges training (or equivalent within their organization), prior to being provided heightened privileges for cloud resources (e.g., root, administrator, power user, etc.). Agreement to these rules of behavior imply that the user has taken all requisite security training within their respective organization.

Community of Practice (CoP) Meetings

Science Cloud Community of Practice (CoP) meetings will be held on a regular basis for the purpose of providing Science Cloud specific information about operational capabilities and security while also creating an opportunity to share specific AWS implementations that could benefit the Science Cloud user community. Case studies and success stories for selected Science Cloud projects will be featured, which will serve to promote collaboration between all Science Cloud users, to include PIs, PIAdmins, Project SysAdmins, and console users.

  • No labels