Cloud Transformation Program Cloud Change Champions June 20, 2018

Transcription

1 Cloud Transformation Program Cloud Change Champions June 20, 2018

2 W June C Today s Agenda C C M! 1 Welcome and Agenda Overview Program Updates 2 Security Issues in the Cloud Presenter: Michael Timineri 3 Feedback and Discussion Meeting Wrap-Up

3 Overall UIT Cloud Program Goals (through 2019) Goal 1: Perform cloud governance and portfolio management Goal 2: Define organizational development program Goal 3: Integrate cloud systems, processes, and services Goal 4: Run mission critical services in the cloud Goal 5: Reduce UIT computing footprint on campus 50% Goal 6: Exit Livermore disaster recovery site

4 Overall UIT Cloud Program Goals (through 2019) Goal 1: Perform cloud governance and portfolio management Goal 4: Run mission critical services in the cloud Goal 2: Define organizational development program Proposal: Remove Goal 5; add metrics to other goals Goal 3: Integrate cloud systems, processes, and services Goal 6: Exit Livermore disaster recovery site

5 Cloud Security Presentation to Cloud Change Champions, June Michael Timineri Director of Information Security Consulting CISSP, CCSP, CISM, CISA, CRISC, CEH, CHFI, PCIP, CySA+, CSM, AWS-PSA, GCP-CA etc. etc. Image credit Linda A. Cicero Stanford University News Service Information Security Office Office of the Chief Risk Officer

6 Presentation Outline 1. Overview of the Shared Responsibility Model 2. Threats and vulnerabilities introduced by cloud computing 3. Stanford s Cloud Minimum Security Standards IaaS/PaaS/SaaS 4. Examples of Cloud Compromises at Stanford 5. Additional Resources and Q&A

7 Information Security Office Goals No incidents attributable to a lack of best practices Automated standards enforcement wherever possible Uniform solutions across the University, Hospitals and SLAC Balance security with usability and personal privacy Stanford as a recognized leader in information security

8 ISO Consulting Core Responsibilities University Cyber Risk Management Internal and Forensic Investigations Security Assessments and Reviews Awareness and Training Incident Response Coordination Penetration Testing Policy and procedure development Governance and Regulations

9 Shared Responsibility Ultimately, you can outsource responsibility but you can t outsource accountability. John McDermott, ACSAC 09

10 KEY:

11 Security Concerns in Cloud Computing

12 Security is the #1 inhibitor of cloud adoption Source: 2012 Cloud Computing Key Trends and Future Effects IDG

13 Threats and vulnerabilities introduced by cloud computing Infrastructure Challenges Management Interface Compromises Compromise of Service Engine Economic Denial of Service Privilege Escalation Legal Challenges Audit or Certifications Gaps Subpoena and E-Discovery Jurisdictional Challenges Lack of Forensic Readiness Licensing Risks Isolation Challenges Poor Encryption Key Management Restrictions on Vuln Management Lack of Resource Isolation Lack of Reputation Isolation Data Processing Remains Unencrypted Recovery Challenges Lack or Compromise of Logs Lack of Backup Data Isolation Media Sanitization Impossible

14 Perspective

15 y A. Phishing and other forms of social engineering B. Unpatched servers and applications H E F C C. Two-step authentication integration gaps A D. Unencrypted endpoints and external storage devices B E. Breach of large, University-operated repository of Moderate or High Risk data J K G F. Breach of large, third party-managed repository of Moderate or High Risk data G. Non-compliance with international data privacy laws D H. Malicious insider threat from Stanford community members I Impact Stanford s top privacy and security risks I. Lack of current & comprehensive data inventory & retention/ disposal practices J. Insufficient intrusion detection capabilities Likelihood x K. Misconfigured permissions

16 Minimum Security Standards

