In the cloud world there are different levels of operation that can be created. The simplest form is basically an instance, which can essentially be a virtual machine running an operating system and functioning like a regular desk computer for all intents and purposes. However, many folks want a far more complex operation that can run libraries, different configurations, mobile-supporting applications and more. When this occurs, a container is used instead to hold all the related pieces together with the associated virtual machines that run them.
Contents
Containers Work Too Darn Well
Clearly, one of the biggest benefits of containers is the ability to use them for multiple instances at the same time, which can be doing different things within an infrastructure with multiple users. Secondly, containers can be isolated and separate from the machine they are running on and essentially “living within.” That second part provides a nice security feature where an environment can be built usually without worrying about compromising one’s core network. A common application would be a neutral zone where vendors and contractors operate with a company and its files in a container but they have no access to the company’s underlying core network supporting the container. Finally, containers help support the third big advantage of scalability; lots of template VMs can be spun up with a container and associated configurations kept inside.
From a maintenance perspective, containers make cloud management far more synchronized and easier. A network admin can proactively push updates that affect all the containers used at the same time instead of having to update each one individually and possibly missing a resource, creating a security gap with needed patching. Containers also help with redundancy, providing the capability of mirroring easily within a cloud environment and copying to two, three or even more synchronous protection systems.
A Sitting Time Bomb
Given all the above, many companies have moved whole hog into cloud container architecture, no surprise. 8 of 10 businesses using the cloud indicated in surveys active use of containers, up from almost 6 out of 10 just four years ago. So, the technology is pretty much a standard mode of operation for cloud networks. That also makes the same a primary target for cybercrime as well, since the most common architecture is what works on the most targets. The proof is in the numbers; more than 9 out of 10 respondents have seen their containers attacked in some form or manner digitally.
Azure container instances represent a very juicy target for cyber criminals because they tend to concentrate on critical assets. Given their advantage for aggregating tools, databases, configurations and more, a hacker inside a container could arguably have the keys to the kingdom, at least in terms of whatever is in that container. While a core underlying network would likely not be automatically compromised, the amount of information possible in a breached container could definitely be a significant asset loss, depending how containers are used by a company. Further,some hacks are now allowing cross-container breaches as well.
Propagation is the Most Common Illness
In many situations as well, the breach of Docker, AWS or Azure container instances is not necessarily outright immediate damage. Far more often the goal is monitoring, surveillance, information collection and capture and stealing of intellectual assets that can then either be sold on digital black markets or deconstructed and effectively stolen, i.e. misappropriation of trade secrets and contact lists. If nothing else, as well, a breach easily makes it possible to seize and hold the container hostage for ransom if an unauthorized encryption tool can be injected into the container to lock it up from the primary owner’s access. This approach is not nearly as successful as many cloud providers have an overriding administrative back key to get into their client containers, but if the data within is encrypted then it can be a total loss absent a ransom payment (another reason why redundancy matters so much, especially when it is so easy to implement in a cloud environment).
The most basic defense for a container and remote access to the cloud tends to be an SSH protocol socket that provides basic encryption. This is a standard for any kind of network and Linux-based network access. In one test, however, a honeypot container system was put out to the public and didn’t last more than 24 hours before being attacked. Worse, it was compromised in that same time window and used to attack other systems. Again, as noted earlier, the purposes vary; one attacker used the system as a proxy front to attack social media platforms. Others tried to use the resource for illicit crypto-mining or running scam operations with the host container as a front, possibly taking the blame for an actual crime and allowing the thief to stay undiscovered digitally.
Bad Configurations Usually to Blame
Unfortunately, even with robust defenses, AWS, docker and Azure container instances can be compromised because they’ve been configured wrong as well. While the technology is robust and reliable, misconfiguration oftentimes leaves open backdoors that savvy hackers take advantage of. The most common misconfiguration is failure to patch properly and timely. Secondly, containers are moved or created in batches usually and the full protocol of defense is not always followed, which can compromise the whole batch since they are all done at the same time, the same way. Finally, the reliance on default settings is a big no-no that hackers love because it’s basically people’s laziness that leaves an open doorway. Simple default passwords are the easiest to guess with a brute force attack, for example. There are many bots now specifically designed to find a breach, propagate inside the container, and then spread to find more breaches faster than the bot can be identified and purged. It usually requires a full system takedown and restoration to stop.
In short, Azure container instances and similar offer tremendous operational advantages for cloud networks, but they come with a lot of risks and vulnerabilities that have to be addressed up-front. Otherwise, it’s not a matter of if, but when a company will be hacked within hours or days at best.
