Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Cloud Transformation Program Cloud Change Champions | June 20, 2018
Welcome and Agenda OverviewProgram Updates1
W June C C C M !
Today’s Agenda
Security Issues in the CloudPresenter: Michael Timineri2
Feedback and DiscussionMeeting Wrap-Up3
Overall UIT Cloud Program Goals (through 2019)
Goal 5: Reduce UIT computing footprint on campus 50%
Goal 1: Perform cloud governance and portfolio management
Goal 3: Integrate cloud systems, processes, and services
Goal 2: Define organizational development program
Goal 6: Exit Livermore disaster recovery site
Goal 4: Run mission critical services in the cloud
Overall UIT Cloud Program Goals (through 2019)
Goal 1: Perform cloud governance and portfolio management
Goal 3: Integrate cloud systems, processes, and services
Goal 2: Define organizational development program
Goal 6: Exit Livermore disaster recovery site
Goal 4: Run mission critical services in the cloud
Proposal: Remove Goal 5; add metrics to other goals
Cloud SecurityPresentation to Cloud Change Champions, June 20 2018Michael TimineriDirector of Information Security ConsultingCISSP, CCSP, CISM, CISA, CRISC, CEH, CHFI, PCIP, CySA+, CSM, AWS-PSA, GCP-CA… etc. etc.
Information Security OfficeOffice of the Chief Risk Officer
Image credit Linda A. Cicero | Stanford University News Service
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
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
ISO Consulting Core Responsibilities
University Cyber Risk Management
Security Assessments and Reviews
Incident Response Coordination
Policy and procedure development
Internal and Forensic Investigations
Awareness and Training
Penetration Testing
Governance and Regulations
Shared Responsibility“Ultimately, you can outsource responsibility but you can’t outsource accountability.”John McDermott, ACSAC 09
KEY:
Security Concerns in Cloud Computing
Security is the #1 inhibitor of cloud adoption
Source: 2012 Cloud Computing – Key Trends and Future Effects – IDG
Threats and vulnerabilities introduced by cloud computing
Legal Challenges
● Audit or Certifications Gaps● Subpoena and E-Discovery● Jurisdictional Challenges● Lack of Forensic Readiness● Licensing Risks
Recovery Challenges
● Lack or Compromise of Logs● Lack of Backup Data Isolation● Media Sanitization Impossible
Isolation Challenges
● Poor Encryption Key Management ● Restrictions on Vuln Management● Lack of Resource Isolation● Lack of Reputation Isolation● Data Processing Remains Unencrypted
Infrastructure Challenges
● Management Interface Compromises ● Compromise of Service Engine● Economic Denial of Service● Privilege Escalation
Perspective
Stanford’s top privacy and security risks
A. Phishing and other forms of social engineering
B. Unpatched servers and applications
C. Two-step authentication integration gaps
D. Unencrypted endpoints and external storage devices
E. Breach of large, University-operated repository of Moderate or High Risk data
F. Breach of large, third party-managed repository of Moderate or High Risk data
G. Non-compliance with international data privacy laws
H. Malicious insider threat from Stanford community members
I. Lack of current & comprehensive data inventory & retention/ disposal practices
J. Insufficient intrusion detection capabilities
K. Misconfigured permissionsLikelihood
Impa
ct
x
y
CH
D
AFE
I
B
GJ K
Minimum Security Standardshttps://minsec.stanford.edu
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 2015
5. Cloud MinSec Standards released December 2017
6. A virtual server in the cloud is subject to the same Standards as the on premise.
Minimum Security Standards for SaaS/PaaShttps://minsec.stanford.edu
SaaS/PaaS Minimum Security Standards (page 1)
STANDARDS WHAT TO DO LOW MOD HIGH
Product Selection Follow the Stanford cloud solution selection workflow found at Choosing and Purchasing a Cloud Solution.
Pre-implementation Planning
Follow the SaaS Considerations checklist.Follow the PaaS Considerations checklist.Follow the Security When Using a Cloud Product guidelines.
Inventory and Asset Classification 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.
Credential and Key Management
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:
1. Minimize their generation.2. Grant minimum necessary privileges.3. Rotate at least annually.4. Do not hardcode.
5.Do not share credentials.
Encryption1.Enable transport layer encryption TLS 1.1 or higher.2.Use encryption of data at rest if available.
Two-Step AuthenticationIf user login is not able to be integrated with Stanford SSO, enable two-factor authentication if offered by the solution.
Logging and Auditing1.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.
Data Management Contractually ensure that Stanford data is purged upon termination of the agreement.
SaaS/PaaS Minimum Security Standards (page 2)
STANDARDS WHAT TO DO LOW MOD HIGH
Privileged Access Workstation (PAW)
Administration consoles should only be accessed through a PAW when logging in with an administrative account.
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.
Regulated Data Security Controls
1.Follow all regulatory data controls as applicable (HIPAA/HITECH, NIST 800-171, PCI DSS, GDPR, etc.).
2.For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used.
Minimum Security Standards for IaaShttps://minsec.stanford.edu
IaaS Minimum Security Standards (page 1)
STANDARD WHAT TO DO LOW MOD HIGH
Platform Selection Follow the Stanford cloud solution selection workflow found at Choosing and Purchasing a Cloud Solution.
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.
Patching and Application Lifecycle
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.
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.
IaaS Minimum Security Standards (page 2)
STANDARD WHAT TO DO LOW MOD HIGH
Vulnerability Management
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.
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.
Inventory and Asset Classification
Maintain an inventory of deployed resources as well as the risk classification and service owner of those resources.
Additional Elaboration:•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.
IaaS Minimum Security Standards (page 3)STANDARD WHAT TO DO LOW MOD. HIGH
Firewall
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.
Credential and Key Management
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.
4.API keys:1. Minimize their generation.2. Grant minimum necessary privileges.3. Rotate at least annually.4. 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.
Logging and Alerting
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.
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.
IaaS Minimum Security Standards (page 4)
STANDARD WHAT TO DO LOW MOD HIGH
Backups1.Backup application data at least weekly.2.Encrypt backup data in transit and at rest.3.Store backups in independent cloud accounts.
Encryption1.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.
Privileged Access Workstation (PAW)
Cloud administration consoles should only be accessed through a PAW when logging in with an administrative account.
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).
Regulated Data Security Controls1.Adhere to applicable regulations: PCI, HIPAA/HITECH, NIST 800-171, GDPR, etc.2.For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement
(BAA) are used.
Additional Resources
Cloud Security Resources
SISA Cloud Security Course: https://sisa.stanford.edu
Stanford Data Risk Classification Standardshttps://dataclass.stanford.edu
Minimum Security Standardshttps://minsec.stanford.edu
Cloud Transformation at Stanfordhttps://uit.stanford.edu/cloud-transformation
Questions and Discussion
Thank youMichael [email protected]
PY19 program goals are with the OCIO, with all proposed UIT goals1
What is important for to know about the cloud?
Please take the training survey if you’ve received it and encourage others to do so2
Additional Feedback and Open Discussion
Your feedback on this presentation?
Your input on communication needs?
Open discussion and questions?
T !Our next meeting will be on July 25, 2018 at 3:00 pm