How Can Cloud Systems Engineer Security and Trust?

TL;DR

Secure cloud systems require trust to be deliberately engineered across every layer, because inherited Internet designs and hidden dependencies create weaknesses that most users cannot independently inspect. Effective protection combines deep infrastructure controls, careful data-lifecycle practices, evolving threat models, and investments proportionate to the value of the data and reputations at risk.

Transcript

Please welcome Quentin Hardy, Suzanne Frey, and Amin Vahdat. Thank you. Thank you very much. Well, and thank you so much for making time at the end of what I hope has been a very fruitful and productive session. All security in some ways, all security talks in some ways are talks and arguments about architecture. Um, the movement of valuable goods ... Read More

Key Insights

• Early Internet design assumed substantial trust because the network was created in an environment unlike today's large, valuable, and highly distributed systems. Those original architectural choices enabled rapid expansion, but they also left weaknesses that cloud security teams must address rather than assume away.
• An IP address represents both identity and location, according to the design regret Vint Cerf shared with Amin Vahdat. The combination was efficient when address space was precious, but it enables parties to make misleading claims about who they are or where they are located.
• Source code access does not guarantee a trustworthy system because the tools compiling that code may themselves be compromised. Ken Thompson demonstrated this problem by describing a concealed compiler backdoor that could provide access to Unix systems without appearing in the source developers expected to inspect.
• Security verification extends through every underlying layer, including generated machine code, processors, and embedded firmware. Only a small number of specialists can evaluate all these components, making complete independent verification technically possible in principle but close to impossible for most organizations and individuals.
• The 1989 Internet worm showed that clever software could overwhelm infrastructure that was not designed for hostile or mistaken self-replication. Its creator intended to place a program across roughly thirty to forty thousand connected computers, but incorrect constants caused replication rapid enough to nearly disable the Internet.
• Processor attacks disclosed by 2018 showed that co-resident users could potentially extract secrets through speculative instruction execution. This expanded the threat model beneath applications and operating systems, demonstrating that cloud defenders must consider hardware behavior when isolating workloads and protecting sensitive information.
• Security checklists improve protection by changing attack economics rather than promising perfect safety. Better security hygiene raises the cost imposed on attackers, while defenders must decide how much investment is justified by the value of their data, services, company reputation, and affected users.
• Secure data disposal is a core cloud responsibility because retired disks may still contain user information. Providers must decide whether storage can be wiped and reused in non-production systems or whether physical destruction is required to ensure that the data can no longer be accessed or misused.

Questions & Answers

Q: Why must trust be deliberately engineered in cloud systems?

Trust must be deliberately engineered because modern cloud services operate on Internet foundations that were not designed for every hostile behavior possible today. Valuable data moves through complex distributed systems whose software, compilers, processors, firmware, networks, and physical storage can each introduce risk. Providers therefore must examine the complete architecture and protect every plausible path through which information could be accessed or misused.

Q: How did early Internet design decisions create modern security risks?

Early Internet designers made choices that were practical for their environment and helped the network grow. One example combined identity and location within an IP address when address space was precious. That decision later enabled misleading claims connecting a network identity with a location and became a basis for denial-of-service attacks. Modern defenders must compensate for these inherited architectural assumptions.

Q: Why does source code access not prove that software is trustworthy?

Source code cannot prove trustworthiness when the tools that transform it may contain hidden behavior. Ken Thompson described how a C compiler written in C could conceal a backdoor without leaving the expected evidence in the inspected source. Verification would then need to continue into the compiler's output, the processor executing it, and potentially the embedded firmware beneath that processor.

Q: What did the 1989 Internet worm reveal about distributed systems?

The 1989 incident revealed that the Internet was not designed for every action a clever programmer might attempt. An undergraduate at Cornell sought to place a program on every connected computer, which then numbered roughly thirty to forty thousand. Incorrect constants made the program replicate so quickly that it nearly took down the entire Internet and threatened hours, days, or weeks of disruption.

Q: How do processor vulnerabilities affect cloud security?

Processor vulnerabilities extend cloud security concerns below applications and operating systems. Attacks discussed from 2018 showed that a party co-resident on the same server could potentially obtain secrets from another address space by using speculative instruction execution. This means effective protection requires an evolving threat model that considers hardware behavior, workload placement, isolation, and the lower layers supporting distributed services.

Q: How do security checklists change the economics of hacking?

Security checklists improve baseline hygiene and force attackers to spend more effort or resources. Their practical purpose is to raise the cost of a successful compromise rather than suggest that every threat can be eliminated. Organizations must continue increasing that cost while weighing their own required investment against the value of their information, operations, users, and reputation.

Q: How should cloud providers handle retired disks containing user data?

Cloud providers must determine whether retired disks can be safely wiped and reused or whether they need physical destruction. The decision requires knowing the level of wiping necessary to ensure that user information is gone, especially before moving storage into a non-production architecture. If reliable removal cannot be established, shredding the disks is an available method for preventing later access or misuse.

Q: Why is complete security verification impractical for most users?

Complete verification requires knowledge and access across many dependent layers. A person might inspect source code and compiler output, but then would need to evaluate the processor and potentially its embedded firmware. The number of people capable of examining each deeper layer becomes progressively smaller. As a result, full verification may be possible in theory while remaining nearly impossible for most users and organizations.

Summary & Key Takeaways

• Early Internet architecture prioritized practical growth rather than protection against every future threat. Decisions such as combining identity and location in an IP address helped the network expand, but also created lasting security problems. Modern cloud architects must understand these inherited assumptions before they can design stronger systems and defenses.

• Complete trust verification is nearly impossible for most people because every software layer depends on lower layers. Inspecting source code is insufficient if the compiler, processor, or embedded firmware may behave unexpectedly. Cloud security therefore requires specialized expertise, extensive investment, layered controls, and continual attention to an evolving range of possible attacks.

• Security must cover the entire data lifecycle, including the retirement and reuse of physical infrastructure. Google had to determine whether old disks containing user data could be wiped and repurposed or needed to be physically shredded. Such operational details illustrate how cloud providers must anticipate every possible route to unauthorized data access or misuse.