17 A MinSec Refresher 1. Designed to be Simple, Practical and Effective 2. Represents the Minimum Controls Expected of an Organization 3. Based on Stanford s Data Classification Standards (dataclass.stanford.edu) 4. Endpoint, Server, and Application MinSec Unchanged Since Cloud MinSec Standards released December A virtual server in the cloud is subject to the same Standards as the on premise.

18 Minimum Security Standards for SaaS/PaaS

19 SaaS/PaaS Minimum Security Standards (page 1) STANDARDS Product Selection Pre-implementation Planning Inventory and Asset Classification WHAT TO DO Follow the Stanford cloud solution selection workflow found at Choosing and Purchasing a Cloud Solution. Follow the SaaS Considerations checklist. Follow the PaaS Considerations checklist. Follow the Security When Using a Cloud Product guidelines. 1.List the product in the department's MinSec Inventory. 2.Ensure the inventory is updated quarterly and reflects accurate data classification and service ownership. 1.Integrate with Stanford's SSO services, preferably SAML. 2.Review administrative accounts and privileges quarterly. 3.Adhere to the Stanford password complexity rules if not integrated with a Stanford SSO service. 4.API keys: Credential and Key Management 1. Minimize their generation. 2. Grant minimum necessary privileges. 3. Rotate at least annually. 4. Do not hardcode. 5.Do not share credentials. Encryption Two-Step Authentication Logging and Auditing Data Management 1.Enable transport layer encryption TLS 1.1 or higher. 2.Use encryption of data at rest if available. If user login is not able to be integrated with Stanford SSO, enable two-factor authentication if offered by the solution. 1.Enable any available application logging that would assist in a forensic investigation in the event of a compromise. Seek vendor or ISO guidance as needed. 2.Contractually ensure that the provider can export logs at the request of Stanford within five days. Contractually ensure that Stanford data is purged upon termination of the agreement. LOW MOD HIGH

20 SaaS/PaaS Minimum Security Standards (page 2) STANDARDS WHAT TO DO Administration consoles should only be accessed through a PAW when logging in with an administrative account. Privileged Access Workstation (PAW) Administrative accounts are defined as: 1.Accounts with the ability to make unrestricted, potentially adverse, or system-wide changes. 2.Accounts with the ability to override or change security controls. Security, Privacy and Legal Review Prior to implementation, follow the Stanford Data Risk Assessment process. 1.Follow all regulatory data controls as applicable (HIPAA/HITECH, NIST , PCI DSS, GDPR, etc.). Regulated Data Security Controls 2.For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used. LOW MOD HIGH

21 Minimum Security Standards for IaaS

22 IaaS Minimum Security Standards (page 1) STANDARD WHAT TO DO Follow the Stanford cloud solution selection workflow found at Choosing and Purchasing a Cloud Solution. Platform Selection Operational Practices As far as possible, apply the Stanford Cloud Operational Principles and Practices. System Architecture As far as possible, apply the Stanford Cloud Architecture Principles for IaaS. Account Management Provision new cloud accounts through University IT. 1.Apply high severity security patches within seven days of release. 2.Apply all other security patches within 90 days. 3.Use a supported operating system and application version. 4.Use machine images only from trusted sources. Patching and Application Lifecycle Additional Elaboration: Managed Services For managed services like Amazon RDS or Google Cloud SQL, define a maintenance window that meets the standard. Ephemeral Servers and Containers If using an automated system to build fully patched machine images, ensure that the patched image, or container base layer, is in use in your environment within the window of time specified in the MinSec standard. LOW MOD HIGH

