Guidance on Applying Minimum Security Standards for Cloud Deployments
Stanford is committed to protecting the privacy of its students, alumni, faculty, and staff, as well as protecting the confidentiality, integrity, and availability of information important to the University's mission.
As University IT migrates applications and infrastructure to the cloud, it is important to protect these assets by applying security standards to cloud technologies. These standards are intended to reflect the minimum level of care necessary for Stanford's sensitive data. They do not relieve Stanford or its employees, partners, consultants, or vendors of further obligations that may be imposed by law, regulation, or contract.
Stanford expects all partners, consultants, and vendors to abide by Stanford's information security policies. If non-public information is to be accessed or shared with these third parties, they should be bound by contract to abide by Stanford's information security policies.
You are encouraged to begin adopting these standards, prioritizing your systems by risk level. As cybersecurity is a rapidly evolving field that continuously presents us with new challenges, these standards will be revised and updated accordingly. In time, these standards will become requirements codified in the Administrative Guide.
Minimum Security Standards: Infrastructure as a Service (IaaS)
- Determine the risk level by reviewing the data risk classification examples, server risk classification examples, and application risk classification examples and selecting the highest applicable risk designation across all. For example, an endpoint storing Low Risk Data but utilized to access a High Risk application is designated as High Risk.
- Follow the minimum security standards in the table below to safeguard IaaS.
| Standards | What to do | Guidance | Low Risk | Moderate Risk | High Risk |
|---|---|---|---|---|---|
| Patching |
No difference from on-premise standard: Based on National Vulnerability Database (NVD) ratings, apply high severity security patches within seven days of publish and all other security patches within 90 days. Use a supported OS version. |
Use machine images that contain an appropriately configured BigFix for Servers agent, or patch management tools appropriate for your management needs to meet the requirement. For managed services like Amazon RDS or Google Cloud SQL, define a patching maintenance window that meets the standard. If using a system to build fully patched machine images, ensure that the patched image is in use in your environment within the window of time specific to the MinSec requirement. |
Required for Low Risk Data | Required for Moderate Risk Data | Required for High Risk Data |
| Vulnerability Management |
No difference from on-premise standard: Perform a monthly Qualys scan. Remediate severity 4 and 5 vulnerabilities within seven days of discovery and severity 3 vulnerabilities within 90 days. |
If the cloud service does not allow external scanning, or monthly scanning can not be coordinated with the cloud provider, the host(s) can utilize the Qualys cloud agent and feed results to the UIT Qualys service. Build machine images that contain the Qualys cloud agent, or bootstrap the installation and configuration of the agent using the management tools specific to your implementation. |
Required for Low Risk Data | Required for Moderate Risk Data | Required for High Risk Data |
| Inventory |
Servers: No difference from on-premise standard. Review and update NetDB and SUSI records quarterly. Maximum of one node per NetDB record. Applications: No difference from on-premise standard. Maintain a list of applications and the associated risk classifications and data volume estimates. Review and update records quarterly. |
Manually add servers and applications to the appropriate inventory in accordance with the standard where it makes sense for your deployment. For systems that are automatically created and terminated, consider using automation mechanisms, such as the NetDB API or equivalent to register the host at creation and update the node’s status at termination. For managed services, like Amazon RDS or Google Cloud SQL, inventory these as applications. |
Required for Low Risk Data | Required for Moderate Risk Data | Required for High Risk Data |
| Firewall |
Server: No difference from on-premise standard. Enable host-based firewall in default deny mode and permit the minimum necessary services. Application: No difference from on-premise standard. Permit the minimum necessary services through the network firewall. |
Use the native tools and design patterns of your platform to ensure that only appropriate network communication is allowed through virtual network devices such as VPCs, load balancers and the like. This includes access to managed services like hosted database platforms. Use machine images and configurations that have the host based firewalls turned on and configured in accordance with the standard. |
Required for Low Risk Data | Required for Moderate Risk Data | Required for High Risk Data |
| Credentials and Access Control |
Server: No difference from on-premise standard. Review existing accounts and privileges quarterly. Enforce password complexity. Application: No difference from on-premise standard. Review existing accounts and privileges quarterly. Enforce password complexity. Logins with SUNet credentials via SAML recommended. |
Ensure that the quarterly audit includes the cloud provider’s management console, service credentials, and any application or developer API keys. If able, ensure that the cloud provider console login integrates with Stanford SAML. |
Required for Low Risk Data | Required for Moderate Risk Data | Required for High Risk Data |
| Two-Step Authentication |
Servers: No difference from on-premise standard. Require Duo two-step authentication for all interactive user and administrator logins. Applications: No difference from on-premise standard. Require Duo two-step authentication for all interactive user and administrator logins. |
If a non-Duo two-factor authentication system is utilized, this should be documented as a MinSec exception request, noting the compensating control or two-factor method. |
Required for Moderate Risk Data | Required for High Risk Data | |
| Centralized Logging |
Servers and Applications: No difference from on-premise standard. Forward logs to a remote log server. University IT Splunk service recommended. |
If using the UIT Splunk service: Implement machine images that contain a configured Universal forwarder, or configure your machines to install and configure the Universal forward on machine creation. |
Required for Moderate Risk Data | Required for High Risk Data | |
| Secure Software Development |
Same requirement as on premise. Include security as a design requirement. Review all code and correct identified security flaws prior to deployment. Use of static code analysis tools recommended. |
It is recommended that the software engineers take into account any platform specific security considerations when developing apps for the cloud. |
Required for Moderate Risk Data | Required for High Risk Data | |
| Developer/Sysadmin Training |
Attend at least one Stanford Information Security Academy (SISA) training course annually. |
It is recommended that sysadmins and developers take courses on security specific to their cloud platform, if not already offered through SISA. |
Required for Moderate Risk Data | Required for High Risk Data | |
| Malware Protection |
Server: No difference from on-premise standard. Deploy Cb Protection (formerly Bit9) in high enforcement mode. Review alerts as they are received. |
Windows Platform: Non-Windows Platform: |
Required for Moderate Risk Data | Required for High Risk Data | |
| Intrusion Detection |
Server: No difference from on-premise standard. Deploy Cb Protection (formerly Bit9) on supported platforms. Otherwise use OSSEC or Tripwire. Review alerts as they are received. |
Windows Platform: Non-Windows Platform: |
Required for Moderate Risk Data | Required for High Risk Data | |
| Backups |
Application: No difference from on-premise standard. Back up application data at least weekly. Encrypt backup data in transit and at rest. |
Use platform's native snapshot features, or related tooling, to ensure that backup data is encrypted in transit and at rest. For example, enable AES256 encryption on an Amazon S3 bucket that will be used for the storage of the backup data. |
Required for Moderate Risk Data | Required for High Risk Data | |
| Physical Protection |
Place system hardware in a data center. |
GCP, AWS, and Azure already meet this requirement and have been vetted by the Information Security Office (ISO) and University Privacy Office (UPO). Further verification is determined through the Security, Privacy, and Legal Review. A Security, Privacy, and Legal Review is required if using a cloud provider other than GCP, AWS, or Azure. |
Required for Moderate Risk Data | Required for High Risk Data | |
| Dedicated Admin Workstation |
Server: No difference from on-premise standard. Access administrative accounts only through a Privileged Access Workstation (PAW). |
Access to cloud admin consoles should be done through a PAW, similar to admin access to a hypervisor in a traditional data center. |
Required for High Risk Data | ||
| Security, Privacy, and Legal Review |
Request Data Risk Assessment if handling High Risk Data (see dra.stanford.edu). Request third party security certifications for hosting facility (e.g., SOC 2 Type 2, ISO 27001, etc.). |
Go to ServiceNow and complete the Data Risk Assessment pre-screening questionnaire, to determine if a DRA is required. If DRA is required, start by filling out DRA intake form found on dra.stanford.edu. |
Required for High Risk Data | ||
| Regulated Data Security Controls |
Adhere to applicable regulations: PCI, HIPAA, NIST, etc. |
Do not put PHI in AWS, not yet approved for PHI. GCP and Azure are approved up to high-risk non-PHI and PHI data, however HIPAA security rule, PCI-DSS, and other security requirements still apply. |
Required for High Risk Data |
Definitions
- NIST-Approved Encryption
- The National Institute of Standards and Technology (NIST) develops and promotes cryptographic standards that enable U.S. Government agencies and others to select cryptographic security functionality for protecting their data. Encryption which meets NIST-approved standards is suitable for use to protect Stanford's data if the encryption keys are properly managed. In particular, secret cryptographic keys must not be stored or transmitted along with the data they protect. Cryptographic keys have the same data classification as the most sensitive data they protect.
- Payment Card Industry Data Security Standards
- The practices used by the credit card industry to protect cardholder data. The Payment Card Industry Data Security Standards (PCI DSS) comprise an effective and appropriate security program for systems that process, store, or have access to Stanford's Prohibited or Restricted data. The most recent version of the PCI DSS is available here.
- Protected Health Information (PHI)
- All individually identifiable information that relates to the health or health care of an individual and is protected under federal or state law. For questions about whether information is considered to be PHI, contact the University Privacy Office.
Who do I contact for questions?
General Questions
| Unit | Website | Help |
|---|---|---|
| Privacy Office | Privacy Office | Contact the Privacy Office |
| Information Security Office | Information Security Office | Submit Help request |
Suspected Information Security Incident
| Unit | Website | Help |
|---|---|---|
| Information Security Office | Information Security Office | Submit Help ticket |
Report Lost or Stolen Device
| Unit | Website | Help |
|---|---|---|
| Privacy Office | Privacy Office | Submit report |
