Cloud security vulnerabilities can come from within an organization in the form of malicious insiders. This type of threat can originate from a current employee, past employee, partner, or others who have access to sensitive data and use it for nefarious purposes. Insider threats can be tough to manage. The following excerpt regarding malicious insiders, access control, and building secure cloud infrastructure in the cloud is taken from a live discussion titled Cloud Security Hurdles and How to Overcome Them.
The panel was moderated by Michelle Drolet, Founder and CEO of Towerwall and included Jeff Foresman, CISO and VP, Security Operations of Digital Hands, David LeBlanc, CPO of SecureCloudDB, and Martin Holste, CTO of FireEye.
Michelle Drolet, Towerwall
Security absolutely is a concern with all the different things that are happening out there — we've seen the SolarWinds [hack], we've seen the Microsoft [hack], we're living Microsoft right now, right? And I know that this group that we have here is really helping their customers not only secure themselves, but combat those bad guys.
So Jeff, I'm actually going to start with you because, really, it's all about security. There's other aspects, but you know in the cloud — cloud detection of a malicious insider — it’s even more difficult... How do you detect malicious insiders inside that cloud environment?
Jeff Foresman, Digital Hands
Whenever we talk about cloud security, we've got to talk about the shared responsibility model. And so that's what makes it difficult, is first of all, organizations have to understand what are they responsible for? What is the cloud provider responsible for?
But there are many opportunities for malicious insiders. Whether it's on the host that you're responsible for supporting, within the cloud itself and your authentication and configuration activities there, traditional logging solutions are just not real effective for detecting malicious insider activity.
And so you've got to look at what solutions does your cloud provider give you? So you know, there's some real good solutions out there from AWS and Azure to monitor what's being done within their services.
But ultimately, if you really want to be serious about detecting insider threat, you've got to look at a user behavior analytics tool. And there are good tools there that will support a cloud environment and look for malicious insider user activities.
Gotcha. Thank you very much for that, Jeff. You know, I'm gonna ask you, Martin, to kind of pipe in on that...
Martin Holste, FireEye
It comes back to traceability and understanding what's available to get from your cloud provider that will tell you who did what, and then being able to work that up the chain into actual business logic.
So you can say, okay, fine, here's a username. But what is this user? Is this someone in accounting? Is this a salesperson? And where things get really tricky is when you get — I would say — outside of cloud infrastructure and into Software-as-a-Service. Because that's where the promises that you often get from most of them — at least the big three cloud providers — really break down, and you're at the mercy of whatever Software-as-a-Service you're using.
So whether it's, you know, Salesforce or ServiceNow, or any of the other large SaaS providers out there, or even, you know, Office365 to some extent, you may not get all the traceability that you thought you were going to get that you would have if you're running application yourself.
What we [Towerwall] find because we do a lot of application penetration tests is that it's that instance, that specific customer’s instance of that SaaS application, that really needs to be checked and made sure that it's secure in the deployment and with that access control. And access control is an interesting, interesting play right now, where it was much easier on prem, so to speak. But it does absolutely present a challenge. David, do you want to address that challenge on access control?
David LeBlanc, SecureCloudDB
Well, yeah, sure. I think one of the things I’d first point out is that a lot of times people dismiss insider threats because they think they hired good people. And they may have hired good people, but they probably have hired people who are capable of making mistakes. And people that make mistakes do things that enable things like advanced persistent threats.
And so you may not be actually being attacked by an insider, you're being attacked by someone impersonating an insider; somebody that's gotten insider credentials. So when I do a network pen test, I always like to start from the presumption of that I've obtained a normal user set of credentials and how far can I go with that? And where can you get that? And so yeah, it is kind of difficult.
The cloud does give you some advantages. So it's, in some respects, depending on the logs, it's a lot harder to erase the logs in the cloud. There're tools that I have at my disposal as an attacker on prem that I don't necessarily have in the cloud. But it's more places to look and one of the things that's always difficult in responding to something like that, is you have to aggregate data from a lot of different sources. Now, you've got more different sources, and it's just made that challenge a little harder.
Gotcha. So that, I guess, kind of dovetails into another question - what are some of the key points for building secure cloud infrastructures? Can I ask you, Martin, that question?
Martin Holste, FireEye
...To go off what David was saying there, backups are really a critical thing. And so you're talking about logging and how it's harder to delete logs in the cloud, I would generally say that's true. I think the caveat is - and this is a fundamental thing that everyone needs to get right the first time when they go into Cloud - is to make sure that every account that you have, whether you're depending on the cloud provider, whether it's a tenant or an account, ID or project, those things need to be writing all of their logs and all their backups in such a way that they can't delete them. And they need to be outside of that account.
So let's say you're on Amazon, then you want to do two things.
You want to centralize all of your logging into dedicated logging accounts that the logs are shipped immediately from the source account into the destination account, note the source account doesn't have rights to delete them. Once you've done that, you are incredibly defensible at that point, it's very, very difficult for an attacker to remove a trace of being there.
The second thing is you need to do the same idea with backups. So Amazon has something called AWS backups, which makes it really easy to say anything tagged with you know, “back me up” or whatever will automatically get backed up. That's great. But we see attackers delete backups all the time. So what you need to make sure is that whatever system is backing that up, that those backups are also just like the logs - immutable; they're going to go somewhere that the original source can't delete.