Cloud computing was one of the last decade’s most transformative technologies. It helped organizations launch exciting new applications and services, as well as innovate the way they operate. However, moving critical parts of IT infrastructure and operations outside of organizations’ perimeters has significant security implications. The cloud is definitely here to stay, so security consultants Laura Kankaala and Nick Jones joined episode 52 of Cyber Security Sauna to talk about the cloud security challenges organizations are facing and will continue to face.
Listen, or read on for the transcript. And don’t forget to subscribe, rate and review!
ALL EPISODES | FOLLOW US ON TWITTER
Janne: Welcome, Nick and Laura.
Laura: Thank you.
Nick: Thanks for having us.
So first off, can each of you speak a little bit about your experience with cloud security?
Laura: Yeah. Actually, I’ve been working with cloud security for some time now. And if I go back to the beginning of my career, I think I started my career in a very convenient spot, because I first started doing this kind of sysadmin type of role for very old Linux servers in this, you could say, traditional data center model. So I was doing that and I feel that I got quite a good feel for how it feels to operate anything in that kind of environment.
Then quite quickly, I started to also maintain cloud servers, and well, in AWS, EC2 instances and whatever was built there. And I got interested in cloud security around that time as well. I think this was like 2016, 2017.
And I think the world is quite different already today than what it was back then. And, for example, with cloud security, we have taken great leaps forward, but also maybe sometimes gone a little bit backwards as well.
Laura Kankaala, Nick Jones
Nick: And in my case, barring a short stint as a software developer, I’ve been a security consultant pretty much my entire career. And I got into cloud after we started seeing it appear more often on engagements, where we’re testing client environments. And the next thing you know, the server you’re looking at is actually not in a data center, it’s hosted in AWS, or in Azure.
And my first exposure was being put down in front of a client and they said, “Oh, actually, yeah. So some of this is in Azure. I hope you’re familiar with that as well.” And I got presented with a console and went, “Hmm, okay. Let’s have a look then.” And it spiraled from there into something that crops up fairly regularly. And from there, frequently enough that it started to really need some specialization.
So from that point forward a few years ago now, I started dedicating my career towards cloud security, and these days I run our cloud security team here at F-Secure Consulting, primarily focused on AWS, but also on attack detection – how do we identify malicious activity within cloud environments? Which, it turns out, is even more of a challenge in many ways the than on-premises estates.
Oh, I’m sure. And that’s a beautiful, typical consultant story, from fake it till you make it to true expertise. I love that. So when we’re talking about the cloud, what exactly are we talking about? Bear with me with the silly question, but it’s easy to confuse software-as-a-service offerings with cloud services and cloud platforms. So what is cloud to you?
Nick: So, I think cloud is all of these things, right? It’s such an umbrella term for so many different things that it’s worth unpacking a little bit, I think, where we typically talk about.
So software as a service, like Office 365 or Dropbox, Gmail, these kinds of things, all definitely fit under the cloud banner. They tend to be less relevant from a preventative standpoint in security, just because so few controls are available to you as an end user.
So most of our time, when it comes to securing these things, to prevent breaches initially, tends to be focused on the infrastructure and platform-as-a-service offerings by people like AWS and Azure. That changes when we start looking at detection and response. But I’m sure we’ll talk about that more later.
Laura: Yeah. I think a lot of the times when me or Nick talk about cloud, we talk about infrastructure as a service, or platform as a service. So that would be AWS, Azure and these kinds of players.
But I think in layman’s terms, you could differentiate between the two on how much control you have over the overall things in the actual cloud service. So can you control the infrastructure? Can you modify the settings there or build your own stuff, or are you just given with some pre-made settings that you can configure a little bit?
So that would be the rough basically distinction between the two, but naturally then there are a lot of legal and other obligations that falls between those two.
All right. So Nick, years ago you wrote an article where you outlined some of the ways that cloud impacts organizations’ ability to detect attacks. Could you just give us a brief overview of this point?
Nick: Sure. So the biggest challenge when it comes to the cloud, versus what organizations are used to working with in terms of on-premises Windows networks, Active Directory, Linux, these kinds of things, is that the nature of the attacks becomes a lot more environment- and context-specific.
So it used to be before, that much of the detection capability that we would build was based on generic detections for things that we knew an attacker would try, because most Windows networks are pretty similar. An attacker’s very likely to try things like Kerberoasting, or if they’re low sophistication, maybe they’re running really common security tools like Mimikatz, and we can see that and go, “Hmm, that’s obviously bad. We should go step in and do something about it.”
The real challenge in the cloud space is that because you have much less control over things, both as the user and as an attacker, there is much less you can do. And so much of what an attacker tends to do is what we’ve taken to calling abuse of legitimate access or abuse of legitimate functionality.
So rather than running exploits or deploying remote access Trojans, Cobalt Strike, all of these things, what typically happens is an attacker gains some kind of level of access through credentials by stealing access keys, or by phishing someone for their username and password. And then using that to speak to the APIs that are exposed by the cloud provider, to understand the environment, steal data, manipulate the permissions model, a number of other things, but it’s all done through legitimate functionality offered by the cloud service providers.
Now the real challenge there then, is it means that these are the same functionality and the same actions that an administrator is going to be taking in order to build the environment and manage it over time. So you need to understand what is normal, not just for your organization, but normal in that particular workload, in that particular environment, and be able to differentiate normal activity from things that shouldn’t be happening to this particular workload. And most organizations aren’t equipped to scale that kind of analysis and capability across the hundred, 200, 300 cloud workloads that they’re running.
Wow. I was still sort of hung up on what Laura was talking about, like platform as a service, infrastructure as a service. Whereas instead of going down to the ICT department and asking for a server, you ask AWS for a server and surely they’ll handle security. But if you’re talking about like behavior detection, then that’s a whole different ballgame.
Laura: Yeah, definitely. And I think here, we should also emphasize that, I think I said this exact same thing before in one of our previous cloud security-related Cyber Security Sauna episodes, but nothing is inherently insecure or secure in the cloud. So it really depends on what you’re deploying and how you’re maintaining that.
So there is the responsibility of, for example, AWS handling the data centers and so on. So you don’t have to worry about the physical security that much, for example. But if you are putting up there code that is vulnerable, then you could risk exposing your whole infrastructure, for example, through, in this case, you don’t even have to leak the API keys, administrative access keys, specifically, but through some things called, for example, the metadata instance, you could be able to get temporary credentials, which you could then use to, basically take over the whole AWS environment.
So I completely agree with what Nick just said, that these kinds of “living off the land” procedures, they are quite good in cloud environments because there are many types of services available. And if you just can get some sort of administrative access, you could easily obfuscate whatever you’re doing there as just normal admin actions, unless you are going to unused regions and spinning up cryptominers or something like that. Then you will definitely be detected, at least at some point I hope. But it’s a tiny bit different than in a Windows enterprise environment.
Nick: And the cryptominers brings up an interesting point actually, in that one of the most basic detection mechanisms we’ve seen so far is actually not in the IT department at all, but in the finance department, who phone up IT and say, hang on, why is our AWS bill 10 times what it was last month? And the answer is, Oh, we’ve been breached and it’s cryptominers. We’ve seen that in a few cases.
Laura: Yeah, that’s true. Yeah.
Man...So is detection like the biggest security change that organizations need to make when they’re transitioning to the cloud?
Nick: So, probably not. Actually in many ways, detection is a sort of a second or third step in your cloud security journey, usually. It’s good to be able to have it, but few organizations that we work with are doing much more than the absolute basics there now.
The real challenge most organizations are facing as they move to the cloud is, securing one cloud environment is probably fairly doable; applying your small security team across the 35 engineering teams, all doing their own projects, becomes a whole different challenge. And so when you have to combine the sharp learning curve for the security people working in these cloud environments with the business’s desire to move as rapidly as possible…
You know, the reason people go to the cloud in the first place is to speed up their development velocity, be able to release new features faster, bug fixes faster, all of these things. We move away from releases every few months or a couple of times a year, to in some cases releasing several times a day into production. AWS famously stated that they do releases into production every 11.7 seconds. And the idea that you can do adequate security testing manually, as most people are used to doing, on a release cycle like that, is insanity, right?
So we have to completely adapt our ways of working in security to meet what the engineers are trying to do. And that means building out automation as part of your deployment pipelines to catch basic security checks there, and building security earlier into your development process, doing design reviews and threat modeling as part of your initial design sessions. There’s a whole raft of things that have to change for this to go smoothly. And a lot of organizations are succeeding to some degree with much of that. But it’s definitely a challenge for most that I’ve worked with.
So the biggest issue for you is not in the cloud transformation itself, it’s that at the same time, the organization is also transforming into this DevOps type of world, is that correct?
Nick: Yes. I think the important thing here, really, is that cloud is in many ways a symptom of DevOps. People have moved to the cloud because it enables DevOps practices. And it happens to come with some other advantages, but at least from an engineering perspective, the big thing that most engineers love about it is that you can deploy brand new resources in a minute or two instead of four weeks for Dell to ship you some servers.
I wanted to ask you guys about transition, like when organizations are moving their IT infrastructure to the cloud. Is that something that we see threat actors exploiting, the confusion and just the mere fact of moving things, lifting things to the cloud?
Laura: If you think, for example, not just the process of moving things, I see in a lot of environments that it’s not just purely cloud, or it’s not just purely one cloud service provider either. So it can be a mixture of on-premise and cloud and multiple clouds and so on. There’s a lot of different types of things that are happening.
Naturally, the way that we are doing this thing, so the DevOps way of doing things, so for example, automatic deployment and giving also developers wide access to the environment itself…While it’s also good for the developmental side of things, so you don’t have to worry too much about the hurdles of contacting another team for making a firewall opening for you or something like that, so you can do all of these things yourself.
But naturally, from an attacker’s point of view, if you can get access to the environment as that specific developer, either through breached credentials or phishing or malware on their computer, I think these things are definitely something that is quite interesting.
And not only that, but when we’re talking about continuous integration and continuous development, I think even more so than ever, we’re bringing a lot of external dependencies on board. So whether that’s images for containers; or pieces of code; or just these, I don’t think that this is an official term, but these plug-in features that you put on top of your own code, let’s say for authentication, for monitoring, for any kind of purpose; we are basically trusting these providers to handle these operations for us.
And I think it’s this trust that can actually end up hurting us quite a lot in the long run. And I think we got quite a good example of that, for example, in the case of SolarWinds and Orion, the monitoring tool that was basically backdoored and allowed access to a lot of, how should I put it, sensitive environments or big players out there such as Microsoft and Intel and governmental offices and so on.
Nick: Absolutely. And I think one of the other interesting things here is to note that where we’ve seen major cloud breaches, very few of them have been purely cloud breaches. Most organizations who have breaches associated with the cloud are breached via other assets, cloud-adjacent, or their on-premise networks that have been leveraged to allow an attack into their cloud environments.
So SolarWinds was a great example here, as Laura mentioned in particular. They used what’s called the golden SAML attack, where they essentially leveraged on-premises systems for authentication to get into the cloud accounts. They got the access they needed locally on premises, and converted that into access into the cloud environments.
And we see that sort of thing quite a lot. Pivoting up from other environments, or equally, compromising secondary assets, cloud-adjacent assets, like source code management systems or continuous delivery systems or these kinds of things, to then alter the cloud environment. And it’s obviously very challenging from a pure cloud perspective to defend against a breached administrator, because by definition they have administrative access. And if an attacker is able to get that, then it’s game over, really.
So one of the challenges we’ve definitely seen in the detection space is effectively weaving the different data sources and detections together from the cloud and from the on-premise networks and all of these other systems that all talk to each other, right? That’s going to be a real challenge long-term I think.
Laura: Yeah. And just to expand on that, I think that we’re quite good at looking at one, let’s say AWS account, or Azure account and verifying that, okay, this specific account is secure if we exclude all of these external things that have access through this specific account.
But I think that’s the issue, that we are dealing with such complex infrastructures that expand not only to other software service integrations, but to on-prem and to other cloud services. And the visibility between these providers, or even within the specific provider, when you have multiple accounts, can be quite tricky to achieve, at least from a technical point of view.
Janne: That’s very interesting. Because one of the bigger conversations when people were considering moving to cloud was the security concerns, like we’re letting go of the control. And now you’re saying that you’re actually sort of better off, like we haven’t seen companies get breached because they moved to the cloud. We’re seeing companies get breached exactly the same way they were getting breached before, but now that’s expanding to the cloud side. Is that correct?
Nick: It’s not entirely the case everywhere. We’ve definitely seen a few cloud breaches. I mean the really famous one was Capital One back in 2018, 2019, whenever that was. But certainly the majority of breaches we’re seeing are compromises of existing systems that are then expanded into the cloud.
And the real classic there is with Active Directory. Everyone’s got an Active Directory network, if they’re a business that’s been around more than five years or so. Those are often very large, very complicated and very legacy, with all kinds of old stuff weaved into them. They are rarely properly secured.
And so if you build your authentication for your cloud on, as we say in English, a castle made of sand, that’s not going to go well for you. And that’s definitely an issue we’ve seen with a number of organizations.
Laura: Yeah. And I would like to point out here as well, that in a lot of these cases, when we talk about these things, we have AWS for a reference or Azure and such, but there are a ton of other cloud providers as well. So it’s not just these two three big names that are out there.
And if we just look at the internet, for example, through Shodan or something like that, it’s quite clear that there are still some…for example, by the amounts of MongoDBs or these kind of internal services that are out there directly plugged into the public internet, they are not necessarily from cloud services, but a lot of the time they are from kind of like a software as a service or from a cloud provider.
But it’s not about human error at this point. I don’t think that we’re accidentally exposing these things, but it’s more about anti-patterns in the configurations that can be made in some service that people are using and stuff like this.
So even though I would say that AWS, for example, provides quite nice guardrails and, for example, everything is denied by default – Well, not absolutely everything, but many things are denied by default – that is not the case for all of the providers. And I think that is something that should be considered again, because if you’re looking for a cloud, just any kind of cloud to be your go-to security solution, then I think you still need to do a little bit of background research on the actual systems and services and platforms you’re using.
Well. I mean, that’s the thing. We talked about infrastructure as a service, platform as a service, so those are fairly simple and well understood terms, but it gets more complicated than that, doesn’t it? So, at one point I was questioning whether or not it’s even possible to configure an S3 bucket so that your information doesn’t leak all over the internet, because there were so many leaks. So how much of this responsibility is on the cloud provider to sort of do things or have defaults secure, and how much of it is just like, “Well, you bought it, you better know how to use it.”
Nick: So that’s a really interesting one, I think. And the main reason that it’s so interesting is that the providers have an official definition of what they’re responsible for. It’s known as the shared responsibility model, and it outlines that for any given service, these are the things that we will handle, and these are the things that you will handle.
Now the problem with that is that while the providers make that information very freely available, and all of the basic cloud education that you can do in terms of training courses and things talk through all that in quite a lot of detail, we have also noticed that a lot of people just click the “give me an S3 bucket” button. And perhaps don’t go in and change anything after they’ve done that. They’ve got their S3 bucket and what more do they care about?
So one of the interesting changes that AWS made was to default S3 buckets to private, rather than public as they had previously. And you can see the graph of new public S3 bucket creations, before and after they published the numbers. And it goes from 80% being public as they’re created, to 20% being public as they’re created, just by flipping the default.
So while officially it’s not the provider’s problem, there is very often quite a lot they can do in terms of the defaults that they set up to reduce these problems for people. And I think they’ve all got a bit of a ways to go on getting that right in more cases.
Laura: Yeah, I absolutely agree. There is basically no written rule for these providers to provide any of these things. But I think with the case of, for example, AWS and this S3 bucket, I think that’s a great example of how easily you can actually make the internet a lot safer place just by, as a provider, forcing effectively people to use the more secure alternative.
But also there’s the fact that a lot of people, depending on the service naturally, and what kind of automated tools there are to deploy stuff there, but they may not actually in that sense, always look at the configurations if they are deploying automatically things. And if you’re, for example, moving from one service to another and stuff like this.
So I don’t know, I feel that it should be the provider’s responsibility to disallow these kinds of, I will repeat the word anti-pattern because I feel that it’s an anti-pattern to allow insecure defaults.
Yeah. Those numbers were mind-blowing. Because to me, that sounds like 60% of those buckets were not supposed to be open to the public in the first place. So that’s quite a chunk. We’re not talking about marginal changes here.
Nick: No, absolutely. And I think that’s quite an important thing, really. AWS themselves, and Azure and Google Cloud and IBM and Oracle and all the rest of them, can, and are now significantly more so than they have historically, putting effort into coming up with secure defaults, making things easier to get right in the first place.
But fundamentally these platforms are all very large and very complicated, and there’s a lot of moving parts. And if you have an engineering team who doesn’t take the time to understand it, because the business hasn’t given them the time or the resources to get it right because of deadlines or budgetary pressures or whatever else, then you’re going to come unstuck eventually, it’s going to go wrong.
One of the great things about the cloud is scale. So companies can quickly scale up their operations by just buying up more computing power, but is the way we approach cloud security equally scalable?
Laura: Yes and no. I think in an ideal situation, it would be scalable with whatever you’re deploying there. However, there are some technical limitations on what you can do. And depending also on the structure of the organization itself. What kind of organization is making these systems and how many AWS accounts are there, how the AWS accounts are handled, are they somehow unified for example, through…Now I’m using AWS again as a reference, but for example, through some kind of like a control tower set up where you could potentially enforce security and visibility in multi-account environments?
But it’s a difficult situation also because it requires the engagement, I think, of the people who are developing these applications and these systems. So it’s time consuming and a technical issue sometimes, yes. But it’s also an organizational level issue. And it depends on the communication and the clear, for example, baselines for security, how well are those communicated, and things such as this.
Nick: Absolutely. And I think the other thing that’s worth noting is that while some aspects of cloud security can scale quite well, many others don’t. And the classic example there is it’s very easy to monitor for misconfigurations. We can easily scan all the S3 buckets in all of our AWS accounts we know about, or scan all of our storage accounts and all the Azure subscriptions that we know about, and go pull out which ones are public and then verify whether they should be or shouldn’t be, against a list that we’ve written down somewhere.
The challenge then comes in remediating that. Let’s say, we’ve got 10 S3 buckets that shouldn’t be public. In your average organization, those are probably split across multiple engineering teams, all of whom have their own time pressures. And so going to them and saying, “Hey, you need to fix this S3 bucket.” They’ll turn around and say, “Okay, sure. We’ll have that into the next sprint, we’ll get it done in a couple of weeks.” That’s not ideal.
So the biggest challenge that many organizations are facing with scaling their cloud security, at least their configuration enforcement, making sure the basics are right, is auto-remediation. How do you automatically set things up so that when someone creates a public S3 bucket, it’s changed to private without anyone having to do anything? And you go from, “Oh, this S3 bucket’s public, someone should do something about that.” To the alert saying, “Well, this S3 bucket was public. It’s not anymore. We fixed it, but you should go talk to the engineering teams.”
And so quite a few of the organizations we work with have been building out their own systems that do this, but unfortunately unlike the automated detection of these issues, which is purely based on the data you get out of the cloud service provider, the auto-remediation needs to also take into account the business practices of the organization that’s using it, and the way the engineers work together, and have an exception system that people can easily use, and all kinds of other things that are very, very organization culture-dependent as much as anything else. And so I think that’s a real challenge that we’ll see for a while, yeah.
Laura: Yeah, I definitely agree with that. And for example, with the auto-remediation, I think it’s a very traditional issue with any kind of alerting and monitoring and doing anything automatically, that there needs to be someone who these things are actually escalated to. And I think that perhaps the teams, the DevOps teams still are in the process of free-forming around this, for example, auto-remediation. Because it’s also, I feel, an issue in the organizational point of view, if it ends up being the developers always handling everything.
So it’s not just developing of the application, but then potentially auto-remediation and then detection and monitoring whatever is going there in the environment. So I feel that a lot of these things just boil down to good old communication and how well that happens in the organization.
No, I get that you need automation and probably new ways of working as well, but do we also need new ways of thinking with the cloud transformation? Do teams just need to stand up and say, “We can’t control access anymore, like we did. We just have to embrace Zero Trust entirely.”
Nick: I’m glad you bought Zero Trust up because it’s one of the most common buzzwords we run into in the cloud space. And it is very much a buzzword, everyone has their own definition for what it means. At its core, it’s the idea that you stop trusting the resources that are speaking to each other. Every system is designed on the basis that everything is talking to is untrusted, all of its inputs are untrusted, and so on.
What many organizations are trying to do is use it as a way to get rid of their premises, the old, big firewall and VPN at the edge. And as a goal, I think it’s quite worthwhile and we’ve seen some quite interesting open source projects come out in this space. Most notably, Boundary by HashiCorp was released a little while back. And that tool is designed to act as a gatekeeper towards squishier internal systems that probably shouldn’t just be exposed to the internet, and to fit into that sort of model.
But the core problem is that identity management is hard. We’ve never really got it right as an industry. Active Directory is always one of the weak points in people’s internal networks. And if you look at AWS IAM, for example, the model that AWS uses for identity and access management, it’s fiendishly complex. There’s something like 6,000 different permissions and various different ways you can apply them to different things, and it’s fundamentally a hard thing to get right.
And so, as long as we haven’t solved the identity and access management problems that we have, moving to a completely Zero Trust type model, as Gartner and everyone is pushing, is a fantasy at best, I think. Not least of which, because we lose a lot of visibility.
One of the biggest challenges with the software-as-a-service offerings, like Office 365 and so on, is that while the fundamental system hardening that’s done for you by Microsoft is great, your ability to detect and respond on it is massively reduced because you don’t have access to a lot of the data that you used to. And that’s going to become a problem more so as we move to more of these Zero Trust deperimeterized setups, where we lose visibility, we lose monitoring, and we need to be able to compensate for that somehow, because otherwise you’re a single session hijacking attack away from half your data being exfiltrated.
Laura: Yeah. I feel that Zero Trust as in, if we boil it down to the bare minimum, what it means, that we don’t trust anyone, and then by that we could eliminate, for example, our perimeter altogether…I don’t think that that’s going to happen in the near future. I think we have a lot of services that don’t just simply support this kind of thinking, because you would need mutual authentication, for example, for devices or for services. This is not something that everything, every application, every device out there supports.
And for users, I think it’s good to have really enforced and strict policies and this Zero Trust kind of mentality even today when they are doing any kind of administrative things, for example, to AWS, because by default the admin API where you can do every kind of administrative operation is public to the internet. And that has always been, so it’s something that should be implemented.
But I don’t think that it’s time yet to put everything out there, open in the internet. And I think this can cause a lot of confusion amongst people and some, now we trust all of our employees, so we can just put our RDPs out there, or remote desktop protocols out there. So I don’t think that this is the way that it was intended, because the threats can come from inside as well.
So we were talking about the grade firewalls and stuff like that, so if you have an internal network and you’re trusting everyone by default in there, I think you are already like in a world of trouble, because just anyone could walk in with their infected computer or connect to a VPN or anything like that. So these kinds of Zero Trust mechanisms, I feel that they are a good way of thinking and adding to the level of security already in place, but please don’t put everything out there on the internet.
It’s the same thing we had when everybody started doing agile development. Being agile means I don’t have to document anything ever again.
Nick: Exactly.
One of the trends we’re seeing is an increasing use of Kubernetes in organizations. How does that factor into the security posture of a company?
Nick: So Kubernetes is a really interesting one. And fundamentally, for those who are familiar with it, it’s a containerization and orchestration technology that came out of Google, back in 2015 or so now. It’s evolved an awful lot since then. But it’s built originally from a thing called Borg, which was designed to scale applications to meet Google’s scaling demands. So it was designed and spun out of a project to operate at a scale that very few companies are already dealing with.
And it certainly has its benefits. If you are running very large, very complex environments, it makes it easier to share resources and control who can talk to what and a number of other things.
But the downside of it being designed to operate at that scale is it brings a lot of complexity, and it brings as many problems as it solves for a lot of smaller environments. It’s quite common for us to see organizations using it in cases where they didn’t necessarily need to, where perhaps the downsides of having to manage and secure and administer the thing long term, perhaps don’t outweigh the benefits.
And so my usual Kubernetes security advice is first, make sure you really do need it, and it’s not an undue burden you’re taking on just because someone wants to play with the cool new toys. And then after that, make sure that you have someone in your security team who takes the time to really understand how Kubernetes works, how all the moving parts fit together, and how to adequately secure it, because there’s an awful lot of moving parts.
And in many ways it’s almost as complex as bringing another cloud service provider on. So it’s like having AWS already and taking on Azure in terms of the additional complexity it can bring. So it’s worth being aware of that and going in with your eyes open.
All right. So we’ve seen international studies show that CISOs are prioritizing learning about cloud security to just ensure that their IT estates stay protected, but also to understand how to help their organizations capitalize on the cloud’s capabilities. So where would we advise CISOs to start this learning?
Nick: For your average CISO, they are fundamentally responsible to make sure that their teams operate as intended and produce the correct results, ensure the business is secure. So it’s on them to understand at a high level what the benefits of the cloud are, and perhaps speak to the engineering side of the house to understand how their colleagues over in that part of the world are operating. Fundamentally, they need to make sure that their teams have the capacity and the capability to do what needs to be done.
Looking lower down the stack, if I was a CISO looking to make sure my teams were effective at what they were trying to do, I’d be prioritizing getting some of my engineers, my security engineers, my detection engineers, on cloud-based training courses. Whatever cloud providers you’re using, all of them have certifications. And our usual approach within F-Secure is to ensure that our security people understand the cloud. So architecture certs, administration certs, these kinds of things are a great way to get that cloud technical knowledge into the teams, because your security teams already understand how to do security. So it’s about having them translate that into the cloud world.
I typically then also recommend that everyone reads The Phoenix Project, which is the book that started DevOps, in many ways. And it’s a relatively short novel telling the story about a team who moved to working in a DevOps manner. And as I said before, the cloud and DevOps are so tightly interlinked that having an understanding of what DevOps really means, what the goals here are, what organizations are trying to solve with it, will mean that your security teams then better understand where the engineers are coming from.
And the key thing really with cloud security is that security is an enabler for engineering to do the right thing. Security is not a gatekeeper. It’s not a blocker. We need to be there with the engineers, helping them on their journey. And the best way to do that is to make sure security understands where engineering is coming from.
Laura: Yeah, and I think that’s also a bigger point in resourcing. So resourcing enough either people or enough hours or days, and making, for example, the detection capabilities happen, and making auto-remediation happen.
So even though sometimes you could think that in cloud, everything comes out of the box as well, because there’s a lot of services for this and that, but a lot of the time there could be some need for extra layers of code or Lambda functions or some kind of serverless operations. So just to have enough resources and enough people looking at these things is also a good thing that the CISO can do within the organization.
Okay. So now back in the on-prem days, there was sometimes the problem of shadow IT. Margaret in marketing would fire up a new web server somewhere, and the security teams wouldn’t know about that at all. So in this day and age, everybody remote working and so forth, it’s easy to imagine where different department and teams start sourcing services from a variety of different providers, everybody’s firing up their services to different cloud providers. So how do you go about monitoring all this activity?
Nick: With difficulty, is the short answer. It’s not an easy thing to do. One of the biggest challenges for many organizations is just finding all of the cloud they’re doing. And that’s often then complicated by mergers and acquisitions or new divisions being spun up or marketing decides to engage with a third party agency, and oh, it’s fine, we’ll just put our credit card on Google Cloud and they can do what they want, all of these kinds of things.
And we’ve seen some organizations take some slightly interesting approaches to how you track and manage these things. One of the most effective is actually just to become best friends with your procurement and finance departments and go ask them for a list of whose corporate credit cards are being charged for cloud usage, give them a list of the different providers and people you might expect to bill for it and get a report of them. It’s likely to be far more accurate than trying to track down all the engineering teams, because someone’s going to pay for it all at the end of the day, right?
That’s a good tip. That’s a very good tip. So overall, are we happy or sad about the cloud transformation, securitywise? Has this been a good thing or a bad thing? Or, to put it in another way, should companies be looking at this as an opportunity to make long lasting investments into security? Or is it sort of just too early to say?
Nick: Yeah, absolutely. From my perspective, the big win for all security teams with going to the cloud is you no longer have to worry about managing your own networks, patching your own servers, at least once you get out of running virtual machines. There is so much low-level data sensory type security work, and operations work too, that the cloud providers take care of for you.
And I challenge anyone who thinks they can run a more secure data center than Amazon or Microsoft, because they are working at such a scale and they’ve got their processes and procedures down so well, that I think anyone would struggle to compete with them in that space.
So you are outsourcing some of your security to probably the best organizations in the world for it. And that gives you the opportunity to focus in more on security concerns that are directly tied to your business and your workloads, rather than focusing on the security work that keeps the lights on, so to say.
Laura: Yeah, I think cloud platforms are the things that people are using these days, and even increasingly so. So I think making investments in cloud security is naturally something that you should do, and perhaps look for the tools that are already in-built in the cloud service providers themselves and see if those can be of any use to you. And if not, then even external tools can sometimes be helpful.
With that being said, I don’t think that, as with any kind of security, this kind of investment is just a one-off thing. It’s more of a long-term strategy, that you have enough resources internally to maintain good security posture, because, as we already discussed, whatever you’re building there and your own applications, they have very specific risks potentially associated with them. So you need to build also custom tooling or custom detections, perhaps, for those as well.
So you should look at security in cloud as a possibility for also internally developing, and look for ways to improve security, even in the future, as it’s more of a moving goal than something you can just patch up with a quick investment.
Yeah. I hear what you’re saying. This is some good advice, although I’m feeling a little disappointed that I don’t think we’ve been able to solve all the problems related to the cloud in this one episode quite yet, but I want to thank you guys for being with us here today anyway, and talking us through this apparently very, very complex topic.
Nick: Happy to be here, and thanks for having us.
Laura: Thank you.
That was the show for today. I hope you enjoyed it. Please get in touch with us through Twitter @CyberSauna with your feedback, comments and ideas. Thanks for listening. Be sure to subscribe.
Categories