[Podcast] De cloud: beveiligingsvoordelen, risico’s en redenen voor gebruik

De manier waarop we zaken doen en de manier waarop we software en infrastructuur ontwikkelen en gebruiken, is door de cloud veranderd. Wat zijn de beveiligingsvoordelen van een overstap naar de cloud en wat zijn de specifieke aandachtspunten? Wat moeten bedrijven doen om hun cloud goed te beveiligen? Voor aflevering 21 van Cyber Security Sauna gaat Janne in gesprek met Laura Kankaala en Antti Vaha-Sipila van F-Secure om te praten over wat het betekent om cloud native te zijn, waarom inbreuken in de cloud plaatsvinden en nog veel meer. Luister hier of lees verder voor het engelse transcript. En vergeet je niet te abonneren of een review achter te laten!

ALLE AFLEVERINGEN | VOLG ONS OP TWITTER

Janne: So what is your relationship with the cloud?

Laura: Well, my relationship with the cloud is quite a long one, I would say. I have done some developmental work on the cloud, like mostly on AWS, but ever since I first stumbled upon AWS, I was kind of…It just changed the way I saw how things can be done and how infrastructure can be built. So I was very intrigued, and also security-wise, I’ve been working a lot with my clients and try to help them with their issues and with their worries regarding the cloud. So I do a lot of assessments and auditing regarding cloud infrastructure.

Antti: I think that my relationship’s mostly being a paying customer for cloud services. But on the other hand, personally I do a lot of work with software security processes, DevOps and all that stuff. And now like with DevOps essentially, especially there, I’ve got a feeling that without modern cloud services you wouldn’t be able to do much of anything. And I’m really interested in getting security in there as well.

Before we go further, let’s talk about what the cloud essentially is. Everyone’s talking about it, but it’s not like any one specific thing. What would be a constructive way to approach what the cloud is?

Laura: Well, I would say that maybe it’s easiest to compare it to a traditional data center model. So you have a traditional data center somewhere sitting, and you’ll typically have some contact people there. You have to contact them like, “Hey, please do this and this change through the firewall setting” or you know, you have this very strongly integrated infrastructure team that is handling your infra. But with the cloud you can actually be your own infra team, so you can have your DevOps people, you can have your developers doing the infrastructure around your systems.

Antti: Yeah, I think that’s probably the main aspect of the cloud, that you don’t have to touch the very underlying infra unless you really want to. But then again, there’s a thing called a split responsibility model with most cloud providers. So they clearly designate which part of the infra they are handling and the rest is left to you. Now this split is obviously it can be on different layers.

Laura: Yeah. I would say, I don’t know if you agree with me, but the rough split responsibility model is that whatever you do in the cloud, that is your problem and that is for you to secure. But everything that you can’t touch, so the data centers and the hardware, that is not your problem, so to say. So you are not responsible for those.

But we’ve heard of different kinds of service models. Like, you’ve got infrastructure as a service, platform as a service, and finally software as a service. Is that the cloud, or is that something else?

Antti: Well, it depends on your needs. I mean, if you just require software that you’re using, then you’re buying SAAS. But from the perspective of the user, it really doesn’t make any difference if your SAAS is running on premises in your data center or in a public cloud, right? You’ll get the same type of software anyway. So depending on the layer that you’re talking about, you can get a cloudlike service even if you have your own data centers.

Laura: Yeah. And it’s also a lot about the scalability of the applications. We’re talking about this split responsibility model, but I think what really makes a cloud service or cloud services also is that they are very scalable. And you can have applications, and in case you don’t need a lot of capacity, at some point, and suddenly you have an online store and suddenly you need a lot more capacity to actually run the store, then you can quickly scale up your resources without having your web application crashing down.

Antti: Yeah, exactly. So if you just want to use software as a service, and the load on your service is usually pretty stable, then you might not actually benefit from the cloud at all in a sense, apart from getting rid of the servers. But then if you want to be elastic, and you want to scale workloads up and down, then of course you will run out of screwdrivers at some point and servers that you can screw into your racks if you own on your own hardware. But typically public cloud providers don’t run out of hardware. I think that’s happened though, I don’t know.

Laura: I’m not sure, has it happened?

Antti: I heard a story, but we’re not going to blame anybody now.

