Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole Analysts. My guest today is Alexei Balaganski, lead analyst with KuppingerCole. And we want to talk about cloud security today. Hi.
Hello Matthias. Thanks for having me again.
Great to have you again and ask me always discuss great, interesting cybersecurity related topics. This is something that we want to continue today as well. So cloud security, this is a challenge that we have been covering at KuppingerCole for quite some time, because all organizations are more or less interested in moving parts of their workloads, parts of their services into the cloud, but they are giving away responsibility. They are giving away control there. And the topic for today is what are the questions that you should ask your cloud service provider when they are providing you services? Where are the areas of problems that we have to look at when we look at cloud security from your experience?
Well, first of all, Mathias, let me correct you a little bit. In fact, when companies are migrated into the cloud, they are not given the way their responsibility on the contrary, they are getting more responsibilities. They are unfortunately, often not even thinking about this is exactly the topic we are going to tackle today. Okay. So as you mentioned, yes, everyone is now moving to the cloud. It's been an ongoing trend for years. And of course now it's only amplified by this whole work from home situation. And yes, usually when companies are moving to the cloud, they can cut costs, I think kind of scalability supporting remote workforce and so on. They are usually not thinking about security or even the horse. I would argue. They are thinking that the clouds are automatically becoming more secure, which is unfortunately, very far from the first of all, or as we just mentioned, responsibility still remains with you or the company, no matter what or how you migrate to the cloud or on this notorious shared responsibility model or which every cloud provider is usually sticking to explicitly define that, regardless of how you're using the cloud, whether you're only renting infrastructure or you are using SAS for example, platform, or you are still responsible for your data in the cloud.
So in truth of GDPR, you are still data controller, even though you do not actually have any control over the data anymore, because it's been stored in the cloud, but you're still responsible for it. If you remember all those high profile data leaks and breaches, when someone discovers in our protected three buckets on Amazon cloud or encrypted data by somewhere else, nobody's punishing them or them or Azure or any other cloud provider, it's always the company neglected to protect the data in the cloud, be fined or otherwise responsible.
What is then what a customer has to look at when w when they are talking about responsibility here, I have to correct that stuff. You're completely right. So it's not that you're giving away responsibility, but you're giving away control. So you need to make sure that the cloud service provider, who does something on behalf of you is really doing that the way that you require him to be. Is that better?
Right? So many companies do, or, I mean, they are in a way, correct. If you mean that a cloud provider can just by the matter of expertise and scale and experience, be more secure than their old school on prem data center, but it doesn't automatically mean that this security of their cloud translates into security in the cloud. And the course, it absolutely does not mean that somehow automatically translates into governance and compliance. All of this is still your responsibility of the company and are on a very abstract and conceptual level. This whole idea of extending your it governance into the cloud is perhaps a topic to discuss for a few hours. And I know that we have quite a lot of research on our website or the topic in today. We are just talking about the key buzzwords, a female, the key things to look for the key keywords, and I would argue, or that are one of the most important things to look for is security by design.
So yes, every cloud provider has its own infrastructure security. Obviously this is our responsibility. This is part of the contract, and this is of course covered by many compliance regulations. And again, they are secure in their infrastructure. It doesn't mean that they will automatically secure your data, hosted on that infrastructure, besides obvious misconfigurations and negligence exploited, and so on. There is always a problem of a nosy, for example, when, just because of, you know, Emory a public cloud and a very multitenant environment, that can be an opportunity for another customer using the same infrastructure to sloop on your data. Sometimes it's just, unexploited like our bark in the Intel processors, Spectre, and meltdown, and other, they have so many names for them. Some customer or law major cloud providers had to page infrastructure, reducing the performance and losing quite a lot of money during that, but who knows how many unpatched on the ability for there. And of course there is always the possibility that and wrong admin of the cloud service provider would Snoop into your data unless you have specific explicit measures in place to prevent it.
But when you mentioned security by design, that looks very different depending on the actual deployment model that you're looking at. If it's infrastructure as a service that you're using, and you're running your own systems on top of that parts or large parts of this security by design approach is in your hands. And again, in your responsibility, the more you move towards software as a service, this also moves more over to the cloud service provider while you retain responsibility, they are in charge of maintaining this correctly, right?
Oh, again, security, security by design is not a technology. It's not a product, it's not something in which you can just ask a cloud service directly. Like, Hey, I use secure by design. And even they say, even if they say yes, how do you verify if it's clean? And obviously it's all about the mindset. It's all about the architecture. So secure by design somehow imply that you will design your hardware and software architecture in a way that security is a high priority from the very first design step, right? So it's sort of, bolt-on, it's not a later edition. It's not the gate installed in the middle of an empty field. It's really something which was being built directly into Emery layer of a cloud infrastructure, for example. And of course your part of your cloud project, like if it's a software or a database, it has to be just as well designed with security. When you design in mind, it involves lots of specific technologies or network isolation or on the cloud infrastructure level. For example, if there are some certain hardware based isolation measures in place or at a certain cloud provider, which would allow them to claim, Hey, our admins have no physical opportunity to slip into your data because they are fully physically isolated from your instance, running on the cloud. That's a huge step towards security by design, but not the only of course,
Right? So we've talked about security by design. We've talked about this concept of shared responsibility. What are other areas that we should look at when w where the issues arise and where we need to ask the right question?
Well, the problem of course is that secure by design is something which you would have to start thinking, okay, I want to say a cloud service provider would have to start thinking about 15 years ago. I think it was 2006 when the first cloud service provider was officially launched to AWS, right? It would be almost foolish to believe that 15 years ago, they already knew about all the security challenges of today. So any cloud service provider, just like any other company already has a technical debt, which prevents them to claim it. Yeah, we are fully secure by design. It's not possible. The next, my feeling is therefore security by default, if you will, that even if you are only secure enough, if you are still not by far secure, like a hundred percent secure, which obviously isn't possible at all, but if you are in theory secure enough, it still doesn't translate automatically that Emory customer using your infrastructure will be secure automatically.
If some are security measures and controls are only optional and the customer would have to enable them manually. And first it would have to find out that those controls even exist. You are not secure by default. There are so many problems with S3 buckets on Amazon, for example, which for years have been leaking gigabytes and terabytes of sensitive data. And because even though they already have so many security controls, they are almost Nemo enabled by default because admins simply forget to enable those controls. So secure means that all those controls are not just available, but they are in fact enabled as soon as a new customer stops using the service, they are configured according to current best practices, they are updated accordingly when you derive and so on. So it's continuous process. And again, it's something which you probably have to trust a cloud service providers claims involved because there is no written standard, which would say, yeah, I'll be certified that this particular service is secure by default. You have to find out, you have to ask explicit questions. Like, does your database as a service come encrypted by default, is it possible to somehow disabled admin password and open your database to the world? And so on, these are all the questions, really important ones, right? So security by default for, for,
To make, to put it easy for me would be this all as the status for starting out and opening up what you do want to open up. And everything else is secure by default is locked, is denied by default. That's one of the
Key factors in that. Yes, you're absolutely right. Of course not only denied by default. There are so many against, there are so many specific technologies we can apply it, the most important takeaway that if there is a security control available, it shouldn't be on by default, right?
In an earlier episode, we've talked about a security from the cloud as a service when we're moving into the cloud, that seems to be a perfect fit there so that you have this level of security that we talked about earlier, also for the platforms that you use in the cloud. Is that a thing?
So locally, I mean, in a way it's the same old school or layer security approach that defense in depth, which was already popularized by, I think ancient Romans, right? Even before the cloud. And the point of that are usually a cloud service provider has their own pretty developed and large ecosystem of technology partners. So a cloud service provider on themselves will probably hesitate to offer a broad range of security tools for you because they will say a competition. So it stands. They will refer you to the partners, third party security providers. And it's up to you to find out which third party security tool is the best for your purposes. Again, the cloud service provider is interested in encouraging you to use as many of those tools as possible because obviously that will bring them more money. And of course, it's eaten your interest to do completely opposite, to minimize the overlap and redundancy of your security controls. And you'll probably refer our listeners to one of the earlier episodes about the concept of security fabric, because that's exactly what we were talking about in that episode. I mean, you were talking about with your guests, right?
Got it. So many cloud service providers already are in a situation that they provide instances of machines of free buckets, whatever, in a highly automated fashion, and when they are doing that, that, that suggests to me that implementing security, looking at threats, reacting to threats is also something that could be, or should be automated as well. Am I right?
Yes, absolutely. I mean, the whole idea of migrating to the cloud is to offload your manual administrative effort to someone else of the obvious the most old school approach is to find the managed service provider. So basically to let other people do it for you, but even though other people have limited capability, and since we are hiring so many new threats or insert attack vectors, and just kind of billions of security events daily on a large scale, humans just can't keep up. So some kind of intelligent automation is definitely needed. Obviously the whole machine learning and AI is a huge topic. Now that is the problem with all solutions is that they are still not quote unquote, automated enough to work without a human in the loop. Yes, they will minimize some tedious menial labor. They will provide some decision support for the human analyst, but the human analyst still has to click a button to make a decision.
This is of course automation, but in my opinion, this is an evolutionary dead end because as the cloud continues to grow, there won't be enough humans to run it security sooner or later, we will have to be looking for completely autonomous as opposed to automated approach towards security, meaning that a system, a service or an application should be able to defend themselves without any human involvement. Unfortunately, until we are in this whole holy grail of general artificial intelligence in reality, which we probably won't have, you know, at least 10 years from now, we have to be content with a very narrow focused specialized solutions. There are some products on the market. For example, the company called Darktrace makes an autonomous email security fellowship, which at least claims to defend your company from email based threats, without any human enrollments in seconds, instead of hours or minutes, there are some interesting developments from Oracle, for example, will be their database products. But then again, north are point solutions, which are great when I was applicable, but there still are kind of having problems with scaling to other types of security vectors. So this is more of a material for future developments, but still it's already the right time to ask those capabilities from your cloud service provider,
Right? In an earlier episode together with our colleague, Annie, I've talked about the, the issues around AI and machine learning and all the topic of explainability and reproducibility of results. That is also something that comes into play. We cannot dig here into that as well today, but I think that is also something that you would not to fully rely upon them and an algorithm on a trained model, which you do not really know why it behaves today, the way it does, and tomorrow, maybe a bit different. They might be good reasons for that. And that might be explainable, but you're not in a situation to really check that afterwards
Problem here in that many
People tend to think about security as purely a reactive process. Like, okay, the IB in the text let's do something against it. It would be great if AI can do that. But many people have trust issues if you just mentioned, but our security isn't just about reaction, right? Proactive security is just more important. It's just as important. If not more, because if, for example, you have a database in the cloud, it has to be pitched. It's still a software product run by someone else. The question is, do you trust that a human engineer at your cloud service provider, we will do that for you. Maybe they'll forget. Maybe they have different plans or like to do it by the end of the month, or would you rather allow a tiny, but relatively smart specialized AI to do the matching for you? Oh, this is that kind of autonomous behavior we are looking for.
Right. Okay. Got it. You've already mentioned that this is a topic that we cover in depth in our cyber security area. And of course you are an active author there, especially when it comes to recovering the solutions, though, it's highly recommended that our audience just goes to our website and checks out our blog, posts our research and gets in touch with you or just the team to ask the individual questions. But if we close down this episode today, we have shown the areas where some of the issues arise from and where we have to look at, but what would be the questions to ask your cloud service provider as a, as a recommendation, if you have not already done. So do it now. And if you are just signing a new contract, make sure that you ask these questions. Do you have a few takeaways for our listeners?
Well, obviously the very first thing is even not the question to the CSP. It's the question to yourself rather, like, do I even understand that other cloud security does not come automatically? It probably won't be included in a quote unquote default cloud package. It's just something that you have to actively look for yourself thorough. You just have to know all the problems that challenge exist, and you have to actively reach to your cloud service provider and ask, do they have some kind of certifications because of course they will probably have an SLA for you. They will probably have some clauses in the contracts, but have they ever been tested and enforced if they were through a lawsuit, for example, have they been tested in the real life scenarios? Not necessarily. So ask for independent certification or attestation that a specific syllabus is actually implemented according to all the standards and compliance regulations.
And that's an important point. You have to ask about MRA service separately and kind of blanket claim that would say, okay, our whole infrastructure is compliant and therefore our service XYZ is compliant by default. That's not true. And of course, as I mentioned, you will have to ask, are there any tools available for the customer to deploy how they are configured as the owned by default, or they mean updated according to the best practices, where do you get the guidance for deploying those controls? And so on? Basically it would probably be very difficult for you to do it on your own. And of course the cloud service provider is there to support you, but they won't do it just because they feel generous. It might be a separate service available for a separate fee and all those assessments and checks. They have to be a continuous, it's not enough to ask once, put the check box in your compliance form form and forget about it. I think the threat landscape changes daily. Auntie probably only around your compliance checks yearly. Some of the gaps are huge, and of course you should be out there looking for all the latest, interesting developments like the autonomous tools, AI machine learning, maybe even blockchain. There are so many interesting stuff available on the market nowadays. And we exist to learn about this and to tell our customers what makes sense and what doesn't
Right. And I've had two episodes already with our colleague Paul from London, and we talked about privileged access management. I assume that that putting the, the keys to the, to the cloud infrastructure, to the software as a service that you're using. So the say Salesforce or whatever application you want to look at also into an privileged access management system that is adequate, and that really serves that purpose or that this main entrance, this key to your kingdom as well-protected right.
It's really interesting that you've brought up the topic of privilege management because this is arguably one of the most under appreciated things about the cloud, because the cloud engineers, the cloud administrators, they are just as well privileged people, privileged accounts, which have, or potentially have full access to your data hosted on that cloud infrastructure. So of course they have to be incorporated your corporate privilege access management strategy or whatever solutions you have deployed because if your service provider doesn't have this kind of opportunity for you to control their privileged access, you know, end up like Twitter, probably remember though, that Bitcoin DeMarco of Twitter, of the recent days with high-profile accounts, right? Yeah. It all has happened because they are internal employees had unchecked access to any Twitter account and they were able to modify the settings or even the right tweets on their behalf. And of course, as soon as a hacker, somehow gained access to that tool, the hacker was able to move the same uncontrollably and check it. And this is the highest preeminent access to sensitive data in the cloud. Imagine what would have happened in this world? Well, let's not name any name, but if this were your cloud service provider, it is a possibility. And if there's something that you have to actively think about and be prepared for, right? So
To sum it up, we need to make sure or everybody has to make sure that they have a full understanding of the security situation that they want to have for their cloud. You don't need to make sure that they have all the technology and the processes in place that are required to achieve this level of security. And that you have also reliable assurance, reliable proof that this security is implemented on a daily basis. You've mentioned certifications. I think you you're talking about something like C5 in Germany or a socket tool certificates when it comes to the U S so this is the type of stuff that we should aim at looking for when also evaluating in the first step, the quality of our cloud service provider, independent of what we all have to do.
Yeah. I guess that's a pretty nice summary and the last or a major takeaway, just let me remind you that in the cloud, no matter how you are using it, no matter how much you pay for it, it is still your responsibility to secure your data. And it's still your responsibility to bear all the consequences of when data breach. So you have to be prepared for that. Okay.
Nothing to add from my side, we, we need to make sure that we live up to this responsibility. Thank you very much, Alex, for joining me today, looking forward to having you again. Cause it's always last to learn here. Thank you very much, Alex.
Thank you. Bye bye. Bye
