The Biggest Cloud Security Mistakes Are Still Basic

I'll give you two two different examples. One is things that are not encrypted. You want your data to be encrypted, especially you as a consumer and and myself as well as a consumer. You want to have the level of trust in your providers, in the the vendors that you're using that whatever data that you're giving them is going to be encrypted, is going to be protected properly. It is still very common going back to your example to find and continuously find oh we forgot about this oh we forgot about that oh there's something in the you know in transition that where we take the data process it and then send it out but that is not encrypted and you end up with another database with another location in your architecture that does not have adequate protections for the data that you have been entrusted with.

So that's a classic example when when you you know when we work with our customers we often hear well yeah like this is this is the architecture this is where the data lies and uh and that's protected that's that's encrypted or or or secured and then they automatically go and there's a lot of other areas that that we're we're still trying to kind of find out and weed out and every time something pops out and the process again it's less about finding the process of now telling you know or or reconfiguring that environment to have the adequate protections is what takes a lot of time again pretty much like your example of oh do this as well and do that as well do that as well so you know I'm just riffing on the same example and and giving you the correlary of what what

does that look like in an enterprise environment the second example is again trivial keeping things open S3 bucket is has been since pretty much the day that S3 buckets have been invented the bane of security issues and the equivalent of those basically forgetting to properly restrict access to information. Uh and again these might be you know these might be storage units that are designed to have information in the clear but should not should not be accessible to the public especially if they can can they can also be written to not just read from. So finding again finding all those things is one part of the problem fairly trivial can still be automated to to a large extent. Applying the right controls and making sure that they're not open to the public and doing that as part of the overall architecture is still one of the

biggest problems. And what our customers tell us is since we can do things in a contextual manner, we're not just slapping, you know, a stop sign in front of an S3 bucket. We're not just shutting down an instance. We're understanding what is the architecture within that instance lives and provide a bespoke kind of curated deterministic fix for that architecture to prevent access to that resource while allowing that resource that architectures to still live. That's where we're being told that we're saving dozens of hours of engineering time that otherwise would have been spent on trying to kind of untangle. How does that environment look like? What are the requirements? What's the documentation? So, these are the the the two most common kind of use cases. I'm not even talking about other other things that are more hygiene or cost optimization or even maintaining an environment and

and upgrading and updating certain software components in that environment in an automated fashion that still takes into account the context and not just trying to kind of mass upgrade a software version for for a component that ends up typically with a disaster. What is your ultimate goal for what you're doing in the next three to five years? And what would you like to leave people with in order for them to better understand why that's um a vision worth working towards? >> I'll make it very quick. The ultimate goal is to save people time and especially organizations to save engineers time that is currently spent in an non-effective manner that is repeatable that requires them to do a lot of reading and contextualizing. That's my goal is to remove a lot of toil from the process of engineering of platform engineering.