A reverse engineer has discovered what is claimed to be “the first known malware targeting Windows containers to compromise cloud environments,” a sentence to put any system administrator on edge.

Building on work published in December of last year on reverse-engineering Windows containers, security researcher Daniel Prizmant’s latest discovery – made during his day job at Palo Alto Networks’ Unit 42 security arm – looks to punch holes in Kubernetes clusters, and has apparently succeeded in doing so across at least 23 known targets.

“Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers,” Prizmant wrote of the malware, which he first discovered in the wild in March. “Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.”

A hidden danger
Siloscape does its best to stay hidden, Prizmant discovered, using the Tor Project network and an anonymous .onion domain to connect to a command-and-control server. During his analysis, Prizmant found 313 individual systems connecting to this server – though could verify only 23 active Siloscape victims, suggesting the malware represents only part of a broader attack.

“Compromising an entire cluster is much more severe than compromising an individual container,” Prizmant explained in his report, “as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application. For example, the attacker might be able to steal critical information such as usernames and passwords, an organization’s confidential and internal files or even entire databases hosted in the cluster.

“Such an attack could even be leveraged as a ransomware attack by taking the organization’s files hostage. Even worse, with organizations moving to the cloud, many use Kubernetes clusters as their development and testing environments, and a breach of such an environment can lead to devastating software supply chain attacks.”

“This particular malware is extremely impressive,” ESET UK cybersecurity specialist Jake Moore told The Register, “and something even infosec professionals were not expecting. However, this is exactly what we should be doing and expecting the unexpected in all walks of cyber crime. This type of attack can be leveraged into multi-layered attacks causing all levels of disruption and grief to any targeted organisation.”

“While it may seem surprising that we now have malware targeting containers, in reality it shouldn’t come as much of a surprise,” added security specialist Sean Wright. “The way organisations run their services has changed, with more and more organisations deploying their services and applications into containers, most notably Kubernetes. Criminals will adapt as well, and time and time again they have shown if anything they are incredibly resourceful and adaptive when it comes to trying to stay a step ahead.

“Additionally,” said Wright, “since organisations will likely run multiple services within a single Kubernetes cluster, gaining access to this could effectively give attackers an enormous level of access and control. It’s no wonder that attackers have their eyes on this. Combine this with the fact the Kubernetes is still a relatively new technology, many companies likely don’t have the sufficient knowledge to ensure that their instances are configured entirely correctly and most importantly securely.”

Microsoft caught napping
Prizmant had previously reported the ability to break out of Windows container boundaries in July 2020, but to his surprise Microsoft was initially unconcerned. “Microsoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server containers are not a security boundary, and therefore each application that is being run inside a container should be treated as if it is executed directly on the host,” Prizmant recalled.

“A few weeks after that discussion, I reported the issue to Google because Kubernetes is vulnerable to those issues. Google contacted Microsoft, and after some back and forth, it was determined by Microsoft that an escape from a Windows container to the host, when executed without administrator permissions inside the container, will in fact be considered a vulnerability.”

It was shortly after this reclassification that Prizmant discovered Siloscape, which he believes has been actively exploiting zero-day vulnerabilities in containerised applications, and using Windows-specific container escape techniques to gain access to the underlying node and from there the cluster for over a year.

“Users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature,” Prizmant concluded. “Furthermore, administrators should make sure their Kubernetes cluster is securely configured. In particular, a secured Kubernetes cluster won’t be as vulnerable to this specific malware as the nodes’ privileges won’t suffice to create new deployments. In this case, Siloscape will exit.”

Cyberattacks are on the rise in the era of COVID-19 and cybersecurity has become paramount to arm business-critical applications. Furthermore, new regulations have emerged to protect personally identifiable information (PII). A new cybersecurity awareness feels quite apparent throughout the tech spectrum. As a result, security policies are poised to integrate more directly within the process of engineering and deploying applications.

Nonetheless, while DevSecOps feels necessary to implement at this critical hour, it does present challenges. Primarily of which is a significant cultural shift. Uniting security and development isn’t as easy as it sounds, especially when faced with rigid enterprise bureaucracy. Plus, how can an organization incentivize DevSecOps if developers fear security tools will slow down their workflows?

The DevSecOps panel at the recent KubeCon + CloudNativeCon North America 2020 brought together leaders in the DevSecOps arena to advise introducing a security-first mindset to DevOps. Dan Papandrea, field chief technologist at Sysdig, led this super-informative panel. It featured:

