Top 3 App Security Threats, Hybrid Cloud Edition -- Virtualization Review

Top 3 App Security Threats, Hybrid Cloud Edition

By David Ramel
04/11/2025

Brien Posey, a well-known freelance technology author and 22-time Microsoft MVP, recently explained how enterprises can protect themselves against application security threats in hybrid cloud environments.

Posey shared his expertise in an April 11, two-part online summit presented by Virtualization & Cloud Review and sponsored by A10 Networks, a cybersecurity and networking specialist, titled "Level Up Your App Security in the Hybrid Cloud Era," now available on-demand replay. In his session, Posey explained to the online audience what organizations can do prepare for the top threats across hybrid cloud implementations. While he dove deeply into some 15 threats, his presentation was too chock full of information to be presented here. So we'll just summarize Posey's top 3 threats, and the rest of this valuable, front-line advice can be found in the replay. Here's the top 3.

Misconfigured Services

"So the thing about cloud services is that they're often deployed very quickly, and the major cloud providers, and certainly there are exceptions to this, but the major cloud providers typically do their best to try to make cloud services easy to deploy by those who aren't super experienced," Posey said.

"So if, for example, you were brand-new to, I don't know, the Amazon cloud, and you decided to set up a virtual machine in the cloud, well, what you would probably find is that it's not a super difficult process once you get started, because Amazon makes it so that you can basically click Next a bunch of times and accept the defaults, and there's very little that you actually have to enter in terms of configuration information. So you can deploy a virtual machine very, very easily, even if you've never done it before. And the same holds true with most of the services that providers like Amazon and Microsoft offer in the cloud.

"The problem with that is that the default configuration isn't necessarily the most secure configuration, because remember, their goal is to make it easy on people, and when you start adding in various security elements, the deployment process becomes more complicated.

"So the reason why all of this is important is that when organizations deploy cloud workloads, oftentimes they try to get those workloads up as quick as they possibly can. You know, we've all seen the emphasis on agility in the cloud over recent years, the idea that workloads need to be deployed like now. So if a workload is configured quickly, it might not necessarily use the most secure configuration, and there have been a number of real-world examples of this. I remember hearing a story where an organization deployed an application in the Amazon cloud and they had an S3 bucket. S3 is Amazon's object storage platform, but they had this S3 bucket that was completely open to the internet, so there were no access controls in place. Anybody who knew the IP address and the path to that bucket could access it without having to enter any sort of credentials or any authentication information. So that unsecured S3 bucket allowed anybody who had that information to go in and access the organization's data. And the same thing could conceivably happen in Azure.

"Unsecured Azure Blob Storage could also be used to exploit sensitive data. So that's one example of a misconfigured cloud service causing a real security risk. Another example might be an AWS EC2 instance that has an improperly configured security group. Now, for those who might not be familiar with the Amazon cloud, AWS EC2 is the platform for running virtual machines in the cloud and instances, just what Amazon calls its virtual machines, and a security group is just what Amazon calls the firewalls that those virtual machines use. So what this last point on the slide is essentially saying is that if you were to set up a virtual machine in the Amazon cloud, and the firewall associated with that virtual machine allowed inbound traffic from 0.0.0.0/00, which is the internet to port 22, then anybody who's out on the internet and happened to discover that virtual machine could conceivably use SSH to connect to that virtual machine. So hopefully you can see why that would be a huge problem.

"So what are some other common mistakes? Well, another potential mistake is one in which a developer spins up a test instance or a test application, and connects it to a production data set. Now that, in itself, isn't necessarily a bad thing. Developers do stuff like that all the time, and in some ways, it's necessary in order to test to make sure that the application truly does what it needs to do. The problem is when the developer forgets to put the proper access controls in place, and at that point that test app could can become a security vulnerability. Similarly, if someone were to deploy an Azure virtual machine from a template, and that template contains default administrative credentials, the use of that template could become a vulnerability at that point. So misconfigurations within cloud services, that's one of the big ones."

Insider Threats

"So security threat number two, insider threats. Now insider threats are one of those things that IT talks about all the time, but most of the discussions that I've heard and things that I've read are done in a hypothetical sense, like, 'okay, bad things could happen if we have a rogue employee,' but I can tell you from personal experience that rogue employees do exist in the real world. I have actually run into this on multiple jobs that I had in the past. Now I'm trying to be really careful, because I don't want to say anything that would accidentally divulge this person's identity. But one of the organizations that I worked for early in my IT career, there was someone who worked there, and this person had some -- we'll call them mental issues. And I'm in no way trying to make light of this or say anything disparaging, but this person had some very real problems. Let's just leave it at that.

"Well, what tended to happen with this person is that anytime that the higher ups and it made a decision and implemented a new system or a configuration change or whatever, this person would come in in the middle of the night and completely undo it and redo it their own way. And believe me when I said that caused issues. I'm not sure there was malicious intent going on, but still, when you've got a rogue employee who's undoing everything that had been done over the course of a day intentionally, that's a problem.

"Another one that I ran into was at a different job several years later, and this particular employee took action against the IT infrastructure as a way of settling personal vendettas. What this person typically would do is if they caught wind of somebody in the IT department having big plans for the weekend, they would sabotage systems that that person was responsible for, like 4 o'clock on a Friday afternoon, so that they would have to stay late and essentially mess up their weekend plans in the process. So rogue IT employees definitely exist. As I said, I've run into at least two of them throughout my career. So as you can imagine, an insider is able to do huge amounts of damage if they really wanted to.

