Frankly Speaking, 4/22/20 - How cloud sessions complicate security
A biweekly(-ish) newsletter on random thoughts in tech and research. I am an investor at Dell Technologies Capital and a recovering academic. I am interested in security, AI/ML, and cloud.
If you were forwarded this newsletter, you can subscribe here, and view old newsletters here.
Many of you know that in order to stay "hip," I try to see cool trends on TikTok. But last week, I felt really left out since no one invited me to Clubhouse! (Not the developer tool, but the audio-based social app.) Now, I know what real FOMO feels like.
Anyway, moving onto more important thoughts....
LET'S BE FRANK
In the last newsletter, I talked about some ways that the public cloud is changing our thoughts on IT and security. More specifically, we need a completely different IT/security paradigm for the public cloud.
I discussed that the public cloud is fundamentally different than a datacenter, and I believe it's hard for legacy security companies to solve cloud security issues organically. So, how should I think about the public cloud? What is the right framework?
I'll dive into a couple of examples in this newsletter. When you own your own infrastructure, it is a private utility, and resources are split up among individuals in your organization. In a way, I think about having your own infrastructure similar to having a dedicated, private network, and using the public cloud as using the wide-area network. So, what are the implications of this?
When you have your own infrastructure, it's one large unit with interconnected pieces. If a breach happens in one portion of it, the attacker can access other parts of the infrastructure. Of course, you can have microsegmentation, etc. to prevent this, but in a sense, you have only weak isolation just because there's no need for strong isolation. However, when you're on the public cloud, your instances are more isolated and session-focused because the public cloud requires it. The isolation is inherently stronger, and a developer has to be very deliberate if they want to connect multiple instances together. From a security standpoint, the focus has shifted to the security of the session and its connections rather than the whole infrastructure. As a result, security focuses are different. For example, in the public cloud, identity becomes a bigger issue as you want to make sure that instances/sessions have the authorization to talk to each other. However, concepts, such as insider threats, are no longer differentiated from regular, external threats.
Another property of having your own infrastructure is flexibility and autonomy. You can write your own customized tools and policies. In the public cloud, you have access to great tools that the cloud providers have written for you that your own developers and IT people might not be able to write. At the same time, you are stuck with cloud-wide policies. For example, S3 buckets are open by default. Network configuration tools are difficult to use and require more DevOps and developer effort. "Boring" IT work can no longer be abstracted way. Now, you have to manage basic security issues, such as insecure configurations whose defaults you cannot change or set.
I'm trying (as well as the industry) to develop good frameworks to think about the public cloud to inform our security frameworks. It's clear we need to start from first principles rather than adapting existing paradigms. I think one interesting way to think about the public cloud is to recognize its session and instance-based nature. With that assumption, that's how we should be focusing our priorities in security for the public cloud. This is just one piece of a very large puzzle and by no means, captures all potential security problems. But, it's a start.
This is an area of ongoing research for me, and I'm always open to chatting more about this! Please email me with questions, concerns, and thoughts.