Safe for joining me for this session on what the cloud threat landscape looks like in 2021. My name is Trickram and I am a cloud security architect or checkpoint, and I work with customers and some of our business partners in the UK and Ireland, mostly discussing our cloud security technology and how that helps to address our customers'needs and requirements when it comes to cloud deployments. Now, I promise I'm not going to talk about any technology or pitch any of our solutions in this session. It's more general talk about the types of interactions I have with customers and the sort of concerns that real customers are seeing that can be quite different to what we see from the different analysts and some of the bigger headline threats that people talk about when it comes to cloud security. So I'm going to be running through a very quick summary of what the cloud threat landscape looks like to us and to our customers, what they're concerned about, but more importantly, what the different types of customer conversations I have are, and what the different sort of customers expect from their type of usage in the public cloud. So a little bit about checkpoint, and again, this is not a pitch. I promise I'm not going to be talking about our solutions or anything. Checkpoint were one of the first vendors to market with a commercial firewall offering back in 1993, and we've been going since then. We've come up with a lot of new technology to address different needs. We've had ips, antivirus, endpoint and other solutions, and now, and this is where I work, I work in the cloud area of the business. I should say that cloud isn't a particularly new technology for us. We've been with cloud pretty much from the start. It's been running for about eight years or so now with checkpoint as a vendor. So what are the biggest threats? And unfortunately, I'll start with a vague answer, which is, it depends. It varies very much depending on the type, the size and the maturity of the customer that we're talking to. Different businesses have very different priorities, and I can't emphasize the very, quite enough here. Some customers are very new to public cloud, some of them are very experienced, and we've got a lot of customers that fall in the middle as well. So for some, cloud might be, hey look, I've got an ECT running in AWS, I'm a big cloud customer. For others, it's huge deployment, multiple platforms, multiple different asset types, compute, database, machine learning, pretty much everything the cloud can offer. They will have an element of that in their deployment. So it is very broad and we speak to very different types of customers, and so much so that one day I'll be talking to one at the entry level public cloud, the next day it might be a cloud expert, and I'm really on my toes trying to keep up with them, more or less. Everyone faces the same risks, though. So in public cloud, in a data center, with a server that sits on a desk in an office, people are exposed to the same types of threats, and it's just maybe in a different order. So again, depending on your maturity in the public cloud and where you are with your level of service adoption in public cloud, you're just going to face different things slightly differently, and maybe to a more or less a degree as well. So I'm going to stereotype some of the customers that I speak to on a daily basis to give you an idea of what sort of interactions I have and how the different types of threats that the analysts talk about affect the customers that we speak to. And I say real businesses or typical businesses. These are the requests that I get from some of my customers, some of the partners that I work with, and hopefully it'll give you an idea of how different they are and where they sit on that maturity scale and as such, where their priorities lie when it comes to addressing these types of threats. So, customer number one, this is what we would call a more traditional customer that's got some servers and a data center, and they don't have a lot of exposure to cloud. So it might be the business they work for, or it could be a public services organization. And traditionally speaking, they don't have any care or desire to move to cloud. But someone somewhere has said, we've had a mandate given to us where we are now going to move to cloud, and you have to start moving into cloud. They don't have the education, they don't know what they want to do in cloud, but they've been told, go off and do cloud. So they'll do just that. They'll go to AWS is your GCP, and they'll start looking at services and think, oh, compute, I've got a web server that might be useful. Databases. Yeah, I've heard of that. We've got one of those in a rack somewhere gathering dust. Let's go with this. So they will almost be forced into public cloud adoption, and it might not be something they want to put a lot of effort into. It might not be something they've got a lot of skill and expertise or even budget to put that level of effort into. So they will go into it, reluctant from the outset. And this type of customer, they will typically face very different problems than someone who is experienced or willing to move into public cloud. They will see a lot of misconfiguration type problems. I'll cover some of the highlight headline problems toward the end of the slides, but this is one type of customer scenario that we see fairly regularly. Then you've got the second customer who has some sort of demand or requirement to be in public cloud, be it a technical demand or a commercial demand. They want to reduce cost potentially, or be more cost effective. The usual type of arguments for why businesses want to move to cloud, and you look at the first or second slide and a typical pitch and cloud is more cost effective. It can be, I wouldn't say cheaper. That's a bit of a misconception, but anyway, not going to talk about that. They have a need and a driver that's pushing them into public cloud, and something about it fixes a particular problem they've got. The reason I've got here, the square peg round hole stock photo, is a lot of people see cloud as the fix all solution. They take what they're doing now and they think if I do it in cloud, it's going to make everything better. They don't necessarily know why, but they've heard lots of success stories about going to cloud. So they take what they're doing or what they have been doing in the data center, in an office hosted solution, wherever it might be. A non cloud scenario, they'll take exactly that and they will dump it into cloud, the lift and shift scenario, if you will. So for these customers, they are going to typically see problems around functionality in the architecture not working in the same way that they wanted. So again, probably misconfiguration, but taking non cloud workloads and putting them into cloud can lead to other problems, like scale, or maybe some of the security mechanisms that they've got in a traditional environment aren't present in cloud, and they've looked over them and maybe thought, yeah, we'll fix that later, let's get it working now, and then we'll worry about security later. Something else that comes up quite frequently for me, then we've got the far end of the scale. We've got customers who have only ever used public cloud and only ever want to use public cloud. For them, data centers are not a thing, and they've missed out on the experience of being in a data center, racking up servers, plugging cables in power, networking, worrying about airflow, making sure the server is cooled, and all the fun things that you have when you have to ferret around in the data center for hours on end, you can tell I'm a little bit jaded about that. But anyway, let's not get bogged down with that. These types of customers have very different demands, and it's all about the native tools. It's all about agility, elasticity, and ultimately speed. Not just speed of the service and how quickly a user can access it, but how quickly they can get the next change pushed out to production. So the points I've got here, if it's not using native tools, if you're kind of shoehorning something in, they don't typically care about that. If I've got a logger request or a firewall rule modification or some other, what they see is archaic control to get an update actioned in public cloud, that's a blocker for them. That's not something that lends itself to the overall experience of being in cloud, which does work well with speed and agility and the ability to get to value more quickly. And there are less barriers there to that app as well. This is something that we come across a lot. People are increasingly more interested in consuming APIs to automate deployment into cloud. So to summarize that, the first type of customer that we have is, I don't want to generalize too much and say that they're slow, but they are more used to a slow moving environment. Somewhere in the middle, you've got people who are wanting to move to cloud and want to take advantage of these things, but are held back by something. So they'll do the best they can and they will cut corners and kind of crowbar things into public cloud where it doesn't necessarily fit there entirely. Then you've got the ones who understand cloud. They know what they're doing, and they just want to go fast, get everything deployed, and make changes rapidly, regularly, and deliver the next feature or the next update or the next thing. And they want to do that without being held back by, dare I say, security. Something to bear in mind, and this is something I have to remind myself of quite regularly, is that cloud is a lot of things to a lot of people, and to some people it is still nothing. So within checkpoint, as an organization, we've got the team that I work in, which is the cloud team, where we predominantly speak to cloud customers. But there are still a large number of people out there who don't know cloud. They're not experienced with cloud. And while a lot of people watching this session are probably thinking this seems quite basic, and I know what cloud is for. I know what I should be doing in cloud. There might be people out there who are new to cloud, same way that there are the types of customers we speak to. They have very little idea about what to do in cloud. They think that it's where technology is going and they want to move what they've got from data center into cloud, but they have no way to kind of get up to speed very quickly. So for them, that is a risk in itself. Moving to cloud, moving to an unknown environment, and being faced with all of these services, all of the controls and all of the ways of setting up these services, that is scary and a risk in itself. So this quite nicely summarizes the type of journey that we see when customers are starting out with cloud or very experienced with cloud. You've got the data center on the left, and then you've got the more cloud focused technologies on the right hand side. So with serverless lambda functions, azure functions, whatever your platform of choice is, you've got serverless in some form or another. Then you've got the different points in the middle. So starting off on the left, one of the first barriers and threats when it comes to cloud is the speed of changes. The first type of customer that I spoke about would maybe see one or two change requests a week to open up a port or to provision a new server, deploy an application onto it. When you're in cloud, one or two times a week just isn't something that most customers will encounter. There will be dozens of changes daily, if not hundreds a day. If you look at the extreme example of Amazon, they have a vast number of changes per day, which would just make a traditional legacy network admin cry and hide in a corner of a data center. Then you've got the shift in focus of who's in control in these environments. So typically you had the system admin, the firewall guy, the network guy, the security guys, they were all the kings in their domains. Now that we've moved to cloud or are moving to cloud, depending on where you are in that sort of customer scale, the developer, the engineer, they're the ones in control, they're the ones that are using this service and pushing this technology out to its new home, which is the cloud you don't have the natural flow of information and infrastructure from. Here is something I've built on my laptop. I'm going to put it on a USB drive or an FTP server, then send an email to the admin team and say, please make this live, please check it for security, please check it for network visibility, et cetera. They do everything. They write the application, they write the code, they are responsible for deployment and hopefully they've considered security when it gets into production. So what ports are open? How am I going to scan the dependencies, the modules, the packages that I use? All of this is basically down to one role, which is the developer. So admittedly, depending on the size of the team, the size of the business, there will be lots of developers with a slightly different focus. But that's probably a topic for another session in itself. Generally speaking, in the larger scale of things, when you're looking at customers who aren't in the cloud, to customers who are very mature in the cloud, the developer is the new person who is responsible overall for these types of things. Now moving on to the next step, each of the newer types of services in cloud. So whether you're using containers or one of the microservices based architectures, sort of beyond containers, kubernetes, for example, you are then faced with a vast number of perimeters that you now have to secure. So again, going back to the traditional days, the traditional teams, you have a very well defined perimeter and that's your data center. Beyond that you've got your firewall and that is the ingress and egress point for all of the traffic and all of the consumption of your application and all of the data that leads. Now if you're using something like serverless and you say to the network guy or the firewall guy, where does the firewall go? Well, it doesn't, it has no place in serverless. You've got to look at other technologies to be able to secure that. So the traditional points of control have gone, they're not gone completely. There are now new points of control that you have to consider, but this is very far removed from what teams are traditionally used to. So again, that is another threat to any workload that's running in the cloud. If you think you're protected by your traditional tools, your firewall, for example, your endpoint solution, your insert other security vendor type here that might not be relevant or even possible to deploy in a cloud scenario. So that's another consideration. And then there's code as well. So we've said already that the developer is the new king in this realm and they're the ones who have a vast amount of control over the deployments, the level of security associated with that deployment as well. Now there are some excellent developers out there who have got a lot of security focus and they know about secure coding and secure software development, lifecycle management. There are some people who have no idea why input validation is important and they just won't do it. So one small example, but generally speaking, a lot of what happens in cloud and cloud architectures and cloud deployments is purely code based now. So you don't have the team that builds the server for you, that puts the security software on it, that patches it, that maintains it. Again, it's down to one person or maybe a handful of people that write the application and then stick it out in production. Not saying that's the case in every scenario by any means. There are some very thorough approaches to security when it comes to cloud deployments. But generally speaking, this is something which is quite lacking and leaving everything up to the development teams who have a very focused level of experience on development and producing code. They don't necessarily know about all of the risks that you face at the network level, at the perimeter level, at the host level, at the operating system. There's a lot to consider and they have a hard enough time thinking about how to make the application work, let alone securing it with many tools and many different techniques. So all of that said, hopefully setting the context a little bit with our take on what the threats are to use and adoption of public cloud for businesses. Again, businesses being a quite varied term in itself. Small business, large business, will approach it differently and face different problems. But the biggest one that I think most people would agree with is misconfiguration. It's probably the biggest one because it covers so much, and it's a very vague and broad term, and I would be here for hours to talk about all of the different types of misconfigurations that I've come across and I talk about with customers. But generally speaking, there are some more commonly misconfigured assets that I see when talking to people. These focus mostly on storage. So s three, storage accounts in azure networks and databases, the most common things that people couple with the different types of workloads and public clouds. S three is something which gets used and possibly misused a lot, not just by users and engineers and architects in the cloud, but also by the media. When it comes to saying cloud is insecure, there's this s three bucket that's been leaking files. It's caused this many problems across so many organizations. Yes, it has. Personally, I think it's a little bit unfair because there was a problem back in the day when you deploy s three that it wasn't secure by default. Now security is the default option, and users have to tick a number of boxes to say, yes, I know what I'm doing. I want to make it insecure. I want to make it accessible to everyone on the Internet. But then users tend to favor functionality over jumping through hoops to get access to something. So that's a problem in itself, and that falls under misconfiguration. So Gartner have said a number of times that most of the failures in public cloud are going to be down to the users. And it was, I think, last year, about 95% of cloud security problems being the user's fault. They've increased that. Now, through 2025, up to 99% of cloud security failures will be on the user, which I can completely see. Cloud contains a number of brilliant services and tools to secure those services, but they're quite complex. And as such, I can see, and we do see customers misconfiguring a lot of things a lot of the time. Then we've got IAM an authorization. This is a really difficult error, and one which we're often asked by customers, do you have a magic thing to fix it and not here to pitch at all? It's not something which we have. A magical solution to controlling what your users do and what they have access to and what they should have access to is a time consuming and difficult task. We've seen some customers with some very unique approaches to it. We've seen some customers with no approach to it, and they will go for the, let's just leave it open. Nothing bad will happen, I'm sure, and we'll secure it later on. That is not something I would advocate by any stretch. It's a terrible idea, although it's complicated. You at least have to get the basics down. If you don't, you're in for a fairly horrible experience. I could almost guarantee that I've got here that it played an important role in a recent incident. It played a very unfortunate role in a number of instances recently where an attacker has got in through maybe a security vulnerability in something that's hosted in public cloud. But they've managed to use IAM to move laterally in the environment and pivot onto other systems until they can eventually get data out. And there have been some large financial institutions and some other software vendors who have fallen foul to this recently. So it's definitely out there. It's definitely happening, and it's definitely being abused. Things like the mitreattack framework can help you address what areas you need to focus on. So with IAM and authorization being such a broad topic, tools like that can help you focus your efforts on the different vectors that you have in your environment and what types of security you need to put in place around those tools and services to at least cover the basics off. The last part I'll put as a threat, and it's kind of something that you can do to combat the other threats as well. And this is agility and visibility. So one of the biggest problems that we see with customers isn't they're not necessarily worried immediately about zero days and advanced threats and apts and other people getting in and pillaging the cloud accounts to find very niche vulnerabilities and abusing IAM to get from service to service. At this point, a lot of customers are concerned about what they've got in cloud from a c level or an executive perspective. They don't know what cloud is to them, so they have no visibility of what workloads they're using, where the workloads are, whether they're compliant with any particular frameworks. GDPR, California Consumer Privacy Act, CCPA, that's the one. I remember the acronym. Finally, any of these frameworks are a huge concern to CSOC levels and execs. So for them, they just want to know what they're doing in public cloud. They're not worried about the misconfigurations. They are, but not directly to the level of do I have the right ACL on my file storage thing? They want to know, does somebody have a handle on everything that's going on in public cloud? And you can get some of this from the cloud platforms, but it's not laid out for you in a nice, easily consumable manner. You quite often have to dig around, find all these different details, and put the pieces together yourself to give you a really complete picture of what your cloud presence, and therefore attack surface means. You have to look at different panels, different tabs, different views, different windows, sometimes even different platforms altogether. If you're a large enough company that you consume multiple cloud platforms, then you're just multiplying the problem. So you've got now two platforms where you don't know where to look for the different assets, to see what you've got deployed in what regions and what state they're in. So visibility, I think, is fundamental to getting control of what you've got in your cloud platforms, and then agility as well. And this is something that I touched on a little with the cloud maturity diagram. So as your cloud level of experience and maturity gets stronger and you get more experience in cloud, you start to do things more quickly with that. The business gets used to that agility and wants to keep up that cadence of releasing things very quickly and very rapidly, that eventually there might be a slight tilt towards let's get things out there and then we'll worry about security later. More often than not, that later never happens until somebody else finds your deployment in a somewhat secure, maybe insecure state and they will be able to take advantage of it. And the whole argument of oh well, we were planning on securing it today, tomorrow, later is irrelevant. Your data is gone. There's someone in there, somebody has damaged your reputation, they've got your ip. You need to do this as soon as you can. Security needs to be a primary consideration when you're moving to cloud. It shouldn't be an afterthought. And with the agility, the roles and the responsibilities have changed when it comes to securing what you've got in public cloud. The security team that the traditional heads, they're no longer the ones that are in control. It's now with the developers. We mentioned this again on the cloud security maturity diagram. Even if there is a relationship between those teams, they might not have overlaps. It might be that the legacy teams are far too legacy and they don't know how to talk to the cloud developers, the engineers, the architects, the people who are pushing out these services for consumption by customers. There's no common ground if you've got the technology team who are still talking about firewalls, and you've got the DevOps team, the cloud architects, whoever it might be talking about, pushing out serverless functions to cater for services to be used by customers. The firewall team can't put a firewall in front of that in a traditional sense. So the teams just operate in isolation, hoping for the best. Agility in that sense is a threat. It's one of these weird ones that you turn around to be a strength as well later on, provided that you bake security into your agility. But that's again a slightly different topic for consideration. So what do we see as solutions to this? I've mentioned commercial offerings in here, again, not here to pitch. Commercial offerings are available on the visibility side of things. I think this is a really important thing to get started with when it comes to cloud deployments. If you don't know what you've deployed in public cloud, you have pretty much no hope of securing it. So make sure you're making the best use of what native tools you've got available. Anything that lets you set up monitoring on logs, whether it's network logs, API logs, user interaction logs, you need to make sure you've got that turned on. Quite often in the cloud platforms, logging isn't on by default because that consumes storage space, which costs money. Some of the analytics services associated with looking at the logs, they're not free either. They will cost a fairly nominal fee in some situations. Some of them are horrendously expensive, so obviously take that into consideration, but try and get some visibility of everything. Don't have any service which is available to users or even developers and internal teams that doesn't have some level of logging on it to see what's going on. If the worst happens and someone does manage to get into your environment, into the cloud environment, the lambda function, the container environment, whatever it might be. If you've got some logs, you can start somewhere, you can see how they got in, you can hopefully fix it and prevent it happening in the future. If you haven't got any visibility of what's going on, things are going to be rough. Then misconfiguration. Again, this is a very broad topic to cover, so I won't be able to cover everything here, but I think automation is the key. And again, couple that with visibility. There are some fairly decent tools out there in the native platforms that you can use for some are free, some of them are not free, but they're not extortionate either. And again, commercial offerings are available, but where they're available, and especially where they're free, make sure you're turning them on. Things like AWS, trusted advisor, they can help out as well. They can give you recommendations on some real easy to fix things like your s three bucket there that's got world writable permissions. That's a very bad thing. Don't do that, turn it off. There are more complex recommendations as well. That's just a common one that tends to come up when talking to customers who are new to cloud environments. But misconfiguration is such an obvious thing to happen, especially when you consider how many services there are and how many of those services have got such diverse configurations about them. Again, if you're using more than one cloud platform, that's multiplied by the amount of cloud platforms you've got, because the service that you're using in one is almost certainly not going to be the same in another platform. So you've got to learn one way to do it in this platform one way to do it in another, and it's very little consistency between platform a and platform b. It might be completely different, completely worlds apart when you're configuring these different things. So trying to automate it where you can can help you achieve a level of consistency across those platforms. But make sure you're testing that automation I have seen some fairly awful situations where something has been automated, not particularly well tested, and that automation has just led to mass deployments of badly configured things. So in one example, fortunately, I didn't make it out of testing. It was automating permission application for a storage facility in a cloud platform. But they got the permissions wrong. So it wasn't just one poorly configured storage service, it was hundreds if not thousands of poorly configured services. Fortunately, it was noticed fairly early on and they managed to update it via automation, via the templating engine they were using, and fix it at scale. So if you can automate, brilliant. But make sure you're paying that attention as well, because that can be a whole different rabbit hole to fall into if you've got poor automation practices in place. Native tools I've mentioned this, some are good, some are better than nothing, some are free and some are not free. So make sure at least to get the bare minimum covered and then on to IAM. So this is probably the hardest area to give any really easy suggestions for. There's so much to cover. There are numerous tools in the platforms, each of them are very diverse and very different. It's unfortunately something you just have to spend some time on. It's worth it though. It is a worthwhile investment to get these right, because they can save you a lot of pain and suffering in the future. If, for example, I mentioned one of the larger, more media focused and highlighted breaches in the last couple of years that did rely heavily on poorly configured permissions in the cloud account. So when the attacker was in, they managed to basically knock on the doors to see which ones were open and abuse the high reveals of privileges on certain services, then get onto that one and escalate those throughout the environment to ultimately get data out. Now, if you take the time from the outset and make sure that you're using IAM, you're using security groups rather than assigning privileges directly to users, following the best practices. At least that will help a lot when it comes to securing what you've got in your public cloud environments and making sure that if the worst happens and somebody does manage to exploit a vulnerability in a software package, or manage to find something that is poorly configured, you're limiting the blast radius and the area of effect of what they can do from that service that they have managed to get a foothold on. If they've managed to get onto, let's say an EC two instance that doesn't have fully open permissions to everything in not just that account, but any of the adjacent accounts to it as well, you're limiting what they can do. Yes, it's bad, but it's far easier to fix than a multiple account affecting breach. Where they've got in, they've got a foothold. Maybe they've even got access to the account. Difficult to say. Attackers are very persistent, and if there is a weakness, they will pursue it until they get what they want, which is ultimately data or resources, be it a crypto mining resource or something else. If they don't want your data, they will be in there for something they won't leave empty handed. So take your time. Get this bit right. There are some tools out there, not necessarily tools, in saying yes, your IAM solution is configured perfectly well done, but tools to make sure you're not giving your users too many permissions. Something like permissions boundaries if you're using AWS, this is a really useful tool, and a fairly simple tool as well, to make sure that no matter what the scenario is, a user in a particular area can't get more permissions than their boundary gives them. That's a really powerful tool to make sure that your user in one situation they don't have read and list permissions for something, but accidentally you've given them root permissions somewhere else. A permission boundary can be a really powerful tool for making sure they don't cross over from a read owner user into a readroot user, which is a fairly bad example, but you get the picture. Use what you've got. It is a time consuming area. If you're not familiar with it, read the documentation. Look at the best practice guides. There are some fairly lengthy documents out there, and they're quite difficult and painful to read. If you've been through any of the certifications, I'm sure you've had the pleasure of looking at the different IAM options available, but it is useful and it's a worthwhile investment in terms of brain space and time invested when it comes to cloud security. So some quick takeaways from this session. Not everyone is a cloud expert. Businesses are very different levels when it comes to cloud adoption. So what might be normal day to day operation for you as you're managing a huge container architecture with lots of microservices scattered across multiple cloud platforms. The person who is considering cloud next might be very new to cloud, and they might be looking at deploying their first instance into the cloud. So for them, their interest in security and the threats that they're interested in might be very different to you. There's no right or wrong. Everybody wants to secure their workloads and their presence in cloud environments just don't look too unkindly on people who are new to cloud. You were new to it at one point, so you didn't get to the level of cloud expertise you're at today without making the same mistakes that people that are new to cloud make. So be kind to people. It's a fairly intimidating place, is cloud, and there's a lot to take in in a fairly short amount of time, especially if you want to make the most of it and not find yourself falling foul of misconfiguration and some of the other nasty things we've spoken about. And businesses still see cloud as new technology in some parts. Not everyone, most people are aware of cloud now, but when I first started out sort of talking about cloud and working with cloud, with customers, there were some people who had no idea about cloud. I think it's fairly safe to assume that most people have at least heard of it now and know some of the benefits and some of the threats that might face them if they were to move into cloud. So that's a very brief summary of some of the customer types that I speak to on a day to day basis, some of the threats they face, and some of the general solutions on how aim to fix them. And thank you to conf 42 for allowing us to present.