We all love stories — they help us understand ideas and concepts quickly and in an easily digestible manner. When told right, good stories also teach us valuable lessons so we don’t make the same mistakes.
In this episode, cybersecurity veteran Jeremy Snyder recounts two war stories, one that's rather funny (on hindsight) and one that's almost a horror story in itself and the lessons you can learn from them to avoid making the same mistakes.
He also shares his opinions on the Log4J vulnerability and presents his take on some future trends in cloud security, such as API security.
Tune in to this episode of Ask A CISO to hear:
- Two war stories and lessons we can draw from them
- Jeremy's opinions on the Log4J vulnerability and its implications
- Why continuous security testing is essential
- The importance of visibility
- Future trends in Cloud Security such as API Security
About The Guest: Jeremy Snyder
Jeremy Snyder is a veteran cloud security practitioner living on the East Coast of the United States.
Jeremy was one of the earliest people at Amazon Web Services (AWS) in Singapore in 2010 and was the first person covering ASEAN.
He has always been an IT practitioner, and ran data centers and back-end systems for several SaaS and video game companies in the early part of his career.
About The Host: Paul Hadjy
Paul Hadjy is co-founder and CEO of Horangi Cyber Security.
Paul leads a team of cybersecurity specialists who create software to solve challenging cybersecurity problems. Horangi brings world-class solutions to provide clients in the Asian market with the right, actionable data to make critical cybersecurity decisions.
Prior to Horangi, Paul worked at Palantir Technologies, where he was instrumental in expanding Palantir’s footprint in the Asia Pacific.
He worked across Singapore, Korea, and New Zealand to build Palantir's business in both the commercial and government space and grow its regional teams.
He has over a decade of experience and expertise in Anti-Money Laundering, Insider Threats, Cyber Security, Government, and Commercial Banking.
Transcript
Paul Hadjy
All right. Good afternoon, everyone. Just want to welcome Jeremy Snyder here, a veteran cloud security practitioner living on the East Coast of the United States.
Jeremy is one of the earliest people at Amazon Web Services here in Singapore in 2010 and was the first person covering ASEAN here. He's always been an IT practitioner and ran data centers and backend systems for several SaaS and video game companies in the early part of his career.
Jeremy was previously a guest on the podcast where he chatted with Rafael Peyret, VP of Product at Horangi about the evolution of cloud securityevolution of cloud security and its future.
Welcome, Jeremy, glad to have you.,
Jeremy Snyder
Hey, happy to be here again, Paul. Great to talk to you.
Paul Hadjy
Yeah, so, how was your holiday, like do anything exciting? Tell us what's new in the Washington area.
Jeremy Snyder
Well, the Washington area, what's new is snow. We just had a couple of downfalls in the last couple of weeks, and the DC area is kind of right at that edge where if you go further north, they have the equipment to deal with snow. If you go further south, there really is no snow. DC has no equipment. So snow is always really disruptive in the area. I think the only thing that's been a saving grace this year is that people aren't really commuting.
Cause otherwise in years past when there's snow, the commute is an absolute nightmare, but otherwise, you know, knock on wood, we're getting reports that the Omicron wave is starting to calm down a little bit. And just hoping that continues to be the case and that people go get vaccinated.
Paul Hadjy
Yeah, having grown up in DC. I definitely remember the snow madness. Anytime there's like one or two inches, like school would inevitably be canceled and there'll be like constantly wrecks in traffic. But it was great when I was in middle school and high school and you're with, it's still one inch and I wouldn't have to go to school, which was awesome.
Jeremy Snyder
Local schools have used all their snow days for the year already, so hopefully we're past the snow for the season, but let's see how it goes.
Paul Hadjy
Yeah. Hopefully, no extra school days tacked on. I do remember that happening during the 96 plus years we talked about before I started recording.
But yeah, that last thing you were on the podcast, we kind of talked about the evolution of cloud security in the future. Yeah. I'd love to hear a bit more today about some of your war stories and kind of your experience in the cloud realm.
Jeremy Snyder
Yeah. Happy to share. Where do you want to start?
Paul Hadjy
So let's start out with the cybersecurity incident that kind of shocked you the most.
Jeremy Snyder
I think that the incident that probably shocked me the most: we were working with a company who shall remain nameless. You know, there were a large scale rapidly scaling digital organization. They had a strategy where they had their primary production in one region and their backup in another region, but both were kind of in the same part of the world continentally.
Right. So in two continents, you know, two different regions. Primary, secondary, very good strategy made a lot of sense. Also serve their customer base well, and they even tested their fail-over routines quite regularly. So they knew they could shift from primary to secondary pretty well. All of that great strategy, where was the problem?
So the problem came when they started to roll out more and more features. And one of the things our developers wanted to do was do performance testing and they wanted to do performance testing, you know, with a lot of freedom around the performance testing that they were doing. So, what did they do?
They knew that primary and secondary regions were monitored quite tightly by the information security teams. So they went to another region in another continent and spun up a cluster of machines to run some performance tests or to originate the performance tests, I should say. So they were going to use this third region to basically point traffic at their primary and secondary regions and run a bunch of automated kind of users type testing.
Right? So what do they do? First thing they do. They go into that third region. They spin up a bunch of virtual machines. They open SSH to the world so that they can access it from where they are sitting, which is, you know, back home in one of those countries where the primary region is, and they install a bunch of automated testing software on a few different machines.
They run their tests and like many people they're kind of lazy and don't clean up after themselves. So now, performance testing is done. They've got a set of machines or virtual machines in a third region that's not being monitored by InfoSec and they leave those machines out there. And by the way, just like completely out there, still running SSH, still open to the world
Paul Hadjy
That's never good.
Jeremy Snyder
No, never good. And you know, one of the stats that I saw a couple of years ago, and I apologize I can't remember where I saw it was that basically from the time you launch a new EC2 instance if you leave ports open to the world, it's under five minutes before those ports will start being probed. And to me, that's kind of mind-boggling considering that, you know, there's a massive pool of IP addresses.
The IP address allocation is somewhat random, right? I mean, yes, it's kind of, sort of tied to the region, but it's still a relatively random IP address that's going to pop up, which actually tells you that, you know, in my mind that the conclusion is that if you're being probed within five minutes, that means these probes are kind of continuously running and just iterating over the entire pool of IP addresses.
And it's really just that it takes five minutes to kind of cycle through and get back there again and hit those IP addresses. So, these machines are found, let's call it within a few hours and what ends up happening, you know, SSH is a somewhat strong protocol, but not bulletproof. There are ways to kind of find ways around it.
You know, using a key with the proper permissions is generally a good practice and somewhat safe. But again, there are ways that, you know, machines can be compromised. So one of these machines gets compromised. Of course, there's no internal security between the machines in this virtual cluster in this third region.
So boom, these machines are effectively owned and you know, this was a relatively smart attack. So sat in there did not immediately look to kind of utilize that infrastructure. This is a few years ago, so this was kind of before the boom and installing crypto mining and stuff. Cause I think that would be the, nowadays, if you, if you have a cluster of virtual machines that gets compromised, that's maybe the first thing that happens. But instead, you know, the bad actor surveyed where things were within the network, looked at some of the logs, saw that there was outbound traffic going to other regions, kind of sat in there through a series of steps, was able to actually extract the customer database.
So just because of some vulnerable virtual machines or unprotected virtual machines sitting in a region that's unmonitored, effectively the entire customer database gets owned. I mean, that's, that's pretty scary. That was one of the most shocking events and it came from something that is ultimately like an understandable behavior.
Maybe you could say it's undisciplined. Maybe you could say, you know, that's poor cyber hygiene. But I'd say this is something that is, you know, pretty common, you know, it's pretty common to want to go do performance testing and to need access to capacity to go do that. It's also not, you know, super strange to open SSH and go, you know, go into those machines to install the software that you need.
Okay. It's lazy to not clean up after yourself. Fine. You know, you can blame the user all you want. But, you know, this is not an atypical event and it was pretty shocking.
Paul Hadjy
Yeah, I think that's a good story. And it kind of gives people those sort of reposition around like the fact that people are watching, like what you're doing in the cloud specifically and waiting for you to make mistakes and it is real, unfortunately.
Yeah, on to something more humorous, but a depressing situation for them at the time, I'm sure. Yeah. But like it's kind of like you know, a story that's a bit more like, kind of funny and like you know, some kind of like humorous hindsight around that.
Jeremy Snyder
Yeah. You know, we worked with a customer a number of years ago and they were still at the early stages of cloud adoption. And let's define early stage by saying, you know, they were below 10% of their infrastructure had shifted over to AWS. So they were primarily an AWS customer at the time. They called us in because they couldn't understand what was going on with their environments.
They had basically one account that they were looking at, one VPC where they were running most of their primary workload. And they were just getting these massive bills and they couldn't understand where it was coming from. And so they called us in, we went through the account with them.
We realized, you know, just one of the consistent problems and kind of true in the first example I gave as well. You have to have visibility on things totally to understand what's out there. I mean, this story is a little bit less of a cybersecurity incident, but we found something like 600,000 assets.
Storage assets that were completely sitting orphaned. So this was a combination of EBS volumes that were kind of secondary volumes that had been attached to EC2 instances post-launch.
This is a really common problem. Right? So before you, if you're kind of at the early stages of cloud adoption, and you're not at the point where you're really automating the launch and the creation of all your assets, one very common thing is, you know, I start an EC2 instance, I need more disk space. Yeah. What do I do?
I go grab another EBS volume, attach it, Mount it, all that good stuff. Right. When I go to terminate the EC2 instance, only the root volume, the primary volume is going to be terminated automatically with the instance. That secondary volume that I attached after launch? It kind of sits there orphaned, and we see this, you know, again and again, and again, right?
So between the actual volumes that got orphaned, the snapshots that were taken, and the automated snapshots that continued to be taken, they had reached 600,000, you know, storage assets. I don't remember what the exact mix was between volumes and snapshots, but it was huge.
And we kind of showed them the data. We showed them, Hey look, and they're like, no, no, no, this stuff can't be out there. No way. They go poking. Sure enough, it's another VPC. Another zone, another availability zone. Sorry, but they weren't really paying attention to very frequently and it's all there and they tell us. You know this is a project that was concluded six months ago by people who no longer work here.
And they had taken care of the EC2 cleanup, but sure enough, none of the storage clean-up, and this was racking up thousands of dollars a month for them. And it's like, you know, there's kind of two perspectives on. Both really come back to hygiene in many ways and, and kind of operational discipline.
There's the, of course, the cost perspective on it, which is don't waste money, right? Like a lot of people get to hear that, that promising call of cloud that you're going to be able to save so much relative to your own data centers. And I can attest, I truly do believe that's true coming from, you know, before AWS, I ran data centers for a video game company.
We wasted so much money, you know, between infrastructure, spare hardware, you know, floor, space, electricity, everything like it is crazy expensive to run your own data centers. The cloud is only cheaper if you run it efficiently, you know, and you have these, you have these situations. The second is of course, the cybersecurity view on it, which is, you know, volumes are typically hard to access on their own.
But snapshots can absolutely be made public. You know, there is a whole use case around organizations taking snapshots, sharing them, whether that is sharing with a partner, whether that is a data set that's being made available publicly or an open-source dataset, what have you. There are valid use cases for public snapshots.
There's always a risk that a, you know, that one little flag gets set incorrectly, and then boom, a bunch of data's exposed. You know, there have been breaches based on accidentally public snapshots. Thankfully, in this case, it was really just a waste of money. That was the primary concern for the customer and what we were able to ultimately help them with and, you know, stop wasting that money.
Paul Hadjy
Yeah. that's pretty interesting. And in both cases, how do you think they could have avoided those situations that they ended up in?
Jeremy Snyder
I mean, look, visibility is kind of the main thing, right? If you know that it's out there, you can at least have a human look at it and decide, what is this thing? Do I need it? You know, is it still in use? Is it still valid, what have you, but if you don't know it's there, then you can easily have problems.
So I really say like all of security, whether it's cloud security, whether it's internal, no matter what, if you don't have visibility, you can have zero assurance that you know if it’s safe or not.
Paul Hadjy
And kind of like switching subjects a bit: what do you think about the Log4J vulnerabilityLog4J vulnerability and how does it affect the cloud?
Jeremy Snyder
Well, I mean, it affects the cloud in so far as you know, Java is a major code language used.
I think I was looking at the AWS stats that were shown at re:Invent. And I think it is the fourth most common code language in their developer surveys. So, you know, you've got a good chunk of Java code out there on the cloud.
You know, the second thing around that is, do you have an understanding about where you have it running and if the places that you have it running are publicly exposed or not?
I mean, I think the exploits that we saw against Log4J were pretty consistently organizations that had it running on a public-facing endpoint. And so, you know, if you don't have that visibility to know, A, this is where I have it, and B, that is or is not a public endpoint, you know, then you're at risk.
So its impact on the cloud is, is really kind of, you know, very similar. What I will say in favor of cloud is getting that visibility on cloud is much easier in my opinion than in private data centers, you know, the ability to query inventory, to build inventory in an automated fashion, I think that's something that cloud does way better than you can do in a private data center.
Paul Hadjy
Yeah, for sure.
We had written a rule to fit into Warden very quickly and sort of helps the customer stay safe. In fact, quite convenient. It's much easier to do that, of course, in the cloud, because it is uniform versus like, if you're in an on-premise world, like, you know, people could use many different versions of the app, which makes it a lot more complicated to detect as well.
Jeremy Snyder
So, how did you correlate the, let's call it the asset infrastructure with the application infrastructure to know that an endpoint had Log4J.
Paul Hadjy
I'm not 100% sure. The engineering team basically wrote the rule that would detect it in the infrastructure case there.
I think they use the infrastructure layer, so kind of figure that out. But definitely, we actually wrote a blog post about this, so I'll link the blog postblog post so the listeners can read it there.
In terms of the law for Log4J2 vulnerability types of thing, how do you think that sort of has evolved? Obviously, initially, it came out quite quickly and then it evolved a couple of times so there was like multiple vulnerabilities that kind of came out of this. What's your take on that?
Jeremy Snyder
So I think the real kind of key challenge facing a lot of organizations is staying on top of change as it happened.
So one of the things that happens is you'll have an incident like Log4J and it throws all these cyber teams into like a mad sprint towards remediation. And that can be like, let's say a massive patching exercise which kind of seems like that's most of what people did relative to Log4J is they went out and as best they can, they identify everywhere that they have it running and then they, you know, run patches and they update Log4J to, you know, a fixed version that doesn't have this vulnerability in it anymore.
It's very easy once you've completed that process. Well, first of all, it's very easy to treat that process as a one-time sprint. And so you'll see a lot of teams. What they do is they kind of like build Excel spreadsheets or they build like a queue of tickets to go patch various assets, whether that's virtual machines, whether that's application code, what have you, right?
They run the sprint, they run the exercise, and then they kind of go away and they don't really take a lesson away from it, which is like, this stuff can pop up any time. And it's not really sufficient to just be ready to react. You need to kind of stay on top of it. And that's where things, like in my mind, that the kind of the correlation between let's say vulnerability management and cloud infrastructure like that's where that really comes.
You know, where those kinds of, if you think of this as a Venn diagram, that's where those two circles overlap. Right. And you kind of gotta be ready for those circles to overlap almost in any way at any time, especially when you're using a lot of open-source software that is very common in, like, I don't say open-source software to say that open-source software is less secure.
I think in general, it's very secure. I think the risk around open-source software is that once something is identified, the flip side of the fact that it's open-source kicks in, which is like, everybody knows about it. And you know, anybody with a computer can go out and try to exploit it, but kind of coming back to what I was saying, I think that the challenges that you have to stay operationally ready and not just kind of let that be a one-time event.
So take a lesson from that. Understand that. Okay. Going forward, we need to be ready to jump into a situation any time when the next big vulnerability kicks in. And so like having inventory that goes beyond infrastructure and into let's say application layer, packages, common packages, operating systems, et cetera. Like that becomes super valuable.
And also then like learning what you can do from a process perspective so that next time it's not such a fire drill, it can be more like a, okay, you know, here's an automated way potentially, or here is like, Infrastructure as code approach, where we're going to like tear down the existing stuff and relaunch new stuff, you know, what can you learn from it and, and do better the next time there's a big vulnerability like this.
Cause there will be, I think we both know that, right?
Paul Hadjy
Yeah. Yeah.
I mean, they're only going to continue on and like, I mean, cyber security, the good and the bad thing about it, that depending on how you look at it, that it's ever-changing based upon what's happening in technology, right?
It's never going to be, it will never be a perfect solution for anything. And you know, I think that's the exciting thing about the industry as well from being a participant in it is that like it's always changing and there are always new things to learn and new technology to secure and new vulnerabilities to prevent against. That's what's interesting and fun about it also.
So when we look at 2022, obviously we're a couple of weeks in at this point. What do you think is going to be kind of some stuff that we'll see, and like, what're the new things that will come out of it?
Jeremy Snyder
Yeah, there is kind of three things that are on my mind relative to cloud security in particular for 2022.
One is what we just talked about. One is going to be like, what is the next big open source problem, whether that's a vulnerability, whether that is something like this, you know, what we saw with kind of the two intentionally corrupted libraries that broke a lot of downstream stuff. Not really a cybersecurity incident, but it shows you kind of the inherent chaining of stuff in the open-source world.
So all of this stuff is connected. It gets into commonly distributed packages. Your organization is probably consuming some of those packages. I know my company is as well. So that's one is thinking about open source being ready to react when the next big incident comes around.
Two Is really around identity. I think identityidentity is really starting to become front and center in people's minds relative to the cloud and cloud security. We're increasingly hearing people talk about making investments in this space in terms of, you know, kind of core principles, centralizing visibility onto cloud identity, understanding effective access. So kind of that question of who can do what, where is something that a lot of organizations can't answer and that's starting to become a real sticking point.
The third thing that I'm personally thinking about quite a lot is kind of the evolutionary state. The way companies use infrastructure. I've been working over the last couple of years. I've been really lucky to work with a lot of very large-scale fast-growing digital native companies.
And when I talk to them about how they're using cloud and where they're going and granted they're very early adopters, right. So they're kind of the leading edge of the curve if you will.
One of the things I hear consistently is reducing their dependency on the compute layer, specifically virtual machines, right? So they're moving away from virtual machines as much as possible. They're like, look, you know, the operational overhead is a pain in the butt. It's an attack surface I don't need, I really just need to run my application code. So let me do that. And I'll do that with serverless. I'll do that with minimal container footprint, what have you.
And so as they move away from kind of the classic VM world, what do they move to? Increasingly that's microservice architecture. That really is like very kind of componentized API-based systems that communicate with each other. And so for me personally, one of the things I'm really thinking about is, well, what's the implication there, you know, what are needs around API security and you know, are people actually designing secure API?
So that's something that's on my mind. I don't know that that's something that's commonly thought about out there. And I might be a little bit a man on an island with his own thoughts relative to API security, but it is something that's on my mind for sure.
Paul Hadjy
Yeah. Yeah. No, I think that's a good point.
I mean, Horangi is completely serverless. So when you have and yeah, like, I mean like that, we obviously have a services part of our business too. And a lot of the testing that we do is on API, right. And there's a lot of that stuff that can probably be prioritized for long term, which I think is quite an interesting problem to solve and something that's very relevant.
As, as companies, like kind of become more dependent on APIs, whether that's like their own or external ones both of which need security. So, something we constantly hear from our customers, that is a concern for them as well. So yeah, I 100% agree on that.
Yeah, so like yeah, I think one of the sort of interesting topics, as well as kind of like the cloud provider vulnerabilities and sort of like research around those, like tell me a bit more about what you think about those.
Jeremy Snyder
Yeah. It's been really interesting. I'm sure you've probably watched this as well and probably some of the listening audience will have as well.
I mean, in the last, what three, four months we've seen at least three or four kinds of major vulnerabilities discovered by third-party research firms. Some of them are, you know, cloud security companies themselves who are kind of finding these things. I hope that everybody's going through good responsible disclosure in kind of, you know, inform the cloud provider before you publish to the wide community.
I know it can be very tempting to kind of make your organization look super great by publishing really quickly and, and very tempting to do that. I know every company in the cloud security space is trying to establish themselves as a “thought leader” or the most innovative in the space. And, you know, to that point, that's where that temptation comes in.
But look, we're at the end of the day, we are talking about real customers, real data. Some of that data is probably yours and mine, whether it's, you know, a user profile on some service or whether it's the company that we work for, who was a customer or a partner of somebody else who's running on one of those clouds, you know, there there's a lot of data at risk.
But I think what's really interesting about it to me is that risks aside, you know, these are massive companies with very good dedicated cybersecurity teams. And the takeaway that I have is kind of twofold.
One is that it really is helpful to try to put yourself in the attacker's mindset from time to time. You know, security by design is always good, but it's usually done along the lines of the person who's writing it, how they could think about attacking it or trying to breach it. And when you have an attacker's mindset, it's a little bit more like I'm not just thinking about it from how the design is flawed. I'm thinking about what are all the possible crazy things I could do to try to trigger an unexpected response.
Cause like in that unexpected response, you might get something like a little nugget that shows you, I could pop command line access, or I could fetch the role that the infrastructure is running with or who knows what, right? But it might give you something, it might give you the S3 URL with some data that is not discoverable in other ways.
So that's one is thinking about it from the attacker's perspective.
And two is to the point that you raised earlier, which is that cybersecurity is ever-evolving. You know, these companies, they've done internal testing on these services before they released them, including by their own cyber teams.
But new stuff comes out. New methodologies, new attack tools all the time. So, you know, it's not enough to kind of design a service, run your security test and then put it out there. You kind of have to be doing this regularly, ideally, continuously but in reality, we know that people don't really do continuous security testing most of the time, you know, Most companies don't, but at least regularly, whether that's, I don't know, like even quarterly would be an improvement on, I think what's happening.
I think it's great that people are discovering these things and you know, if they're going through responsible disclosure paths, then that's great too. Because ultimately, we all want all services to be more secure. Like I think that's one of the reasons we will go into cybersecurity is cause we, it's, not that we, you know, obviously there's money to be made, but we actually do it also because we want stuff to be more secure.
Like I said, my data is out there. Your data is out there. Like none of us want to use a service just thinking, okay, you know, I'm pretty sure this data is going to be public and you know, two weeks, no way.
Paul Hadjy
Yeah, for sure. I mean at some, some sadly in some ways I default assume that with a lot of the things that I use, like not my personal perspective, I'm just like accept the risk.
But yeah, I mean, in reality, like, of course, if we can prevent it we should and enabling a lot of these companies to do that, I think is an important part of like, why I'm interested in, I, I mean, for me also, it's like the sort of like changing nature of things, right. What I know today, like it's going to change somewhere, like, you know, in five years from now will be completely different.
And within that, we kind of talked about like, what you think is going to happen in terms of 2022. We talked about like five years from now. What do you think are going to be the security problems then?
Jeremy Snyder
I think a lot of the same stuff will be true in the sense that, you know, we'll be even more kind of gravitating towards serverless components, towards just running application code.
The cloud providers will be taking care of even more for us, you know, right now, for instance, as an example, We do a lot of stuff with kind of componentized storage, right? Whether that is like a database or long-term file storage, you know, just things like S3 and RDS. I think over time, the cloud providers are going to make that stuff even easier where you just say like, Hey, I have an application that looks like that.
And cloud providers will automatically say, oh, okay. So it looks like you need this kind of storage backend. We'll just go ahead and provision that for you. And boom. It's just magic. So I do think that continuing abstraction is going to happen.
The second thing that I think actually kind of comes back to my third point around 2022 is I do think API security is actually going to be kind of front and center at that point.
Because if you look at kind of the direction that many, many things are going, mobile apps, IoT devices, all they are is kind of a small client talking to a backend over an API. And so the nature of data transmission is already moving in that direction pretty heavily, right. And five years from now, that's just going to be more and more the case in my view.
Many more services will be integrated with each other. So, you know, just like you log in with. Facebook who will, whatever, when you go around various sites today, I think, you know, you're going to have much more of that kind of third-party services integrated with each other, exchanging data in various ways. And again, their APIs are going to be key to that data transmission and data sharing.
So those are, those are things that I think will be kind of consistent for the next five years.
Paul Hadjy
Yeah, I agree. I mean, like, that problem is never going to go away and the different services will have to talk to each other over API. This is what we call today may change in the future in terms of how that, that it has been sort of exchange but very interesting to see what happens because I mean, I think none of us could have predicted the, I mean, I remember like seeing cloud back in 2008/9 and thinking, oh, that's gonna take so long to adopt, but the speed I kind of think, and the guys could have predicted and then COVID, of course, pushes it up for sure.
None of us also could've predicted the kind of acceleration.
Jeremy Snyder
Yeah. For years I've been telling myself, oh, now we're right in the middle of the curve. So if you think about like, kind of the bell curve of cloud adoption and you think about kind of like the far-right being early adopters. And then the big part of the curve is kind of like mainstream, right?
For years I've been telling myself, oh, now we must be hitting mainstream. We must be hitting the mainstream. It's like cloud’s the norm. And then every year it gets bigger and bigger and it's like, oh, okay. Actually, we're still in the growth phase.
You have to remind yourself we're still in the adoption phase. And it's only, I can't remember what the stat was that Adam Selipsky (CEO at Amazon Web Services) shared at re:Invent, you know, but it's something between 30 and 40% of workloads are cloud-based at this point, there's still a long way to go and it's just going to continue.
Paul Hadjy
Yeah. And that's crazy to think about, right. And the cloud business is so big already and then it's got so much more room to grow. That's not even really considering like that's just people moving. We also have to consider the growth within the cloud, that 30% itself. Right. Which is also exciting.
So just to kind of like wrap it up, like maybe give us some thoughts just like about the whole conversation or like yeah anything you want to kind of have a talk about terms of cloud security for me.
Jeremy Snyder
Just two things.
So one is visibility underpins out.
It's like, if I always tell people, like, when they ask me like, okay, well crap, where do I start? Like, number one, all we start with is visibility. And I said it, I don't know how many times. I'm probably a little bit sick of saying it, but it's still true. And it'll still be true in five years, right? Like maybe in five years, it won't matter so much on the infrastructure side because that'll be more obstructive.
But at that point, it'll be visibility as to what are the data and what are the third parties that you're interchanging data with? What are the communication paths? Like? You have to have visibility onto that stuff. Otherwise, you have no way of securing it or knowing about it.
And then I think the second thing, especially for now and for the coming year is to really think about the correlation between things like we talked about, Log4J. A place where you're running Log4J has many layers, right? There is a network layer there's infrastructure there's the application, operating system, application code.
So as much as you can bring visibility correlated across those layers so that you're ready to react. If you don't know like where the problem is going to be, right, the next big kind of cybersecurity panic, will it be infrastructure layer, will it be application layer? Will it be an operating system problem?
And then, and till you can correlate across those layers, it's hard to react.
Paul Hadjy
Yeah, a 100% true. And I still remember in like, when I was studying networking in college, like one of the basic things that my teacher was sort of like I guess in, ingraining in my brain was like, know your network. And I think that that's still true today.
As you mentioned in terms of visibility, right? You have to know what's out there. And if you don't, you're bound to get bitten by the thing that you can't see.
Well, thanks again for the time, Jeremy, really appreciate you spending the time with us to talk a bit about cloud and some war stories as well.
Jeremy Snyder
Happy to. Happy to share. Always a pleasure.
