In this episode, Tripwire's Brent Holder and Raymond Kirk discuss what cloud security means today. Breaking down the different aspects of cloud security controls, they cover the technology, security implications and risks with cloud use.
Spotify: https://open.spotify.com/show/5UDKiGLlzxhiGnd6FtvEnm
Stitcher: https://www.stitcher.com/podcast/the-tripwire-cybersecurity-podcast
RSS: https://tripwire.libsyn.com/rss
YouTube: https://www.youtube.com/playlist?list=PLgTfY3TXF9YKE9pUKp57pGSTaapTLpvC3
Tim Erlin: On the latest episode of the Tripwire Cybersecurity Podcast, I had the pleasure of speaking with Raymond Kirk, and Brent Holder. Raymond and Brent are both distinguished members of the Tripwire team.
The topic that we focused on was cloud security, which is definitely a hot topic. But, as the technology for cloud is expanding, it's not always clear what people actually mean when they say “cloud security”. You might say that it's an overloaded term. What does the term “cloud security” really mean?
Brent Holder: I think about the different answers that we get from different people when we're talking to them. There's a lot of different ways that my mind goes with cloud security, but what's always interesting to me, is that if you ask someone about some of the challenges they are experiencing with cloud security, their answer will depend on their specific area. For example, if they are on a development team, but have security priorities, then cloud security is focused on making sure that their teams are correctly using their accounts, which doesn't necessarily have anything to do with the templates that are being used for the virtual machines in the environment. Then, if you ask the question of the folks in IT, they are focused on the approved virtual machine templates. Meanwhile, if you ask the question to a security team member, they want to make sure that when someone works their way around a policy, the security team can find out because it might go unreported. So, it's like a puzzle where it seems like a lot of different people are holding individual pieces, and if everyone held up their pieces together, you might be able to see the whole picture. But, depending on which part of the organization someone's in, their concept of cloud security is going to be, uh, pretty tightly crafted to their area of expertise or concern.
Tim: Yeah, it reminds me a little bit of the old adage about people who are all feeling different parts of an elephant, describing a very different animal than what comprises an elephant because none of them can see the entire animal. Raymond, what can you add about your experience with the term “cloud security”?
Raymond Kirk: When people speak about cloud security I tend to hear them talking about Infrastructure as a Service (IaaS). But there's a wider landscape than that, such as Platform as a Service (PaaS), and also, Software as a Service (SaaS). Cloud security pretty much encompasses anywhere that data is living, outside of your own data center.
Tim: We also have to tie it to a little bit of the technology evolution. Brent, you mentioned technology in there, but if we take a step back and talk about what cloud was, just five or 10 years ago, what is it today? What are the technologies involved? What comes to mind of how cloud has grown as a set of technologies?
Brent: This brings to mind the Continuous Integration / Continuous Deployment (CI/CD) pipeline, because, similarly, the CI/CD pipeline has changed over the years. Early on, it was a developer-centric focus. As more and more stakeholders try to tailor it to their specific purpose, it's been slowly changing. For example, during the Black Hat conference in 2019, there were different people whose talks were all about DevSecOps, explaining that security and DevOps need to be closely connected, or you're going to end up with warring groups. So, when I think about spinning up containers to fulfill a job for a company, an automated process just made the work happen. Over time this task had to follow certain policies. That introduces Compliance, or IT involvement, and it needs to follow the security practices. So, when I think of cloud advancement, I think of who got on the bus to shift left first.
Tim: I don't know exactly the sequence of events here, but with the concept of CI/CD, did that concept pre-date cloud? Were organizations doing effectively DevOps type integration without deploying it to cloud, or was it a practice that just came with cloud deployments?
Brent: Anytime you talk about cloud, you're going to end up in the hybrid zone. Some companies have totally valid reasons that they absolutely, positively, have to keep everything on premises. Conversely, you have people who are seemingly born in the cloud, using the technologies to race for advancement, who are just completely in the cloud. Then, there's the whole spectrum in between, because of the kind of timeline of this. As the whole concept of continuous integration and continuous deployment came out, there were probably at least some people who were getting very cloud-centric, and some who were practicing CI/CD strictly on-premises. I think that they tie together though, in terms of the purpose of the efficiencies gained from moving to the cloud, and why people move workloads to the cloud to begin with.
Tim: Yeah, it's interesting, because the more that we talk about cloud, and cloud technology, and the way it has evolved, it is not a separate entity from the on-premises capabilities. More and more, cloud security has to address on-premises and use cases as much as deployment in the cloud because of the hybrid nature of most enterprises.
Brent: Yes, and that comes back to the “who are you talking to” part of it. Unfortunately, a lot of times there are people whose area of expertise or focus might have them siloed into one function, such as being the “on-premises data center windows person.” And somewhere else in the organization, a different person has to care about cloud. If you ask the person who's been in the midst of moving workloads to the cloud for the last five years for that company, they would have a totally different perspective. If you zoom out, and you can see that it's all hybrid, you rarely see a situation where someone has a full personal grasp of both the security needs in the on-premises infrastructure, and the security needs in the cloud infrastructure.
Tim: Yeah. That's an interesting way to look at it. Raymond, does anybody actually have the ability the whole picture from a cloud perspective, or is it just a collection of individual specialized expertise?
Raymond: Well, I think that's the challenge. So many organizations are looking to gain full visibility to see the entire environment, and what state it is in. Whether or not that problem has been solved completely is still unsolved, because there are so many new technologies that are coming into play. Even as far back as 2014, it was reported that the average company was using somewhere close to 300 different SaaS applications. The landscape is ever-growing.
Tim: That brings up an important point, which is, as we talk about this big bucket of things that we call cloud security, there's a spectrum of capability where an organization can lose course. Some organizations have reasonably good visibility, but I want to touch on the things that are the blind spots. So if I'm one of those folks who has only a partial view of what I am like as an organization, what elements am I missing that I should be more aware of?
Raymond: Oftentimes, a lot of the focus is on the workloads. A company may be relaunching production applications and making sure those things are secure. But, they need to be reminded about some of the other SaaS and business critical systems that are out there that the organization may be using that they may not have visibility to. Applications such as Human Resources tools, and sales tools that also contain highly sensitive, important information to the business that the average IT security person may not necessarily consider as cloud security.
Brent: To tie it back to the CI/CD thing, some of the tools that Raymond mentioned can be actually part of the work being done. Data can be moved from, or to a sales tool as part of an automated process. So, to literally do the work, some of these SaaS tools are part of the same chain. Everyone's all tied in together. That visibility takes on a little extra importance when you've bought all the different integrators and modules that tie it all together and make it do the work. Yet, I think that one of the biggest pauses that I hear in user interviews, is when we ask people about using security. Most people would say yes, and they are, and that is not technically untrue. However, what they're saying is that they switched on the service that they consider “security” in the provider’s options, but they don’t know that it's working, or how to judge its effectiveness.
Raymond: Turning on the security feature is one piece of it, but I think we've all heard about the shared responsibility model. It's important to remember that if a software manufacturer pushes out updates and patches, it's actually up to the company’s administrators to manually activate those updates. There's not a “one-button click-all, and then forget about it” entity in these SaaS environments.
Tim: Those are a couple of interesting views. Just to clarify the idea of a shared responsibility model, the point there is that the provider is responsible for the security OF the cloud, and the customer is responsible for security IN the cloud. So, customers who believe that the cloud provider is going to supply the security for customers’ data and workloads are going to be disappointed.
Raymond: Yeah. 100%. As we all learned when the pandemic started, even with all the remote meeting tools, there are configurations within those, that, if left at their default settings could potentially be risky, such as, making sure that recorded meetings are set as private. Similarly, you have configuration settings in a cloud environment, like making sure your S3 buckets are secure. There are also some of those same controls in some of the third-party SaaS applications that organizations are using.
Tim: Yeah. You point out an interesting contradiction there, that a lot of ways people shift to a cloud provider, whether it's SaaS application, or a platform, because those providers take care of the administration of the backend infrastructure. But, but at the same, time customers request flexibility in terms of configuration. For example, they may not want to want automatic updates. This can create the administrative burden that they were hoping to escape by shifting to the cloud, and it also adds complexity, which certainly has a tendency towards security implications.
Brent: There's also the idea that, with any compliance framework, you may get into a situation where a company can be advised of the best practice; what they should be doing. But in some scenarios, a customer will choose to fail at that advice because they are doing something for a specific reason. You have to waive certain things. That is the inverse of the security services or tools that are enabled by cloud service providers, or SaaS providers. They give you the tools to do certain things, but they're also giving you the flexibility to do things your way. Some people mistake a service as a managed service. There isn't someone sitting watching on the other end to make sure that everything is being done as securely as possible. They're giving you the flexibility you need, to use their solution to solve your business problem. And that includes letting you do things in a way that, if you're not careful could make a company vulnerable to a security compromise.
Another blind spot that's top of mind for me lately, is translating the concerns of infrastructure to software as a service. The move from traditional infrastructure, such as physical and virtual servers to containers. They are still part of your infrastructure. They are still handling parts of the workloads that may be under the purview of your clients, like payment card security, things like that. How do you do the same work to ensure that those workloads are compliant, or secure for containers? It gets real muddy.
Tim: Yeah. The containers are supposed to be immutable, but the configurations will ultimately determine the effectiveness of that immutability.
Brent: Yeah. But, we know that everyone does not do it perfectly, following best practices. For example, even though it's best practice to have the root file system as the container itself immutable, you still have to have state change. The image needs to change for your website, and you don't necessarily want to spin up a whole fleet of containers just to make these little changes like that, so that’s where volumes come in. So, having state change in a workload being handled by containers isn't inherently bad, but how much of that can you see? How much of it can you see, to determine whether the change was intended or not? It's a, it's a pretty murky terrain right now.
Tim: Yeah. That's interesting. We talked a lot about technology, and security implications, and blind spots. But, what we haven't touched upon yet are some of the landscape risks that cause us to worry about cloud security. What's top of mind, in terms of the risks of cloud technology stuff we've talked about so far.
Raymond: We have seen ransomware in the news a lot. But, there is also data breaches, leaking sensitive information, and even the whole crypto-jacking and the rise of that going on as well.
Tim: Let's talk about crypto-jacking, because many people may not be as familiar with that as the others that you mentioned. Crypto-jacking seems like something that is a little bit more cloud specific.
Raymond: Definitely. To define it, crypto-jacking is when some bad actor out there gains unauthorized access to your cloud infrastructure and resources, and uses that access to launch software that enables them to mine for digital currency, which is, effectively, making them money, but costing the compromised organization money as well by using their computing resources. In a cloud environment, the customer pays for processor cycles, and since mining crypto-currency is processor intensive, the crypto-jackers will use a target’s computing power to attempt to create new currency. The criminals try to make sure that they don't raise any alarms. They make sure that while they're operating in a company’s system, that things look relatively normal.
Brent: Crypto-jacking reminds me of when people would get a video game to work on some new piece of technology that wasn’t designed for that purpose. It seems like that's the new challenge. They drop the mining software right into a writeable S3 bucket, or they replace the base image name in a container definition. The container does otherwise everything you expect it to, but now, it goes into production with this added bonus of surreptitiously mining for crypto.
Tim: Yeah. And if the criminals are successful, the customer doesn’t see any material change in the environment, except that the cloud cost suddenly increases. The customer is effectively using resources to just to generate money for the criminal. It's arguably much more efficient than the ransomware, I suppose.
Brent: Yeah. You don't have to agree to what's being actively stolen from you. That's true. It's the whole point of the MITRE ATT&CK® Framework of evasion techniques. I was looking into MITRE ATT&CK Framework, versus the CIS Controls, and realized that MITRE is the Red Team view, and CIS is the Blue Team view, but they are both trying to solve the same problem.
Tim: Yeah. That's true. That's a good analogy; a good way to think about it.
Brent: For all of these technologies that are out there now, and the spread of them, and the hyper-specific jobs that they'll sometimes fulfill, it's all meant to give you either that red or blue team's view of possible reasons of what may be going wrong in your environment. If you start to be able to catch these little defense evasion techniques, or catch these moments of unexpected running processes, and things like that, that's where you can, you can save yourself money and time.
Tim: Excellent. Thank you, Brent and Raymond, for joining me. It was really interesting, covering some interesting topics, and providing a little bit more clarity, and a little bit more about cloud security, and what it means. Thanks.
Are you finding it hard to assess the security level of your cloud accounts? Try Tripwire Configuration Manager for free for thirty days. Test drive it with your own cloud accounts or use our sample data to see what simplified cloud monitoring looks like in action.
Learn more here: https://www.tripwire.com/products/tripwire-configuration-manager/configuration-manager-free-trial
