A moving target is hard to hit. And fast-moving-targets are even harder to hit. And still harder are targets that are fast-moving and small. It should come as no surprise then, that a small, fast-moving target would be a great security model to use if it could be made to work for machines in the cloud.

Once upon a time, security models for digital data and computing resources were based on strong perimeter defenses. And the model worked pretty well when enterprises operated with on-premises data centers where security was placed at the perimeter and systems monitored the digital traffic that came in and out of the data center. Tools like firewalls and gateways were effective and administrators were physically present.

Today, because of digital transformation, enterprises are replacing legacy on-premises data centers with the “cloud'' to improve business performance and gain competitive advantages. This brings new security challenges from new technologies (containers) and architectures (microservices) that leverage the inherent speed and scale of the cloud. The evolution of software applications has also changed with Software-as-a-Service (SaaS) products and pricing models; feature upgrades and patches are automated with minimal human intervention.

The cloud holds tremendous promise for enterprises, but along with it are new and ever evolving challenges to secure sensitive data and information. In the cloud there are many more non-human entities (‘machines’) that operate as “workloads” inside “containers” and use application programming interfaces (APIs) to exchange data with other workloads. In addition, SaaS applications include dependencies on third-party services such as a payment service or open source software, which introduce risks and increase vulnerabilities. Before the cloud, it was easier to protect enterprise resources, but as the perimeter disappears through digital transformation, the complexity of the cloud opens up a new world of vulnerabilities that allow adversaries to reach enterprise services and data. 

Understanding the Cloud

To understand a moving-target defense, let's look at the cloud using a three dimensional model consisting of a physical dimension, a logical/abstract dimension, and a functional dimension. There are no clean boundaries between these dimensions. A lot of different industries (e.g., telecom), protocols (e.g., HTTP), and standards make up the cloud to ensure its smooth continuous global operation. It’s pretty amazing to think that it all started with just a few simple inventions like the telephone, wireless, and the transistor.

Cybersecurity and the Cloud

The Internet was built for sharing data between computers in different Geographic locations. The keyword there is sharing. There wasn’t much thought to someone with adversarial intentions inserting themselves Into the operation and stealing and misusing the data. 

‍

Today we know how big a problem that is. Intruders can be on the other side of the world and access data from a single home computer connected to the Internet, or control the temperature in your home or the locks on your door. Because technology is constantly changing and new innovations and capabilities appear in the cloud continually, there are always a new variety of vulnerabilities for adversaries to exploit. There is no such thing as perfect cyber security. It is an evolving specialty that can be very technical and very challenging. Adversaries are highly skilled and have an advantage of time and anonymity. 

Goons Inside the Fence

“Goons inside the fence” is a military phrase used by security forces protecting a base near the front lines. It was used to describe when a hostile force (“Goons”) had broken through the perimeter defense and was inside the fort or base. In December 2020, we discovered that cyber Goons were inside certain cloud boundaries that we thought were secure. The Solarwinds hack (also known as “Sunburst”) changed our confidence in cloud perimeter security. The security breach put a spotlight on the software supply chain and rippled through the cloud to impact many large enterprises and government agencies across the globe. The hack revealed that skilled and persistent adversaries can bypass even the best perimeter security tools and operate inside business networks without detection.

‍

Today, the operating premise must assume perimeter security has been breached and adversaries are probably already inside the perimeter defense of most enterprises. If your systems are connected to the Internet, regardless of whether they are on-premises or in the cloud, you have 100% exposure to attack. And in the Solarwinds hack, we know the adversaries were undetected and working inside the network for months before they launched their attack. This is not unusual, a 2022 study found that it takes an average of 212 days for an enterprise to detect a security breach.

‍

The Sunburst hack led to the concept of a “zero trust” operating posture. In other words, you could no longer assume your network perimeter was secure. Instead, you must assume that adversaries are already inside your systems. It means that even internal systems, applications, and services under your control should not be trusted. Trust and access control to any of these would have to be verified at a very granular level each time they interacted with each other. The zero trust paradigm is like having a lock on every door in your house (each with a different key) no matter where it was or what was behind it. You could no longer trust the lock on your front door to keep an intruder out.

Six Steps to a Moving-Target Defense in the Cloud

Marketing hype has over-used the term “Zero Trust,” but it’s still a valuable operating principle and achievable in a practical way. The best way is to always be one step ahead of the attacker. A good strategy is to know what the adversary is after and move it faster than they could find it. It’s been reported that 90% of an adversary’s time is spent planning and only 10% in conducting the actual attack. Frequently moving the target (what they need to execute an attack) keeps them from launching the attack. Here are six steps that Hopr uses to establish a moving-target defense in the cloud.

Step 1: Shrink the Perimeter

As mentioned earlier, the security perimeter in the cloud is difficult to define. The figure below depicts various physical and logical entities of the cloud. As the entities get smaller, they grow in number, but their individual perimeter and “attack surface” also shrinks. The smallest entity is a container that holds the ‘workload’ such as a microservice. Shrinking the perimeter to the smallest entity within the cloud (containers) offers the advantage of a well-defined and defensible perimeter. And many small perimeters makes it challenging for adversaries because they have additional work to do to find and target the one to attack. 

‍

