Hi, everyone. Welcome to another episode of the Ask A CISO podcast powered by Horangi. Every month you get insider security tips and insights on the newest trends in cybersecurity from top CISOs to help you improve your domain knowledge and get better at your job.
My name is Raphaël Peyret, I'm the VP of Product at Horangi. With me today is Jeremy Snyder, a veteran of the cloud security space, and one of the first people in the team at AWS all the way back in 2010 covering ASEAN.
Hi, Jeremy, thank you so much for your time today and joining us on this podcast. How are you today?
Cool. Well, I'm sure we have loads of really, really interesting topics that our audience will be interested in hearing. But first, I'd love to hear a little bit more about your background and kind of, you know, what have you seen in this world of cloud security?
Yeah, absolutely. I'm happy to share. As you mentioned, I was one of the earliest people at AWS in Singapore back in 2010, I was the first person covering the Southeast Asia region, a region that people in that side of the world may know as ASEAN, the Association of Southeast Asian Nations.
Before that, I was actually a practitioner, an IT practitioner, I ran data centers and back-end systems for a couple of SaaS companies and a video game company in the early part of my career, made the transition to AWS when cloud was really first becoming a thing.
And Amazon's goal at the time was to bring people into roles like this that could go talk to CIOs. CISO was not as much a thing yet, by the way back then. So I was mostly talking to CIOs and CTOs about using AWS as a potential platform to run their applications or run their infrastructure.
And you know, it was a great experience at the time going around and just explaining to people the vision of what Cloud could do for them and how it could dramatically transform the way that they ran their IT operations. Just as you know, an easy example of that one of the main things that I discussed with every CIO was, you know, or every CIO rather was that we're on the hook for replacing that hard drive at 3 am, not you. And just getting out of the hardware maintenance game was already a game-changer for a lot of organizations at that time, especially with, in those days, the quality of some of the data centers around Southeast Asia not being all that great.
But ultimately, you know, I decided to move on from Amazon. I have, however, stayed in the cloud ecosystem ever since. I've gone through a couple of other companies. Rain Cloud (Consulting), DivvyCloud, being kind of the one that is probably most notable for people who are interested in this podcast talking about security.
DivvyCloud was a cloud security posture management company founded in 2013, acquired in 2020, by Rapid7. I came into the organization in 2016, I led the commercial activities from 2016, through exit in 2020. Really built up the sales team, sales engineering team, worked with customers around the world, which was really fascinating working with different profiles of customers, from those who were making their first foray into the cloud, to those who are cloud-native organizations, and we're really doing things very differently.
After DivvyCloud, I joined the team at Rapid7 as part of the acquisition, actually moved into the M&A team at Rapid7, worked on three acquisitions that Rapid7 closed in the course of 2021. And recently decided to take a little bit of a break, and that's where you find me today.
Great. I mean, lots of different and varied experiences, maybe, first, kind of line of questioning, I think it's really interesting that you got to see the really early beginnings of the cloud, and even kind of before CISO was so much of a topic. And that leads me kind of to my first question: how have things evolved? And I think something you mentioned that was really interesting, as well, CISOs weren't quite so much of a thing back then. And, you know, does the cloud have something, a part to play in that? Or is that unrelated?
It's certainly related. I think that when I think about the cloud, to me, the number one thing that really always comes to mind is that the cloud has been this massive enabler for organizations to digitize. So as they have started to move away from, you know, paper processes and move towards digital processes, the cloud has been the place that has enabled them to move quickly, to get things up and running quickly.
But what are the results of digitization?
Well, you're naturally accumulating metric tons of data at this point, right. And so that is where I think CISO really evolved out of that realization that we're just going to have so much more data as an organization than we ever had before. And oh, crap, a lot of this data is sensitive, and it would be really, really bad if it got out.
And I think, you know, for a lot of organizations, it became the case that they realized that it wasn't enough to have security just roll up to IT, which is how it had been done previously, you know, a lot of companies that you went into, either the IT people double as security people, where you'd have an IT department with one or two people who were kind of security specialists intended to come in and review things, and, by the way, say no, a lot.
That is kind of a well-earned reputation from a lot of security professionals is that they are the “no” people within an organization. But it's really that kind of digital evolution that I think about as creating the need for a role like CISO, you know, Chief Information Security Officer, it's just volumes and volumes of information that organizations never had before. And now they do have, and they need to, you know, exercise good governance and be good stewards of all the data that they have.
And so, one of the things that's interesting with the cloud, right, you said it yourself, it's, it lowers the barrier to digitalization. And that also kind of means “I don't really need the IT team quite as much as a, you know, as a business team. I can spin up my own stuff, I don't need somebody to set up those, you know, those data centers.” And so the “no” guys kind of aren't in the picture anymore. So how does that change security?
Well, I think the “no” guys still are in the picture in most organizations, I think, you know, there may be a vision that they evolve out, or that they evolve into other parts of the organization and kind of get integrated with teams.
But I'd say the way that this has really affected security is that things are moving so much faster than they ever have before. And whereas in the past, you would have kind of a dedicated security review to a lot of proposed changes, that could be anything from a modification to an existing firewall, that could be a new application coming up and running. But companies would typically build in a cycle, whether that's, you know, two weeks, four weeks, what have you, where security got to review things and then provide feedback in the past.
That's going away. That's one of the main evolutionary steps that I think, you know, businesses are under pressure from either from competition or from just market forces to move quickly and really quicker than they ever have. And that is a real challenge for a lot of organizations.
How do you build security into a process that's moving at a speed you're not used to operating at? And how can you be sure that the changes that you're making are actually not going to cause problems to your environment? That's where I think, you know, is a real challenge that a lot of companies are facing.
Yeah. I think that's a great segue into, kind of, up until now, we're talking more about kind of pre-cloud versus cloud. So how about, like, the beginnings of cloud and cloud security? And in particular, you know, with DivvyCloud, you guys, you started, basically, you created this category out of nowhere: Cloud Security Posture ManagementCloud Security Posture Management. Tell us about that.
Well, we weren't the first or the only company really exploring that space at that time, there were other companies like Evident.io and Redlock, who were really also kind of working on the similar problem set.
But if you think about how Cloud has evolved, you know, back when DivvyCloud started, and when I joined the team in 2016, there was a lot fewer services available. And the paradigm from those companies was still: launch EC2 instances, install software on top of those instances, run your applications there.
And by the way, it tended to be, you know, one to maybe five accounts per organization or per company. And the best practices at the time were, maybe, a dedicated network segment. So, in the words of AWS, a dedicated VPC for an individual application. But within one account, you might be running tens, if not hundreds of applications, you would use VPCs to separate them or segment them from each other.
But ultimately, you are primarily relying on a kind of Compute, Storage, Transfer (CST), the core services as we used to refer to them, which is to say, EC2, S3, and database services, and maybe EBS for block storage, right.
And so the evolution that we've seen over time is that you know, that pattern, if you went into a modern organization and you said that that was how you wanted to run your cloud environment today, you'd be laughed out of the room, like no one would take you seriously, that's not how modern applications are designed.
Modern applications are typically designed with a natural blast radius of a single account. The only application running in the account is the one that you're working on right now. In fact, you might have other dedicated accounts for that application and non-production environments, such as, like a dev-test or a staging environment. And you then kind of really use that as your segmentation. You'd probably try in the first effort to not use EC2 anymore. You probably tried to use a more efficient compute model, something like serverless, or straight to containerization.
I mean that, that change on its own, this kind of evolution of how organizations are using accounts, how they're using different segmentation constructs, and how they're using different compute environments, that has really kind of forced change on the security side.
You know, I think back in 2016, when I started at DivvyCloud, for the most part, we were really focused on very simple use cases. Things like open security group rules, you know, did you have Port 22, open to the world? Did you have RDP open to the world, where you're, you know, SQL databases open to the world, etc, right? And, of course, S3 buckets being one of the big, big ones for many, many years, they're 2016 through 2019, early 2020. You know, that was a major, major cause of concern.
And frankly, the cloud providers made that an easy, low-hanging fruit to go after, so to speak, right, because the default settings on a lot of those services was to leave them open. If you just follow the setup wizard and you just click through on your security group, the only rule that's going to be suggested to you is leave that thing open to the world so you can connect to it. Right?
Or similarly, you just take the default on S3 and you know, it just creates a public s3 bucket. You know, that really started to change in 2019, along with kind of the overall shift in how organizations were using cloud, which by the way, like that may have started earlier. But yeah, you know, those early days, those early years were really focused on very, very simple binary checks. Is this thing open to the public or not? And can we help you identify it? Can we help you identify if it's not open to the public, but somebody goes and makes it open to the public? How quickly can we catch that? How quickly can we give you an alert around that change in your environment? Those were some of the core use cases. And I'd say nowadays, the use cases are much more sophisticated and much more complex.
That's really interesting. So where's this whole headache? If we're adding, I mean, in particular, what I'm hearing here and things that maybe, you know, the scary in some way, when you're handling security, and you're talking about getting more alerts, right? Where is that going? If we're going for? What do you mean by more complex, right? And yeah, is that necessarily a bad thing? Or, or not necessarily?
It's not necessarily a bad thing, because I think the complexity comes from the fact that customers have gotten better at covering some of those basic use cases. And that's a good thing, right?
So the complexity is really around things like multi-vector attacks that layer multiple, sorry, that leverage multiple layers of the application, or the infrastructure. So if we look at some of the recent examples from the last couple of years, of course, we still see open S3 buckets from time to time. But we also see things like an attack that started with an application layer vulnerability, that then opened command-line access on an EC2 instance and allowed the attacker to enumerate the IAM role associated with the instance, understand the permissions that that role provided, and then use that for, you know, East-West discovery of data and then data exfiltration from the account.
So those kind of multi-layer multi-vector attacks, I think, is where the market is headed. And where the market really where I mean, is where the attackers are headed. You know, they have realized that companies have gotten better at the basics. They're still not great at overall top to bottom security up and down the stack.
By the way, I think that is largely still a function of, kind of, siloed teams that don't necessarily coordinate with each other. The vision of DevSecOpsDevSecOps is honestly, for most organizations, still a vision, and not a real integrated function. But that's, you know, that's where I think attacks are headed and the trends show us that that's where, you know, customers are, are, the advanced customers are thinking about protecting themselves top to bottom, and that's a good thing.
Yeah, defense in depth. A lot of you know, the problem is that when you really want to do it, there's so much and so much needs to change, particularly is, you're saying for, to bring about this DevSecOps vision. What are the, you know, pioneers doing there, the more mature companies that have been at this for a while, if we want to look to see kind of what the future holds?
Yeah, well, look, I think that there's a couple of things that I would really identify as, where, let's say, the real leading-edge companies, those that are, you know, pure cloud, 100% cloud, born in the cloud, whatever you want to say, cloud-native companies, but those that are really advanced in their utilization of cloud platforms.
One is moving away from compute instances. Compute instances are great, they're very powerful, you can do a lot with them. They're super flexible, all of that is awesome. But they still fundamentally make you as the customer manage the instance, which is to say, managing the operating system, responsible for vulnerabilities baked into the operating system. And that could be you know, a CVE in any open-source package or who knows what. And so what we're seeing from these companies is it's more efficient, it's less management overhead and it is less attack surface, if they move towards serverless, if they move towards containers, if they try to get out of managing the underlying compute instance, the operating system if you will, and they move towards something that just has a lighter footprint and doesn't necessarily have an operating system accessible to the customer or to an attacker. So that's one.
And along with that, by the way, I realized that that's kind of aspirational for many companies, including those cloud-native companies, they are still running quite a lot of their workloads on EC2 or other compute services on other cloud providers.
One of the other things we're seeing from them is just regular cycling of those instances - don't let an instance live very long. You know, let an instance live for one day, two days, things like that. But then redeploy it just as a best practice. You don't know about APTs until they've been in your network for a while. And being able to clear things like in-memory exploits, being able to clear things like somebody who may have had access to a compute instance, wasn't yet using it, you know, those can be good practices as well. So just from a hygiene perspective, let's throw away our instances or cycle our instances every so often. We just kind of raise the bar, or the level of effort that a bad actor needs to go through in order to compromise their organization. So if they had access, okay, it's gone. If they really want to, they can come back and try again. But frankly, you know, most bad actors are lazy, they're going to go where the easiest stuff is, where it is easy for them to compromise an organization. So that's the second thing.
I have heard also from some of these customers, is that they're no longer deploying endpoint protection on a lot of these compute instances. And, you know, I, I honestly questioned that when I spoke to a couple and this is, by the way, just anecdotal, just a couple of things, no scientific data behind it. But talking to some very, you know, very advanced cloud organizations that are, like I said, moving toward serverless, and containers and cycling instances regularly.
One of the messages I heard consistently was that the management overhead of making sure that an endpoint agent is installed is pretty high. And the benefit doesn't necessarily justify the management overhead. So I thought that was really interesting. And I think it'll be interesting to see how the endpoint vendors really evolve their own offerings to move towards serverless and containerized platforms. And I think, you know, I think they are ahead of the curve there. And there, there are some interesting things coming from different companies.
The other thing is, you know, really evolving into as much as possible, chasing that dream of having security end to end throughout the lifecycle. So Secured by Design, secure by what we're including in our build, and secure in our production environment, post-launch. So we think about organizations that are using vulnerability scanners for their build pipeline. And they're doing things like making sure that they have the latest and greatest of the common open-source libraries that they're deploying, or at least, that they're getting CVEs out of their open-source packages that they're including in their application structures, right.
Doing things like checking infrastructure as code configurations and templates, and making sure that if I've got, you know, secure code, I've got vulnerabilities worked out of my application. Now, the next step is to make sure I don't deploy into an insecure infrastructure, and that my design pattern there actually, you know, is only allowing the kind of access that I really wanted to have.
And then last but not least, and this is one where I think a lot of customers struggle is all of these cloud provider accounts come with so many defaults and includes, you know, that could be default roles, that could be user accounts, things like that permission sets, etc.
The really advanced customers that we see are actually getting rid of all of that. And so when they create new accounts, they're using more of a templated system that strips away everything from that account and only instantiates things that they explicitly declare.
So okay, you need a role for your EC2 instance to access S3? Well, great, let's create a dedicated role for only that S3 bucket access with the right permissions to access that bucket. And that will be the only S3 access role in that account. You know, really stripping away everything, more of a zero-trust kind of approach, if you will, right. And only using things that you've declared that should exist in the environment. But again, that's like, you know, that's something that almost every customer struggles with, and frankly, it's a lot of effort to set up. So yeah, that's those are some of the patterns that I've been seeing over the last couple of years.
It sounds like you know, we're in a sense of the shared responsibility model of the cloud, that the movement is towards shifting more of the responsibility towards the cloud service provider from, you know, the hardware and is moving up and up and up. So how far up do you think it'll go? Where do you think the balance is going to be there and I'm assuming it's going to depend on the type of workloads or?
That's a great question. I think, from what I've seen, customers will try to shift absolutely as much as they can, off of their own books and onto the cloud providers’ books. And whether that is by embracing native services that have security baked in or reduce the attack surface or reduce the number of, you know, misconfiguration possibilities, you know, that is, I think, the draw for a lot of customers, you know, make this so easy for me, serve my needs, in terms of infrastructure, in terms of application availability, in terms of whatever, but make it so easy for me as the customer that I can't actually make a mistake, even if I wanted to, you know, that I can't actually expose my data.
And I think that is where most customers would ideally love to get to. And, frankly, you know, the cloud providers, they are tools vendors, right? So they will always try to make these things easy. It will be left in the customers' hands, or it's a massive opportunity for service firms to come in and help customers configure this stuff. Well. So there's a there's always kind of give and take.
And probably like a combination of all of the above. I mean, there is kind of a talent crunch, right? On the cloud, around cloud security. Hopefully, there have been some good takeaways, what is the, if there were to be just like one or two key things that people, particularly a lot of firms that are still at the beginning of their journey towards this deep, deep layer of security in the cloud. What are the key things that they should keep in mind, you know, and maybe thinking practically, they might not have the biggest teams, you have to do what these you know, pros are doing, but to get started on their journey?
Well, if they don't have the teams to do what they need to do, I would say go get some help. I mean, there is expertise, as you said, there is a talent crunch in cloud in general, and in cloud security in particular. So yeah, that's, that's a real thing. But I do think that there are, you know, teams and companies out there that can really help with good security design patterns, with security execution, with managed security, with managed services, who knows what. So that's one thing is, you know, don't feel like you're alone. Go get helpGo get help.
Second thing, though, is everything always starts with visibility. And we haven't talked about it really on this podcast so far. But, you know, I kind of assume it goes without saying: if you can't see what's out there, or you don't know what's out there, there's no way on earth that you can have a level of confidence that it's not being exposed or that it's not misconfigured, or that you are protecting it properly. So you have to know what's there. And that can be accomplished in any number of ways.
If you look at, you know, kind of the first wave of CSPM companies of which DivvyCloud was a part, the very first thing that all of the CSPM vendors did was gain access and visibility into cloud accounts. AWS, Azure, GCP, it's always kind of the same pattern, get access to the API layer, issue a set of queries to build up an inventory, present that to the customer so they know what all is out there.
And by the way, most organizations, when they would get that first look, there was always at least one surprise. They didn't know that they had this, they didn't know that they had five compute instances running in a region on the other side of the world. They didn't know that their developers were running things. 24/7. Whatever it is, I mean, there's all kinds of stuff. So start with visibilitystart with visibility.
And then I would say, definitely get rid of the low-hanging fruit so do make sure that you don't have stuff accidentally exposed to the world, whether that's S3 security groups, compute instances, database instances, what have you. But one of the places that I really recommend companies start these days is: don't try to get it all done in one move.
A lot of organizations think, Oh, well, I need, you know, PCI compliancecompliance so I'm gonna start my cloud security journey by working towards PCI audit compliance. I think like, wow, that's great as an aspiration, (but) you're setting yourself up for a really long-term process without a lot of success in the medium term.
I always tell organizations: start with something that is, if this really is the beginning of your cloud security process, start with something that is much more attainable, has immediate results, and then iterate out from there. So I always recommend to people start with the CIS benchmark. It's very lightweight, it's very simple. You know, even for, I think the latest iteration on AWS, you know, you're talking about 40, to 50, checks or 40, to 50 controls that they need to look at. Get familiar with that. It's really helpful as a starting point. It also exposes you to a lot of the different security configurations.
So it's not only compute layer, it's not only network layer, it actually goes through a little bit of everything, Compute, Storage, Network, Identity. And so, as well as things like audit, by the way. So start with that as a good starting point, work through that. You'll get a lot of exposure, you'll get a lot of learning out of how that process goes and about how the different services work and the implications. And then when you next go work on that PCI compliance project, you're going to be much better positioned. You're going to have already, you know, check the box on quite a few things, but the new things that come up, you will have forced yourself, your team, your organization to learn how those things work, and you'll be able to tackle that much more confidently, I think.
So those are, you know, some of my recommendations: get help, get visibility, start with something like CIS benchmark, that's a good entry-level security, you know, exercise if you will.
Thanks, Jeremy. I think that's great advice. You know, you don't start with the Olympics, right? Build towards it, get those muscles, organizational process, knowledge, etc.
Thank you so much, Jeremy, for being with us on the podcast today, and all your great insights!
To those listening to the podcast, thank you for tuning in. Once again, this is the ASK A CISO podcast and this is Raphaël Peyret signing off.