Laura: Yeah, no. Yeah, let’s not go there. Cloud is good.

Fair enough. So, what are the most obvious security differences between cloud providers versus a traditional data center mode of operation?

Laura: Well, I would say that it comes with the shared responsibility model and maybe the way that the developers actually have more control over the infrastructure, so they can actually implement more security controls. It of course depends on what kind of agreements you used to have with the traditional data center, and you know, but –

What kind of controls are we talking about?

Laura: Well, the controls that I’m talking about are that you can actually implement the security more. It can be part of your whole pipeline. When you build the code, many of these cloud services offer services to actually enforce security requirements or compliance requirements in the environment. So you have better options to actually monitor the environment and actually make this security part of the – Not iust an add-on after you’ve deployed your code. But as an integral part of the whole lifecycle.

Antti: In addition to that, I mean, when you’re actually deploying stuff, if you can do it automatically, there’s the option of not putting the human into the loop that much, which makes it even more secure because you don’t have to go and click on different consoles and work on CLI that much. So you can lock down the deployment.

Laura: Yeah, that’s true. You don’t have to expose that much surface to the internet. So no one is going to SSH into the servers.

Antti: And I think that this is important to understand, that it’s not necessarily a public cloud that can provide this. So most of this locking down deployment and handling the security automatically can be done on an on-premise cloud as well. It’s the same software stack that can be run whether or not the servers are owned by you or the public cloud provider.

You guys were talking about sharing the responsibility between the cloud providers and cloud customers. So what are the responsibilities of each group in keeping your data secure?

Antti: I think it’s, to put it really bluntly, the cloud provider is responsible for the service and the customer is responsible for the configuration of the service. And this is then replayed on every layer. So if it’s infra, it’s the raw networking that the cloud provider needs to take care of. And then the customer needs to look at the configuration of the network, including like opening ports and what have you.

So this is like the old infrastructure as a service model. So here’s your bare metal. Don’t hurt yourself.

Antti: Yeah, yeah. And then on a higher layer, so for example, if you’ve got some sort of a platform as a service, like a managed Kubernetes or something like that, then yes, you’ll have the Kubernetes that’s hopefully secure, but how you actually deploy your workloads on that then is your problem.

Yeah, so if you leave your S3 buckets wide open, that’s on you.

Antti: Yes. Or if you decide to run a vulnerable application on Kubernetes, then nothing in the provider’s Kubernetes is going to help you.

Laura: Yeah. So a good distinction here is that nothing is inherently secure in the cloud or in the traditional data centers unless you test it out, you know that your code is good, you know that you are not exposing too much attack surface. For example, with the S3 buckets being open to the internet. So that’s on you and you have to test it and you have to be aware of how you actually build stuff there.

The cloud is not secure per se, but it’s not super unsecure either.

Antti: Yeah, exactly. So I think it’s probably, in many cases, actually more secure than anything you could whip up yourself unless you have the means. I mean, the big cloud providers, they have clients that have really, really strict security requirements. Even like something that requires national clearance, of sorts.

Yeah, and people who manage these kinds of things is everyday all day.

Antti: Yeah, exactly. And now, they’re not going to weaken the security just for you because you are an individual, but you’ll actually be standing on the shoulders of giants, so to speak. So you will benefit from all the stuff that was done for those really security-conscious customers.

Laura: Yeah. And I think it’s a good thing to point out that many of these, for example, AWS, Azure, these major cloud providers, they have to meet many compliance requirements. So somebody has at least looked under the hood and said, okay, it appears to be okay and it appears to be secure.

Antti: Yeah. But on the other hand, that’s the only thing that you can do if you want to look under the hood. So if you really have some really esoteric security needs, you’re only going to have a whitepaper or a bunch of PDFs written by an audit company.

Laura: Yeah, that’s a good point.

Antti: And you have to trust that. You cannot go and see for yourself. But arguably, in most cases, even if you went to see for yourself into a data center, you wouldn’t be able to tell.

Laura: Yeah. Like, here’s the machines and yeah, they’re turned on, hopefully, and –

Antti: Yes. Light blinks, everything’s secure.

So you guys did touch upon this, but what are the specific security benefits and advantages of going to the cloud?