But shrinking the perimeter to a container is not enough, because at least two containers (workloads) are involved in cloud data transactions. The perimeter needs to shrink to the size of at least two containers and also include the communication route between them. A moving-target defense must fit the operating perimeter if it is to protect running workloads data exchanges between them.

Step 2: Adapt the Perimeter

Although the adoption of microservices and APIs increases concerns with the “attack surface” that is exposed to adversaries, a large number of microservices and APIs can also become an advantage in a moving-target defense when the operating security perimeter is dynamically changing with the running workloads as they exchange data in a “session” (a series of API calls and responses). The second step of a moving-target defense is to autonomously adapt the security perimeter so that it includes only the running workloads. Operating perimeters are dynamic and automatically align with the two workloads involved in a data transaction, such as a cloud microservice (client) and an API (server). 

Step 3: Include the Connection

The next piece of the moving-target defensive strategy is to include the connection (the communication route) between the two running workloads. This is usually done with Public Key Infrastructure (PKI) certificates and Transport Layer Security (TLS). But like everything else that changes when moving from on-premises operations to the cloud, these security protocols aren’t working as well as they once did. A 2021 study by the Ponemon Institute reported that 55% of security professionals surveyed believed that PKI was incapable of supporting new applications (e.g., cloud applications such as mobile devices and IoT). 

‍

End-to-end encryption (E2EE) is a technology widely recognized in digital human communications with applications such as What’s App (Facebook), Signal, and Telegram. E2EE encrypts message traffic over the entire route between endpoints regardless of the presence of TLS or not. Step three of a moving-target defensive strategy is to apply E2EE and protect the data exchange between two running workloads. E2EE is essential to integrate the communication route into the perimeter defense (see the figure above - the blue lines illustrate the perimeter). E2EE is further discussed in Step 5.

Step 4: Move the Target

Once the perimeter is defined, it’s time to discuss how to move the target. Adversaries operating inside a cloud environment must use the communication routes between containers to access the workloads in the same way that legitimate activity among containers occurs. The routes are determined by specifying the IP address and Port, which are easy to discover. However, in the cloud, they’re not entirely reliable because entities (mobile device apps, IoT devices) often appear and disappear from the cloud and their IP addresses are transient and re-used. But it is not too difficult for adversaries to identify workload endpoints.

‍

With the right location, all the adversary needs at this point for their attack is to get access to credentials. Unfortunately, this is easy, too. Gartner reports that three of the top four vulnerability paths for APIs involve credential theft. API credentials are usually static, easy to find (sniff), identifiable (they are a long string of random characters), and easily exfiltrated without detection by skilled adversaries. In fact, API “keys” really aren’t a security feature as their name might suggest; they’re used by APIs as an identity credential to associate requests with authorized access.

‍

Since the adversary’s target is credentials, then ephemeral credentials are a good way to protect the access through the defensive perimeter. Step four of our moving-target defense is to use ephemeral credentials that are short-lived and vanish when they expire. Ideally, they would expire quickly to prevent an adversary from finding and using them, and be automatically replaced as needed. 

‍

Access through the operating security perimeter of our moving target defense (Step 2 above) can only occur at two points: the App and the API, so there are only two pairs of credentials that need to move quickly for a moving-target defense in the cloud. But the moving credentials must be immediately available to trusted authorized workloads and no others. An autonomous mechanism is needed to simultaneously replace the credentials for two machines at a high frequency and ensure they are never exposed to theft. 

Step 5: Re-purpose the Secret Credential

Authentication is the traditional use of a “secret” credential when it exists for an entity. That's the reason why credentials are attractive targets. Authentication is a simple process, but it involves passing the secret to a workload and the receiving workload matching it to their “authentic” copy. As presented in Steps 1 through 4, this would be nearly impossible in real-time cloud operation because of the difficulty of getting the secret through the operating security perimeter and to both workloads. Our solution is to re-purpose the ephemeral secret credential so that it is not used for authentication, but instead it becomes the key for the E2EE as mentioned in Step 3. With E2EE the secret credential never leaves the workload and would never be exposed outside the workload. So to fully protect running services, both workloads must possess the identical ephemeral secret

Step 6: Build Identical Secrets Where They Are Used

The final step in our moving-target defensive strategy is to “build” the secret credential where it is used. Usually, secrets are built by a separate service and then stored in a secure place for retrieval or injected into a workload where authentication would occur (in a future API call). But a better approach is building an ephemeral symmetric secret at each running workload and using them for E2EE as described in Step 5. The trick is how to build identical secrets in two different workloads at the same time?  This is solved by using a special algorithm that both workloads would possess.

‍

The special algorithm would run with each workload within the security perimeter and it would produce an identical symmetric secret (key) to encrypt their messages. The special algorithm is the key component on which the entire moving-target defense operates. Fortunately, making the special algorithms is where Hopr technology excels.

Closing Thoughts

A moving-target defense is a wonderful thing when traditional perimeter defenses cannot be assured and adversaries with advantages such as anonymity, access, and skill are inside your perimeter. But that doesn’t mean that adversaries should benefit from their advantage of time. A moving-target defense built on autonomous high frequency credential rotation eliminates their time advantage and keeps them from ever obtaining the target (credentials) they need to launch an attack on enterprise resources. Zero-trust is possible with a moving-target defense, but it must start with the identity of a cloud entity early in its lifecycle (when it receives its special algorithm) and then using that algorithm to maintain the trust throughout its life.

‍