"Now, how much damage could they potentially do? Well, think about it this way. We always talk about what would happen if an attacker were to gain access to a privileged account, and how much damage they could do. And I'll be the first to admit that if an attacker got a hold of a privileged account in an organization, they could do a whole lot of damage. Well, when it comes to a rogue employee, it's probably a little bit worse than that, because the rogue employee has something that the attacker may not and that's an intimate knowledge of how the organization does things, where all of their assets are stored, and that sort of thing.

"So if an attacker just happens to get a hold of a compromised account, logs in and has been on destruction, well it might take them a while to do a tremendous amount of damage just because they don't know their way around the system, whereas, if an employee has the same intention, they already know how to get around the system, and they know where they can inflict the most damage. So insider threats are a huge concern. And as I mentioned earlier, when I was talking about the various types of applications, hybrid setups increase the attack surface. So when you start creating distributed applications and hybrid applications, you inevitably increase the attack surface and the potential to do damage. So is this thing that you should stay away from distributed applications and hybrid applications Absolutely not. There are many workloads that are simply impossible to run on single systems. So hybrid applications and distributed applications are the norm. They're a necessity. There's not really any getting around it. What you do need to do instead is to focus on what you can do to keep those applications secure.

"So you know, I've talked about all the damage that a rogue employee in the IT department could do to your applications, but I just want to quickly mention that a careless IT employee could also do a lot of damage simply because of the permissions that they've got. Now, someone who's just being careless isn't deliberately going out trying to destroy all of your systems. But in my 30-plus years in IT, I've seen example after example after example of an employee who just gets in a bit of a hurry, or maybe they're tired or something like that, or even just inexperienced, and they click on something that they shouldn't, and all of a sudden the critical workload is offline and damage has been done. So things like that happen. So how do you defend against these sorts of things? Well, I'm not sure that you can ever completely defend against them, but you can definitely do some things to hedge your bets.

"For one thing, put strong governance policies in place. Use role-based access control, so that nobody has permission to do any more than is absolutely necessary for them to do their jobs. Another thing that you can do is put in place behavioral analytic systems. Behavioral analytic systems establish access patterns. Over time, they learn what's normal for an employee. So if the employee starts doing something really abnormal, it alerts whoever's in charge, so that way, they can be made aware you've probably got a rogue employee or an employee's account who's been compromised. Another thing that you may be able to do is put in just-in-time access. For anybody who's not familiar with just-in-time access, it comes in a few different flavors, but the basic idea is that permissions are stripped away from privileged accounts. So that way, if an attacker tries to take over a privileged account, well, there's no privileges associated with that account for them to even be able to use.

"So if a legitimate employee needs to perform an administrative action, they log in with that privileged account, and then they actually have to use the system to request permissions, and those permissions are granted on a temporary basis. So the permissions might be given for 10 minutes, just long enough for them to do whatever it is they're about to do, and then the permissions are once again taken away. So these sorts of things can help with rogue employees, careless employees, things like that."

IAM Problems

"Threat number three, IAM problems. So when we're talking about IAM, what we're really talking about is identity and access control, management. And one of the biggest issues with regard to IAM in a hybrid environment is disparities between on premises and cloud based IAM permissions. So if you're managing permissions manually. What you can oftentimes end up with is not having quite adequate permissions in one environment, having excessive permissions in another, and things just kind of being a mess. I've even seen environments where usernames are mismatched across environments and things like that. So what you really want to do is try to avoid having fragmented IAM, if you possibly can. One of the best ways to achieve that is to use a centralized identity management solution. Active Directory is a good option, but it's not the only option. Just use some sort of centralized identity management solution.

"And then the other thing that's just as important, probably even more important, is to use a tool that will allow you to manage permissions consistently, and this consistency is a theme that I'm going to be hitting several more times over the course of this presentation, simply because it is so important. So the idea behind this consistency is this, let's suppose that you've got multiple clouds that you use, and you need to apply a permission to a particular user in a particular cloud. Normally, the way that you would have to do that is to either open up PowerShell or log on to the console associated with that cloud and perform the change. Then if that employee needs another permission in a different cloud, you would open up the console in that other cloud and perform the change there. And the problem is that even though the cloud providers give you basically the same mechanism as their competitors -- or same features as their competitors, rather -- mechanism used to actually implement the change is different from one cloud to the next to the next. So what a single pane of glass tool will allow you to do is to enter your changes in one way, and then the tool does a heavy lifting. It implements the change in the cloud based on that cloud's requirements.

"So it doesn't matter if you're using Azure and AWS and Google, you can put the change in in one way, and then the tool will take care of all of the cloud-specific stuff on the back end. And this helps immensely with regard to being consistent in the way that you manage resources in the cloud. Another thing that I would recommend is to use role-based access controls, just to make sure that you're only delegating the permissions that you need to delegate, and then that falls in line with adhering to the principles of Zero Trust and least privileged access. Zero Trust is more of a philosophy than like a product that you can go buy, and everybody seems to have different ideas about what constitutes Zero Trust. In my mind, zero trust is just the philosophy that you don't trust anything until it's proven to be trustworthy, and that you verify the trustworthiness every time a resource tries to access another resource. Least privilege access is the idea that users should have access to only what they need to do their jobs, nothing more, nothing less.

Of course, one benefit of attending such events live is the ability to answer questions of bona-fide subject-matter experts -- not to mention the chance to win great prizes, which in this case involved sponsor A10 Networks providing a $300 Best Buy gift card. With those considerations in mind, here are some upcoming webcasts and summits being presented by Virtualization & Cloud Review and sister publications in the remainder of April.