Laura: I think there are multiple benefits when you go to the cloud and when you deploy your software in the cloud. For example, the services you can use to monitor compliance and monitor the security status of your configurations on that account. For example, in AWS you have a config to monitor how your AWS account is configured. You have so many different options for logging and for seeing if things are working as intended. And I think that’s very good, especially if you need to be very conscious of what is happening in your environment and you are handling, for example, very sensitive data in there, like personally identifiable data. You have so many options for providing an audit trail that could have been hard to implement in this traditional data center model. You would have to buy new equipment or you would have to buy new applications to actually see or get that visibility in that kind of environment.

So what about the concerns, the risks or threats associated with the cloud?

Antti: Well, again, I mean you’re using a service. If you configure it in a wrong way, that’s a risk. So you really have to know how the service is laid out and which are the configuration options you have to apply.

That’s not specific to the cloud. That’s always been the case.

Antti: That’s true in a way, yes. But the cloud gives you tools that you may not have seen before. Looking at the new releases from the public cloud providers, what sort of services they offer, it would probably be a full time job just to keep on top of these things that they actually come out with, and in order to be actually fluent in all the security configurations of all of these would probably need a couple of people full time.

So just seeing all those cool things lying around, there’s a temptation to pick one up before you’re ready to actually do something smart with it.

Antti: Yeah, there’s this shining +2 mace that’s lying on the ground and you really want to pick it up.

I love that. I love that analogy. (Laughing) So let’s say your company does choose a cloud provider. Laura, you were recommending doing penetration testing anyway to to further assess the security of your data. How does that even work? Given that you’re pentesting what’s essentially someone else’s computer, and the environment is shared with other customers as well?

Laura: Yeah. I mean, you’re not pentesting AWS or Azure per se, you’re pentesting your own applications. And when it comes to cloud providers, they have different processes around this. So with AWS, you have to apply for this, like, “I’m going to conduct a penetration test on my application” so they know that you’re going to do this. Because I think this is true like with traditional software, you have to test it. You have to know how secure it is. And there’s no escaping that no matter where you are hosting your services.

Basically this comes down to the division of responsibilities. You’re pentesting the part you’re responsible for, but you can’t touch the parts that the cloud provider is responsible for. You just have to take them by faith, as you said.

Antti: Yes. You have a look at the PDF provided to you by an audit company and then you decide that yes, I trust this.

So how aware are companies about the ramifications of sharing this security responsibility with the cloud provider?

Antti: Well, many companies might not actively realize that. The same pattern actually turns up in software development, where they use a lot of third party dependencies. They are just essentially blindly trusting that all the software they are pulling into their own product does what it says on the tin.

It’s open source. I’m sure somebody has taken a look at it at some point.

Antti: Yes. In most cases somebody has. But whether or not somebody has changed that source code afterwards is then another thing.

Or just written an exploit.

Laura: Someone made a pull request and nobody merged it. (Laughing)

Antti: Yeah. Although I have a feeling that almost all the firms that are kind of “cloud native” or start using cloud services from the beginning, they are very, very aware of these things. And I think that public cloud providers are doing an excellent job in actually educating people about the responsibility split and all this stuff. So I don’t think it’s that rare anymore, that people would be completely in the dark.

So we’re not seeing a lot of traditional companies that are sort of moving to the cloud, and now there’s this firm belief that “It’s in the cloud, somebody else has taken care of it. I don’t have to worry about things so much anymore.”

Antti: I think that for many companies who are doing the leap into the cloud, it’s actually the other way around. So they are afraid that now they don’t have anymore control.

Laura: People are still a little bit hesitant. They’re not sure, like, “Okay, some big company is now in possession of my data and I have to trust them with everything. Which is weird also, I think, because you can always encrypt your data even when you’re storing it in AWS and you can also be in possession of the encryption keys. So in that sense you can have also this, hopefully maybe, the ease of mind that “Okay, I am truly in control of my data.” It of course comes down to trust every time. So you have to also trust the providers you’re using, whether they are cloud or a traditional data center.

But is that trust well-founded? Like, what would you say are the most common reasons that cloud security breaches happen, and are the problems typically in the responsibility of the cloud provider or the customer?

