Helix Nebula: Secure Brokering of Cloud Resources for escience Dr. Jesus Luna Garcia
Outline Background The Blue-Box architecture Security Goals and Requirements
Let s imagine
Why a Public-Private Partnership for escience? The scale and complexity of services needed to satisfy Europe s IT-intense scientific research & space organizations are beyond what can be provided by any single company. European escience requires the collaboration of a variety of service providers and SMEs!
Helix Nebula: big science teams up with big business Strategic Plan Establish a federated multi-tenant, multiprovider cloud infrastructure To support the computing capacity needs for the ATLAS experiment Setting up a new service to simplify analysis of large genomes, for a deeper insight into evolution and biodiversity To create an Earth Observation platform, focusing on earthquake and volcano research Identify and adopt policies for trust, security and privacy Create governance structure Define funding schemes Adopters
Long Term Goal To create a multi-tenant Open Market Place for Science, where data, scientists, funding bodies, SMEs and downstream industry meet to work towards common interests An ecosystem to transform data into valuable information
Timeline 2011 2012-2013 2014 Endorse the Common Strategy Agree on the Partnership Select flagships use cases Define governance model Pilot Phase Deploy flagships, Analysis of functionality, performance & financial model Towards an open market for Science
Broker-based architecture: the Blue Box Each customer and supplier have a single connection to the Blue Box resulting in M + N relationships
What is a Cloud Broker? According to Gartner, Cloud Brokers may be classified 3 different categories as intermediaries between Cloud Providers and Cloud Consumers: 1) Cloud Service Intermediation: The broker provides added value to a cloud service, enhancing some capabilities or guaranties offered by the underlying cloud provider to cloud consumers. 2) Aggregation: The broker acts as an integrator, combining several Cloud Provider services into one, ensuring security and governance of data circulating between the composing services. 3) Cloud Service Arbitrage: The broker continuously attempts to select the best cloud provider based on price/feature considerations, potentially changing and migrating data between providers frequently.
Blue Box: Security Goals Baseline security policy across the HN federation. Secure data transfer between providers. Well-defined security service levels. Security assurance/transparency for cloud services. Centralized (continuous) security monitoring and incident response.
Security Service Levels "If you can not measure it, you can not improve it. Lord Kelvin (1824 1907) It is uncommon for cloud providers to specify the security level associated with their products and services. This limits informed customer decisions on security offerings: Despite the belief that my cloud provider seems secure, is it actually secure enough for my needs? Is my (confidential) data in the cloud more secure than in my data center? How do I compare different cloud offers with regards to security and price? If it s so important, then why is cloud security not measured?
Security Service Levels What makes it hard to measure cloud security? All the possible threats are not known. Quantitative vs. Qualitative vs. Uncertainty Technology-specificity: measuring security in cloud computing has several challenges e.g., IaaS-PaaS-SaaS supply chains. How to reason about measured cloud security? Security aggregation: drawing (useful) conclusions based on 100+ security controls. Security negotiation and adaptation (e.g., automated incident response). Specifying/standardizing security parameters in Cloud SLA s.
Security Assurance/Transparency The CSA Open Certification Framework is an industry initiative to allow global, accredited, trusted certification of cloud providers.
CSA STAR: Security, Trust & Assurance Registry Launched in 2011, the CSA STAR is the first step in improving transparency and assurance in the cloud. The STAR is a publicly accessible registry that documents the security controls provided by cloud computing offerings Helps users to assess the security of cloud providers Searchable registry to allow cloud customers to review the security practices of providers, accelerating their due diligence and leading to higher quality procurement experiences. It is based on a multilayered structure defined by Open Certification Framework Working Group
Continuous Security Monitoring Confidentiality level Uptime consumer CTP provider = Reports + Commitments + Alerts
Blue Box: Security requirements (at a glance) Authentication, Authorization and Accountability Role Based Access Control e.g. for remote management interface. Accountability security-related logging, signed timestamping, WORM functionality. Data lifecycle Secure de-provisioning/deletion/decommissioning (degauss etc ) Specific data export/portability requirements (formats, time limits) Cryptography Key management Crypto hardware/acceleration Entropy/randomness sources. Incident and vulnerability management Incident response services and service levels Testing requirements (e.g. external pen-testing) Third party security services used, interfaces required. Legal/Policy/Compliance Certifications Sector-specific laws applicable (e.g. for healthcare data). Processing of personal data Location/jurisdiction-limitations Third parties/subcontractors Breach notification requirements Maximum, minimum data retention Purpose limitation.
The road ahead Solving the security challenges associated with cloud brokers. Legacy security services. Don t forget high performance!
Thank you! Contact@helix-nebula.eu http://www.helix-nebula.eu All Helix Nebula public documents are held in an open access repository: https://cds.cern.ch/search?cc=helix+nebula&ln=en&jrec=1