Download as PDF, PPTX
Uploaded byPriyanka Aash
What is needed in the next generation cloud trusted platform ?
The document discusses the essential elements of a next-generation cloud trusted platform, emphasizing the importance of a multi-layered security approach that includes hardware, operating system, application, and deployment layers. Key points include the need for trusted hardware and software supply chains, continuous monitoring, and sandboxed applications to mitigate risks, particularly in the evolving landscape of cloud security. It concludes by highlighting the importance of robust authentication measures and best practices for moving to the cloud securely.
More Related Content
Similar to What is needed in the next generation cloud trusted platform ?
What is needed in the next generation cloud trusted platform ?
- 1. SESSION ID:SESSION ID: #RSAC CSV-T10 Directorof Cloud Security Google @MrDBCross David B. Cross What is needed in the Next Generation Cloud trusted platform?
- 2. How Do YouTrust a Cloud Platform? Trust through transparency: Logging, auditing, compliance Automation: Abstraction, detection and remediation Control: Policy, IAM, encryption, 2FA, etc. Defense in Depth: Protection at cloud scale via trusted stack Innovation: Next generation application model 2 Fact: Everyone is moving to the cloud
- 3. What Comprises aCloud Trusted Platform? Usage Operations Deployment Application Network Storage OS + IPC Boot Hardware 3 Think of the cloud platform as a 9 layer stack From Hardware -> Users Each layer is a security layer Trust is built by ensuring you have security in each layer
- 4.
- 5. The Need fora Trusted Hardware Stack 5 Trusted Supply Chain of Hardware and Software Cloud Attack Surface Controlled design/build of server components Secure microcontroller Firmware and BIOS integrity protection Validated components before loading Monitoring from chip level to the cooling systems Cryptographically authenticated and authorized Trusted hardware Secure boot Monitoring at scale
- 6.
- 7. OS Layer: TheRisks Without a Hardened Kernel Reality: VMs should always be viewed as untrusted 7 VM Containment is Mission Critical Boundary between the host kernel and untrusted code running in a VM A separate userspace virtual machine monitor
- 8. OS Layer: TheRisks of Unknown Hardware Unknown hardware configurations The more untrusted software, the risk is exponential Attack is easier through drivers at the OS layer 8 Controlled Harware Configurations Homogeneous system configurations No legacy hardware or unused devices in cloud datacenter Tightly controlled software driver supply chain
- 9. OS Layer: RecommendedRisk Mitigations Continuous attack surface reduction. Trim the kernel and hardare drivers to only what is needed Constant fuzzing of all components. Attackers do the same. Extensive kernel address space randomization and code flow integrity All kernel and user mode crashed should be monitored and analyzed. This is how you find the zero days. 9
- 10.
- 11. #RSAC The Cloud FabricLayer is Evolving 11 Standard Cloud Fabric Definition: "The loosely coupled storage, networking and parallel processing functions linked by high bandwidth interconnects" TrustedFabric: All functions and flows are known and validated through policies and monitoring
- 12. Application Layer: CodeHas an Identity 12 Right code running on the right machine authorized by the right identity accessing the right data at the right time Data Policy Binary authorization Data protection Machine Identity Machine identity Code Identity User Identity
- 13. Trusted Fabric Recommendations Codeis always tested and reviewed Only execute code with known cryptographic signatures and trusted provenance All jobs and policy changes audited automatically Code and machine identity tightly bound by policy Compartmentalization of code based on its role 13
- 14. Despite this EvolutionWe are Not Secure 14 Mainframes ContainersServers Virtual Machines Micro- services Multi-tenant systems do not have adequate partitioning of resources The container security ecosystem and isolation is still immature
- 15. Consider a SandboxedApplication Model 15 Mainframes ContainersServers Virtual Machines Host kernel syscall are the continued source of big risk Sandboxing the application environment reduces this risk Sandboxed Application Model
- 16. Sandboxed Applications –The Challenges 16 Untrusted app Memory Compute OS/IO/Disk User Data Privileges More Less Privileged instruction isolation Privileged memory isolation Machine resource isolation User data isolation Supervisor bit, SMEP ASLR, SMAP, TrustZone chroot, namespaces, capabilities File permissions, encryption VMs, Containers Cloud Storage GCP, AWS IAM, Encryption at rest, user supplied keys On Premise Datacenter Cloud
- 17. Sandboxed Applications -Philosophy Defense Layers 17 Independent security boundaries Combining diverse technologies in single sandbox No single vulnerability affects all user data
- 18. Sandboxed Applications -Philosophy 18 Continuous internal and external reviews Assume attackers have all your source code Unit, functional and fuzz testing Continuous integration and deployment of upstream changes Maintenance
- 19. Sandboxed Applications -Philosophy 19 Monitoring Logging at all layers, all the time Central repository and tamper resistance Alerting and incident response processes Incidents are how you improve the system
- 20. Problem: We all havesecrets! The Continued Application Layer Risks Protecting secrets is increasingly hard Database credentials Passwords API and OAuth tokens 20 SSH keys SSL certs and keys, etc… IP protected algorithms
- 21. The Next GenerationCloud Application Model Past Ecosystem Solutions Explored: TPMs were the "hope" for trusted applications Intel TXT and AMD SVM (secure hypervisor launch) also had potential... 21 The Past
- 22. The Next GenerationCloud Application Model 22 Looking forward into the future: Secure Isolated Execution Environments (SIEEs) The Potential Solution: Software enclaves with attestation and optional hardware Next generation application containers
- 23. Next Generation CloudApps Using Hardware The benefits of hardware Reduce the Trusted Computing Base to the smallest footprint Protect memory against bus snooping and memory tampering attacks Protect against root-level admins and malicious users Attested and verified VM_BVM_A app_z bins/libs app_x bins/libs trustlet_y bins/libs guest kernel Shared Volume Storage Hardware/Firmware guest kernel KVMHost OS 23
- 24. The Next GenerationCloud Application Model 24 Emerging industry technologies: Intel SGX hardware enclaves • Dedicated HW chip as a root-of-trust • Hardware-assisted isolation of code execution • Fully attested state (pre-OS, Host OS, VM, and Enclaves) • Verifiable by consumers AMD Secure Encrypted Virtualization • Encrypted guest memory • Restricted key access Potential Future Solutions
- 25.
- 26. Deployment: Strong Multi-FactorAuthentication The boundaries are down and the model is changing 2FA and security keys are here now Session re-use and lack of device binding is the continued risk Advance MFA usage with other policy constraints 26 Secret Protection is Critical Token Reuse Strong Authentication Hardware session binding and enforcement Policy based, unphishable authentication using Security Key
- 27.
- 28. Ops Layer: MachineLearning is Not the Only Answer 28 Trusted Machine Trusted Person Untrusted Location Untrusted Time High Risk Environment specific endpoint policies Machine learning analysis Two motions must be combined at the ops layer to achieve Defense in Depth: 1 2
- 29. Apply: Best Practiceswhen Moving to the Cloud 29 1 Examine the cloud platform security stack in detail from an end to end hardware and software perspective Establish end to end trust capabilities and policies from devices to your data Ensure your cloud security policies use both your environment policies with machine learning analysis Explore building next generation applications to be to be sandboxed and using hardware isolation 2 3 4