Emily Fox, DevOps Security Lead, NSA
Peter Bosch, Cisco
Sunil James, HPE
Christian Weichel, Gitpod
Nicolas Chaillan, U.S. Air Force
Below, I’ll cover some of the key insights garnered from the event. To summarize, the panel identified how policy-first tools and open source initiatives are placing security controls within IDEs and CI/CD pipelines. And what will it take to get everyone onboard? It appears that transparent tooling automation, making security adherence natural and a new wave of security-aware employees will be critical components in the future era of DevSecOps.

What is DevSecOps?
First off, to get a better picture, what exactly is DevSecOps? And why has it come about?

In a previous article, we defined DevSecOps with six traits: security automation, security culture, de-siloing IT, shifting security left and security as an enabler (not a stalling force).

The KubeCon panelists seemed to echo all of these points. Fox described DevSecOps as “a term used by organizations to ensure their DevOps approaches have a security-first mentality.” To her, this means placing security automation within workload environments.

DevSecOps is something new. For most organizations, security isn’t baked into the standard development processes—it historically hasn’t been the first priority, Chaillan said. DevSecOps is changing that, adding continuous monitoring, zero trust enforcement and reducing the overall attack surface.

The move toward continuous release is also an impetus for DevSecOps. “Our cadence of delivery has been quickened,” said James. All organizations now feel pressure to deliver value to customers rapidly. An interesting byproduct of building security-first, he said, is “the ability to create the consistency and speed with which you can actually offer these capabilities.”

Another cause for DevSecOps is the sheer imbalance in the workforce. On average, the number of developers far outweigh the number of security folks, noted Bosch. So, DevSecOps could scale security across an organization more effectively than human power could.

Bosch also is hopeful DevSecOps could put an end to time-consuming bureaucracies stalling an agile security process. “Developers used to write code and wait for free months to open a firewall.” This may have been standard operating procedure decades ago, but in the age of continuous everything, enterprises must evolve how they handle IT security policies. “By uniting security with developers, we bring speed, robustness, avoid OWASP issues, and build applications that better contribute to the bottom line,” he said.

Finally, embracing DevSecOps is a significant commitment. The combination of culture and technology is essential, noted Weichel. As we infuse security testing into CI/CD pipelines and make everything security-first, he said, we indeed undergo a cultural shift—it’s something that permeates everything.

Challenges in Implementation
Companies attempting to introduce DevSecOps may run into a few challenges, including instilling the culture, implementing regulatory compliance and finding the right blend of open source and propriety tools to get the job done.

Bosh is no stranger to sluggish enterprises and the systemic change required to introduce DevSecOps. In these environments, changing companywide antiquated processes may require executive sponsorship. “By and large, it’s mostly culture,” he said, yet acknowledged a vast divide between the two groups: “How do you convince security do get out of their comfort zone? And how do you convince developers to get out of theirs?”

There is also developer experience to consider: Developers often view security tools as limiting their ability to deliver code quickly. Perhaps the biggest challenge to overcome is improving the experience of working alongside new security policies. If new practices are causing more pain, instead of automating pain points away, DevSecOps could suffer.

Outside of team dynamics, there are also technical hurdles involved when introducing and enforcing legal regulatory requirements. “Getting any sort of compliance baked into CI/CD pipelines is a challenge,” said Fox. Part of the problem is that the tooling to enforce such requirements isn’t there yet. “Cloud-native is continually evolving and security is constantly playing catch up,” she noted. “It’s an ongoing challenge.”

Incentivizing the DevSecOps Culture
Employees need incentives to change established habits. With the above challenges in mind, how can organizations create incentives to adopt DevSecOps? Well, outside of monetary incentives or straight up demanding it, incentivizing that security culture could happen in a few different ways, the panelists noted.

To Fox, it’s about “making security transparent to the developers.” You want developers to quickly build and deploy secure applications without the need for intensive cybersecurity training. Thus, the tools and processes must be as transparent and usable as possible. DevSecOps is possible “if you make it second nature,” she said.

Another way to consider DevSecOps culture is the end performance. If customers are happy, this is a positive gauge. James said he has witnessed CIOs at a few organizations using customer satisfaction scores as a guiding light for not only the business but for security effectiveness well.

Bosch similarly stressed an indirect incentive about overall company performance. “Companies that really embrace DevSecOps leads to better code,” said Bosch. This leads to more robustness, higher speed, and better-operating enterprises. Co-building a thriving success could be ample incentive alone for those who have the whole team in mind.