23 IaaS Minimum Security Standards (page 2) STANDARD WHAT TO DO Based on National Vulnerability Database (NVD) ratings: Identify and remediate severity 4 and 5 CVE vulnerabilities within seven days of discovery, and severity 3 vulnerabilities within 90 days. Stanford provides and recommends the Qualys toolset (which includes the Qualys Cloud Agent), however platform specific tools such as Amazon Inspector and Google Cloud Security Scanner may be used instead. If a detection tool other than Qualys is used, ISO may request a review and audit of your tool and practices as well as periodic verification of efficacy. Vulnerability Management Additional Elaboration: Managed Services Qualys scanning may be omitted on infrastructure provider managed services, however if the platform provides a native vulnerability detection capability, it should be implemented. Ephemeral Servers Build machine images that contain the appropriate agent, or bootstrap the installation and configuration of the agent using the management tools specific to your implementation. Containerized Solutions Scan image for CVEs using CLAIR, Anchore, private DockerHub scan, or similar tool. Maintain an inventory of deployed resources as well as the risk classification and service owner of those resources. Additional Elaboration: Inventory and Asset Classification Ephemeral Servers Systems designed for a lifespan no greater than 7 days (commonly those in autoscaling worker groups) should be inventoried as a single application. Managed Services Infrastructure managed services like Amazon RDS or Google Cloud SQL should be inventoried as applications. LOW MOD HIGH

24 IaaS Minimum Security Standards (page 3) STANDARD Firewall WHAT TO DO Use the native tools and design patterns of your platform to ensure that only the minimum necessary network communication is permitted through virtual network devices such as VPCs, load balancers, and the like. This includes access to managed services such as hosted database platforms. 1.Where possible, integrate with Stanford SSO authentication for all cloud administration consoles. 2.Abide by Stanford s password complexity rules. 3.Review administrative accounts and privileges quarterly. Credential and Key Management 4.API keys: Minimize their generation. Grant minimum necessary privileges. Rotate at least annually. Do not hardcode. 5.Do not share credentials. Two-Step Authentication Enforce two-factor authentication for all interactive user and administrator logins. Stanford provided Duo two-factor authentication is recommended, but other two-factor options are acceptable. 1.Enable any available application logging that would assist in a forensic investigation in the event of a compromise. Seek vendor or ISO guidance as needed. 2.Forward logs to remote logging solutions. 1. University IT Splunk service recommended, but third party SaaS solutions are also acceptable. Logging and Alerting Additional Elaboration: Administrative Activity Logs Log user actions and API calls that create or modify the configuration or metadata of a resource, service or project. Data Access Logs Log user actions and API calls that create, modify, or read High Risk data managed by a service. One example would be to enable data access logs on AWS S3 buckets containing High Risk Data. LOW MOD. HIGH

25 IaaS Minimum Security Standards (page 4) STANDARD Backups Encryption WHAT TO DO 1.Backup application data at least weekly. 2.Encrypt backup data in transit and at rest. 3.Store backups in independent cloud accounts. 1.Enable transport layer encryption for all communications external to the private cloud environment. 2.Use TLS 1.1 or higher. 3.Use encryption at rest if available. Data Centers Prefer US based data center locations. Cloud administration consoles should only be accessed through a PAW when logging in with an administrative account. Privileged Access Workstation (PAW) Administrative accounts are defined as: Accounts with the ability to make unrestricted, potentially adverse, or system-wide changes. Accounts with the ability to override or change security control Security, Privacy, and Legal Review Prior to implementation, complete the Stanford Data Risk Assessment process (dra.stanford.edu). 1.Adhere to applicable regulations: PCI, HIPAA/HITECH, NIST , GDPR, etc. Regulated Data Security Controls 2.For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used. LOW MOD HIGH

26 Additional Resources

27 Cloud Security Resources SISA Cloud Security Course: Stanford Data Risk Classification Standards Minimum Security Standards Cloud Transformation at Stanford

28 Questions and Discussion Thank you Michael Timineri

29 What is important for to know about the cloud? 1 PY19 program goals are with the OCIO, with all proposed UIT goals 2 Please take the training survey if you ve received it and encourage others to do so

30 Additional Feedback and Open Discussion Your feedback on this presentation? Your input on communication needs? Open discussion and questions? Our next meeting will be on July 25, 2018 at 3:00 pm T!