Laura: To my knowledge, I have not heard of anyone breaching, for example, AWS or Azure data center and, you know, gone there actually and from that hardware gotten any data out. So when the breaches happen, I would say it’s a human error or it’s a misconfiguration in that specific cloud provider, like the way you build your application or just you know, regular vulnerability in your application that somebody exploits. So in that case it’s kind of the company’s fault who built that software in there.

So we’re not seeing a lot of mistakes made by the cloud providers.

Antti: Well, would they tell us even if they had any breaches?

Would they be able to hide? Like, if there was like an epidemic problem in the security of a cloud platform, wouldn’t that be discernible to someone?

Antti: This is one of the key problems that we have in the risk analysis for information security. There’s not enough data to go around, that you could actually do any sort of statistics for example, of how probable it is that I’m going to get hacked, or something like that. Companies don’t willingly disclose information. Some regulations are place that try to force you to disclose that, but even all that information doesn’t end up in the public domain. It might only be reported to the authorities.

How have cloud services changed the way we develop software and deploy infrastructure?

Antti: Yeah, that’s a big and very good question. I think it’s having a tremendous effect right now. So what we are hearing about is a trend or a buzzword called “cloud native,” cloud native architecture, cloud native computing, that utilizes the aspects of the cloud to make it easier for development teams to do operations as well.

Laura: Yeah, it does change also the roles of people. So maybe at some point we don’t actually need this kind of like, when you think of sysadmin, just sitting on the servers and doing configurations there. You can actually have your whole infrastructure as code so you can deploy your infra from your code.

Antti: Yeah. So what that means really is that you have a text file that describes what your cloud infrastructure is looking like, and then some robot automation comes, picks up the text file, and then make sure it looks like that. And if there’s a change, it will then implement that change for you.

So you basically you saying this is what it looks like, makes it so.

Antti: Exactly.

That’s magic.

Laura: I think it’s very beautiful because then you know exactly what you’re deploying, you know exactly what’s going on. And that’s the beauty of cloud. And that’s the beauty of automation. And not only that, but you can actually build your own tests around it. So you can actually, well, test, for one, the functionality of your software. But also if you want to take that a step further, you can also apply security testing in that as well. So I think it’s very beautiful.

Antti: And now that we have even more plumbing in the cloud, on the platform as a service, so to speak, service meshes and everything, you can actually describe very intricate network layer configurations, for example, in those files and then just get it applied. Stuff that would be a nightmare to maintain manually.

Like you said, cloud nativity is a buzzword you hear thrown around a lot. For the purposes of this conversation, when we’re saying the cloud, we’re talking about applications that have been developed to be cloud native from the word go. Is that what cloud nativity means?

Antti: Well, I’ve read at least three different definitions, like a semi-formal definition of what cloud native means, but in a sense it means that you have your applications or workloads that you want to run. You package them in boxes called containers with all the dependencies that they need to run. And then you have some sort of an orchestration system that you run them in, and that’s the platform as a service typically. And that gives you a lot of security benefits already at this stage, even if you wouldn’t go into the actual architecture of how your application is laid out.

So what kind of benefits, what are the implications of this kind of approach?

Laura: Well, for one, the benefits are that your services, they don’t have to be this huge big system. You can have these small services like microservices for example, that you have an easier time to manage. You can have an easier time deploying them, you have an easier time scaling them up and down depending on your needs. So if your online store suddenly gets a ton of visitors, you can just scale up the amount of containers you’re running and then suddenly you are able to actually handle all those customers instead of the web shops just shutting down under the load. So that is like the availability benefit at least. And when you talk about containers for example, if you’re doing it right and you are in control of the images that you use for deploying these containers, I believe you can make quite secure solutions, because you can isolate these services also. You don’t have to run every service on the same server. So if one of those services, somebody finds a vulnerability in it and can run their code through it or somehow exploit it, their impact can be limited to only that one service and that one container.

Antti: Microservice architecture is one of the building blocks that’s usually mentioned in conjunction with cloud native. And for data breach avoidance, that’s actually a really interesting pattern because you will require all your users to go through a very well-specified API that’s hopefully very robust and tested. And each microservice will also own their own data and they won’t offer any sort of like backdoor access to the databases, for example, that somebody could use to dump the stuff. So they would have to do that through the API. So if you have like this sort of chain of microservices, one service calling another one, and when you even lock down the network connections between those, you end up with a pretty robust basic architecture. That’s one of the key things there.

