Yes, thank you, Alexei. Welcome, everybody. Thank you for coming to this session on cloud security. And for the audience in the room, I can say that you needn't be shy. I've never yet eaten any of the members of the audience. Those people lurking at the back can come to the front.
So, I'm Mike Small, and I've been researching the area of cloud security for the last 15 years. And there's been many different views and concerns about this, ranging from that the cloud providers were not secure, through that I'm not going to be compliant enough, and now that, in fact, I'm going to make a mistake myself.
So, the result of this is that I've come up with these five, four pillars of cloud security. And so, I'm going to talk in this talk about the challenges. I'm going to talk about how these challenges have led to an alphabet soup.
And then, I'm going to say how we can resolve this by looking at it from four different key areas and conclude a good approach for cloud security. So, let's look first of all at the challenges. And the first challenge is that basically, most of the incidents that have occurred related to cloud are the fault of the cloud customer.
So, it's your organization that's probably going to be at fault if there is a security incident related to the cloud. And it's very interesting to look at the common theme that goes through these incidents. That we have, in previous sessions, talked in great detail about the Ticketmaster and all of the other ones that came around the use of the Snowflake cloud data store. And basically, those problems came from not using multi-factor authentication, which allowed the adversaries to steal simple passwords, simple credentials, and make access.
A more recent one, which is an interesting one, but still related, is that there was actually a case of ransomware, which was inflicted upon a news network in Australia. And there, what happened was that the adversaries managed to get access to an open S3 bucket, which contained key information, which they were then able to encrypt. And the other one was, again, open S3 buckets.
So, all of these come down to mistakes by the cloud user. So, some people say, well, why is cloud security different?
And again, these are themes that we have seen from some of the previous talks. The first thing is, the ephemeral nature of the cloud.
That, whereas in the physical world, you would buy a resource, you would be able to secure it, and you would then be able to use it. And that would take hours, weeks, even months.
In fact, in the cloud, everything is created as it's needed, that it's all virtual, it's all software defined, and there is not enough time for us to do a scan of everything before we use it. So, you need a different approach. That in any case, the whole thing runs in shared infrastructure. And that means that both from the perspective of your virtual resources being protected against access by other peoples, within your virtual world, those virtual resources have to have identities, and they have to have access controls. And these all need to be managed.
And that is another source of opportunity for the cyber adversaries. That the scale and complexity of the way in which people use the cloud is unprecedented. That applications often include a vast array of infrastructure as code, with multiple containers running in multiple services, and depend upon multiple controls.
So, being able to actually understand what you've got, and to control that, can be a problem. And in any case, there isn't just one cloud, there are multiple clouds, and they all have their own different way of securing things.
So, I wish I could say it was going to get better, but I think it's only going to get worse, because we've all got generative AI. And that's going to introduce its new opportunities, as well as some new risks. And for example, one of the things that we foresee is that there is going to be an explosion in the number of bespoke apps, because gen AI helps you to write them. And that makes it easier for organizations to have an app. And since an app, in its own way, gives you some kind of business benefit, then there's going to be more of them.
And the problem is that each app tends to need its own bespoke way of being secured and managed. That this is all based on a multi-cloud architecture. And whilst all the clouds provide capabilities to secure things, they all provide them in slightly different ways, with slightly different APIs, and different user interfaces.
So, that leads you to, from a business point of view, these three major challenges, which is, if anything goes wrong, you're going to compromise your business continuity, you stand the risk of suffering some kind of data breach or data loss, or you will, in fact, become non-compliant, and that will cause problems. So, looking at gen AI itself, and some of the challenges that this brings, that it is more of the same in the sense that gen AI produces risks around the privacy and confidentiality of data.
You have to control what data you use to train it, and to make sure that that data is used in a way which cannot subsequently be leaked to your competitors. That it introduces a lot more services that are provided by the cloud providers, and each of those services needs to be secured in the same way. And you have this increasing risk of what's being called shadow AI, where people are using services that the organization didn't know about, and putting data that the organization didn't realize was being put into those services.
And there is a supply chain additional risk, in the sense that which LLMs are you going to use? Are you going to use ones that are sanctioned? Are you going to use ones that may have been poisoned on the way to you? And how can you be confident that what you're using is correct?
So, you need another layer of control over the development cycle of the AI applications. So, in a sense, what is needed is included in your security posture, is something that represents the AI security posture.
Now, where are we? Well, where we are with cloud security is what I call cloud alphabet soup.
So, I'm just going to talk for a moment about how we got here. So, in effect, when security started to be thought about for the cloud, it focused around cloud application development. And there's a lot of sense for that, because many of the ways in which organizations were using the cloud was not simply to lift and shift what they already had, but was to create new things.
And so, there was this famous cycle of code to cloud and cloud to code. So, the focus was, first of all, on how is the development of cloud native applications secured? And this is important, because not only does it include regular code, but it also includes the data definition in terms of infrastructure as code.
And then, as you started to build things, it introduced more third-party supply chain risks, because you would probably include open source or common modules in those things. And security then was focused on preventing things from getting into the build that shouldn't get into the build, and making sure that the build was clean.
And then, as you put it out to the cloud, you had to make sure that the services that you used in the cloud were free of vulnerabilities, and that as the system was deployed, there were no more unforeseen and unwanted changes being made, i.e. configuration drift, and led to the need to report on the security and compliance of what you were doing.
And then, finally, as you run it, then you needed to be able to detect and respond to events that occurred. And the key thing about this as being a circle is that if there were any problems that you discovered when it was running, you probably had to go back and alter the cloud, the code that you had originally created, which led from code to cloud, and then from cloud to code. And that all sounds very good, but in fact, it created this alphabet soup of solutions.
So you had cloud infrastructure entitlement management, cloud workload platform protection, you had cloud security posture management, you've got now AI posture management, you've got Kubernetes security posture management, data security posture management, and things like extended detection and response. And this in itself has become the problem. So there was an interesting study that was done by the IBM Business Institute. And this actually studied a range of organizations. And it found that on the average, these organizations were using something like 83 different cloud security tools.
And they were coming from somewhere in the order of 29 different vendors. And that is a major problem to do with management.
So now, the caveat that I would say with this is that whilst this is a good study, it was actually commissioned by one of the cloud security vendors. And so perhaps they had an axe to grind. But nevertheless, complexity is the enemy of security, and doing things to reduce it is good. So that led me to this notion of the four pillars of cloud security.
And these four pillars, hopefully, will remove the alphabet soup by creating some kind of a security fabric, and they should be built and support good practices such as, for example, the MITRE and ATT&CK framework, so you can trace why you are doing a particular thing. And I'm just going to go through each of those pillars reasonably quickly. First of all, everything is based on this notion of shared security. And this has led to all kinds of confusion. But basically, you, your organization, the user is responsible for securing what they use.
And that usually means, we're an identity and access conference, identity. It means securing access, who can access your cloud services, and in what way at what time. And that is number one. And number two, is to do with your data, which is being able to control through access control or other ways, that the data that's held in the cloud is secured. It is up to the cloud service provider to secure the infrastructure, and your responsibility is to assure that they do it. And that means things like independent certification.
So what I'm going to talk about next is about what you should be doing, but the same things apply to the cloud service provider. So first of all, identity centric security. Now there's a lot of stuff to do with identity. So why did I put those particular things? Because when I looked at MITRE and ATT&CK, and I looked at how often a particular control or approach was mentioned as a response to one of the threat tactics, I came up with a list in order. And so enforcing least privilege is one of the most powerful and most frequently mentioned things to do.
Then implementing strong authentication, followed by detecting abnormal behavior, and so forth. And in a modern framework, we should also expect artificial intelligence to support these things, as well as perhaps making it easier for the adversaries to succeed. And so if you don't believe me, I produced this little matrix.
Now, I'm not asking you to read this here, but the slides will be available afterwards. And so you can look for yourself at how the different approaches to cloud security, in fact, are usable and are good controls for the different threats in the MITRE threat tactics matrix. So then if we look at the second pillar, which is that you need to secure your data.
Now, identity is good. Identity is, if you will, the first layer of control of who can get at your data. But there are other reasons why that data may become compromised.
And so, for example, you need to know what you have, and then you need to protect it correctly. And the single most powerful thing to do that in the cloud is denying public access. We keep seeing these incidents where, in fact, the problem was that there was an exposed bucket with internet access and no controls. If you go to the next stage, it's a good idea to encrypt what you put in the cloud. And there are lots of different ways of encryption, including things like confidential computing, which allow you to do things like training data for AI without actually exposing the data itself.
And then, last but not least, for resilience, you need to have some kind of data backup. And again, there is a matrix, and I'm not going to dwell upon that.
And the third pillar is, having done both of those things, is then there are all what you might call the cyber hygiene areas, which are essential for cyber resilience, which include things like training your users, which is top of the list in terms of that, securing your network in all of the conventional ways, zero trust and controlling lateral movements and things like this, making sure that there are no unnecessary technical vulnerabilities in the way you do computing, to manage DevSecOps and Gen AI in the same way as we've described.
And finally, most importantly, actually, is detection and response, to be able to detect that something bad is happening, and to respond to it rapidly and in a timely manner. And again, a matrix.
So, this approach takes us, in my view, from alphabet soup to a cloud security fabric. And these are the four things which we talked about, which are dealing with shared responsibility, making sure you control identity and access, that you then ensure that you manage the data and control access to that data. And finally, deal with the, prepare for, monitor and detect and be able to respond to the different kinds of the cloud. And this is the areas that we've looked around, which will be in the leadership compass that will be published in late June on this area.
And I look forward to seeing that. And so, as always, here is my details. If you'd like to book any meetings with me, I'd be very happy to discuss this further. And with that, I'll say, thank you very much.