What about the sort of dynamic web between all these microservices and things? You’re sort of creating this moving entity, this Hogwarts staircase that’s always in motion. Does that make it harder for the attackers to sort of figure out what’s going on and where to go, things like that?

Laura: Well, I think for one, if you’re running containers and your applications are in containers, the lifecycle of a container may not be that long. And you may not even use a container. You may use, for example in AWS a lambda, or Azure, you may use an Azure function, to have the serverless functions that operate as your API or they do calls in the back end. So there’s actually not that much to exploit when you don’t have this, it’s just alive for that amount of time that you call the function or the lambda, unless you specify that this will stay alive for a longer period of time. So there’s not much to attack there, in the end.

Antti: Well, at least the attacks have to happen immediately.

Laura: Yeah.

Antti: I mean, you cannot just like put up house on somebody’s server because the server is going away very soon. But it doesn’t necessarily do much for like a traditional SQL injection. If you’re vulnerable for that, it doesn’t really help, if you have a kind of ephemeral node.

Yeah, whenever you spin that up you’re still going to have the vulnerability.

Antti: Exactly. And you can just exploit in a second.

Absolutely.

Laura: And when it comes to lambdas, well, I personally have done some research and stuff like that with them. So of course there are ways of exploiting stuff if you are running vulnerable code as lambda, like naturally there are ways of gaining persistence at least for a short amount of time. But it’s still quite hypothetical in most cases. And if you do assessment for your code that you run as a lambda or as a function, then I think they’re quite secure.

But now that developers are running continuous integration in these cloud native thingamajigs, does that mean that the sort of gap between security person and developer is growing narrower and narrower?

Antti: Well, I think it should, meaning that at some point the developers who now can do some sort of operations as well, will also be able to do some sort of security operations. But then again, when you get to the point where you have a creative attacker that’s looking at you, then you’ve got to be a creative defender as well. And you can create a robust service, but in order to foresee all sorts of different risks, it would help if you had some background in security because then you would be able to do creative risk assessment essentially. But there’s no reason why developers couldn’t do that. So I think that what we’re going to see is security work very much transferring to the desk of the developers.

Laura: Yeah. And I think that’s a good thing as well because the developers know what they’re doing. They know their code inside and out. So when the role of security and developer, the space between them grows narrower, it makes the applications even more secure, because then the developers have full understanding like, “Okay, this is the implication if I’m going to use this vulnerable – or this old NPM module” or something like that.

So in the future, even those developers who so far have been able to sort of hide behind the security department and sort of externalize the security to somebody else, they’re going to be less able to do so, and will have to take a more of a security point themselves.

Antti: Or if you want to twist that around, it might also be that the security departments have to give developers the empowerment to do security. In my experience, most engineers, most developers actually want to do things properly. They want to do security, they just need time to do that. And this time and empowerment has been taken away from them to an external party.

Laura: Yeah. And then they still have to do the coding and they have to do the developing of the software, but they’re not given any extra time to actually implement the security features as well.

What is the main takeaway security advice you have for companies using cloud services?

Laura: Use it. (Laughing) No, I mean, I encourage using cloud, especially if you need scalable architecture, and if you just want to do things in an agile manner, I would say there’s no reason why not, unless there are some compliance reasons or something like that. But there are so many ways of enforcing security in cloud, like through the services and through running your infra as code and everything. So I think that is the future and that is the future maybe for everyone or almost everyone.

Antti: And I’d say if you are a type of company who makes software that’s going to run on a server somewhere (I mean, there’s a lot of other types of software as well), if you start new projects, try to architect them so that you could theoretically deployed them on a public cloud. You don’t have to, but then you have the option. You can still run all that stuff in house if you want.

Laura: Yeah, and you can use the same automation tools for that as well.

Antti: Yes.

That makes sense to me. Thank you guys for joining us.

Laura: Thank you.

Antti: Thank you. It was nice.

If you want to hear more about Laura’s thoughts on security issues, check out her podcast, We Need to Talk About Infosec. Antti you can find on Twitter as @AnttiVS. That was our show for today. I hope you enjoyed it. Make sure you subscribe to the podcast and you can reach us with questions and comments on Twitter @CyberSauna. Thanks for listening.